Utveckling inom Augmented Reality med Unity

(1)

Linköpings universitet | Institutionen för datavetenskap Kandidatrapport, 15 hp | Civilingenjör i datateknik/mjukvaruteknik Vårterminen 2016 | LIUIDA/LITHEXG16/033—SE

Utveckling inom Augmented

Reality med Unity

____________________________________________________________

Development

in Augmented Reality with Unity

Daniel Björnander, Måns Gezelius, Emil Gustafsson,

Raymond Leow, Joakim Lidstedt, Ludvig Noring,

Nils Petersson, Jonatan Pålsson och Mikael Ångman

Handledare: Jonas Wallgren Examinator: Kristian Sandahl

Linköpings universitet SE581 83 Linköping 01328 10 00, www.liu.se

(2)

(3)

Syftet med den här rapporten är att behandla frågeställningar utifrån projektet, vars mål är att utveckla ett Augmented Reality-ramverk för att skapa värde för en kund, BioOptico.

Punkter som programmeringsmiljön Unitys lämplighet vid utveckling av mobila AR-applikationer, hur BioVision kan implementeras så att det ger värde för BioOptico, vilka erfarenheter som kan dokumenteras efter arbetet med projektet och vilket stöd SEMAT Kernel ALPHA ger för det här

projektet behandlas i den här rapporten.

För att besvara dessa frågor används verktygen Unity och SEMAT Kernel ALPHA state cards under utvecklingen av BioVision. Genom agil utveckling och framtagning av tidiga prototyper undersöks vilka implementationssätt som ger värde för BioOptico och vilken dokumentation av

erfarenheter som kan vara intressant för framtida projekt.

Som resultat dokumenteras de områden där Unity lämpar sig väl för utveckling av mobila AR-applikationer, vilka de viktigaste beståndsdelarna var för hur BioVision implementerades så

att det ger värde för BioOptico och vilka erfarenheter och vilket stöd som ges av utveckling av BioVision respektive användning av SEMAT Kernel ALPHA:s.

Som slutsats ses Unity som en lämplig utvecklingsmiljö för utveckling av AR-applikationer, medan SEMAT Kernel ALPHA kan vara användbart, dock överflödigt, vid utveckling av BioVision. De viktigaste lärdomarna att ta med sig från projektet är att planera, utveckla och dokumentera i god

tid. Slutligen dras slutsatsen om att strukturen på projektet och inte bara produkten som skapas spelar en stor roll för hur applikationen kan ge värde för BioOptico.

(4)

Innehåll

Del I 1 1 Inledning 3 1.1 Syfte . . . 3 1.2 Frågeställningar . . . 3 1.3 Avgränsningar . . . 3 1.4 Juridisk anmärkning . . . 3 2 Bakgrund 4 2.1 BioOpticos motivation för systemet . . . 4

2.2 Gruppens bakgrund . . . 4

2.3 Gruppens tidigare erfarenheter . . . 4

3 Teori 6 3.1 Augmented reality . . . 6

3.2 Användningsområden för AR . . . 6

3.3 SEMAT Kernel ALPHA . . . 7

3.4 Virtual reality . . . 7

3.5 Verktyg . . . 8

3.5.1 Samsung Gear VR . . . 8

3.5.2 LaTeX och ShareLaTeX . . . 8

3.5.3 Git och Gitlab . . . 8

3.5.4 Slack . . . 9 3.5.5 Chromecast . . . 9 3.5.6 Utvecklingsmiljöer . . . 9 3.6 Systemutvecklingsmetoder . . . 10 3.6.1 Scrum . . . 10 3.6.2 Kanban . . . 10 3.6.3 Extreme Programming . . . 11 3.6.4 Vattenfallsmodellen . . . 12 3.7 Ordlista . . . 12 4 Metod 14 4.1 Frågeställning 1: Utveckling i Unity . . . 14

4.1.1 Utvecklingen av BioVision . . . 14

(5)

4.2 Frågeställning 2: Värde för kunden . . . 14

4.2.2 Andra aktiviteter . . . 16

4.3 Frågeställning 3: Dokumentering av erfarenheter . . . 17

4.3.1 Reflektionsmöten . . . 17

4.3.2 Seminarier . . . 18

4.3.3 Dokumentarbete . . . 18

4.4 Frågeställning 4: SEMAT Kernel ALPHA . . . 18

4.4.2 Dokumentarbete . . . 19

5 Resultat 20 5.1 Frågeställning 1: Utveckling i Unity . . . 20

5.1.2 Jämförelse med andra utvecklingsmiljöer . . . 20

5.2.2 Kundkontakt . . . 22

5.2.3 Demonstrationer för BioOptico . . . 22

5.2.4 Kravspecifikation . . . 23

5.2.5 Andra aktiviteter . . . 23

5.5 Översikt av de individuella bidragen . . . 25

6 Diskussion 26 6.1 Frågeställning 1: Utveckling i Unity . . . 26

6.1.2 Jämförelse med andra utvecklingsmiljöer . . . 26

6.2.1 Iterationsstruktur . . . 26

6.2.2 Kundkontakt . . . 27

6.2.3 Systemutvecklingsmetoder . . . 27

6.5 Samhälleliga aspekter . . . 29

(6)

6.5.2 Augmented reality . . . 29 6.6 Miljöaspekter . . . 30 6.7 Etiska aspekter . . . 31 6.8 Källkritik . . . 31 7 Slutsats 33 Del II 35 A Daniel Björnander - Ingenjörens etiska ansvar till sin omvärld 37 A.1 Inledning . . . 37

A.1.1 Syfte . . . 37

A.1.2 Frågeställning . . . 37

A.2 Bakgrund . . . 37

A.3 Teori . . . 37

A.3.1 Etik och moral . . . 38

A.3.2 Metaetik . . . 38

A.3.3 Normativ etik . . . 38

A.3.4 Tillämpad etik . . . 39

A.3.5 Utilitarism . . . 40 A.3.6 Kantianism . . . 41 A.3.7 Aristotelism . . . 42 A.4 Avgränsningar . . . 43 A.5 Metod . . . 44 A.6 Resultat . . . 44

A.6.1 Frågeställningen ur utilitaristiskt perspektiv . . . 44

A.6.2 Frågeställningen ur kantianskt perspektiv . . . 44

A.6.3 Frågeställningen ur aristoteliskt perspektiv . . . 45

A.7 Diskussion . . . 46

A.8 Slutsats . . . 46

B Måns Gezelius - Konsumentvänlig utveckling inom AR 47 B.1 Inledning . . . 47 B.1.1 Syfte . . . 47 B.1.2 Frågeställning . . . 47 B.2 Bakgrund . . . 47 B.3 Teori . . . 47 B.3.1 Augmented reality . . . 47

(7)

B.3.2 Konsumentvänlighet inom mjukvaruområdet . . . 48 B.4 Metod . . . 49 B.5 Resultat . . . 49 B.5.1 BioVision . . . 50 B.6 Diskussion . . . 50 B.6.1 Google Glass . . . 51 B.6.2 BioVision . . . 51 B.7 Slutsats . . . 51

C Emil Gustafsson - VR-beroende 53 C.1 Inledning . . . 53 C.1.1 Syfte . . . 53 C.1.2 Frågeställning . . . 53 C.1.3 Avgränsningar . . . 53 C.2 Bakgrund . . . 53 C.2.1 Virtuell verklighet . . . 53 C.2.2 Datorspelsberoende . . . 54 C.3 Teori . . . 55 C.3.1 Virtual reality . . . 55 C.3.2 VR-hjälm . . . 55 C.3.3 Beroende . . . 55

C.3.4 Datorspelberoende eller spelberoende? . . . 56

C.4 Metod . . . 56

C.5 Resultat . . . 56

C.6 Diskussion . . . 56

C.7 Slutsats . . . 57

D Raymond Leow - Undersökning av testning av AR-system enligt standarden IEEE Std 829-2008 59 D.1 Inledning . . . 59 D.1.1 Syfte . . . 59 D.1.2 Frågeställning . . . 59 D.1.3 Avgränsningar . . . 59 D.2 Bakgrund . . . 59 D.3 Teori . . . 60 D.3.1 Augmented Reality . . . 60 D.3.2 Testning . . . 60 D.3.3 IEEE Std 829-2008 . . . 60

(8)

D.3.4 Unity . . . 61

D.3.5 Git issue tracker . . . 61

D.4 Metod . . . 62 D.4.1 Interna källor . . . 62 D.4.2 Externa källor . . . 62 D.5 Resultat . . . 62 D.5.1 Interna källor . . . 62 D.5.2 Externa källor . . . 63 D.6 Diskussion . . . 63 D.7 Slutsats . . . 64

E Joakim Lidstedt - Hälsorisker vid användning av VR-hjälm 65 E.1 Inledning . . . 65 E.1.1 Syfte . . . 65 E.1.2 Frågeställning . . . 65 E.1.3 Avgränsningar . . . 65 E.2 Bakgrund . . . 65 E.3 Teori . . . 65 E.3.1 Balanssinnet . . . 65 E.3.2 Informationskonflikt . . . 66 E.3.3 Symptom . . . 66

E.3.4 Cyber sickness . . . 66

E.4 Metod . . . 67

E.4.1 Simulator Sickness Questionnaire . . . 67

E.4.2 Genomförande . . . 68 E.5 Resultat . . . 68 E.6 Diskussion . . . 68 E.7 Slutsats . . . 69 F Ludvig Noring - UX i AR 71 F.1 Inledning . . . 71 F.1.1 Syfte . . . 71 F.1.2 Frågeställning . . . 71 F.1.3 Avgränsning . . . 71 F.2 Bakgrund . . . 71 F.2.1 Virtual Realtiy . . . 71 F.2.2 UX och GUI . . . 71

(9)

F.3 Teori . . . 72 F.3.1 Augmented reality . . . 72 F.3.2 VR-hjälm . . . 72 F.3.3 UX . . . 72 F.4 Metod . . . 73 F.4.1 Användartest . . . 73 F.5 Resultat . . . 73 F.5.1 Användartest . . . 73 F.6 Diskussion . . . 74 F.6.1 Användartest . . . 74 F.7 Slutsats . . . 75

G Nils Petersson - Undersökning av mjukvarukvalitet 77 G.1 Inledning . . . 77 G.1.1 Syfte . . . 77 G.1.2 Frågeställning . . . 77 G.2 Bakgrund . . . 77 G.3 Teori . . . 77 G.3.1 IEEE 730 . . . 77 G.3.2 ISO 9126 . . . 77 G.4 Metod . . . 78 G.4.1 Kvalitetsplan . . . 78 G.4.2 Kodstandard . . . 78 G.4.3 Kvalitetstester . . . 78 G.4.4 Kvalitetsfaktorer . . . 78 G.5 Resultat . . . 79 G.6 Diskussion . . . 79 G.6.1 Metod . . . 79 G.6.2 Resultat . . . 80 G.7 Slutsats . . . 80

H Jonatan Pålsson - Gruppstorlekens påverkan på mjukvaruprojekt 81 H.1 Inledning . . . 81

H.1.1 Syfte . . . 81

H.1.2 Frågeställning . . . 81

H.1.3 Avgränsningar . . . 81

(10)

H.3 Teori . . . 81 H.3.1 Scrum . . . 82 H.3.2 Slack . . . 82 H.4 Metod . . . 82 H.4.1 Kommunikation . . . 82 H.4.2 Produktivitet . . . 82 H.4.3 Gruppdynamik . . . 82 H.5 Resultat . . . 83 H.5.1 Kommunikation . . . 83 H.5.2 Produktivitet . . . 83 H.5.3 Gruppdynamik . . . 83 H.6 Diskussion . . . 84 H.7 Slutsats . . . 84

I Mikael Ångman - Undersökning av några versionshanteringsstrategier 85 I.1 Inledning . . . 85 I.1.1 Syfte . . . 85 I.1.2 Frågeställning . . . 85 I.1.3 Avgränsningar . . . 85 I.2 Bakgrund . . . 85 I.3 Teori . . . 86 I.3.1 Release . . . 86 I.3.2 Commit . . . 86

I.3.3 Feature-driven branching . . . 86

I.3.4 Versions-driven branching . . . 87

I.3.5 Konservativ branching . . . 87

I.3.6 Andra versionshanteringsverktyg . . . 87

I.3.7 Unity . . . 87

I.4 Metod . . . 88

I.4.1 Iteration 1: Feature-driven branching . . . 88

I.4.2 Iteration 2: Semi-Konservativ branching . . . 88

I.4.3 Iteration 3: Fri strategi . . . 88

I.5 Resultat . . . 88

I.5.1 Iteration 1: Feature-driven branching . . . 88

I.5.2 Iteration 2: Semi-Konservativ branching . . . 89

I.5.3 Iteration 3: Fri strategi . . . 89

(11)

I.6.1 Iteration 1: Nytt och spännande . . . 89

I.6.2 Iteration 2: Anpassning och vana . . . 89

I.6.3 Iteration 3: Erfarenhet och självstyre . . . 90

I.6.4 Exempel på hur andra projekt gjort . . . 90

I.7 Slutsats . . . 90

I.8 Källkritik . . . 90

Referenser 91

Figurer

1 Exempelområden på Augmented reality . . . 6

2 SEMAT ALPHA state cards från The Essence of Software Engineering: The SEMAT Kernel . . . 8

3 Förenklat flödesschema för hur Scrum fungerar . . . 11

4 Exempel på en ”Kanban board” . . . 12

5 Flödesschema för de olika faserna i vattenfallsmodellen . . . 13

6 Uppdelning av de olika faserna i projektarbetet . . . 15

7 Checklista över funktionella krav som bör uppfyllas . . . 16

8 Exempel på planerade tillstånd av SEMAT ALPHA state cards, från Essence Kernel 19 9 Två exempel på filterbehandling i BioVision . . . 20

10 Menyelement för justering av filterinställningar . . . 21

11 Behandling av skärmbild och skärmdelning . . . 22

12 Tillstånd placerade efter iteration, taget från ALPHA state cards . . . 25

13 Via en översättningsapp kan text översättas och presenteras på ett lättläst sätt. . . 30

14 Videoplace, Myron Krueger . . . 47

15 Applikationen ViewAR, Butlers . . . 48

16 BioVisions grafiska hjälpgränssnitt som visar vilka handlingar som går att utföra . 50 17 Sammanställning av enkätundersökningen . . . 68

18 SSQ-resultatet av enkätundersökningen . . . 69

19 Lösningar på problem upptäckta under användartestet. . . 75

20 Exempel på feature-driven branching . . . 87

Tabeller

1 Jämförelse under varje iteration av vilka ALPHA:s gruppen anser sig ha uppnått (av vad som planerades från början) . . . 24

2 Testdokument som skrivs under kandidatarbetet och som bör skrivas enligt IEEE Std. 829-2008 . . . 63

(12)

(13)

Del I

(14)

(15)

1 Inledning

”Augmented reality” (AR) är en beskrivning av principen att blanda verkligheten med virtuell information från en mjukvaruapplikation i realtid. AR-teknologin är en snabbt växande teknologi, och allt fler visar större intresse för AR-applikationer. Den här rapporten kommer främst att fokusera på frågeställningar relaterade till utveckling inom AR, men även på sådana kopplade till mer generell mjukvaruutveckling.

Den här rapporten skrivs i samband med utvecklingen av gruppens egen applikation, BioVision — en AR-applikation för filterbehanding i realtid. Applikationen körs på en smarttelefon som är parkopplad med en Gear VR-hjälm, vilket tillåter användaren att ”se” verkligheten genom kameran.

Projektets gruppmedlemmar består av nio studenter vid Linköpings universitet som studerar på civilingenjörsutbildningar inom data- och mjukvaruteknik.

1.1 Syfte

Syftet med rapporten är att granska alla delar av projektet samt analysera och diskutera rapportens frågeställningar (se avsnitt 1.2). Rapporten speglar även varje gruppmedlems egna arbete och tankar runt projektet. Det görs i delen för individuella rapporter.

Det övergripande syftet med projektet är att studenterna i gruppen skall få erfarenhet av organi-serat projektarbete mot en kund och att individuellt utveckla de tekniska och sociala färdigheter som den här typen av arbete kräver. Projektet är utformat på så sätt att gruppen tvingas kon-frontera de viktiga problem inom mjukvaruutveckling som uppstår i arbetslivet. Projektets mål är att utveckla en mjukvaruprodukt med värde för kunden.

1.2 Frågeställningar

Denna rapport behandlar följande frågeställningar:

• Hur väl lämpar sig programmeringsmiljön Unity för utveckling av mobila Augumented reality-applikationer?

• Hur kan applikationen BioVision implementeras så att den ger värde för BioOptico? • Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intressanta för

framtida projekt?

• Vilket stöd kan man få genom att använda och följa upp SEMAT Kernel ALPHA:s?

1.3 Avgränsningar

Rapporten behandlar endast utveckling för Samsung Gear VR och behandlar inte andra VR-plattformar. Projektet som utförs i samband med skrivandet av rapporten omfattar 3600 timmar under vårterminen 2016, inräknat i tiden är utvecklingen av BioVision och skrivandet av samtliga dokument.

1.4 Juridisk anmärkning

Av immaterialrättsliga skäl innehåller den här rapporten inga detaljer om beräkningarna i BioOp-ticos filter.

(16)

2 Bakgrund

Projektet görs på beställning av företaget BioOptico. BioOptico är ett företag i Linköping som sedan tidigare har erfarenhet av AR-användning inom endoskopi. Företaget önskar utforska nya plattformar för sin verksamhet, däribland smarttelefoner.

Augmented reality har länge varit dyrt att implementera och har krävt stor och otymplig hårdvara. Detta är ofta fortfarande fallet ute i industrin; exempel på detta är MRI-skanners på sjukhus och avancerad militär utrustning. Ett skifte till mer bärbara mindre produkter sker dock då produkter som Microsofts HoloLens och Oculus Rift utvecklas. De kommer att marknadsföras till relativt låga priser, men kommer trots detta troligen inte vara tillräckligt billiga för att klassas som något annat än dyra leksaker.

Smarttelefoner finns redan i stor omfattning hos privatpersoner och blir kraftfullare och mer pris-värda år för år. AR realiserad med smarttelefoner ger möjlighet till många olika fördelar för indivi-der och företag. Massproducerad AR-kompatibel hårdvara skulle medföra att bl.a. allmännyttiga institutioner som skolor, sjukhus, polis och brandkår på ett billigt sätt skulle kunna utrusta elever och anställda och på så sätt erbjuda ett nytt och kraftfullt verktyg.

2.1 BioOpticos motivation för systemet

BioOptico vill ha ett ramverk för att utveckla filter till en Android-miljö, och en Android-applikation att använda för demonstration av utvecklade filter.

BioOpticos tänkta användningsområde för produkten är att demonstrera filtrering av videoström-mar från telefonens kamera på mässor och dylikt, med mål att på ett kreativt sätt visa upp sitt arbete. Det innebär att de slutliga användarna av systemet är slumpmässigt valda personer som med stor sannolikhet aldrig tidigare har använt en Samsung Gear VR.

2.2 Gruppens bakgrund

Samtliga medlemmar i gruppen läser kursen ”TDDD96 Kandidatprojekt i programvaruutveckling” vilken går ut på att utveckla ett projekt för en kund. Den här rapporten baseras på utvecklingen av BioVision och kommer att presenteras som gruppens kandidatrapport. Innan arbetet började var gruppens medlemmar väldigt lockade av projektet eftersom AR och VR känns väldigt modernt. Många medlemmar har inte heller gjort en app tidigare vilket bidrog till entusiasmen.

2.3 Gruppens tidigare erfarenheter

Gruppens sammanlagda erfarenheter kommer från kurser på utbildningsprogrammen datateknik och mjukvaruteknik vid Linköpings universitet. Alla gruppmedlemmar läser sitt tredje år och har under sin utbildning arbetat med diverse projekt. Här är några exempel på kurser som varit kritiska för projektet:

• TDDC93 - Programutvecklingsmetodik

I den här kursen lärde sig samtliga medlemmar om hur agilt arbete genomförs och projekt-planering.

• TSEA29 - Konstruktion med mikrodatorer

I den här kursen lärde sig 7 av 9 personer om dokumentsskrivning, projektplanering och hur det är att arbeta i ett större projekt.

• TDDD80 Projekt: Mobila och sociala applikationer

(17)

(18)

3 Teori

I följande avsnitt förklaras de koncept som behövs för att lättare förstå de begrepp som rapporten behandlar. Det inkluderar även ett avsnitt om de verktyg som används för att fullfölja projektar-betet.

3.1 Augmented reality

Augmented reality (AR) är en teknik för att skapa en bild av verkligheten, där utvalda element förstärks eller tas fram med hjälp av en dator. Tanken är att datorn skapar bilden med hjälp av analys av till exempel ett fotografi, en kontinuerlig videoström, ljud eller GPS, vilket sedan förmedlas till användaren för att ge ett förändrat eller förstärkt intryck av verkligheten. Exempel på användning av AR kan ses i figur 1.

Augmented reality förknippas vanligtvis med realtidsbehandling där systemet används kontinu-erligt. Genom att digitalisera verkligheten skapas möjligheten att interagera och manipulera den skapade världen samt visualisera data som inte är direkt synliga, till exempel ljusspektrum eller olika ytors värme (förutsatt att hårdvara som klarar av detta används) [1].

Figur 1: Exempelområden på Augmented reality

3.2 Användningsområden för AR

Augmented reality är ett snabbt växande område med många tillämpningar. Inom arkitektur och konstruktion används AR för att skapa digitala representationer av byggnader som på det viset kan förhandsgranskas innan bygget är färdigt. Inom det militära används det för virtuella kartor och simuleringar. Inom medicin används det för att skapa videofilter som analyserar hud och detekterar blodådror, visar patientinformation eller blodtryck och hjärtslag [2]. I många sammanhang ger AR ett intuitivt sätt att visa upp information i ett grafiskt gränssnitt placerat framför ögonen.

Ett företag som utvecklade inom AR är Google med produkten Google Glass. Deras lösning är rea-liserad med en skärm framför ett öga och är tänkt att användas i vardagen, till exempel genom att visa upp GPS-direktiv på skärmen. Microsofts senaste framsteg inom AR-teknologin är produkten HoloLens: ett genomskinligt headset som visar upp holografiska bilder samt tillåter användaren att interagera med hologram genom gester. [3]

På den mer konsumentvänliga marknaden för privatpersoner, där prisvärdhet är en viktigare de-signfaktor, är en av de vanligaste lösningarna handhållen AR i form av smartphone-applikationer. Filterapplicering på fotografier och direkt textöversättning via kameran är exempel på vardaglig

(19)

AR-funktionalitet som erbjuds av vissa applikationer. För hjälm-driven AR med en parkopplad smartphone finns ett fåtal kompatibla spel och applikationer.

3.3 SEMAT Kernel ALPHA

Software Engineering Method and Theory (SEMAT) är en standard som grundades 2009 av Ivar Jacobsson, Bertrand Meyer och Richard Soley. Standarden brukar även gå under namnet Essence [4]. SEMAT Kernel är en yttring av SEMAT-standarden och möjliggör jämförelser, appliceringar och förbättringar av programutvecklingsmetoder med ett och samma språk. Oavsett hur storskaligt eller väldokumenterat projektet är ska denna yttring fortfarande kunna vara applicerbar.

Abstract-Level Progress Health Attribute (ALPHA) är en indiktator som belyser de tillstånd som är de viktigaste för projektgrupper att använda och följa upp [4]. Utifrån SEMAT Kernel-yttringen representeras dess indikatorer som en kompromiss av de viktiga beståndpunkterna från alla pro-gramvarumetoder. De olika SEMAT Kernel ALPHA:s blir som checklistor av olika kategorier med tillhörande tillstånd. Tillstånden har i sig specifika krav som bör uppnås. De olika kategorierna som dessa checklistor och indikatorer går under, är följande:

• ”Requirements” innehåller tillstånd som beskriver hur systemet som ska byggas uppfyller de krav kunden har satt på systemet.

• ”Software System” är de tillstånd i livscykeln som mjukvarusystemet ska inta, bland annat om den är användbar, redo att användas eller om systemet ej används längre.

• ”Stakeholders” är de tillstånd där intressenter står i fokus, om hur de är involverade och hur systemet som byggs möter deras förväntningar.

• ”Opportunity” framhäver hur det givna systemet kan vara en lösning och kan produceras utifrån en kommersiell eller social möjlighet eller en affärsmöjlighet. Där gäller de situationer där behovet och värdet på produkten sätts in.

• ”Team” är den gemensamma ALPHA för hur projektteamets samarbete och projektarbete fungerar. Jobbar teamet effektivt?

• ”Work” innehåller tillstånd som beskriver hur väl själva arbetet går. Tillstånden kan exempel-vis handla om hur alla krav måste vara uppfyllda för att själva projektarbetet får påbörjas, eller om funktionaliteter som producerats under projektarbetet samt om de är kvalitativa nog att ingå i den slutgiltiga produkten.

• ”Way of Working” är de tillstånd där tillvägagångssätten för att fullfölja projektarbetet veri-fieras. Ett exempel på tillstånd är om de viktigaste tillvägagångssätten (nyckelmetoder och nyckelverktyg) är valda och används. Ett annat tillstånd är om tillvägagångssätten fungerar bra med projektgruppen.

Projektgruppen kan identifiera projektets tillstånd utifrån dessa SEMAT Kernel ALPHA:s och på så sätt hålla koll på var i livscykeln projektet befinner sig och vilka tillstånd som behöver uppnås när [4]. SEMAT ALPHA state cards representerar dessa tillstånd med fysiska kort som projektgruppen kan ta del av för att hålla koll på deras utveckling [5]. Några av de kort som används kan ses i figur 2. [6]

3.4 Virtual reality

Virtual reality (VR) är en tredimensionell, datorgenerad miljö. Personen som befinner sig i en VR-miljö kan interagera med, ta del av och utföra aktivteter i den virtuella världen. [7]

(20)

Figur 2: SEMAT ALPHA state cards från The Essence of Software Engineering: The SEMAT Kernel

3.5 Verktyg

För att förstå tillvägagångssättet vid behandling av rapportens frågeställningar ges även beskriv-ningar av de verktyg som används för utveckling av BioVision.

3.5.1 Samsung Gear VR

Samsung Gear VR, som även kort kallas för en ”VR-hjälm”, är en utrustning där man kopplar in en Samsung Galaxy-telefon1_{. Hjälmens konstruktion utnyttjar telefonens skärm och beräkningskraft}

för att generera AR- och VR-upplevelser. [8]

3.5.2 LaTeX och ShareLaTeX

LaTeX är ett typsättningssystem för dokument [9]. ShareLaTeX är en textredigerare för LaTeX. Det som gör ShareLaTeX unik är att det tillåter realtidsutveckling av dokument där flera användare kan redigera samma LaTeX-dokument samtidigt. Dessutom är det möjligt att kompilera de olika filerna till kompletta, läsbara dokument online. [10]

3.5.3 Git och Gitlab

Git är ett distribuerat versionshanteringssystem för alla stora operativsystem [11]. Via Git versions-hanteras källkoden i så kallade repositorys eller Git-repo:n, vilka sedan lagras lokalt på utvecklarens dator. I ett Git-repo sparas alla versioner av källkod som utvecklats, vilket ger utvecklaren tillgång till tidigare versioner.

GitLab är en tjänst som tillåter flera personer att arbeta mot samma Git-repo genom att synkro-nisera dem via en GitLab-server [11]. Linköpings universitets institution för datavetenskap (IDA) erbjuder en GitLab-server som används under projektets gång.

(21)

3.5.4 Slack

Slack är ett kommunikationsverktyg som strukturerar gruppkonversationer [12]. Därmed kan det skapas kanaler utifrån projekt, ämne, team eller vad som helst. Det kan dessutom skapas privata kanaler som ger möjlighet till att skicka direktmeddelanden. Förutom det har verktyget fildel-ningsfunktionalitet. Slack erbjuder även stöd för integration med andra verktyg, t.ex. Git där programmet kan skicka ett meddelande på Slack varje gång någonting händer på Gitlab-servern.

3.5.5 Chromecast

Chromecast är Googles egna medieströmningsenhet [13]. Den används för att sända live, som också kallas att ”casta”, olika sorters underhållningsmedier från en mobilenhet till enheten du vill skärmdela till osv.

3.5.6 Utvecklingsmiljöer

Det finns flera olika utvecklingsmiljöer för Android-utveckling. Nedan listas de alternativ som projektgruppen överväger.

Unity Unity, utvecklat av Unity Technologies, är en spelmotor som har stöd för flera plattformar såsom iOS, Android och Microsoft Windows. Genom att använda Unitys redigerare har spelmo-torn även funktionalitet för att utveckla VR- och AR-produkter. Det är inte möjligt att skriva programkod i Unity, utan detta görs för sig i en textredigerare, t.ex. MonoDevelop eller Visual Studio. [14]

MonoDevelop MonoDevelop är en utvecklingsmiljö som, förutom att vara en textredigerare, även har avlusning och andra administrativa funktionaliter. MonoDevelop har full support för integrering med Unity och kan därmed användas som Unitys externa skriptredigerare. [15]

Xcode Xcode är en IDE utvecklad av Apple. Xcode har stöd för ett flertal stora programspråk, däribland C, C++, Objective-C, Java, Python, Ruby, och Swift. Utvecklingsmiljön kan bland annat användas för att utveckla applikationer till Apples egna hårdvara, däribland enheter som iPhone, iPad och Mac. Eftersom Xcode stödjer programutveckling i Java så är det möjligt att utveckla Javaprogram i Xcode, men IDE:n kan inte kompilera dessa applikationer för att köras på Android-enheter. Det måste göras separat i en terminal. Något inbyggt stöd för Samsung Gear VR finns därför inte. Xcode ger inte heller användaren möjligheten att skapa grafiska gränssnitt till Android-enheter. [16]

Xamarin for Visual Studio Xamarin är ett ramverk utvecklat av samma team som står bakom Mono och MonoDevelop. Ramverket används för att kunna skriva en gemensam kodbas som kan kompileras till både iOS, Windows Phone och Android-enheter. I början av 2016 köpte Microsoft upp Xamarin och implementerade ramverket i sin egna IDE Visual Studio. Det innebär att det nu är möjligt att utveckla Android-applikationer i Visual Studio. Xamarin for Visual Studio ger även användaren stöd för att skapa grafiska gränssnitt till sina applikationer. Någon inbyggt stöd för Samsung Gear VR finns dock inte ännu. [17]

Android Studio Android Studio är en IDE utvecklad av Google för att utveckla applikationer till deras operativsystem Android. Android Studio har därmed stöd för de allra flesta funktioner man kan vilja ha i en IDE för Android-utveckling. Något enkelt sätt att skapa applikationer för Samsung Gear VR finns dock inte ännu. [18]

(22)

3.6 Systemutvecklingsmetoder

I den här delen förklaras olika systemutvecklingsmetoder, som är tillvägagångssätt för utveckling av ett projekt och metoder för att framlysa särskilda aspekter i ett projektarbete.

3.6.1 Scrum

Scrum är ett ramverk som använts för utveckling sedan början av 90-talet. Ramverket grundas på empirism, som är en kunskapsteori baserad på erfarenhetsmässiga fakta. Scrum definerar olika roller för de som är delaktiga i ett projekt, och dessa inkluderar utvecklarna i projektgruppen, intressenterna och produktägaren. Produktägaren ser till att produkten som utvecklas ska nå max-imalt värde. Utvecklingen utförs i ett antal så kallade ”sprints”. Sprintsen, som kan ses i figur 3, är indelade i fem aktiviteter: ”sprint planning”, ”daily scrum”, ”utvecklingsarbete”, ”sprint review” och ”sprint retrospective”. Alla aktiviteter har förbestämda maximum för hur länge de får utföras. Under dessa tider finns möjligheter att granska och anpassa delar av utvecklingsarbetet för ökad utvecklingskvalitet. [19]

Sprint planning Hur hela arbetet ska utföras för en viss ”sprint” planeras. Hela projektgruppen och produktägaren är delaktiga i planerandet. Sprint planning får hålla på i max åtta timmar för en sprint som sträcker sig över en månad. Här fastställs vilket arbete som bör utföras under sprinten och hur det valda arbetet kan genomföras.

Daily scrum Daily scrum är ett möte som utförs varje dag och täcker de närmaste 24 timmarna. Mötet pågår i max 15 minuter och utförs av projektgruppen. Här ska varje utvecklare svara på vad de har gjort sedan senaste daily scrum, vad de ska göra innan nästa daily scrum och vilka hinder som uppstod under utvecklingen.

Utvecklingsarbete Under den här delen av ”sprinten” utförs själva utvecklingen.

Sprint review Mot slutet av en sprint granskas de krav som eventuellt bör undersökas eller änd-ras. Produktägaren, projektgruppen och intressenterna diskuterar vilka krav som blivit uppfyllda för den aktuella sprinten. Därefter planeras nästkommande krav som kan uppfyllas. Sprint review pågår vanligtvis i max fyra timmar.

Sprint retrospective Det här tillfället används för att projektgruppen och produktägaren ska sammanfatta sprinten och planera för möjliga förbättringar inför nästa sprint. Vanligtvis hålls sprint retrospective i max tre timmar och inträffar i slutet av en sprint.

3.6.2 Kanban

Kanban är ett sätt att planera och ge en visuell struktur av utvecklingen. Man delar upp utveck-lingsarbetet i små aktiviteter, vanligtvis i form av fysiska kort eller ”post-it-lappar” och sätter upp dem på en så kallad ”Kanban board”. Figur 4 visar en förenklad modell av hur ett kanban board kan se ut. Aktiviteterna kan delas in i kolumner beroende på vilket tillstånd en viss aktivitet befinner sig i. Det är viktigt att begränsa hur många aktiviteter som får pågå samtidigt. På så sätt kortas tid och arbete ner för varje aktivitet som för tillfället pågår. [20]

(23)

Figur 3: Förenklat flödesschema för hur Scrum fungerar

3.6.3 Extreme Programming

Extreme Programming (XP) bygger på ett flertal regler som bör följas. En nyckelegenskap i den här systemutvecklingsmetoden är ”user stories”, som är enkla, korta beskrivningar av vad en användare vill göra eller uppnå. De viktigaste reglerna är att:

• Projektgruppen ska arbeta iterativt, dvs. utveckla mot att uppfylla user stories och upprepa med att utveckla, fixa eller ändra de user stories som misslyckas vid tester.

• Släppa mindre utgåvor och ofta, då utvecklingsarbetet sker iterativt.

• En planering bör skrivas. I den ska det förklaras vilka user stories som bör implementeras och när de bör vara implementerade.

• Planera takten som man utvecklar produkten i så att man får ut det mesta av varje iteration. Vid tidspress gäller det att planera om arbetet för att maximera utvecklingsprestationen.

• Fokusera på att utföra de enklaste uppgifterna först.

• Refaktorera koden, dvs. ändra om koden så att den får minskad redundans och inte har kvar oanvända funktionaliteter eller uppdatera koddesignen. Detta sker ständigt under hela projekttiden.

• Utvecklarna ska integrera och bidra med ny kod så ofta som möjligt. • Bygga tester innan själva koden.

• Programmera i par.

(24)

Figur 4: Exempel på en ”Kanban board”

• Ha gemensam äganderätt till produkten. Vilken utvecklare som helst ska kunna lägga till eller ändra vilken kodrad som helst.

• Utföra acceptanstester, som är tester baserade på user stories. Kunden specifierar scenarion som ska testas och när ett test är genomfört utan problem ses motsvarande user story som uppfylld. [21]

Det finns ett flertal andra regler som bör följas, men ej täcks i denna rapport.

3.6.4 Vattenfallsmodellen

Vattenfallsmodellen är en sekventiell systemutvecklingsmetod eftersom den går igenom ett visst antal faser i en viss följd. Ett projektarbete som följer denna metod delas upp i olika faser. För att komma till nästa fas behöver man slutföra alla aktiviteter i nuvarande fas. Fasernas ordning kan ses i figur 5 och består av:

• Kravspecifikation där krav på den blivande produkten samlas och dokumenteras.

• Systemdesign där kraven från föregående fas granskas och en design av systemet samman-ställs.

• Implementation där design under föregående fas används för utveckling av systemet. • Testning där de enheter, delar av system eller hela system som utvecklats från föregående fas

testas.

• Release där produkten släpps ut på marknaden.

• Underhåll där fel på produkten korrigeras eller där produkten förbättras fastän produkten redan är i marknaden. [22]

3.7 Ordlista

I den här delen beskrivs de datatekniska termer som kommer att vidare användas i rapporten.

Touchpad På Samsung Gear VR finns en pekplatta som känner av beröring. Den används för att interagera med den mobila enheten som är kopplad till Samsung Gear VR. I rapporten används ”touchpad” för att referera till pekplattan.

(25)

Figur 5: Flödesschema för de olika faserna i vattenfallsmodellen

Swipe Användaren kan via Samsung Gear VR:s touchpad ge två olika sorters inmatning. Den ena av dem är att svepa sitt finger över touchpaden i olika riktningar. Den här typen av använda-rinmatning kommer i rapporten hänvisas till som en ”swipe”.

Slider En slider är ett grafiskt gränssnittselement i form av ett skjutreglage. En användare kan med en slider specifiera ett numeriskt värde inom ett intervall.

Branch I ett Git-repo kan en användare kopiera hela projektstrukturen och förgrena den för att t.ex. påbörja utveckling av en ny funktionalitet. En sådan förgrening hänvisas i rapporten till som en ”branch”; plural ”branches”. Varje branch är av typen ”separat universum” vilket betyder att när utvecklaren byter branch, byts alla projektfiler ut mot de som ingår i ”branchen”.

Iterativ utveckling När man arbetar iterativt börjar man med att ta delar av ett krav, utveckla dessa delar, göra en återblick på det som utvecklats och vidare behandla andra krav. Det upprepas sedan tills att alla delar av kravet har uppfyllts. Konceptet att upprepa processen för att successivt uppnå ett krav kallas för iterativ utveckling. [23]

Agil utveckling När man arbetar agilt jobbar man iterativt och håller sin utveckling dynamisk för att snabbt kunna svara på och hantera olika situationer. Situationerna kan exempelvis vara att kunden begär plötsliga ändringar i systemet, eller att man väljer att skapa en ny prototyp för att få kundens återkoppling om systemet. [24]

IDE När man skriver programkod använder man sig ofta av ett program som underlättar genom att ge förslag på funktionsnamn och automatiskt indenterar koden. Ett sådant program fungerar som utvecklingsmiljö för att hjälpa programmeraren och kallas på engelska för ”Integrated develop-ment environdevelop-ment”. I rapporten används förkortningen ”IDE” för att referera till sådana program. [25]

(26)

4 Metod

Tre huvudsakliga metoder används för att svara på frågeställningarna: utvecklingen av BioVision, dokumentarbete och analysering av externa källor. Utöver dessa tre metoder kräver några av frågeställningarna andra aktiviteter. Alla metoder och hur de används för respektive frågeställning behandlas i detta kapitel.

4.1 Frågeställning 1: Utveckling i Unity

I det här avsnittet behandlas metoderna som används för att svara på den första frågeställningen: ”Hur väl lämpar sig programmeringsmiljön Unity för utveckling av mobila Augumented reality-applikationer?”

4.1.1 Utvecklingen av BioVision

Utvecklingsmiljön och det primära verktyget för utvecklingen av BioVision är Unity. För den bildhantering projektet kräver används OpenCVForUnity, som är ett C#-skal till OpenCV och som finns tillgänglig i Unitys digitala plug-in-butik Asset Store. Produktens grafik utvecklas i Unitys 3D-miljö och MonoDevelop, den textredigerare som gruppen valt att utnyttja, används för att skriva underliggande logik.

I början av projektarbetet byggs ett kodskelett som varje utvecklare har möjlighet att bygga vidare på. Projektgruppens tidsplan konsulteras löpande och arbetsuppgifter distribueras därefter. Utveckling av produktens olika funktioner sker på separata Git-branches som mot slutet av varje iteration mergas samman för att skapa de prototyper projektgruppen testar och demonstrerar för BioOptico. Under kundmöten diskuteras prototypen och utvecklingsarbetet och BioOptico får komma med kommentarer och förslag på utökningar av den ursprungliga kravspecifikationen.

Dessa kommentarer och förslag tas till hänsyn vid planeringen av nästkommande iteration och utvecklingsprocessen upprepas igen.

4.1.2 Jämförelse med andra utvecklingsmiljöer

En kort undersökning om hur väl Unity lämpar sig för utveckling av mobila AR-applikationer i jämförelse med andra utvecklingsmiljöer som Xcode, Xamarin och Android Studio uförs. Under-sökningen grundas enbart på externa källor.

4.2 Frågeställning 2: Värde för kunden

I det här avsnittet behandlas metoderna som används för att svara på den andra frågeställningen: ”Hur kan applikationen BioVision implementeras så att den ger värde för BioOptico?”

Projektets mål är att utveckla en produkt med värde för BioOptico. För att åstadkomma det är det viktigt att hålla nära och frekvent kontakt med denne. Av den anledningen utvecklas BioVision agilt, i den mening att arbetet kretsar kring framtagandet och påbyggnaden av en evolutionär prototyp som vid varje kundmöte demonstreras för BioOptico. Med evolutionär prototyp menas en långlivad prototyp som utvecklas inkrementellt och slutligen resulterar i den färdiga produkten.

För att fullfölja denna utvecklingsprocess sker utvecklingen iterativt och inkrementellt. På så sätt kan BioOptico ge sina synpunkter på BioVision. Dessutom får projektgruppen en bättre bild av

(27)

deras sanna behov och missuppfattningar mellan parterna blir sällsynta. För utvecklingen av Bio-Vision väljs koncept och regler från de befintliga systemutvecklingsmetoderna Scrum respektive XP. Projektarbetet är indelat, likt Scrums sprints, i fem faser: en förstudiefas, ett uppehåll, tre iterationer och en reservperiod. Se figur 6 för uppdelningen. Faserna och iterationerna beskrivs nedan.

• Förstudiefasen är den tid projektgruppen först tar kontakt med BioOptico. Ett tidigt kundmöte bestäms och under mötet bearbetas en gemensam grund mellan projektgruppen och BioOptico. Grunden dokumenteras i en kravspecifikation och ett kundkontrakt. I den här fasen läggs även en bas för dokumentarbete upp som dokumentmallar och tidiga utkast. Ett gemensamt ShareLaTeX-konto används för dokumentskrivning och Google Drive för all dokumentlagring. En Slack-kanal sätts upp och ett gemensamt Git-repo anordnas. Därefter undersöks områden som är relevanta för utvecklingen av BioVision, som Unity och OpenCV. Tidiga prototyper i Unity med OpenCV byggs för att projektgruppen lättare ska komma igång med utvecklingen.

• Iteration ett består av fyra veckors arbete, med målet att producera nödvändiga första utkast av dokument och en prototyp att visa för BioOptico. All den framtida färdiga produk-tens funktionalitet, som den vid det tillfället beskrivs i kravspecifikationen, ska vara färdig och implementerad i prototypen, på ett fungerande men inte nödvändigtvis användarvänligt sätt.

• Uppehåll är en period som används för att sammanställa arbeten som ej kunnat fullbordas under förstudiefasen och iteration ett.

• Iteration två är en tre veckor lång period där projektgruppen avser att förbättra pro-totypens användarvänlighet och implementera de önskemål om prototypen som BioOptico framför under kundmötet i slutet av iteration ett. Under den här iterationen utförs också ett användbarhetstest. Iteration två avslutas liksom den första med ett kundmöte där en förbättrad prototyp demonstreras.

• Iteration tre är en tre veckor lång period. Under den här perioden arbetar projektgruppen med att optimera prototypen och ytterligare förbättra användarvänlighet och interaktions-design efter återkoppling från användbarhetstesterna och kundmötet i iteration två. Utöver arbetet med prototypen spenderas mycket tid på dokumentarbete.

• Reservtid är schemalagd och används för att ägna tid åt sammanställningar av dokument.

Figur 6: Uppdelning av de olika faserna i projektarbetet

Varje iteration (och förstudiefasen) är indelade i projektgruppens egna varianter av sprint planning, sprint review och sprint retrospective där det inte kommer att finnas en produktägare. Skilt från Scrum hålls ett möte i början av varje vecka med planering av vad som ska utföras under veckan. Projektgruppen planerar även en egen variant av daily scrum som hålls i slutet av varje vecka. Projektmedlemmarna redogör för sina aktiviteter, men reflekterar också över hur varje vecka har gått.

För utvecklingen av BioVision används även XP-reglerna om att leverera små utgåvor till BioOp-tico, ha gemensam äganderätt till produkten, utveckla BioVision under en gemensam kodstandard och att parprogrammera.

I frågan om hur BioVision bör implementeras är det viktigt att analysera hur systemet är tänkt att användas samt vilken målgrupp den har. Under möten med BioOptico lägger projektgruppen stort fokus på att klarlägga vad denne vill ha och hur denne planerar att använda produkten.

(28)

Anpassning av systemet för ovana användare genomförs via textmeddelanden eller andra grafiska handlingsinviter som visas på på skärmen. De grafiska hjälpmedlen vägleder användaren genom produktens funktioner.

4.2.2 Andra aktiviteter

Systemtestning BioVision måste bibehålla sin kvalitet under hela utvecklingsarbetet; oavsett vilka aktiviteter som utförs får inga krav invalideras. Vid systemtestet testas den senaste, mest kompletta versionen av produkten grundligt för att se ifall alla krav som ställts på systemet hålls. Två dokument används vid systemtestningen. Det första dokumentet är en checklista i form av ett exceldokument, som kan ses i figur 7. Den innehåller alla krav som bör ha uppnåtts mot projektets slut, både i produktens mobila version och versionen som körs via Samsung Gear VR. Det andra dokumentet är en lista över funktionella krav, indelade i de delmål som måste nås för att kravet ska anses uppfyllt. Delmålen är korta och fokuserar endast på ett praktiskt område, exempelvis ”att kunna köra applikationen i fem minuter utan krasch” eller ”att kunna navigera i applikationens menyer”. När ett delmål är uppfyllt bockar man av i checklistan att det är uppfyllt och vem eller vilka som utfört testet.

Figur 7: Checklista över funktionella krav som bör uppfyllas

Användbarhetstestning BioVision kommer även att testas under realistiska scenarion, av re-presentativa användare, i en realistisk miljö. Det gäller även att undersöka om systemet är imple-menterat på sådant sätt att kravspecifikationer som ej kan bekräftas av projektgruppen uppfylls. Därför behövs utomstående testare som kan bekräfta att krav på viss funktionalitet uppfylls. På

(29)

så sätt kan man vara säkrare på att ett krav är uppnått och kontrollera aspekter som hur intuitivt och konsekvent systemet är.

Som nämnt kommer produkten att användas för demonstration vid mässor för vad som antagligen ofta kommer vara förstagångsanvändare av Samsung Gear VR. Eftersom både hård- och mjukvaran är obekanta för användaren är produktens interaktionsdesign av stort intresse. Av den anledningen utförs en användarbarhetstestning, där användarna genomarbetar ett antal praktiska uppgifter. Projektgruppen observerar och antecknar beteenden som kan vara relevanta för BioVision samt skriver ner svaren på frågor som muntligt ställs till användarna. Frågorna baseras ofta på utom-ståendes beteenden för att bekräfta att någon eller några av systemets funktionaliteter orsakade beteendet hos användarna. Efter att användarna genomarfört uppgifterna fyller de även i enkäter för att ge deras uppfattning om vad de tycker om systemet som helhet.

Kundkontakt Att få en kund att känna sig nöjd med en produkt kan vara väldigt problematiskt. Det finns många risker inför ett projekt och det kan vara svårt att rätta till en kontakt som haft dålig start. Det är därför viktigt med god kommunikation mellan kund och utvecklare samt att ha en tydlig plan om hur utvecklingsarbetet ska gå till för att skapa värde för kunden.

Genom att ha regelbundna möten med kunden skapas en dialog för hur produkten ska utvecklas. Hur ofta mötena ska äga rum kan vara olika från projekt till projekt. Om det uppstår delade åsikter om produktutvecklandet mellan olika parter krävs det att mer fokus måste ligga på kommunikation. Det är dock viktigt att tänka på om ett möte är nödvändigt, eftersom för många möten kan vara ett problem i sig. [26]

I projektet planeras möten mellan BioOptico och ett urval av utvecklarna i slutet av varje iteration. Här sker en genomgång av vad utvecklarna har gjort sedan föregående möte, eventuella problem som har uppstått som kan leda till att krav måste modifieras och slutligen vad som kommer göras tills nästa möte. Det skapar en uppfattning hos BioOptico om hur utvecklarna ser på produkten. Det skapar även en möjlighet för BioOptico att uttrycka om de anser att utvecklingen har gått i en felaktig riktning.

Här är det viktigt för utvecklarna att lyssna på samtliga kommentarer från BioOptico. Vad de anser är bra, dåligt, förvirrande eller behöver förbättras. Genom att spegla feedbacken mot projektets ordinarie plan och aktuella kravspecifikation så kan den ge en god uppfattning om hur arbetet ska utvecklas.

Utöver iterationsmöten förekommer en kontinuerlig mejl-korrespondens mellan de båda parterna. Extra möten kan bokas vid behov, och BioOptico är även inbjuden till projektets Git-repo.

Kravspecifikation När en kravspecifikation dokumenteras används krav som ska vara så test-bara som möjligt. Varje krav har en av två prioriteringsnivåer. Nivå ett måste vara uppfylld för att BioOptico ska kunna tillfredsställas av BioVisions funktionaliteter. Nivå två uppfylls i mån av tid och resurs. Då ett flertal krav är beroende av andra krav prioriteras de krav som inte har några beroenden först. De krav med minst beroenden tenderar att ge mest värde för BioOptico.

4.3 Frågeställning 3: Dokumentering av erfarenheter

I det här avsnittet behandlas metoderna som används för att svara på den tredje frågeställningen: ”Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intressanta för framtida projekt?”

4.3.1 Reflektionsmöten

Varje vecka under projektarbetet schemaläggs ett möte med gruppens handledare. Under varje möte går projektgruppen ”bordet runt” och varje gruppmedlem berättar hur dennes arbete har

(30)

fortskridit under veckan. Detta involverar att beskriva gamla problem som lösts (och hur) samt nya problem som dykt upp (och hur gruppmedlemmen planerar försöka lösa dem). Resten av gruppen är fria att ställa frågor och komma med förslag.

Denna process är avsedd att öka hela gruppens förståelse för alla delar av projektarbetet, speciellt delar där enbart en liten del av gruppen har varit delaktiga i utvecklingsprocessen. Genom aktivt deltagande under mötena går inga medlemmar miste om sinnrika (eller klumpiga, men nödvändiga) lösningar, som kan komma att vara av intresse i framtiden. Protokoll förs under varje möte, så betydande problem och deras slutliga lösningar dokumenteras.

4.3.2 Seminarier

Som del av kandidatarbetet deltar projektgruppen i flertalet seminarier med andra grupper. Inför varje av dessa seminarier, som schemaläggs med jämna mellanrum under projektarbetet, samman-ställer gruppen en lista över de erfarenheter de samlat på sig dittills. Detta görs i ett gemensamt dokument på gruppens Google Drive-sida och alla gruppmedlemmar uppmuntras delta i skrivandet.

4.3.3 Dokumentarbete

I kandidatarbetet skrivs ett antal dokument för erfarenhetsinfång. Dessa dokument är:

• Projektplanen, som lär gruppen att systematiskt planera sin utvecklingsprocess.

• Arkitekturbeskrivningen, i vilken gruppen dokumenterar produktens sammanhängande struk-tur på en teknisk nivå. Skrivandet av arkitekstruk-turbeskrivningen kräver att gruppen beskriver produkten på ett mer tekniskt sätt än de annars är vana vid och kan därför ge upphov till många lärdomar.

Det skrivs även en lista över designbeslut och varför de togs. På så sätt dokumenteras moti-veringar till (ibland kanske till synes underliga) beslut angående produktens arkitektur, då dessa kan vara nödvändiga för framtida vidareutveckling. Dokumentering över vilka beslut som togs, och varför, är även värdefulla för gruppens erfarenhetsinfång, eftersom de vittnar om flera viktiga aspekter av utvecklingsarbetet. Finns det egenheter och svagheter inom t.ex. programspråk eller utvecklingsmiljö kan man i denna dokumentering läsa om hur dessa kan kringgås.

• Användarhandledningen, där gruppen bl.a. beskriver möjliga sätt för framtida utvecklare att förbättra BioVision.

• Denna kandidatrapport, som i sig ger en sammanfattande erfarenhetsrapport samt erfaren-heter från de individuella rapporterna.

4.4 Frågeställning 4: SEMAT Kernel ALPHA

I det här avsnittet behandlas metoderna som använts för att svara på den fjärde frågeställningen: ”Vilket stöd kan man få genom att använda och följa upp SEMAT Kernel ALPHA:s?”

SEMAT ALPHA state cards används under utvecklingen och följs upp ett antal gånger under projektets gång.

För att se hur SEMAT Kernel ALPHA:s kan spela in i projektet använder projektgruppen själv dessa kort. Under kandidatarbetet undersöker projektgruppen vilka tillstånd gruppen själv, pro-dukten, BioOptico, intressenter och arbetet befinner sig i. Projektgruppen går igenom SEMAT

(31)

ALPHA State Cards i förstudiefasen för att bestämma vilket tillstånd som bör uppnås under vilken iteration. Se figur 8 [4]. Korten evalueras (och eventuellt revideras) ett par gånger under förstudiefasen och ungefär en gång per iteration under resten av projekttiden.

Den här formen av utvecklingsprocess kommer projektgruppen att evaluera och utvärdera efter det stöd som gruppen anser att SEMAT Kernel ALPHA:s ger.

Figur 8: Exempel på planerade tillstånd av SEMAT ALPHA state cards, från Essence Kernel

4.4.2 Dokumentarbete

För varje gång projektgruppen använder sig av dessa kort skrivs det dokumentation för de ALPHA:s som för tillfället projektet befinner sig i och vilka som bör nås härnäst.

(32)

5 Resultat

Under projektets gång tas en genomgående prototyp av BioVision fram. Utvecklingsarbetet sker i samband med dokumentskrivning och forskning inom de frågeställningar som behandlas i den här rapporten. I den här resultatdelen ges en översiktlig beskrivning av produkten som utvecklats, varav detaljer angående varje frågeställning tas upp i var sin del.

5.1 Frågeställning 1: Utveckling i Unity

För utvecklingen av BioVision lämpar sig Unity mycket väl. Utvecklingsmiljön erbjuder en enkel översikt av mycket av den önskade funktionaliteten, vilket innebär att mer tid läggs på enkelt programmerande på hög nivå. Den här typen av utveckling lämpar sig bra för projektet då utveck-lingsperioden är relativt kort och intensiv och gruppen har en ringa erfarenhet av utvecklande inom AR. Unity erbjuder en snabb start, men är fortfarande ett kraftfullt verktyg. De prestandaproblem som slutprodukten har beror på Unitys uppbyggnad som en generell spelmotor kombinerat med telefonens begränsade processorkraft.

Varken Xcode, Xamarin eller Android Studio har särsklit bra stöd för utveckling i AR och VR. Därför uppmanas det att utveckla i Unity istället som har väldigt god funktionalitet för denna typ av utveckling. Även om det går att utveckla i andra miljöer än Unity så är det mer bekvämt att hålla sig till Unity.

5.2 Frågeställning 2: Värde för kunden

Den här delen visar hur varje aktivitet för varje fas utförs utifrån de metoder som beskrivs i avsnitt 4.

Av de krav som BioOptico ställer på BioVision och som projektgruppen bearbetar inom mån av tid, sammanfattas funktionaliteterna i form av: möjlighet för filterbyte, olika filtertyper, funktionalitet för inställningsmenyer, val av färg, ta skärmbilder och att dela sin skärm. I det här avsnittet beskrivs dessa funktionaliteter och hur användarna kan dra nytta av dem.

(a) Euclidian Spectran Distance filter (b) Canny Edge filter

(33)

Filterbyte Genom att swipa åt antingen höger eller vänster på Samsung Gear VR:s touchpad byts filter ögonblickligen. En kort stund efter att filterbytet sker visas en text på vilken filtertyp som för tillfället används. I figur 9b syns ett exempel på hur det ser ut när man kan byta filter.

Filtertyper Två av BioOpticos egna filter används i mjukvaran. Dessa två är Euclidean Spectral Distance(figur 9a) och Texture Bandpass Spectral Distance-filter, vilka framhäver valda texturer eller färger. Projektgruppen har även utvecklat ett eget filter på BioOptico begäran. Canny Edge-filtret(figur 9b) framhäver kanter mellan färgskillnader på svart bakgrund.

(a) Inställningsmeny (b) Färgväljare

Figur 10: Menyelement för justering av filterinställningar

Inställningsmeny Genom att swipa ner över Samsung Gear VR:s touchpad dyker en inställ-ningsmeny upp för det filter som används. På menyn finns ett flertal inställningar av olika typer beroende på det valda filtret. Genom att rikta sitt huvud mot en inställning framlyses inställnings-valet och det är därefter möjligt att ändra på den inställningen.

En slider kan ställas in på ett önskat värde på två sätt. Man kan rikta huvudet mot sliderknappen och hålla ett finger mot touchpaden (och på så sätt ”greppa tag” i knappen) och sedan flytta knappen till önskat värde genom att röra på huvudet. Alternativt kan man rikta huvudet mot slidern och långsamt swipa horisontellt över touchpaden, tills sliderknappen befinner sig vid önskat värde.

Det finns även kryssrutor som kan tryckas på eller av genom att man rör sitt huvud så att markören är på rutan och klickas med ett enkelklick på touchpaden. I figur 10a återfinns ett exempel på hur inställningsmenyn ser ut för Euclidean Spectral Distance-filtret.

Färgväljare I figur 10b syns ”färgväljaren”. Det är ett inställningsalternativ som används av vissa filter. För att komma in i läget behöver man enkelklicka på de alternativ som har en färgad ruta med ett hexadecimalt värde över sig. I exempelvis Euclidean Spectral Distance-filtret kan färgväljarläget aktiveras genom att man väljer ”Target Color” eller ”Mask Color”. I det här läget göms inställningsmenyn för tillfället för att lättare se vilken färg man vill ha. En box med en särskild färg visas. Färgen som syns i boxen är den färg som kommer att användas för det valda inställningsalternativet. Boxens färg beror på vilken färg markören i mitten av skärmen riktar in sig på. Därför gäller det att rikta huvudet så att boxen har den färg man vill ha och utföra ett enkelklick på touchpaden. Därmed är den valda färgen den färg boxen fick.

Skärmbild Samsung Gear VR har en ”tillbakaknapp” placerad bredvid touchpaden. Genom att trycka på den kan man ta en skärmbild på den bild som skärmen visar för användaren. BioVision ger en auditiv feedback i form av ett kameraslutarljud samt ger visuell feedback i form av en blin-kande effekt som är mycket likt en vanlig digitalkameras. En skärmbild utan något filter applicerat sparas i Androidenhetens galleri tillsammans med ett antal andra skärmbilder, med alla olika filter applicerade separat. Figur 11a visar hur galleriet kan se ut efter användning av BioVision.

(34)

(a) Galleri för bilder efter körning (b) Chromecast till extern skärm

Figur 11: Behandling av skärmbild och skärmdelning

Skärmdelning BioVision har en inbyggd funktion som möjliggör skärmdelning med en Chro-mecastenhet. Det som ses igenom Samsung Gear VR kan även ses på en extern skärm med HDMI-uttag. I figur 11b syns hur bilden ser ut på den externa skärmen.

5.2.2 Kundkontakt

Kommunikationen mellan utvecklarna och BioOptico har fungerat bra under arbetets gång. Föru-tom de inplanerade mötena i slutet på varje iteration så har endast ett extra möte hållits. Under detta möte möttes ett fåtal utvecklare med BioOptico för att diskutera hur kundens filter funge-rade. De utvecklarna hade som uppgift i andra iterationen att översätta BioOpticos färdiga filter så filtret kunde implementeras i BioVision.

Under projektets gång har mejlkorrespondens existerat mellan BioOptico och utvecklarnas analy-sansvarig.

5.2.3 Demonstrationer för BioOptico

Iteration 1 Under denna demonstration så är samtliga utvecklare närvarande för att alla ska få träffa BioOptico. De huvudsakliga funktioner som visas upp under denna iteration är:

• Användning av filter

De första filter som konstrueras demonstreras för att visa kapaciteten hos filtren och vilken bilduppdateringsfrekvens som kan uppnås.

• Grundläggande interaktion

På sidan av hjälmen finns det en panel som kan användas för interaktion med telefonen. Med hjälp av den så demonstreras byte av filter och skärmbildtagning genom att swipa i en specifik riktning.

• Skärmdelning

Genom användning av Chromecast så återspeglas VR-hjälmens användares vy till en projek-tor så att samtliga i rummet kan se vad användaren gör.

• Skärmbilder

Skärmbilder sparas i telefonens galleri. Det sparas en kopia utan filter applicerat samt kopior med varje filter applicerat separat.

Efter en kort genomgång av alla funktioner vi implementerat under första iterationen får BioOp-tico tid att testa produkten. BioOpBioOp-tico tycker att en viktig del i iteration två är att möjliggöra förändring av filterparametrar under körtid. BioOptico uppfattas som nöjd med projektets gång så långt och är förvånad att utvecklingen kommit så långt.

(35)

Iteration 2 Möten inleds med att BioOptico får testa den uppdaterade produkten för att få se vad som gjorts sedan föregående iteration. BioOptico tycker att produkten är bra i sin helhet, men saknar en knapp som återställer alla filterparametrar. Efter en diskussion angående sista iterationens fokus kommer BioOptico fram till att den sista iterationen framförallt ska handla om att förbättra användarupplevelsen. BioOptico förtydligar även för vilken målgrupp produkten ska utvecklas.

Slutgiltig demonstration Vid den slutgiltiga demonstrationen redovisas systemet med den slutliga versionen i åtanke. Som tidigare nämnt är användaren som står i fokus de intressenter som BioOptico visar sin produkt för vid mässor och dylikt. Intressenterna är människor som aldrig använt ett sådant system sedan tidigare eller vet hur ett filter fungerar. Under demonstrationen ska systemet visas som intuitivt uppbyggt och ska lätt guida användaren genom dess funktionaliteter. Ett viktigt mål är att BioOptico kan visa upp BioVision utan att användarna ska behöva läsa en manual. På så sätt ska BioVision implementeras och redovisas för att ge värde för BioOptico.

5.2.4 Kravspecifikation

Kravspecifikationens utformning gör att utvecklingen av BioVision kan fortlöpa smidigt. De olika prioriteringsnivåerna gör att gruppen vet vad som är viktigt att fokusera på och vad som kommer i andra hand. Det skapas ett dokument som visar beroende mellan kraven som leder till en naturlig utveckling.

5.2.5 Andra aktiviteter

Systemtestning Utförandet och rapporteringen av systemtestningen möjliggör att de krav som nämns i kravspecifikationen bekräftas som uppfyllda. Systemtestningen täcker dock inte alla krav, då vissa angår projektet i helhet och inte utvecklingen. Dessa krav kräver inte testning.

Användbarhetstestning Projektgruppens användbarhetstestning sammanställs och kan sam-manfattas enligt följande resultat:

• Faktorer som inte upptäcks vid utvecklingen av BioVision eller av systemtestning hittas via användbarhetstestning. Ett exempel är att BioVision har en risk för överhettning när Chromecastenheten används och att uppkopplingsfel för skärmdelning kan inträffa.

• Användare som ej använt en Samsung Gear VR förut är ovana med kontrollerna. • Någon form av instruktion eller vägledning när det gäller navigation i BioVision behövs. • Man vill få en visuell respons eller feedback när man utför en rörelse med Samsung Gear

VR:s kontroller.

5.3 Frågeställning 3: Dokumentering av erfarenheter

De erfarenheter som kan vara intressanta för framtida projekt kan sammanfattas enligt följande punkter:

• Planering och tidsmarginaler är viktigt för ökad dokumentkvalitet. Mot slutet av iteration 2 är projektgruppen ej tillräckligt förberedd på dokumentarbete. Rapporten saknar många individuellt skrivna delar, har många kvarglömda kommentarer och har mycket ofärdig text trots att interna deadlines bestäms av projektgruppen.

(36)

• Användbarhetstestningen utförs på ett dåligt planerat sätt. Ingen genomgång och ingen gene-ralrepetition på hur testningens flöde skulle föras framåt genomförs. Som konsekvens förlorar Chromecast-adaptern kontakt med projektgruppens hårdvara under körtid. Därför fick nya medel användas för att bekräfta att användaren utför uppgiften. Uppgifterna som användar-na utför formuleras i sista minuten, vilket påverkar motiveringen bakom uppgiften eller syftet med uppgiften. Generellt sett har projektgruppen för lite tid till att förbereda testningen.

• Man lär sig nya tekniska områden på grund av oförutsägbara problem som uppstår. Exempel är lärdom om hur Java och de interna Androidfunktionerna fungerar i C#, att få Chromecast att integrera med applikationen eller generella optimeringar på systemet.

• Eftersom det inte meddelas om alla seminarier under projektets gång, tar man till sig erfa-renheter från hur oplanerade händelser kan förändra tidsplanen samt hur man planerar runt det. En stor ändring i systemet av BioOptico påverkar tidsplanen.

• Lärdom av gemensam, koordinerad och strukturerad planering av tidsanvändning.

• Att lägga ner mycket tid på planering i projektets inledande fas brukar leda till effektivare arbete under projektets gång.

• 400 timmar per person är mycket tid. Man har råd att tackla många uppgifter i par.

5.4 Frågeställning 4: SEMAT Kernel ALPHA

Under början av kandidatarbetet väljs en iteration för varje ALPHA där den uppskattas vara klar. De olika placeringarna av ALPHA:s kan ses i figur 12 [27]. Vid slutet av varje iteration går gruppen igenom och jämför de initiella placeringarna med det de tycker att de själva har uppnått. Jämförelsen kan ses i tabell 1.

Tabell 1: Jämförelse under varje iteration av vilka ALPHA:s gruppen anser sig ha uppnått (av vad som planerades från början)

ALPHA Iteration 1 Iteration 2 Iteration 3

Opportunity 5 (3) 5 (4) 6 (6) Stakeholders 4 (3) 4 (4) 6 (6) Requirements 5 (4) 5 (4) 6 (6) Team 3 (2) 4 (4) 5 (5) Software System 2 (3) 2 (4) 6 (6) Work 4 (3) 4 (4) 6 (6) Way of Working 4 (3) 3 (5) 6 (6)

Det stöd SEMAT Kernel ALPHA ger är följande:

• Tillstånden låter alla i projektgruppen att få en översikt, oavsett vilken roll, ansvar eller situation man befinner sig i.

• Alla i projektgruppen förstår var i utvecklingslivscykeln projektarbetet befinner sig.

• Att diskutera kring hur man uppnår svårare tillstånd hjälper gruppen att inse vad som behöver arbetas mer med för att samarbetet ska förbättras.

• SEMAT Kernel ALPHA-möten låter gruppens medlemmar ta en paus och reflektera över vad som har gjorts och vad som behöver göras.

(37)

5.5 Översikt av de individuella bidragen

Varje utvecklare i projektgruppen utför även egna undersökningar som ligger i den individuella delen.

• Daniel undersöker ingenjörens ansvar mot sin omvärld ur några väletablerade etiska teoriers synvinklar.

• Måns undersöker vilka faktorer som spelar roll då det kommer till konsumentvänlig utveckling av AR-produkter.

• Emil undersöker om datorspelande med virtuell verklighet kan vara beroendeframkallande hos användaren.

• Raymond undersöker testbarheten av AR-applikationer enligt teststandarden IEEE 829-2008 i sin individuella del.

• Joakim undersöker hur användarens hälsa påverkas vid användningen av en VR-hjälm. • Ludvig undersöker hur man skapar en bra användarupplevelse i AR för förstagångsanvändare. • Nils undersöker hur man når hög kvalitet inom ett mjukvaruprojekt.

• Jonatan undersöker hur antalet gruppmedlemmar påverkar utvecklingen av ett mjukvarupro-jekt.

• Mikael undersöker hur man bäst anpassar sin versionshanteringsstrategi beroende på grup-pens och uppgiftens sammansättning.

(38)

6 Diskussion

I det här avsnittet diskuteras det hur väl de resultat projektgruppen har producerat besvarar de frågeställningarna som har ställts i rapporten. I del 6.1 diskuteras hur väl Unity är lämpad för utveckling av mobila AR-applikationer. 6.2 täcker diskussionen för hur väl BioVision implementeras för att ge värde för BioOptico. De erfarenheter som kan vara värda att dokumentera för framtida projekt diskuteras och sammanfattas i del 6.3. Slutligen ger projektgruppen sina kommentarer kring SEMAT Kernel ALPHA:s stöd för utvecklingen av BioVision i del 6.4.

6.1 Frågeställning 1: Utveckling i Unity

Då Unity är en grafisk utvecklingsmiljö för generell utveckling av bl.a. spel, leder det till att en del av processorkraften används för funktioner som inte behövs i BioVision, men som är inbyggda i Unity. Exempel på dessa är Unitys inbyggda motorer för fysik och ljushantering vilka är väldigt prestandakrävande, men ej nödvändiga för BioVision. Det går till viss del att motverka, genom att avaktivera fysikhantering för element i Unityscenen, men lite overhead kvarstår.

Unity har däremot ett färdigt stöd för utveckling av program för VR-hjälmar, vilket i det här fallet är helt avgörande för att projektgruppen skulle hinna utveckla BioVision inom den budgeterade tiden. Unitys uppbyggnad med en grafisk redigerare och scenstruktur leder till att gruppen snabbt kan komma igång med att bygga en prototyp utan att först lära sig spelmotorns alla funktioner.

Flera alternativa utvecklingsmiljöer till Unity finns, men eftersom Unity är den enda (som pro-jektgruppen vet om) som har stöd för Samsung Gear VR så var valet av Unity givet. Att utveckla applikationen i en utvecklingsmiljö som inte har färdigt stöd skulle också vara möjligt, men det skulle antagligen ta mycket längre tid. Projektgruppens ringa erfarenhet av utvecklande inom AR-området är också en faktor som spelar in på Unitys lämplighet, vilken på många plan därmed kan anses vara god trots sina nackdelar.

En bättre metod för att besvara frågeställningen hade troligtvis varit att utvecklat applikationen i flera olika miljöer men på grund av kursens tidsomfattning är det inte görbart. Med den nuvarande metoden är det dock svårt att veta om utveckling i en annan miljö hade förbättrat det slutgiltiga resultatet även om vägen dit blivit svårare.

6.2 Frågeställning 2: Värde för kunden

I den här delen behandlas och diskuteras det hur väl BioVision implementeras och hur det ger värde för BioOptico. Alternativa implementationssätt kommer även att diskuteras i detta avsnitt.

6.2.1 Iterationsstruktur

Iterationsstrukturen som användes i projektet lämpade sig väl på många sätt för att kunna ge värde till BioOptico. I slutet av varje iteration fick de en demo av den senaste versionen av BioVision och möjlighet att lämnna feedback till nästa iteration. På så sätt fick BioOptico och gruppen en bättre möjlighet att förstå varandra och på vilket sätt de vill att projektet skall fortskrida. Det gav gruppen en god chans att skapa värde för BioOptico.

En eventuell nackdel med den struktur som användes är att mycket testningstid krävdes, något som gruppen ej ansåg skulle vara nödvändigt om någon annan struktur användes. Vanligtvis är det

Utveckling inom Augmented Reality med Unity