Linköpings universitetSE–581 83 Linköping

013-28 10 00 , www.liu.se

Linköpings universitet | Institutionen för datavetenskapExamensarbete på grundnivå, 15hp | Datateknik

Vårterminen 2017 | LIU-IDA/LITH-EX-G--17/041--SE

Simulering i Virtual Realityför prestations- ochmotivationsförbättringSimulation in Virtual Reality for Performance and Motiva-tional Improvements

Anton DalgrenCian HjortGustav KvistKevin Larsson AlmAnton Mo ErikssonSeth RamströmNoak RingmanAugust Uusitalo

Handledare : Rikard NordinExaminator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 årfrån publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstakakopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och förundervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva dettatillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. Föratt garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sättsamt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende elleregenart. För ytterligare information om Linköping University Electronic Press se förlagetshemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement– for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone toread, to download, or to print out single copies for his/hers own use and to use it unchangedfor non-commercial research and educational purpose. Subsequent transfers of copyrightcannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measuresto assure authenticity, security and accessibility. According to intellectual property law theauthor has the right to be mentioned when his/her work is accessed as described above andto be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of documentintegrity, please refer to its www home page: http://www.ep.liu.se/.

c©

Anton DalgrenCian HjortGustav KvistKevin Larsson AlmAnton Mo ErikssonSeth RamströmNoak RingmanAugust Uusitalo

Sammanfattning

Denna rapport behandlar det kandidatarbete som projektgruppen SurVive utfört undervårterminen 2017 vid Linköpings universitet. Arbetet gick ut på att i forskningssyfte, kon-struera en virtuell miljö för studenter att träna på krävande situationer. Rapporten syftaratt diskutera och analysera både virtuell verklighets applicerbarhet på prestationsförbättringsamt utvecklingen av den virtuella miljön.

Systemet som har utvecklats ska ge en säker och trygg miljö för användaren att praktis-era sin presentation. Vidare kommer relevant användardata illustreras på en hemsida för atttillhandahålla återkoppling på framförandet. Huruvida det utvecklade systemet egentligenbidrar till prestationsförbättring, kräver ytterligare forskning och användning.

iii

Abstract

This report processes the software development project created by the project group SurViveduring the spring semester of 2017 at Linköping University. The project involved in thepurpose of research, construct a virtual environment in order to allow students to practicedemanding situations. The report aims to discuss and analyze virtual realitys applicabilityon performance enhancement and the development of the virtual environment.

The system that has been developed will provide a safe and secure environment for theusers to practice their presentations. In addition, relevant user data will be illustrated on awebsite to provide feedback on their performances. Whether the developed system reallycontributes to enhanced performance, requires further research.

iv

Tillkännagivanden

Gruppen skulle vilja tacka Rikard Nordin för hans vägledning och hjälp med dekorering utavAkvariet. Tack till Dennis Petersson för all hjälp kring utrustningen i Akvariet. Gruppen villäven tacka Kristian Sandahl för en lärorik kurs och för hans hjälp med dokumentet ”Arkitek-toniska anteckningar”.

v

Innehåll

Sammanfattning iii

Abstract iv

Tillkännagivanden v

Figurer ix

Tabeller x

Kodexempel xi

Definitioner xiii

I Gemensamma erfarenheter och diskussion 1

1 Inledning 21.1 Översiktlig beskrivning av projektet . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Motivering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Bakgrund 4

3 Teori 53.1 Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.4 Flask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.5 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.6 eXtreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Metod 84.1 Metoder & verktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.2 Utvecklingsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.3 Metod för att fånga erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Resultat 105.1 Systembeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.2 Gemensamma erfarenheter: Vilka erfarenheter har vi fått som är överförbara

till framtida projekt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.3 Vilka val har tagits för att simuleringen ska hjälpa personen att bli mer bekväm? 19

vi

5.4 Hållbar utveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 Diskussion 206.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.3 Vilka val har tagits för att simuleringen ska hjälpa personen att bli mer bekväm? 216.4 Gemensamma erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.5 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7 Slutsatser 25

II Individuella bidrag 267.1 Översikt individuella bidrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

A Skillnader i utveckling av REST-API i Node.js och Python 29A.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30A.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30A.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32A.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

B Versionshanteringssystem vid grupparbeten 36B.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36B.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36B.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36B.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38B.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38B.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40B.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

C Arbetsgruppens utveckling under ett projekt 42C.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42C.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42C.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43C.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44C.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44C.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46C.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47C.8 Figurappendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

D Jämförelse mellan komponenter och arv inom spelutveckling 50D.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50D.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50D.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51D.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52D.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53D.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57D.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

E Teamledarens roll i agil mjukvaruutveckling 59E.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

E.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59E.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59E.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62E.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62E.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63E.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

F Virtual Reality - Vad är verkligt 65F.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65F.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65F.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66F.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66F.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69F.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70F.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70F.8 Figurappendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

G Testning vid spelutveckling i Unity 74G.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74G.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74G.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75G.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75G.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75G.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77G.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

H Påverkan av att skriva lokalt eller via molntjänster 80H.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80H.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80H.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81H.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82H.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82H.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83H.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84H.8 Figurappendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Litteraturförteckning 91

Figurer

3.1 Grafisk illustration av arbetsmetodiken Scrum [12]. . . . . . . . . . . . . . . . . . . 6

5.1 Illustration av systembeskrivningen för systemet. . . . . . . . . . . . . . . . . . . . 115.2 Illustration av systemanatomin för systemet. . . . . . . . . . . . . . . . . . . . . . . 125.3 Grafisk miljö som ska efterlikna ett klassrum. . . . . . . . . . . . . . . . . . . . . . . 135.4 Student skapad i MakeHuman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.5 Grafisk miljö som ska efterlikna en föreläsningssal. . . . . . . . . . . . . . . . . . . 145.6 Grafisk miljö som ska efterlikna en föreläsningssal. . . . . . . . . . . . . . . . . . . 145.7 Arvsträd över olika beteenden, där pilar visar arv från grundobjekt till ärvande

objekt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.8 Inloggningsfönster på webbsidan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.9 En tidig version av hur mätdata presenteras på webbsidan. . . . . . . . . . . . . . . 175.10 Demonstration av Git-arbetsflöde. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

A.1 Filstrukturen över det färdiga Express-projektet. . . . . . . . . . . . . . . . . . . . . 31A.2 Exempel på callback-hell där callback-funktioner är rödmarkerade. . . . . . . . . . 33A.3 Kodexempel där Promises används. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.4 Kodexempel i Python för kommunikation med databas. . . . . . . . . . . . . . . . . 34

B.1 Centraliserade systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39B.2 Distribuerade systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

C.1 Enkätens frågor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

D.1 Exempel på system och komponenter i EKS. . . . . . . . . . . . . . . . . . . . . . . 52D.2 Exempel på hur ett arvsträd kan se ut, där pilar denoterar arv i pilens riktning. . . 53D.3 Exempel på arvsproblem med flera föräldrar, där pilar denoterar arv i pilens rikt-

ning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54D.4 Exempel på arvsproblem som skapar redundans, där pilar denoterar arv i pilens

riktning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55D.5 Exempel på hur ett arvsträd kan se ut när EKS används. . . . . . . . . . . . . . . . 56D.6 Exempel på ett problem med EKS: ökad komplexitet hos delade komponenter. . . 57

F.1 Skärmbild ur ”The Price of Freedom” . . . . . . . . . . . . . . . . . . . . . . . . . . 67F.2 Skärmbild ur ”NewtonVR” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68F.3 Svar på enkäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

G.1 Exempel på ett testflödesdiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

H.1 Svar på enkäten angående skrivmetoder . . . . . . . . . . . . . . . . . . . . . . . . . 90

ix

Tabeller

A.1 Exempel på HTTP anrop till ett REST-API innehållande studenter . . . . . . . . . . 30

x

Kodexempel

A.1 Kommando för installation av bibliotek för att skapa ett fungerande Express-projekt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A.2 Kodexempel för att göra en inloggning med HTTP-anropet POST i Express. . . 31A.3 Kommando för installation av biblioteket Flask . . . . . . . . . . . . . . . . . . . 32A.4 Kodexempel för att göra en inloggning med HTTP-anropet POST i Flask. . . . . 32

xi

Definitioner

Nedan listas de benämningar som används inom ramen för projektet.

• Blender – En utvecklingsmiljö för avancerade grafiska objekt.

• Burn-down-graf – En graf som visar hur mycket arbete som genomförts kontra denestimerade tidsplanen.

• eXtreme Programming – Utvecklingsmetodik där bland annat parprogrammering in-går. Används ofta i samband med Scrum.

• Feature freeze – Ny funktionalitet får inte läggas till, endast bearbetning av existerandefunktionalitet tillåts.

• Freemium – En affärsmodell som erbjuder en bastjänst gratis, men fler funktioner kaninförskaffas med premiumprenumeration.

• Git – Ett versionshanteringsprogram för att hantera källkod och filer.

• GitHub – Webbplats där kod versionshanteras med hjälp av Git.

• HTC Vive – VR-utrustning från HTC och Valve som består av ett headset, de två hand-kontrollerna och basstationerna.

• HTML – HyperText Markup Language, ett märkspråk som används för att skapa webb-sidor.

• JavaScript – Dynamiskt prototypbaserat skriptspråk.

• Kodinspektion – En person som inte varit med och skrivit en funktion kontrollerarkoden för att se till att den följer kodstandarden.

• Learn to SurVive – Arbetsnamn för projektet VR-simulering för prestation- och moti-vationsförbättring.

• MakeHuman – Ett utvecklingsprogram för att skapa humanoida 3D-modeller.

• Master-gren – Den gren på GitHub som alltid bör ha fungerande och väl kommenteradkod.

• Mixamo – En tredjepart webbplats med färdiga animationer för humanoida 3D-modeller som går att ladda ner.

• MySQL – Databashanterare som använder sig av programspråket SQL, StructuredQuery Language, för att hämta och modifiera data i en databas.

• Parprogrammering – Två programmerare sitter vid samma dator. Den ena skriver kodoch den andra hjälper till med kontinuerlig kontroll av koden som skrivs.

• Product backlog – En lista av alla aktiviteter som ska bli klara under ett projekt.

xii

• Pull request – Begäran om att slå ihop sin egen gren med master-grenen.

• Python – Generellt interpreterat programspråk.

• Scrum – Utvecklingsmetodik där man bland annat delar upp ett helt projekt i ett antalsprinter och arbetar med de uppgifter som är planerade att göras under den sprintensom pågår.

• Slack – En internetbaserad kommunikationstjänst.

• Sprint backlog – En lista av alla aktiviteter som ska blir klara under en sprint.

• SurVive – Samlingsnamn för projektgruppen.

• Trello – En tredjepart webbplats som visualiserar en anslagstavla.

• Unity – Ett verktyg och utvecklingsmiljö för utveckling av grafiska applikationer somspel.

• Unreal Engine – Ett verktyg och utvecklingsmiljö för utveckling av grafiska applikatio-ner som spel.

• VR – Förkortning av virtual reality, vilket översatt betyder virtuell verklighet.

• Werkzeug – Är ett bibliotek som följer Web Server Gateway Interface standarden förPython.

• WYSIWYG – ”What you see is what you get” är en benämning för bland annat ordbe-handlare, som utnyttjar ett användargränssnitt för att kontinuerligt representera resul-tatet av dokumentet i sin utskrivna form.

Del I

Gemensamma erfarenheter och diskussion

1

Kapitel 1

Inledning

Detta dokument handlar om projektgruppen SurVives kandidatarbete. Projektet fokuserar påstudenter och består av att skapa virtuella miljöer av situationer med muntliga presentatio-ner. Beställaren av projektet var Therese Kristoffer Publishing AB som ville utföra projektet urett forskningsperspektiv. Grundidén var enkel och bestod av att skapa ett sätt för studenteratt öva och uppleva att man lyckas med krävande uppgifter. Med hjälp av HTC Vive har ensimulering skapats och användarens beteende analyseras för att ge återkoppling efter simu-leringen.

1.1 Översiktlig beskrivning av projektet

Projektet ägde rum under vårterminen 2017 och är huvudmomentet i kursen TDDD96 Kandi-datprojekt i programvaruutveckling. TDDD96 är en obligatorisk kurs i programmet Civilingenjöri datateknik/mjukvaruteknik vid Linköpings universitet och är avsedd att fungera som en in-troduktion till organiserat projektarbete och uppgifter liknande de i arbetslivet. Produktensom har utvecklats är en VR-simulering för att motverka prestationsångest kring situationeri studentlivet som upplevs som krävande och stressande, som till exempel presentationer.Projektets omfattning är 400 timmar per person vilket resulterade i en omfattning på totalt3200 timmar.

1.2 Motivering

I dagsläget känner sig många studenter nervösa och stressade inför att tala framför publik.Presentationer, redovisningar och tal ses som stressande situationer och är en fobi med storomfattning [2]. Ett sätt att underlätta stressen och nervositeten är att öva på framförandeti en kontrollerad miljö. Detta kan göras med hjälp av VR och har visats fungera i andraapplikationer, till exempel för att bli av med spindelfobi [3].

Det har visats av tidigare studier att prestationen blir bättre om situationen upplevts iVR. Bland annat så har en studie utförts på basketspelare vilket resulterade i att spelarnapresterade bättre i verkligheten [4]. Det har också påvisats att VR-modellering av en resagenom rymden förbereder astronauter inför de mentala påfrestningarna rymden ställer påastronauten [5].

Slutprodukten av projektet gav användaren möjligheten att öva på sitt framförande därpersonen kan välja hur stor och levande publiken ska vara. Personen kan även ändra hurlänge den ska öva för att förbättra sin prestation.

2

1.3. Syfte och mål

1.3 Syfte och mål

Projektet utfördes i utbildande avsikt och dess syften sammanfaller därför med målen frånkursen TDDD96. Ett urval av dessa lyder att studenten, efter avslutad kurs, ska kunna:

• Använda sig av sina kunskaper inom programmering och datalogi för att lösa kom-plexa arbetsuppgifter.

• Formulera en kravspecifikation utifrån ett projektdirektiv.

• Utföra ett projektarbete enligt en projektmodell.

• Planera ett projektarbete och dokumentera detta i projekt- och tidplaner.

• Aktivt medverka till en väl fungerande projektgrupp.

• Ta initiativ och finna kreativa lösningar.

• Använda moderna utvecklingshjälpmedel för mjukvaruutveckling, samt känna till des-sa systems möjligheter och begränsningar.

• Utföra felsökning i stora mjukvaruprojekt med hjälp av moderna utvecklingsmiljöer.

Detta medför att uppdelning av projektets arbetsuppgifter i första hand kommer motiverasav gruppmedlemmarnas roller och intressen för de olika uppgifterna, snarare än dess kom-petens att utföra dem effektivt.

Projektets syfte är att utveckla ett program för VR-simuleringar av muntliga presenta-tionsmiljöer för studenter. Detta för att ge studenter en tryggare miljö att öva på införansträngande presentationssituationer som kan stötas på under utbildningen. På så vis skaanvändaren bli bekvämare i just den situationen som återspeglas i simuleringen.

Produkten ska kunna redovisas och demonstreras i slutet av kursen TDDD96.

1.4 Frågeställning

Projektet medförde följande frågeställningar som skulle svaras på:

1. Vilka val har tagits för att systemet ska hjälpa personen att bli mer bekväm att hållapresentationer?

2. Vilka erfarenheter har vi fått som är överförbara till framtida projekt?

3. Vad har systemanatomin haft för inverkan på projektet?

1.5 Avgränsningar

Systemet kommer att, på kundens begäran, baseras på HTC Vive för att simulera miljöerför att hålla presentationer. Svenskt tal och skrift i simuleringen kommer att prioriteras överandra språk, såsom engelska.

3

Kapitel 2

Bakgrund

Bakgrunden till projektet ligger i att många individer i samhället går genom sitt liv medstress och ångest inför situationer som genomförande av en presentation framför kollegoreller andra människor [2]. Då situationer som dessa är svåra och krävande att öva på harSurVive blivit kontrakterade av Therese Kristoffer Publishing AB för att modellera ovannämnda situation med fokus på studenter i en virtuell miljö. I den virtuella miljön finns detmöjlighet för användaren att själv kunna öva i en säker miljö, där omgivningen ska kunnaförändras i både storlek och interaktionsgrad. På så sätt ska användaren få uppleva ochkänna känslan av att lyckas med att hålla en presentation.

VR-modelleringar är ett oerhört nytt forskningsområde inom datavetenskapen, vilket gör attdet är svårt att hitta forskning som beskriver hur miljöer ska modelleras. Det ser även ut attområdet är på väg att växa vilket är väldigt lovande inför framtiden för VR. Då priset förVR-relaterade produkter fortfarande är relativt högt för gemene person förutses det att närutbudet ökar kommer det bli billigare för gemene person att köpa VR-relaterade produkter.[6]

4

Kapitel 3

Teori

I det här avsnittet beskrivs arbetsmetodik, verktyg och ramverk som använts under projektetsgång.

3.1 Unity

Unity är en plattform för att skapa spel och applikationer i 2D och 3D med stöd för VR.Plattformen inkluderar både en grafisk redigerare för miljöer och animationer samt ett kod-bibliotek för att skriva egen logik. Det går även att kompilera spel till flera olika plattformarså som Android, iOS, Windows och OS X. Unity:s utvecklingsmiljö är begränsad till Win-dows och OS X. Unity är idag en av de vanligaste spelmotorerna för att skapa mobilspel ochfram tills det tredje kvartalet år 2016 hade cirka 5 miljarder Unity-spel laddats ner. [7] Vidareställer Unity en mängd krav på hårdvaran för att kunna exekvera vad Unity beskriver somen generell produkt utvecklad i Unity. Kraven följer enligt nedan:

• Grafikkort – DirectX 9 shader modell 3.0 eller DirectX 11 med GPU funktionalitet pånivå 9.3. [8]

• CPU – Stöd för SSE2 (Streaming SIMD Extensions) instruktionsuppsättning. [9]

Unity stödjer fortsättningsvis nedanstående operativsystem av version enligt nedan eller se-nare versioner:

• Windows XP SP2.

• Mac OS X 10.8.

• Ubuntu 12.04.

• SteamOS.

Vidare till hur kraven för utveckling i Unity. Följande hårdvara krävs: grafikkort – DirectX 9shader modell 3.0 eller DirectX 11 med GPU funktionalitet på nivå 9.3. [8] Sedan stöder Unityutveckling på operativsystemen Windows XP SP2 och Mac OS X 10.8 eller senare versionerav de uppräknade operativsystemen. [10]

3.2 Node.js

Node.js är en variant av JavaScript som är tänkt att användas för att exekveras på servrar.Den är baserad på Googles V8-motor där fokus ligger på att hålla hög prestanda med lågminnesförbrukning. Programspråket är eventbaserat och det ligger redan implementerat påspråknivå till skillnad från andra programspråk där bibliotek måste användas för att kunnautnyttja den eventbaserade modellen. [11]

5

3.3. Scrum

3.3 Scrum

Scrum är en projektstyrningsmetodik, skapad av Jeff Sutherland och Ken Schwaber. TermenScrum kommer ursprungligen från sporten rugby, där Scrum syftar till ett tillfälle där bollenska sättas i spel. Allt detta har sedan översatts till en agil, iterativ samt inkrementell utveck-lingsmetodik.

Figur 3.1: Grafisk illustration av arbetsmetodiken Scrum [12].

Nedan kommer viktiga begrepp inom Scrum förklaras.

• Backlog – En prioriterad lista av aktiviteter för att underhålla, färdigställa och vidare-utveckla produkten.

• Burn-down-graf – Ett diagram som visar aktiviteter eller timmar kvar på projektet.

• Dagligt Scrum – Ett möte som startar arbetsdagen och behandlar kommande och utförtarbete.

• Sprint – Längden av en iteration.

Dessa termer ovan är några av de mest frekvent använda termer inom Scrum-relaterat arbete.

Arbetsflödet i Scrum går ut på att man skapar en product backlog av alla aktiviteter somfinns i projektet. Från product backlogen så skapar man en sprint backlog med de viktigasteaktiviteterna. En sprint pågår sedan i en till fyra veckor med dagliga små sprintar. Allt dettapågår till man har en fungerande produkt. Detta arbetsflöde har visualiserats i figur 3.1. [13]

3.4 Flask

Flask är ett mikroramverk till programspråket Python som är baserat på Werkzeug. Det är tänktatt användas som en enkel variant till en back-end för en webbplats. Direkt från installationav ramverket så finns det stöd för bland annat enhetstestning, REST-API, säkra kakor samtWeb Server Gateway Interface[14].

6

3.5. MySQL

3.5 MySQL

MySQL är en relationsdatabas som använder sig utav det standardiserade programspråketSQL för att hämta och modifiera data [15]. MySQL är väldokumenterat och har öppen käll-kod.

3.6 eXtreme Programming

eXtreme Programming (XP) är en agil utvecklingsmetodik vars fokus ligger på produktivitetoch att kundens krav gått till mötes. Hela processen går ut på att producera det kundenbehöver, beställt och inget extra. Där stor flexibilitet för dokumentation har tillhandahållsför denna utvecklingsmetodik jämfört med äldre utvecklingsmetodiker så som vattenfalls-modellen. eXtreme Programming:s kärna ligger i dess utomordentliga förmåga att väva intestdriven utveckling som sitt främsta vapen för att utveckla högkvalitativ kod. En vital delav eXtreme Programming är parprogrammering, vilket går ut på att två utvecklare samar-betar vid samma dator, för att i sin tur producera mer lättläslig kod samt sprida kunskapmellan kollegor. [17] Vidare kräver också eXtreme Programming att utvecklarna användersig av kodinspektioner för att säkerställa kvalitén på nyutvecklad kod. Kodinspektioner ärnära sammankopplat med testdriven utveckling, då det tillåter automatiska enhetstester attexekveras och evalueras innan koden push:as till projektets repository. [1]

7

Kapitel 4

Metod

Detta kapitel beskriver hur arbetet förts framåt med hjälp av bestämda metoder och verktyg.

4.1 Metoder & verktyg

För hantering av grafik valdes spelmotorn Unity enligt följande resonemang:

• Unity fanns redan installerat på arbetsdatorerna och flera kontaktpersoner på institu-tionen hade erfarenhet av Unity.

• Unity har stöd för många olika VR-headsets, så som HTC Vive och Oculus Rift.

• De flesta av projektgruppens medlemmar hade inte någon erfarenhet av spelmotorervilket gjorde att valet av spelmotor hade mindre betydelse.

Att arbetsstationerna som kunden bidrog med redan hade Unity installerat samt att gruppenkunde fråga kontaktpersoner om råd kring Unity bedömdes uppstartstiden för projektetminska. Detta bedömdes vara av särskild vikt då gruppen inte hade någon tidigare erfaren-het av spelmotorer, vilket annars skulle kunnat minska uppstartstiden.

För att välja utvecklingsmetodik så förespråkades det i en tidigare kurs att använda sigav agil utvecklingsmetodik såsom Scrum och eXtreme programming. En annan anledningtill att välja dessa var att gruppen hade intresse för att testa dessa utvecklingsmetodiker.

Flask var till en början det primära ramverk i projektet för att sedan bli utbytt mot No-de. Anledningen till att Flask valdes som ramverk var till en början på grund av tidigareerfarenheter av det från tidigare projekt. Detta val gjordes av bekvämlighetsskäl. Node komin i projektet av intresset och engagemanget för att lära sig nya tekniker och ramverk. Detberodde alltså inte på att till exempel Flask var otillräckligt för de behov projektet ställde.Node och Flask är väldigt liknande varandra och förflyttningen från Flask till Node varväldigt smidig just på grund av detta.

Motiveringen som ligger till grund för användningen av MySQL var att projektgruppenhade tidigare erfarenheter kring MySQL.

4.2 Utvecklingsmetodik

Under förstudien bestämdes det att projektets utvecklingsmetodik skulle grunda sig i enlättare kombination av Scrum och eXtreme Programming. Fördelarna med metodikernatogs fram och kombinerades, vilket resulterade i en blandning där nyttjandet av användar-berättelse, product-backlog samt sprintar var de främsta fördelarna med Scrum. Ur eXtreme

8

4.3. Metod för att fånga erfarenheter

Programming valdes parprogrammering och kodinspektion som huvudsakliga metoder [16].Denna kombination av utvecklingsmetodiker valdes att kallas sXream Programming, vilketuttalas Scream Programming.

Efter kontinuerliga möten med kunden togs en kravspecifikation fram och med hjälp avden kunde ett antal milstolpar definieras. Dessa bröts sedan ner i mindre aktiviteter somkunde tidsuppskattas och lades in i en tidsplan över tre iterationer. Eftersom Scrum använ-des så illustrerades en backlog i Trello.

För att behålla en struktur och säkerhet bland filerna har GitHub använts för versions-hantering. I GitHub har pull requests aktiverats för att få kodinspektioner att bli ett krav.Detta för att koden ska hålla hög kvalitet när den ska slås ihop med master-grenen. Utöverhög kvalitet ger kodinspektion en inblick i koden för gruppmedlemmarna som inte deltog iutvecklingen av den pull request:en.

Minst ett gruppmöte hölls varje vecka för att se hur arbetet gått sedan föregående mötesamt vad som skulle göras inför kommande möte med hjälp av Trello-korten. Gruppenstidsåtgång med aktiviteterna lades in i en burn-down-graf för att se hur väl tidsplaneringenföljs. Om problem och ovissheter inte kunde lösas snabbt via Slack gicks de igenom undermötena. Planerade möten, arbetstillfällen och övriga relevanta kursmoment lades in i engemensam kalender.

4.3 Metod för att fånga erfarenheter

Med tanke på gruppmedlemmarnas olika kompetenser inom olika områden har flera utbild-ningsseminarier ägt rum för att lära ut kunskap till gruppen. Parprogrammering har ocksåanvänts som verktyg för att jämna ut kunskapsklyftorna. Paren som jobbat tillsammans harskiftats med jämna mellanrum för att få erfarenhet av att arbeta med olika personer och föratt få inblick i andras arbetsgång [17].

Vidare hade gruppen möten minst två gånger per vecka, där aktuella problem togs upptill diskussion. Fortsättningsvis fördes protokoll på dessa möten för att dokumentera beslutssom fattas samt vederbörandes föregående och in planerade arbete.

En lättare variant av iterationsutvärderingar har också utförts av gruppen, dock inte påett formellt möte utan mer i ett öppet klimat parallellt med det vanliga arbetet.

9

Kapitel 5

Resultat

I detta kapitel ges en översikt över vad som uppnåtts i projektet. Detta innefattar en be-skrivning av hur produkten har utvecklats, beskrivningar kring frågeställningarna samt vadgruppen har gjort för att göra utvecklingen hållbar.

5.1 Systembeskrivning

Systemet består av två delsystem, simulatorn i Unity samt webbservern. Dessa behandlas ivarsitt avsnitt i detalj om vad de är uppbyggda av och hur de fungerar.

5.1.1 Systemanatomi

I projektets början skapade projektgruppen en systemanatomi som en obligatorisk del av kur-sen TDDD96. Denna visas i figur 5.2. Anatomin togs fram för att strukturera upp systemetsförmågor och beroenden, de användes som stöd för att skapa andra arkitektoniska doku-ment. Exempel på detta är figur 5.1, som skapades för att komplettera systemanatomin.

10

5.1. Systembeskrivning

Figur 5.1: Illustration av systembeskrivningen för systemet.

11

5.1. Systembeskrivning

Figur 5.2: Illustration av systemanatomin för systemet.

Gruppen fick användning för systemanatomin främst som ett tidigt hjälpmedel i början avprojektet för att få en gemensam uppfattning av vad systemet kommer att bero på och krä-va. Den användes även som ett hjälpmedel för att specificera krav som skulle uppfyllas ochaktiviteter för att uppnå dessa krav. Aktiviteterna ersatte sedan systemanatomins roll somförmedlare av systemets struktur och implementation. Systemanatomin har således haft sominverkan att få samtliga gruppmedlemmar att snabbt förstå hur systemet skulle se ut.

5.1.2 Unity

Unity har bra stöd för funktioner som projektet behöver i form av att skapa grafiska VR-miljöer, hantera spelobjekt och verktyg som förenklar möjligheten till att utvinna mätdata.Det medför att Unity har blivit en grundpelare i projektet. I Unity har en grafisk miljö skapatsmed spelobjekt som kan förändras under sessionen och det har även skrivits kod för att samlain data över användandet av systemet.

Grafisk miljö

Den miljö som simuleringen utspelar sig i ska efterlikna ett klassrum, se figur 5.3. I klassrum-met finns föremål som alla är modellerade i Blender, så som projektor, klocka, bord, stolar,lampor och fläktar. Studenterna är skapade med hjälp av MakeHuman och där skapas ävendet ”skelett” som används vid animering i Unity. Exempel på en av modellerna som ska-pats med MakeHuman för simuleringen kan ses i figur 5.4. På samma sätt har två större rumskapats som är tänkta att efterlikna föreläsningssalar, se figurer 5.5 och 5.6.

12

5.1. Systembeskrivning

Figur 5.3: Grafisk miljö som ska efterlikna ett klassrum.

Figur 5.4: Student skapad i MakeHuman.

13

5.1. Systembeskrivning

Figur 5.5: Grafisk miljö som ska efterlikna en föreläsningssal.

Figur 5.6: Grafisk miljö som ska efterlikna en föreläsningssal.

14

5.1. Systembeskrivning

Interagera med miljön - Beteende

Beteende är det namn på hur studentmodellerna interagerar i den grafiska miljön. Saker somnär, var och i vilken kontext olika animationer spelas upp klassas som beteende.

Figur 5.7: Arvsträd över olika beteenden, där pilar visar arv från grundobjekt till ärvandeobjekt.

Strukturen för hur olika studenter beter sig är organiserat i en trädstruktur som visualiserasi figur 5.7. Alla agenter som har klassen Ambient inkluderar grundläggande beteenden somtill exempel blinka, hosta, klia sig. Mer specifika beteenden som till exempel att somna ärbegränsat till klassen Sovande.

Klassen Student designades som en agent, där en handling agenten kan utföra är tillexempel en animering, att titta på spelaren eller att räcka upp handen. Dessa handlingar hari sin tur vikter som används för att skapa en sannolikhetsfördelning över alla handlingar.Varje gång en handling är utförd i sin helhet slumpas en ny handling fram utifrån sannolik-hetsfördelningen. Detta skapar då livscykeln för en handling, då denna procedur upprepastill simuleringen avslutas.

Det finns två olika typer av handlingar i systemet: animeringshandlingar och kodhandlingar.En animeringshandling spelar bara upp animeringen som tilldelats till den. Kodhandlingarkör den kod som definierar handlingen, till exempel att titta på användaren. Separationen avhandlingarna behövdes då användaren kan flytta på sig i simuleringen medan handlingenför att titta på användaren körs. Ytterligare ett exempel på en kodhandling är handlingen attgöra ingenting en viss tid, som används för att skapa mer levande beteenden genom att intespela animationer hela tiden.

Animationer

För att minimera det annars tidsomfattande arbetet med att skapa animationer så importera-des en del av animationerna från Mixamo. Det är grundläggande animationer som till exem-pel att gå och att sätta sig ned. För de mer specifika rörelserna har egna animationer tagitsfram med de verktyg som finns tillgängliga i Unity. Exempel på animationer som har skapatsär att blinka, gäspa, nicka och lägga sig ner på bordet. Animationerna har sedan kopplatsihop med Unity och de beteenden de hör till.

15

5.1. Systembeskrivning

Interaktion

Interaktion i simuleringen använder sig av HTC Vive:s handkontroller och headset för attsamla in följande data:

• Vad användaren tittar på.

• Vad användaren pekar på för objekt.

• Hur användaren rör på sina händer och huvud.

Det är denna data som sedan kommer att ligga som grund till statistiken av användandet.Exempel på statistik som systemet kan ge är hur ofta användaren svarar på frågor, hurmycket användaren rör på händerna samt hur stor andel av tiden som lades på att titta påolika saker. Data så som positionen på handkontrollerna och huvudet samlas in genom attförst kolla om handkontrollen eller headsetet i fråga har rört sig över ett tröskelvärde. Näranvändaren rör på sig kommer datapunkter samlas in tio gånger per sekund.

För att mäta vad användaren tittar och pekar på kommer både tiden som man tittade påtypen av objekt samt antalet gånger man tittat på objekttypen sparas. Tiderna kan sedanjämföras med varandra och den totala speltiden för att ge en bild över vad användaren harinteragerat med under sessionen. Systemet har stöd för att spara rörelsemönster för vissaobjekt, till exempel att följa efter en student med blicken.

Nätverk

För att lagra data om användandet efter sessionens avslut så skickas data till databasen. Fördetta behövdes en nätverksmodul som kan hantera anrop till servern och ta emot svar frånden. Modulen sköter inloggning av användaren och uppladdning av statistiken till servernoch använder sig av HTTP-standarden för förfrågningar till servern. För att logga in, loggaut, skapa konto och skicka statistik används POST-anrop till servern. Anropen till servernhar samma struktur som anropen från webbsidan. I vissa fall ska en presentation laddas in isimuleringen och då hämtas den från servern med hjälp av ett GET-anrop. Unity:s inbyggdabibliotek, Unity.Networking.UnityWebRequest, användes för samtliga HTTP-anrop.

Personliga presentationer

En viktigt del av simulationen är möjligheten av importera en personlig presentation till si-mulationen. Där användaren kan praktisera sin egna prestation i simulationen för att maxi-mera förberedelsen för användaren.

5.1.3 Webbserver

En del i projektet var att kunna visualisera statistik från simuleringar. För att enkelt genom-föra detta samt representera den mätdata som erhålls, används en webbserver. Webbservernkan i sin tur beskrivas som två delar: en back-end och en front-end.

Back-end

Back-end består huvudsakligen av två delar: en MySQL-databas och ett skal skrivet i Node.jsför anrop till databasen. Databasen innehåller information om registrerade användare ochhåller även koll på inloggade användare. Skalet används för att kunna ta emot anrop somsker när användaren interagerar med front-end och presenterar information ur databasen.

16

5.2. Gemensamma erfarenheter: Vilka erfarenheter har vi fått som är överförbara tillframtida projekt?

Front-end

Front-end består av en webbsida som är skriven i HTML och JavaScript. Beroende på vilkendel av webbsidan som användaren interagerar med kommer olika data att skickas och erhål-las från back-end. Varje användare har ett eget konto på servern som används för att loggain och se data från olika sessioner. Inloggning på webbplatsen visas i figur 5.8 och en tidigversion av hur data presenteras på webbsidan visas i figur 5.9.

Figur 5.8: Inloggningsfönster på webbsidan.

Figur 5.9: En tidig version av hur mätdata presenteras på webbsidan.

5.2 Gemensamma erfarenheter: Vilka erfarenheter har vi fått som äröverförbara till framtida projekt?

Detta avsnitt ämnas att presentera några av de erfarenheter som gruppen fått. Detta inklude-rar positiva erfarenheter kring arbetet samt några av de problem som gruppen stött på.

5.2.1 Teambuilding

Ett skäl till att gruppen fungerat så bra tillsammans har varit att gruppen känt sig som ettteam. Detta tros ha påverkats av gruppens alla gemensamma aktiviteter vilket till exempel ärgrilldag, utelunch och tårtfika. Under projektet så har gruppen fått tillgång till en lokal vilkethar blivit en naturlig samlingsplats för alla att arbeta i och har gjort att gruppen har kunnatdela erfarenhet och att be varandra om hjälp.

5.2.2 Animationer

Ett stort tekniskt bekymmer som uppstod under projektet vara animationer av 3D-modeller.Till en början visade det sig vara alldeles för tidskrävande att skapa alla animationer för hand,varpå några gratisanimationer från Mixamo användes. Det uppstod dock problem kring huranimeringssystemet i Unity fungerade, vilket ledde till att mycket tid i början av projektet laspå att få animationer att fungera. Gruppen insåg även att arbetet för att få alla animeringar

17

5.2. Gemensamma erfarenheter: Vilka erfarenheter har vi fått som är överförbara tillframtida projekt?

att se perfekta ut skulle ta mycket mer tid än vad det kunde ge. Istället skapades en separataktivitet för att förbättra animationerna senare i projektet, i mån av tid.

5.2.3 Sen ankomst

För att motverka sen ankomst infördes en kassa för fikapengar. Varje gång en person kommersent utan god anledning till ett möte behöver den tillföra pengar i kassan. Reglerna var att ompersonen kommer mellan en och tio minuter försent får den en skuld på tio kronor. För varjeytterligare tio minuter sent ökar skulden med tio kronor med ett tak på 50 kronor per möte.Trots detta så har projektgruppen haft vissa problem med att flera personer kommer sent tillmöten. Vid flera möten togs det upp att gruppmedlemmar blev irriterade på personer sominte var i tid men trotts detta vid togs inte några åtgärder. Ur detta utvinns erfarenheten omatt det är problematiskt med sen ankomst samt svårhanterat.

5.2.4 Datorproblem

Ett problem som uppstod under projektets gång var att det inte fanns tillräckligt många da-torer i arbetsrummet. Detta tillsammans med att en av simuleringsdatorerna inte gick attanvända på grund av störande fläkt vilket skapade brist av arbetsstationer i lokalen. Proble-met löste sig genom att några i gruppen hade bärbara datorer som klarade av att köra Unityoch att alla inte behövde arbeta i Unity. Den erfarenhet som skapades av detta problem varinsikten av att det finns ett maximalt antal personer som kan arbeta vid samma datorplats.Parprogrammering löste detta problem för de som satt vid de större skärmarna men inte förde som arbetade på laptops. Skärmarna på dessa upplevdes som för små för att sitta mer änen person kring.

5.2.5 Git

Under projektets gång har gruppens samlade och individuella erfarenheter kring Git förbätt-rats markant. Vid starten av projektet använde gruppen sammanlagt tre grenar för att arbe-ta på. Det som skedde vid första demonstrationstillfället var att all utvecklad funktionalitetskulle integreras ihop till en fungerande simulering. Det resulterade i sin tur att en demon-strationsförberedelse gren skapade. Den grenen blev sedan kvar efter demonstrationen somen sekundär master-gren som flera jobbade på. Detta gav upphov till att den grenen aldrigblev färdigutvecklad och stoppade då effektivt gruppens förmåga att utföra pull request. Detproblemet hanterades genom att under en tvådagarsperiod införa en feature freeze och enbartbearbetat redan utvecklad funktionalitet till att nå en tillräcklig nivå för att bli accepterad ini master-gren via en pull request.

Figur 5.10: Demonstration av Git-arbetsflöde.

18

5.3. Vilka val har tagits för att simuleringen ska hjälpa personen att bli mer bekväm?

Händelsen resulterade i att gruppen hädanefter implementerade en bättre Git-användning.Där en aktivitet ur backlog:en som ska arbetas med grenas av från master-grenen till enaktivitetsgren för att sedan när aktiviteten är färdigställd slå ihop aktivitetsgrenen medmaster-grenen. Detta för att säkerställa att master-grenen är kontinuerligt uppdaterad medny testad och kommenterad kod.

I slutskedet av projektet hade gruppen nått en bra mogenhetsnivå i Git-användandet ocharbetsflödet som illustreras i figur 5.10. Figuren är färgkodad för att tydligare beskriva hurolika grenar hör ihop. Gula pilar representerar en utcheckning av en gren till en annan ochsvarta pilar att man slår ihop aktivitetsgren till submodulgrenen. Detta arbetsflöde är precisdet som beskrivs av Atlassian [18].

5.3 Vilka val har tagits för att simuleringen ska hjälpa personen att blimer bekväm?

Människorna i simuleringen är skapade för att vara lite ”dumma” men samtidigt levande.Tanken med att göra lite dumma studenter är att simuleringen inte ska vara för verklig. Omen simulering är för verklighetstrogen kommer användaren att upptäcka varje liten sak somavviker från den riktiga världen. Det är viktigare att skapa en levande simulering för atthjälpa personen att bli mer bekväm [19].

Ett försök att kunna hjälpa användaren att bli bättre är att samla in användardata undersimuleringen. Den data som samlas in analyseras sedan och visas både i form av grafer samtuppmaningar som ska hjälpa användaren prestera bättre vid nästa tillfälle [20].

Alla personer är olika bekväma med att hålla en presentation. Därför kan simuleringenanpassas efter den svårighetsgrad som användaren vill ha. Personer som tycker det är krä-vande att hålla en presentation kan börja med en liten sal med få störande moment. Närpersonen känner sig mer bekväm finns det möjlighet att öka storleken på rummet samt ökaantalet störande moment. Moment som anses som störande är antalet frågor användaren får,antalet åskådare eller bakgrundsljud från till exempel fläktar.

5.4 Hållbar utveckling

Här listas några beslut som togs under projektets gång för att upprätthålla en god och hållbarstruktur kring projektet:

• Stänga av datorerna och släcka lamporna när vi inte är i arbetsrummet.

• Maximal tid för användning och varna användaren när hen har suttit för länge.

• Digitala manualer och inte fysiska vid stationen.

• Färre interaktioner mellan webbservern och Unity gör det mer energieffektivt.

Dessa punkter är åtagande som gruppen har använts för att öka hållbarheten.

19

Kapitel 6

Diskussion

I detta kapitel diskuteras resultaten, metoderna samt hållbarhetsaspekten hos arbetet ochprodukten. Detta inkluderar diskussioner kring det egna systemet och metoden kring ut-vecklandet samt alternativ som är värda att betrakta.

6.1 Resultat

Presentationens bilder samt egna anteckningar skulle laddas in i simuleringen för att ge såbra stöd för en redovisning som möjligt. I nuläget konverteras en PDF av presentationen ochanteckningarna till JPEG-bilder i simuleringen som sedan kommer att renderas, då Unityinte har stöd för att rendera PDF:er direkt. Detta kunde ha gjorts på ett annat sätt genom attistället för att konvertera PDF-filen så kunde man ha lagt ner mer tid på att hitta ett eller ut-veckla ett eget PDF-renderingsprogram som kunde användas i simuleringen. Konsekvensenav detta har varit att konverteringen från PDF till JPEG-bilder tar tid, vilket skulle behövaförbättras.

Ett annat val som gjordes i projektet var att systemet skulle visa användarens statistikpå en webbsida, där användaren kan få råd om förbättringsmöjligheter. Ett annat alternativhade varit att visa detta efter en session i simuleringen och ge råd om förbättringsmöjligheter.

Varför en systemanatomi gjordes var på grund av att det ingick som obligatoriskt mo-ment i kursen TDDD96. Gruppen specificerade senare en systemöversikt som var merdetaljerad och som hjälpte ytterligare med att ta fram aktiviteter. Användandet av just ensystemanatomi kan ha varit överflödigt, särskilt om man senare skapar andra dokument föratt komplettera anatomin.

Vid leverans har majoriteten av kraven på systemet uppfyllts men det finns många för-bättringsmöjligheter. För att produkten ska bli bättre kan en större analys av användardatautföras. Då kan mer och, förhoppningsvis, bättre återkoppling ges till användaren. Simule-ringen kan göras mer verklighetstrogen genom att förbättra både ljud och grafik. På grundav okunskap och saknad av utrustning har ljudfilerna som spelas upp under simuleringvarierande kvalitet.

6.2 Metod

I detta avsnitt diskuteras de viktigaste metoderna som valdes att användas i projektet. Dettamed fokus på vad för konsekvenser valet kom med uppföljt av en diskussion kring alternati-va lösningar.

20

6.3. Vilka val har tagits för att simuleringen ska hjälpa personen att bli mer bekväm?

6.2.1 Användandet av Unity

Ett av de tidigaste valen gruppen hade var valet av spelmotor. Gruppen visste att en spel-motor skulle behövas för att färdigställa kundens produkt och då stod valet mellan Unityeller Unreal Engine. Unity valdes som grund för simuleringen för att arbetsstationerna somkunden bidrog med hade Unity samt att en gruppmedlem hade erfarenhet av Unity.

När Unity valdes som grafikmotor så uteblev alla andra alternativ eftersom det är myc-ket omständligt att byta spelmotor för att man då behöver skriva om mycket kod. Även omdet är omständligt att byta spelmotor så ska det inte vara någon omöjlighet att byta till UnrealEngine [21]. Detta för att det finns flera likheter i uppbyggnaden och det medför att ett byteär möjligt. Att gå från Unity till Unreal Engine verkar vara det enda bytet av spelmotor somhar en guide för hur man skulle kunna gå till väga. Det tyder på att andra spelmotorer harstörre skillnader och är betydligt mycket omständligare att byta till. Eventuella konsekvenserav att projektet är låst till Unity är dess beroende på Unity:s fortsatta utveckling av grafikmo-torn. Under utvecklingen av detta projekt utnyttjades Unity:s licensvillkor som innebär attspelmotorn kan används gratis för projekt med liten omsättning. Om Unity väljer att ändrasin hantering av licenser skulle det kunna innebära att projektet inte kan få någon vidareutveckling på grund att det inte finns pengar till en licens.

6.2.2 Skapandet av animationer

I nuläget är många av de animationer som används av studenterna inte så levande som be-hövs för att skapa en bra upplevelse. De animationer som laddades ner från Mixamo be-dömdes vara levande, men gruppens egna animationer var inte. Detta kan ge upphov tillen konflikt i vad användaren kan förvänta sig. Ett alternativ till att göra alla animationer förhand vore att istället använda sig av Inverse Kinematics, vilket skapar animationen givet enstartpose och en slutpose. Förutom att detta hade underlättat arbetet med animationer hadedet gett ett mer konsekvent utseende hos studenternas beteenden. Detta tros kunnat öka hurlevande studenterna i simuleringen upplevs. Det hade även kunnat ge en mer realistisk si-mulering, då Inverse Kinematics även kan användas för att se till att studenterna sitter ner påföremål i miljön.

6.2.3 Användandet av Node.js

Att använda Node för att skriva back-end var ett väldigt enkelt val. Det grundade sig i attprojektgruppen ville prova ett nytt programspråk som ingen hade använt sig av tidigare, mensamtidigt ett programspråk som inte är för okänt. Att använda ett nytt programspråk är noginte det absolut bästa att göra om man vill uppnå resultat snabbt. Men då detta är i utbild-ningssyfte och vi vill lära oss nya programspråk och tekniker så valdes Node att användasför detta.

6.3 Vilka val har tagits för att simuleringen ska hjälpa personen att blimer bekväm?

Studenterna i simuleringen är skapade för att verka levande men lite ”dumma” eftersomdet går åt mycket resurser för att ha realistiska modeller för studenterna. Det bedömdes attdetta var alldeles för belastande för att vara en möjlighet. En hypotes har inom gruppenformulerats med hjälp av handledare understödd av Uncanny Valley-teorin [24] på följandevis: en vacker grafisk modell av studenterna skulle kräva mer utförlig interaktion mellanstudenterna och användaren för att skapa en illusion av verkligheten. Enligt hypotesenskulle det inte tjäna något syfte att ha en realistisk grafik om miljön inte beter sig realistiskt.Det skulle leda till en konflikt mellan vad användaren ser och vad användaren förväntar sig

21

6.4. Gemensamma erfarenheter

hända. Att istället använda människoliknande modeller som verkar levande skulle det enligthypotesen skapa en bättre upplevelse för användaren. Då förväntningar på hur realistiskastudenterna i simuleringen beter sig kommer vara lägre.

Ett alternativ till de nuvarande modellerna och animationerna hade varit att satsa på merrealistiska modeller och animationer. Kravet för det blir att hårdvaran dels kan exekverasystemet med den ökade belastningen samt att animationerna ser mer realistiska ut. För attuppnå detta kan animationer skapas från rörelsemönster istället för att skapas för hand. Dåskulle variationen hos studenterna komma ifrån att spela in många personers rörelsemönsteroch då inte bara baseras på modellens utseende.

Med hjälp av den data som samlas in kommer förbättringsförslag ges till användarenoch statistik över användningen presenteras. Om förbättringsförslagen inte är rimliga, ellerom statistiken som visualiseras inte förstås kommer det inte hjälpa användaren att se vadsom kan förbättras med presentationen. Vidare är det viktigt att systemet genererar förbätt-ringsförlag som tolkas på ett passande sätt. Detta för att förmedla förbättringsförslag på ettkonstruktivt sätt till användaren.

Simuleringen kan anpassas efter den svårighetsgrad som användaren vill ha genom attjustera hur miljön ser ut. Användaren kan till exempel justera hur mycket publiken inte-ragerar med användaren, publikens storlek samt rummets storlek. Detta ger användarenmöjlighet till att skapa lämpliga scenarion anpassade för användarens behov. Detta i jäm-förelse med att bara erbjuda ett scenario tros göra upplevelsen mindre ansträngande föranvändaren, då användaren har kontroll över hur scenariot ska se ut och hur det ska spelasupp.

6.4 Gemensamma erfarenheter

I detta avsnitt diskuteras några av de främsta erfarenheterna gruppmedlemmarna fått kringarbetet och utvecklandet av produkten som är överförbara till framtida projekt.

6.4.1 Sen ankomst

Tanken med en fikakassa var att den skulle motverka sena ankomster till viktiga händelser,men det är oklart hur bra det fungerade. Kassan innehöll mer än 1000 kronor vid projektetsslut. Erfarenheter som kan dras av detta är att fikakassan behöver ha en annan struktur föratt det ska motverka sena ankomster. En till anledning till att fikakassa inte fungerade så brakan vara att när man kan betala för att man är försenad så har man redan blivit bestraffadoch behöver därför inte känna någon skuld. Men om man inte behöver betala något så harman inte blivit bestraffad och kan då känna mer skuld.

En förbättringsmöjlighet hade varit att göra avgiften större, så att det skulle kännas vär-re om man kommer sent. En variation av detta förslag är att de första tio minuterna har enhögre avgift än de övriga minuterna som överträds. Exempelvis skulle man kunnat ha enstartavgift på 50kr de första tio minuterna följt av 10kr för varje extra tio minuter man är sen.Detta skulle kunna minska antalet förseningar som sker i början av ett pass utan att ge en ilängden allt för stor avgift.

6.4.2 Varierande kunskapsnivå

Vissa personer upplevde att det blev kunskapsskillnader mellan de gruppmedlemmar somlade ner mycket tid i början av projektet jämfört med de som lade ner mer tid i slutet. Per-sonerna som arbetade mycket i början fick bra kunskap om systemet samt de verktyg som

22

6.5. Arbetet i ett vidare sammanhang

användes vid utveckling. Parprogrammering var tänkt att motverka detta, vilket det kanskegjorde, men inte i tillräckligt stor utsträckning. Parprogrammering utfördes inte hela tiden pågrund av att det var praktiskt svårt tidsmässigt. Om gruppen hade varit mer flitig med par-programmering kunde båda de två problemen ha motverkats. Med mer parprogrammeringhade det blivit mindre tidsskillnad mellan gruppmedlemmarna samt att den genomsnittligakunskapsnivå antagligen hade ökat.

Det fanns ingen underliggande tanke med att vissa arbetade mer tidigare i projektet änvad andra i gruppen gjorde. Utan något som inträffade för att några av projektmedlemmarnaville sätta igång hårdare i början än vad andra ville göra.

6.5 Arbetet i ett vidare sammanhang

Då samhället utvecklas och miljömedvetenheten ökar måste även mjukvarubranschen anpas-sa sig till dessa nya spelregler.

6.5.1 Samhällsaspekter

Systemet som utvecklats är tänkt att användas som ett utbildningsverktyg, en plattform förde som vill bli bättre på att presentera och redovisa inför en publik. Förhoppningen är attfärre ska tycka att prata inför en publik är en krävande situation. Om fler finner sig bekvämamed att tala inför andra får fler möjligheten att påverka allt från miljö och politik till att säljaprodukter till kunder.

Systemet i sig kräver dock en beräkningskraftig dator förutom VR-headsetet i sig, vilketbåde kostar mycket och kan leda till en överkonsumtion av varor som inte kommer använ-das länge. Att systemet kostar mycket påverkar vilka som kan få möjligheten att användadet. Detta faktum förbättras om man kan få skolor, företag och kommuner att köpa systemetoch att de sedan anordnar stationer med systemet istället för att varje privat användarebehöver skaffa sig all utrustning som krävs. Detta hoppas även förhindra överkonsumtionenav utrustning som inte kommer användas senare, givet att en köpare som en skola eller ettföretag, nyttja produkten mer effektivt.

6.5.2 Hållbar utveckling

Eventuella för- och nackdelar med de saker som togs upp under rubriken Hållbar utvecklingunder resultat kommer här att diskuteras.

• Stänga av datorerna och släcka lamporna när ingen är i arbetsrummetGenom att stänga av datorerna och släcka lamporna efter ett arbetspass minskas ener-gianvändningen under utvecklingen. Många andra datorer på universitet stängs inteav när de inte används. Om det inte sitter någon vid datorn finns det inte någon an-ledning att den är på. Däremot kontrolleras stora delar av lamporna på universitet avrörelsedetektorer och det samma gäller lamporna i arbetsrummet. Intressant nog ver-kar rörelsedetektorn inte sitta i arbetsrummet utan i korridoren utanför. Det medför attlamporna i arbetsrummet tänds när någon går i korridoren om den inte stängts av medlysknappen.

• Maximal tid för användning och varna användaren när användaren har suttit förlänge.Genom att varna användaren för att ha spelat under en längre tid så kommer använda-ren att ta fler pauser. Detta tros förbättra koncentrationsförmågan och leda till en bättreträningsmiljö för användaren. Vilket kommer se till att användaren förbättras och blirmer bekväm i en snabbare takt. [22]

23

6.5. Arbetet i ett vidare sammanhang

• Digitala istället för fysiska manualer vid stationenGenom att erhålla digitala manualer eller ha manualer på en webbsida så kommer ut-skrifter inte behöva göras. På detta sätt undviks behovet av att byta ut manualer närde blir för slitna eller när de blir utdaterade. Dessutom så sliter fysiska manualer merpå miljön då de skrivs ut på papper. Den kostnaden försvinner då genom att ha digita-la manualer eftersom att det inte behöver produceras papper och därmed inte belastamiljön.

• Färre interaktioner mellan webbservern och Unity gör det mer energieffektivtGenom att ha färre interaktioner mellan webbservern och Unity så kommer projektetatt förbruka mindre energi. Det kan ske genom att skapa större paket och skicka färregånger istället för små paket och fler gånger. Under projektets gång används en serversom var tillhandahållen av institutionen vilket då var en del av deras stor server. Detmedför en energibesparing på cirka 10% när system konfigureras för att skicka mycketdata vid få tillfällen. Trotts detta togs beslutet att skicka mycket data få gånger eftersomom system kommer i drift kan det ske på en extern server och då kan mer energi sparas.Eftersom när det inte kommer någon data kan serverns strömspararåtgärder användas.[23]

• Minska andelen människor som lider av social fobiUr ett social hållbart perspektiv har produkten som utvecklats en positiv effekt, fram-förallt under antagandet att produkten kommer i vida användning. Förhoppningsviskommer användare av produkten att bli bättre och inte undvika att prata inför andramänniskor. Det innebär att fler kommer på ett bättre sätt att sprida kunskap i samhälletoch samhället blir mer upplyst. Produkten skulle kunna ha positiv effekt på kommuni-kation mellan enskilda människor också eftersom människor blir mer självsäkra.

24

Kapitel 7

Slutsatser

Produkten uppfyllde dess kravspecifikation och levererades till kunden efter några mindrejusteringar. För att få systemet att hjälpa användaren med att bli bekvämare med att hållapresentationer utformades en publik som både känns levande med sina animationer och stelmed sitt utseende, för att påminna användaren om att den är i en simulering. Användarenkan även välja storlek på publiken, hur mycket publiken interagerar med användaren ochstorleken på miljön för att ge användaren möjlighet att själv sätta svårighetsgraden på si-muleringen. Huruvida den färdiga produkten faktiskt gör skillnad för användare kan intebesvaras i denna rapport. För att kunna besvara denna fråga krävs en rapport som utvärderaranvändares presentationer före och efter de övat i simulatorn.

De viktigaste lärdomarna som gruppen tar med sig är:

• Tillgången till ett gemensamt arbetsrum och många gemensamma aktiviteter gör myc-ket för hur gruppen arbetar tillsammans.

• Om man har en straffavgift för att komma sent bör denna vara anpassad så att personerinte kommer sent, till exempel via högre avgift.

• Varierande kunskapsnivå i projektet kan jämnas ut genom att använda parprogramme-ring flitigt.

Systemanatomin har legat som grund för att formulera krav och aktiviteter och har använtssom diskussionsmaterial när det gällde systemets design. Andra typer av dokument medliknande innehåll kan ha använts istället för en systemanatomi, som till exempel en system-beskrivning. Det viktiga med ett sådant dokument är att det finns och kan användas för attförmedla systemets design till alla i gruppen. Ett sådant dokument har för gruppen haft sominverkan att hela gruppen snabbt kunde förstå hur systemet skulle designas.

Sammanfattningsvis har en produkt utvecklats som förhoppningsvis kan hjälpa människorlindra sin fobi för presentationer. Projektet har medfört att medlemmarna i projektgruppenhar införskaffat nya erfarenheter om områden mjukvaruutveckling i grupp, grafiska miljö-er för VR, utveckling av front-end och back-end samt utvecklingsmetodikerna Scrum ocheXtreme programming.

Som avslut på denna rapport önskar författarna att väcka intresse för området VR ochframtida forskningsprojekt inom branschen.

25

Del II

Individuella bidrag

26

7.1. Översikt individuella bidrag

7.1 Översikt individuella bidrag

Detta avsnitt beskriver kort vad de individuella bidragen kommer att behandla.

A Skillnader i utveckling av REST-API i Node.js och Python

När utvecklingen av en webbplats ska göras så finns det många olika sätt att göra detta på.Denna del behandlar utvecklingen av ett REST-API på back-end sidan av webbplatsen. Vilketprogramspråk lämpar sig bäst för detta och vilka större skillnader finns det mellan dessaprogramspråk.

B Versionshanteringssystem vid grupparbeten

Det finns två stycken versionshanteringssystem, centraliserade och distribuerade, men vilketgynnar större grupparbeten? Detta individuella bidrag kommer att ge en överblick på dessatvå system och sammanställa skillnaderna.

C En grupps utveckling under ett projekt

En projektgrupp är näst intill aldrig perfekt från början, utan den utvecklas under tiden grup-pens medlemmar arbetar tillsammans. Vissa grupper blir inte heller okej under ett helt pro-jekt. I detta bidrag gås det igenom hur just vår grupp utvecklas, från början till slut, i ettScrum-liknande projekt.

D Jämförelse mellan komponenter och arv inom spelutveckling

För att kunna utveckla ett system som använder sig av Unity är det klokt att betänka designenav objekten som kommer att användas i simuleringen. Unity använder sig av en entitets-komponent-design istället för en traditionell arvsbaserad design. Alla i gruppen hade intekoll på vad detta innebar. Därför valdes det att skrivas om vad de är och vad de medför förarkitekturen och kodbasen samt hur de skiljer sig åt.

E Teamledarens roll i agil mjukvaruutveckling

I det här bidraget kommer teamledarens roll att diskuteras och analyseras genom projektstre olika faserna; före, under, efter. Ett extra fokus på projektstyrningsteknikerna Scrum ocheXtreme programming kommer även att inkluderas.

F Virtual Reality - Vad är verkligt

När man pratar om Virtual Reality, VR, så pratar man om virtuell verklighet. Det vill sägaen virtuellt skapad värld som efterliknar den verkliga världen, men inte med samma konse-kvenser för hälsan som den verkliga världen kan ha. Men vad är det egentligen människorupplever som verkligt och hur lätt är det att lura hjärnan?

G Testning vid spelutveckling i Unity

Testning av mjukvara kan ske på många olika sätt. Unity har flera inbyggda verktyg somska underlätta. Dessa verktyg beskrivs tillsammans med andra metoder som kan vara an-vändbara vid utveckling av grafiskt komplex mjukvara. Förslag hur testning utföra på närutveckling sker med grafikmotor Unity nämns.

27

7.1. Översikt individuella bidrag

H Påverkan av att skriva lokalt eller över cloud

På grund av att det ligger en sådan vikt i hur väl utförd projektets dokumentation är, är detviktigt att inte låta faktumet att hela gruppen deltar i skrivandet påverka kvaliteten på doku-mentet. Att se till att dokumenten upplevs som skrivet av en författare, även om det är fleraindividers bidrag. Enigheten i dokumenten är viktig för att läsaren inte skall behöva anpassasig utefter skrivstilen som då kan skifta från stycke till stycke. Hur går man då tillväga för attenkelt skriva, korrekturläsa, och versionshantera dokument i grupper?

28

Bilaga A

Skillnader i utveckling av REST-API iNode.js och Python

Författare: Anton Dalgren

A.1 Inledning

När en webbtjänst ska utvecklas kan det finnas många olika sätt att göra det på. Det vanli-gaste idag är ett system där tjänsten är uppdelad i två olika delar; front-end samt back-end.I det här kapitlet kommer skillnaderna mellan att utveckla ett REST-API i programspråkenJavaScript samt Python för back-end delen att utredas.

A.1.1 Syfte

Syftet med denna rapport är att utveckla och visa på eventuella skillnader mellan de olikaprogramspråken och ramverken som används för att utveckla ett REST-API, samt att reda utvilket ramverk som passar bäst.

A.1.2 Frågeställning

1. Vilka större skillnader finns det mellan de olika programspråken?

2. Vilket programspråk lämpar sig bäst för utveckling av ett REST-API?

A.2 Bakgrund

Det finns idag många olika sätt att bygga ett REST-API på med många olika ramverk i väldigtmånga olika språk. Hur ska man gå tillväga för att välja ett ramverk som passar just detspecifika projektet? Denna rapport kommer att behandla två olika sätt att göra detta på.

A.3 Teori

JavaScript är ett dynamiskt och svagt typat skriptspråk som körs i webbläsaren för att modi-fiera HTML-element vid anrop [25]. Node.js är baserat på JavaScript men har skrivits om tillatt kunna exekveras på en server istället för enbart i webbläsaren. Detta bidrar till att utveck-laren bara behöver kunna ett programspråk för att kunna arbeta hela vägen från back-endtill front-end [11]. Likt JavaScript är Python också ett dynamiskt svagt typat skriptspråk somär skapat för ett användande inom generell programmering [26].

29

A.4. Metod

Begreppet RESTful Web Services används ofta inom webbutvecklingen. REST står för Re-presentational State Transfer, vilket är en IT-arkitektur för att beskriva maskin-till-maskinkommunikation. Inom en webbtjänst används ofta en back-end som är representerad i formav ett REST-API. Front-end sidan gör ett HTTP-anrop till back-end och får ett svar som oftastär av den struktur som ett JavaScript-objekt har, kallat JSON.

Tabell A.1: Exempel på HTTP anrop till ett REST-API innehållande studenter

Adress Metod Operation/Student GET Hämtar alla studenter/Student POST Skapar en ny student/Student/<StudentID> GET Hämtar en specifik student/Student/<StudentID> PUT Uppdaterar en specifik student/Student/<StudentID> DELETE Tar bort en specifik student

I ett HTTP-anrop till ett REST-API används oftast de vanliga metoderna GET, POST, PUT ochDELETE. Dessa metoder berättar för ett REST-API vad den ska utföra för operation på deninkommande adressen. I tabell A.1 finns ett exempel listat på vad ett REST-API gör vid deolika HTTP-metoderna till en specifik adress [27].

A.4 Metod

Denna rapport kommer att beskrivas mestadels med information från artiklar samt doku-mentation som beskriver hur de olika programspråken fungerar. Dokumentation kring deolika ramverken kommer att stå till grund för resultatet. Det kommer även att förekommareflektioner kring vissa delar i de olika programspråken och ramverken som kommer att tasupp.

A.5 Resultat

Här kommer information om och skillnader mellan de två olika programspråken Node ochPython, samt ramverken Express och Flask att presenteras.

A.5.1 Node.js

Node är baserat på Googles V8-motor som till största del är skrivet i C och C++ där fokusligger på att hålla hög prestanda med låg minnesförbrukning. V8-motorn är tänkt att använ-das till att köra JavaScript i Google Chrome medans Node är tänkt att användas för att hållaigång serverprocesser.

För att köra parallella processer i Node används inte multitrådning som i många andraspråk, utan det är ett eventbaserat språk som använder sig av asynkron I/O. Till skillnad motandra programspråk när den eventbaserade modellen vill användas, så krävs bibliotek fördetta, men i Node är det implementerat redan på språknivå [11]. Det gör att JavaScript passarperfekt till detta då det stödjer så kallade callbacks. Det är en funktion som är parameter tillen funktion och körs när den funktionen är klar. Till exempel när en fil har lästs in från diskså körs funktionen som har blivit inskickad som en callback.

A.5.2 Python

Python är ett interpreterat programspråk, vilket innebär att koden kompileras i samma stundsom den körs. Detta gör att det är svårt att hitta fel som skulle hittas vid kompilering i ett

30

A.5. Resultat

kompilerat programspråk, till exempel Java. Sådana fel kan vara att försöka sätta en variabelsom innehåller en sträng till en siffra eller att glömma returnera ett värde i slutet av enfunktion.

Parallella processer i Python kräver till skillnad från Node multitrådning. Detta kan gö-ras med hjälp av funktionerna i det inbyggda biblioteket threading. Biblioteket är skapatför just trådbaserad parallellism [28].

A.5.3 Express

Express är ett ramverk för att bygga REST-API i Node. Det vanligaste sättet att använda sigav Express är genom att installera det genom Nodes egna bibliotekshanterare NPM. För attinstallera ett bibliotek som skapar ett fungerande Express-projekt se Kodexempel A.1

1

2 $ npm i n s t a l l express´generator ´g3

Kodexempel A.1: Kommando för installation av bibliotek för att skapa ett fungerandeExpress-projekt.

Figur A.1: Filstrukturen över det färdiga Express-projektet.

När detta bibliotek sedan exekveras från terminalen skapas det ett projekt med en filstrukturenligt Figur A.1 som är fungerande och detta är vad denna rapport har utgått ifrån.

REST-API strukturen

För att kunna bygga ett grundläggande REST-API i Express krävs det inte särskilt mycketkod. I Kodexempel A.2 finns ett kodexempel för hur HTTP-anropet POST kan gå till.

I samma listing har vi ett tydligare exempel på hur callbacks i JavaScript ser ut. Den andraparametern till funktionen router.post() är ett exempel på just en callback-funktion. Detär den funktionen som kommer att köras när eventet POST-anrop till adressen “/sign_in“avfyras.

1

2 router . post ("/sign_in" , function ( req , re s , next ) {3 var username = req . body . username ;4 var password = req . body . password ;5 password = sha256 ( password ) ;6 r es . send ( { success : true , message :"Success signing in" } ) ;7 }8

Kodexempel A.2: Kodexempel för att göra en inloggning med HTTP-anropet POST i Express.

31

A.6. Diskussion

A.5.4 Flask

Flask är det ramverk som valts att använda i detta projekt för att skapa ett REST-API i pro-gramspråket Python. Det är ett mikroramverk som är baserat på Werkzeug [14]. Även dettaramverk är smidigt att installera. På samma sätt som Node har sin bibliotekshanterare haräven Python sin egen, PIP. För att installera Flask gör enligt Kodexempel A.3.

1

2 $ pip i n s t a l l F lask3

Kodexempel A.3: Kommando för installation av biblioteket Flask

REST-API strukturen

Strukturen för att bygga ett grundläggande REST-API i Flask är väldigt likt den för Express.Koden beskriver för interpretatorn vilken funktion som skall exekveras för en specifik adressvilket beskrivs enligt Kodexempel A.4.

1

2 @app . route ( "/s ign_ in " , methods =[ "POST" ] )3 def s ign_ in ( ) :4 username = request . form [ " username " ]5 password = request . form [ " password " ]6 re turn j son . dumps ( { ’ success ’ : True , ’ message ’ : ’ Success s igning in ’ } )7

Kodexempel A.4: Kodexempel för att göra en inloggning med HTTP-anropet POST i Flask.

Till skillnad från Node och JavaScript använder sig inte Flask utav callback-funktioner utanhär används en dekoratör. Dekoratörer är till för att ha möjlighet att utöka funktionalitetenhos en funktion. Route-dekoratören används för att hantera de HTTP-anrop som inkommertill en viss adress.

A.6 Diskussion

Funktionaliteten i ramverken är väldigt liknande varandra men sättet koden för ramverken ärskriva är väldigt olika. Detta har att göra med att de är skrivna för just det språket de är tänktaför. Det gör att strukturen för att skriva kod i det ramverket är bundet till den kodstandardsom finns i språket. Det blir på så sätt lättare att utveckla ett system i ett ramverk för ettprogramspråk som man känner sig bekväm med.

32

A.6. Diskussion

Figur A.2: Exempel på callback-hell där callback-funktioner är rödmarkerade.

Inom JavaScript är det vanligt att alla funktioner som sköter någon typ I/O har en callbacksom sista parameter. När detta har gjorts i detta projektet har det varit i form av kommunika-tion med en databas. Här är det vanligt att det kan bli en lång kedja av anrop till databasen.Det gör koden mer komplex och svårare att förstå. Inom JavaScript världen går detta underbenämningen “callback-hell“, vilket exemplet i Figur A.2 illustrerar.

33

A.6. Diskussion

Figur A.3: Kodexempel där Promises används.

För att förhindra detta har Promises tagits fram i JavaScript. Det skulle kunna förklaras somen variabel som får ett värde i framtiden. Denna variabel tilldelas ett värde om anropet lyckasoch tilldelas ett fel om anropet misslyckas av någon anledning [29]. I detta projekt har Promi-ses använts för att få koden att vara snyggare och mer lättläst men med samma funktionalitetsom i callback-hell exemplet, se Figur A.3. Detta får koden att ge skenet av att vara synkrontrots att den egentligen är asynkron då den kommunicerar med en databas. Projektgruppenhar valt att benämna detta med “Gods-Promise“.

Figur A.4: Kodexempel i Python för kommunikation med databas.

34

A.7. Slutsatser

Eftersom att Python är ett sekventiellt programspråk och hanterar all sin I/O synkront såfinns det bara ett sätt att skriva den här funktionaliteten på. Vilket enligt Figur A.4 kan seväldigt enkelt och smidigt ut.

A.7 Slutsatser

De skillnaderna som finns mellan ramverken är så små att det inte spelar någon större rollvilket som används. Den största skillnaden mellan ramverken är det språk de är baseradepå. Då JavaScript sköter sin I/O asynkront blir det till stor del asynkron programmering närExpress används, medan i Python och Flask är det synkron programmering. Vilket gör att detsnarare är en preferens mellan programspråk än vilket ramverk som lämpar sig bäst. För enutvecklare som kommer i från front-end världen är det troligen mer naturligt att arbeta medNode och Express då det bara krävs ett programspråk för att kunna skriva hela applikationenfrån front-end till back-end. Medan en utvecklare som inte arbetat med webben passar bättremed den traditionella synkrona programmeringen i Python och Flask.

35

Bilaga B

Versionshanteringssystem vidgrupparbeten

Författare: Cian Hjort

B.1 Inledning

Versionshantering används vid projekt för att hantera arbetet genom att behålla en viss struk-tur och kvalitet bland filer. Det finns två olika typer av versionshanteringssystem; distribuera-de och centraliserade. Men vilket system är mest gynnsam vid grupparbeten? Denna rapportkommer att gå igenom och förklara dessa två system.

B.1.1 Syfte

Syftet är att med hjälp av frågeställningarna undersöka de distribuerade och centraliseradeversionshanteringssystemen, jämföra de två systemen med varandra och evaluera hur depåverkar större projekt.

B.1.2 Frågeställning

1. Vilka fördelar och nackdelar finns hos ett centraliserat versionshanteringssystem?

2. Vilka fördelar och nackdelar finns hos ett distribuerat versionshanteringssystem?

3. Hur kan de olika systemen gynna ett större projekt?

B.2 Bakgrund

Under projektet har det distribuerade versionshanteringssystemet Git använts för att hållakoll på gruppens gemensamma filer. Detta eftersom de flesta i gruppen har använt sig avGit tidigare. Som konfigurationsansvarig har versionshantering varit ett centralt begrepp ochdärför skulle det vara intressant att förstå varför gruppen under projektet använder ett distri-buerat system. Alla i gruppen har tidigare erfarenhet av SVN som är ett centraliserat systemmen varför använder gruppen inte det och skulle det kunna vara mer gynnsamt?

B.3 Teori

Detta avsnitt är ämnat att ge en djupare förståelse kring versionshantering, distribueradesystem och centraliserade system.

36

B.3. Teori

B.3.1 Centrala begrepp

• Merge - Integration av filer

• Merge-konflikt - När flera användare jobbar på samma fil samtidigt och har gjort änd-ringar på samma rad/rader uppstår en konflikt som programmet inte kan lösa automa-tiskt

• Push - Integrerar ett lokalt repository med ett externt repository

• Repot - kommer att användas vid bestämd böjning av ordet repository

• Större projekt - åtta eller fler personer jobbar med samma projekt

B.3.2 Versionshanteringssystem

Ett versionshanteringssystem är ett program dedikerat till att spåra alla tidigare revisionerav till exempel ett projekt eller en fil för att kunna se mer specifikt vad som ändrats, närförändringarna gjordes och vem som gjorde dem. Alla dessa revisioner och historik överförändringarna sparas i en slags mapp, även kallad. repository [30] Ett metaforiskt exempelpå hur detta fungerar är en webbläsares historik, om webbläsarens sökfält skulle jämställasmed en fil. Varje gång sökfältet ändras, hamnar sökningen som senast i historiken. Närsom helst kan historiken ses igenom och även återställas till en tidigare sökning. Precis somwebbläsarens historik kan versionshanteringssystemet återställa en tidigare version på en fileller ett helt projekt.

Det första versionshanteringssystemet utvecklades omkring 1970-talet och konceptet hargenomgått en hel del förändringar sedan dess. I dagsläget finns det två typer av system;centraliserad versionshantering och distribuerad versionshantering. [31]

B.3.3 Centraliserad versionshantering

Ett centraliserat versionshanteringssystem definieras av att systemet har ett repository. Sy-stemets arkitektur bygger på klient-server modellen som gör att de användare som har läs-och skrivprivilegier kan jobba och uppdatera repot som ligger på servern. [32] Detta betyderatt det centraliserade systemet kräver en uppkoppling mot nätverket för att användaren skakunna använda repot. [33]

Som tidigare nämnts har det centraliserade versionshanteringssystemet endast ett repo-sitory. Det begränsar användaren till att enbart kunna hämta ut en arbetskopia från repot, detvill säga alla filer utan revisionerna och utan förändringshistoriken. Dock kan användarenvid hämtning begära en specifik revision. [34]

Ett vanligt arbetsflöde som kan tillämpas i det centraliserade systemet är lock-modify-unlockarbetsflödet. Om två användare, användare A och användare B, ska jobba med samma filkan användare A låsa filen, jobba färdigt med filen och merge:a de nya ändringarna till repot.Detta betyder att användare B inte kan jobba med filen tills användare A har låst upp denigen. Denna modell kan leda till försämrad produktivitet om andra användare behöver väntapå att en fil ska låsas upp, men den undviker så kallade merge-konflikter. [30]

B.3.4 Distribuerad versionshantering

Det distribuerade systemet är den mest populära versionshanteringssystemet bland mjukva-ruutvecklare i större och mindre projekt [36]. System har till skillnad från det centraliseradeett decentraliserat repository. Vilket innebär att alla användare har ett eget repository lokalt

37

B.4. Metod

på sin dator. [33] Vid större projekt, då användare inte har tillgång till andras repository, kandet vara en fördel att använda ett lämpligt arbetsflöde som ser till att användarna kan delaarbetet med varandra. Ett sätt att lösa detta är att använda det centraliserade arbetsflödet,vilket innebär att ha ett externt repository på en server som användarna kan push:a sitt arbetetill. Denna struktur påminner mycket om klient-server modellen, men att alla användareockså har ett lokalt repository. Det distribuerade systemet kan anpassas till många andraolika typer av arbetsflöden. Detta gör det distribuerade systemet mycket flexibelt. [34]

Ett problem med det distribuerade systemet är att det kräver mer diskutrymme än detcentraliserade bland annat för att förändringshistoriken och alla revisioner finns lokalt. Där-emot blir nätverksbelastningen mindre för att användaren kan jobba utan nätverk och kanistället kommunicera direkt med det lokala repot, vilket gör att det distribuerade systemetsversionshanteringskommandon är snabbare. För att inte kräva för mycket diskutrymmeanvänder det distribuerade systemet datakompression. [34]

Det decentraliserade attributet, att flera användare har ett lokalt repository, minskar ris-ken för dataförluster vid till exempel större projekt eftersom det finns flera kopior på repot.Skulle en användares hårddisk gå sönder har kollegan en kopia av projektet, vilket endastresulterar i dataförluster för användarens nya ändringar om de inte blev push:ade till detexterna repot. [35]

B.4 Metod

Information om centraliserade system, distribuerade system och versionshanteringssystem ihelhet samlades in från bland annat akademisk litteratur och webbsidor. Det som har använtsi rapporten är enbart akademisk litteratur. Relevant insamlad information från teoriavsnittetkommer användas för att sammanställa resultatet och besvara frågeställningarna.

B.5 Resultat

Den insamlade informationen i teorin för både centraliserade och distribuerade system kom-mer att sammanställas här.

B.5.1 Centraliserade systemet

Här är en sammanställning av både fördelar och nackdelar för det centraliserade systemet.

38

B.5. Resultat

Figur B.1: Centraliserade systemet

Fördelar:Användare i det centraliserade systemet, enligt figur B.1, kan hämta ner senaste versionenav till exempel filen från repot utan att behöva tänka på vilket arbetsflöde som används pågrund av klient-server modellen. Det går även att undvika merge-konflikter om lock-modify-unlock arbetsflödet används.

Nackdelar:Centraliserade systemet kräver uppkoppling mot nätverket för att ta del av versionshante-ring. Centraliserade systemet får ganska stora problem om något skulle hända med servern,där repot finns, och ingen backup gjorts på servern. Om lock-modify-unlock modellen an-vänds kan det leda till försämrad produktivitet på grund av att en utvecklare kan behövavänta länge på att en annan utvecklare ska jobba färdigt med en fil.

B.5.2 Distribuerade systemet

Här är en sammanställning av både fördelar och nackdelar för det distribuerade systemet.

39

B.6. Diskussion

Figur B.2: Distribuerade systemet

Fördelar:Det distribuerade systemet, enligt figur B.2, tillåter användaren att ha ett eget lokalt reposi-tory på hårddisken vilket möjliggör att arbeta utan nätverk. Det lokala repot kan kombinerasmed externa repon som gör det distribuerade systemet väldigt flexibelt vid anpassning avolika arbetsflöden. Systemet minskar även risken för dataförlust på grund av dess peer-to-peer modell. Eftersom det distribuerade systemet har ett lokalt repository exekveras vissaversionshanteringskommandon snabbare än om det skulle exekveras över ett nätverk.

Nackdelar:Distribuerade system kräver mer diskutrymme för användaren än det centraliserade syste-met på grund av ett det distribuerade systemet sparar ett lokalt repository istället för attspara en arbetskopia på användarens hårddisk. Vid större projekt kan användaren inte seandra användares lokala repository. Detta kan medföra problem om projektmedlemmar inteständigt push:ar efter gjorda förändringar vilket skulle kunna innebära att flera medlemmarjobbar med att lösa samma sak parallellt.

B.6 Diskussion

Från resultatet kan det avläsas att det distribuerade systemet verkar lösa många av de pro-blem som det centraliserade systemet har. Distribuerade systemet verkar mer flexibelt förolika typer av projekt det vill säga att systemet kan utgå från olika modeller av arbetsflödenför att få det system som är lämpligast för ett visst typ av projekt. Centraliserade systemverkar användas av projektgrupper och användare som har haft en vana av centraliseradesystem. Ur ett historiskt perspektiv är det centraliserade systemet det äldre av versions-hanteringssystemen, vilket skulle kunna förklara frågan om vana. Som tidigare nämnts hardet distribuerade systemet fler användare än det centraliserade, vilket känns rimligt medavseende på sammanställning från resultatet.

40

B.7. Slutsatser

Denna rapport sammanställer centraliserade och distribuerade system utifrån informa-tion från artiklar, rapporter och böcker. Det finns inga utförda experiment som skulle kunnajämföras med den litteratur som hämtats. Detta innebär att det finns en risk att viktig in-formation som har missats inte tagits med i rapporten och att resultatet skulle kunna seannorlunda ut. Med t.ex. en kvalitativ undersökning om vad min egna projektgrupp har förerfarenheter av dessa system, eller en större kvantitativ undersökning där flera programme-rare förfrågas skulle man med mera säkerhet kunna märka om väsentlig information harmissats.

B.7 Slutsatser

På grund av det distribuerade systemets lokala repository möjliggörs det att användarenkan arbeta utan nätverk, men om användaren vill dela med sig av arbetet krävs ett nätverk.Det lokala repot gör också att versionshanteringskommandon exekveras snabbare än detcentraliserade systemet. Däremot kräver det distribuerade systemet mer diskutrymme ändet centraliserade. Det är dock inte ett så stort problem då distribuerade system använder sigav datakompression. Användare kan inte se andra användares repository vilket kan medföraproblem vid större projekt, men vid rätt val av arbetsflöde till exempel en centraliseradmodell kan detta undvikas. Dock med förutsättningen att användarna tar eget ansvar ochpush:ar sina ändringar till det externa repot.

Användare i det centraliserade systemet kan hämta ut den senaste versionen från repotför att det endast finns ett att jobba mot. Systemet erbjuder också en lock-modify-unlockmodell som hjälper till att undvika merge-konflikter men kan försämra produktiviteten pågrund av väntetid att någon annan ska bli klar. Systemet kräver även uppkoppling motnätverket för att nyttja versionshantering och uppdatera repot. Detta kan bli ett problem omen arbetsgrupp är utspridd över världen. Det centraliserade systemet är också mer osäkernär det gäller dataförluster än det distribuerade systemet eftersom allting finns på en server.

Distribuerade system och centraliserade system har olika fördelar och nackdelar. Det distri-buerade systemet har tagit över rollen som den mest populära versionshanteringssystemetbåde för grupper och enstaka användare. Att avgöra vilket system som är bäst är svårt attsäga, det får användaren själv dra slutsatser om. Men det distribuerade verkar passa till enbredare grupp på grund av dess flexibilitet.

41

Bilaga C

Arbetsgruppens utveckling under ettprojekt

Författare: Gustav Kvist

C.1 Inledning

Alla arbetsgrupper är inte perfekta från början. Vissa grupper utvecklas inte ens under etthelt projekt. I denna rapport tas det upp hur just vår grupp har utvecklats från första itera-tionen till den sista. Detta är med avseende på dynamiken och mognaden i gruppen samtanvändningen av de verktyg och hjälpmedel som gruppen valt att använda sig av. Kan detfinnas några samband mellan gruppdynamikens utveckling och användandet av valda verk-tyg? Detta kommer bearbetas för just projektgruppen SurVive om hur alla gruppmedlemmarkände under de olika iterationerna.

C.1.1 Syfte

Denna rapport ska utvärdera dynamik och mogenhet i gruppen samt jämföra det med verk-tygsanvändning vid första och sista iterationen i ett projekt med instanser av Scrum ocheXtreme Programming (XP). Målet är att se hur en grupp utvecklas över en specifik tids-period.

C.1.2 Frågeställning

1. Hur utvecklas dynamiken och mognaden i en grupp under fyra iterationer i ett projektsom bygger på Scrum och XP?

2. Hur utvecklas användningen av valda verktyg och hjälpmedel?

C.2 Bakgrund

Att arbeta i en grupp vid ett tillfälle är aldrig samma sak som att göra det vid ett annat till-fälle med en annan grupp. Att en grupp fungerar helt och hållet från början händer i principaldrig, utan medlemmarna i gruppen genomgår en konstant utvecklingsprocess där de lärkänna varandra och utvecklar gruppens sammanhållning. Från början kanske inte alla kän-ner varandra och man agerar på ett visst sätt mot de andra gruppmedlemmarna; men i slutetkan man agera på ett helt annat sätt beroende på hur väl dynamiken i gruppen utvecklats.Oftast går det framåt och medlemmarna blir bättre och bättre på att arbeta som ett team, menvissa gånger går det inte alls.

42

C.3. Teori

C.3 Teori

I detta kapitel kommer det både förklaras vad gruppdynamik är och hur mogen en grupp ärberoende på hur medlemmarna ligger till inom vissa områden som utgår från till exempelCapability Maturity Model Integration (CMMI).

C.3.1 Gruppdynamik

Gruppdynamik beskriver hur bra alla medlemmar i en grupp fungerar tillsammans. Kän-ner medlemmarna inte varandra tillräckligt bra kan det bli jobbigt för några att arbeta medgruppen och flera av medlemmarna jobbar hellre själva än med de andra. En grupp med bradynamik arbetar tillsammans, har roligt och får saker gjorda. En grupp med dålig dynamikgår ofta inte mycket framåt i sitt arbete på grund av bristande kommunikation eller motiva-tion.

C.3.2 Mognadsgrad

I denna del tas olika mognadsnivåer upp och förklaras.

Första stadiet

Om en grupp skapas med medlemmar utan motivation eller som inte passar med varandrakommer gruppen inte producera lika mycket som en helt fungerande grupp. En sådan gruppkan producera, men resultatet beror ofta på att en eller ett fåtal produktiva personer görnäst intill allt arbete som inte alltid stämmer överens med bestämda processer och verktyg[16][37][38].

Om en grupp ur första stadiet får för mycket arbete tilldelat till sig är risken hög att detspårar ur och inget blir gjort. Om gruppen mot förmodan skulle lyckas med något är riskenhög att medlemmarna inte drar lärdom av den använda processen, och därav inte återanvän-der den för att lyckas med andra uppgifter. Sannolikheten är hög att produkten inte kommerbli klar i tid och inte heller inom budget [16][37][38].

Hanterade stadiet

Om en grupp kommer förbi första stadiet kommer den till det hanterade stadiet. Där an-vänder sig gruppen av bestämda processer, både när det går bra och dåligt, och de kan ut-värderas efter hand när medlemmarna i gruppen känner att det behövs. I detta stadie harutomstående mer koll på hur det går för gruppen tack vare att det arbetas med milstolparoch kontrollpunkter som gruppen kan visa upp eller dela med sig av. Gruppen har även kollpå kundens åsikter, tack vare möten och bra kommunikation. Därav blir det lättare att styraförändringar och återanvända processer som lett till att uppgifter klarats av. Dessa proces-ser är i detta stadie mycket lättare att planera och kontrollera för att se till att krav och måluppfylls, samt att gruppen slipper förvånas när något nytt händer [16][37][38].

Definierade stadiet

Detta stadie är som det hanterade stadiet, fast lite mer avancerat och definierat. Tack vare merförståelse för projektet kan gruppen i detta stadie skapa egna utvecklingsprocesser, utifrån deförutbestämda processerna, som fungerar bättre för just det projekt som pågår för tillfället.Gruppen kan alltså gå in mer på detaljer i sina processer och ändra dem under projektetsgång, för att de ska fungera så bra som möjligt och för att de ska kunna följa dem mer striktutan avvikelser [16][37][38].

43

C.4. Metod

Kvantitativt hanterade stadiet

Når gruppen till detta stadie har de mycket förståelse för grupparbete. Gruppen kan då väljaspecifika delar av sina processer som ska användas för att kunna dra ner på tiden som behö-ver läggas på vissa delar. Här kan nya mål som baseras på kundens och användarnas behovskapas och det sker ofta ändringar i processerna. Det finns alltså mer valbarhet i detta stadieän de tidigare, tack vare mer förståelse än innan [16][37][38].

Optimerade stadiet

Under det optimerade stadiet vill gruppen konstant förbättra prestandan för processernasom används och medlemmarna skapar mål för hur mycket de vill förbättra dem. För attkunna ta sig hit måste gruppens medlemmar inte bara vara arbetsvilliga, utan de mås-te också alla vara duktiga på området. Detta gör att de lättare kan skynda på arbetet ocheftersom alla står för att förbättra processerna kommer de kontinuerligt bli bättre [16][37][38].

En stor skillnad mellan detta stadie och förra är att förbättringen här inriktar sig mer påde vanliga stegen i processen, medan i föregående steg var det mer fokus på speciella sakersom tog mycket tid [16][37][38].

C.4 Metod

För att ta reda på mer information om generell grupputveckling och få mer allmän kunskapom just gruppdynamik, gruppmognad och verktygsanvändning undersöktes internetsidoroch litteratur. Med informationen i åtanke skapades en enkät som alla gruppmedlemmarsvarade på i början och i slutet av projektet, se figur C.1. Det är svaren på dessa enkäter ochallmänna diskussioner inom gruppen som kommer vara grunden för denna rapport.

Enkäten svarades på efter första iterationen av projektet för att få en bild av hur grup-pen låg till från början. Andra gången svarades den på i slutet av projektet för att kunnaurskilja större skillnader mellan dem. Utifrån svaren på enkäterna kunde likheter och skill-nader mellan informationen från internetsidorna, litteraturen och svaren på enkäterna tasfram och presenteras.

C.5 Resultat

I detta kapitel presenteras resultaten från enkäterna som gruppen svarade på.

C.5.1 Första iterationen

I denna del följer en summering av svaren från första enkäten.

Gruppstämning

Redan från början var gruppen enig om att arbetet fungerade bra tillsammans. Ett par avgruppmedlemmarna var lite oroliga över hur fördelningen av tid som läggs på projektet sågut. Vissa började redan då dra ifrån andra och tvärt om. Enligt några var det lite tråkigt att viförst fick ”Go Supernova” som projekt, men alla tyckte att det var roligt och spännande attbyta till ”SurVive”.

På frågan om vad gruppen skulle kunna förbättra togs det upp att de skulle kunna hamer gemensamt arbete, fördela uppgifter bättre och även att vissa borde lägga ner mer tidpå projektet. Ett par kände att de själva borde lägga mer tid på projektet och några tyckteatt arbetsparen kan skiftas lite oftare än de gör. Parprogrammeringen funkar inte helt och

44

C.5. Resultat

hållet enligt dem då vissa personer sitter med varandra hela tiden. Dock tyckte några attparprogrammering fungerade väldigt bra.

Gruppen har bra kommunikation och det är en trevlig arbetsmiljö i projektgruppens ar-betsrum Akvariet. Att det är bra med möten varje vecka togs upp flertalet gånger. Gruppenförsöker reda ut problem på ett bra sätt och gruppens teamledare har bra koll på alla ochinformerar så fort det är något.

Verktyg

Trello var ett väldigt bra verktyg redan från början. Alla tyckte att det var bra. Det enda somsades vara negativt var röran i början och när det läggs in kort som inte alla vet vad det är.Med lite mer disciplin skulle det fungerat utan problem från start.

Överlag var även Slack lyckat redan från start. Alla vågar säga vad de tycker där och al-la är med i alla diskussioner. Ibland verkar det dock vara svårt att få svar från någon och detkan ha spårat ur med antalet kanaler som skapas. Det kan bli lite rörigt.

Alla har inte arbetat med Unity, men de som har det tyckte att det var mycket att lärasig när de inte kunde det sen tidigare. Det är svårt, men efter att de lärt sig lite mer märktede att mycket är simpelt och att det hjälper en lite på traven. Någon tyckte inte om drag-and-drop-miljön.

Det var bara ett fåtal personer som arbetat med Blender under första iterationen. Densom använt det mest tyckte att det var ett bra verktyg, men att det var krångligt att exporteratexturer och material mellan Blender och Unity. Genomgående verkade de flesta som använtdet tycka att det var krångligt, speciellt när man inte använt det tidigare.

När det gäller dokumentation var inte alla helt överens om vad som var bäst. Enligt flertaletvar det krångligt med installationen av lokalt LATEX, medan ett par tyckte att skriva lokaltvar det absolut bästa. Enligt de som föredrog molnbaserat skrivande var det en som tyckteatt ShareLATEX var bättre än Overleaf, på grund av att det är snabbare än Overleaf på attuppdatera när flera skriver samtidigt. Dock tyckte största delen av gruppen att Overleafvar det som var bäst. Det samlar alla dokument på samma ställe, det är smidigt och det sersnyggt ut. Det enda dåliga med molnbaserat skrivande verkar vara om uppkopplingen tillinternet inte är bra.

Enligt de som använts sig av tester har det fungerat bra. Det har dock inte blivit myckettestning för alla då mycket av arbetet har varit grafiskt i Unity, vilket har gjort det svårt atttesta. Enhetstester har påverkat vissa personers kod till det bättre, medan för några har detmest skapat mer arbete eller inte ändrat så mycket.

C.5.2 Sista iterationen

I denna del följer en summering av svaren från andra enkäten.

Gruppstämning

Alla gruppmedlemmar är eniga om att gruppen fungerar mycket bra och att alla har roligttillsammans. Alla kan prata med varandra och ingen är utanför gruppen på något sätt då allaär väldigt öppna och lyssnar på vad de andra har att säga. Behöver någon hjälp med någotfinns det alltid någon som ställer upp och hjälper till.

Det som skulle kunna förbättras är speciellt de sena ankomsterna som varit där från start.

45

C.6. Diskussion

Flera personer tycker att det har varit ett problem som borde lösts redan från början. Ettannat problem som funnits redan i tidigt skede av projektet är att vissa har lagt mer tid änandra. Ett par känner nu själva att de borde lagt ner mer tid redan från start. En annan saksom togs upp av ett par var att det kan bli lite för mycket lek och stoj på eftermiddagarna närman är trött och har arbetat hela dagen.

Verktyg

Trello har de senare veckorna inte använts lika flitigt som tidigare på grund av att det varitväldigt mycket dokumentskrivande. Det har också hållits bra iterationsmöten som gjort attalla har koll på vad man ska göra utan att kolla Trello. De som använt sig av det tycker dockatt det inte uppdateras så ofta som det borde.

Slack fungerar mycket bra då all information kan hittas där och alla kan fråga vad somhelst. Det enda problemet enligt en person är att notifikationerna från Slacks mobilapp intealltid fungerar, vilket gjort att den personen kan bli lite sent informerad om vissa saker.

Unity har, precis som Trello, inte använts av lika många den senaste tiden då mycketkrut gått åt dokumentskrivandet. Dock har de som använt Unity haft lite problem.

Det är fortfarande inte alla som arbetat med Blender, men de som har det tycker att detfungerar bra.

Dokumenteringen har endast gjorts i Overleaf den senaste iterationen, men det har bör-jat bli långsamt. Eftersom ett dokument innehåller många filer tar det lång tid att laddaPDF-filen. När då automatisk uppdatering av PDF-filen är inställt flyttas markören runt närnågon annan skriver ovanför.

Precis som innan har det varit många visuella tester. Dock de få som gjort vanliga kod-tester har tyckt att de tas mer seriöst än innan. Enhetstesterna har gjort att specialfall tänktsigenom och koden blivit mer strukturerad.

C.6 Diskussion

I detta kapitel diskuteras resultatet av rapporten.

C.6.1 Gruppstämning

Gruppen blev först tilldelad ”Go Supernova” som projekt, vilket inte låg högt upp på listanav gruppens föredragna projekt. Det var under första kundmötet som förslaget att gruppenskulle arbeta med ”Learn to SurVive” istället kom. Detta gjorde att medlemmarna var tvung-na att ställa om helt eftersom det var ett helt annat projekt. Detta kan ha påverkat resultatetbåde till det bättre och sämre. Att medlemmarna fick ett intressantare projekt kan ha gjortdem mer positiva till att arbeta med varandra redan från ett tidigt skede. Dock skulle detkunna ha påverkat några negativt ifall de hellre ville arbeta med ”Go Supernova”.

Gruppen använde under hela projektet ett gemensamt dokument för att skriva upp ti-den som lades ner för varje person. Det var med hjälp av detta de kunde se att vissa personerdrog ifrån andra i spenderad tid på projektet. Att fördela uppgifter bättre togs upp då mångaarbetsuppgifter blev tilldelade till ett fåtal personer tidigt under projektet. Självklart villvissa arbeta hårt och få saker gjorda snabbt, men i detta fallet verkade det som att vissa andrapersoner inte riktigt fick arbeta med något de ville. Det kan vara en orsak till att några drogifrån andra i tid. Att en del tog åt sig arbete som var lite lättare att lägga mycket tid på och

46

C.7. Slutsatser

andra fick ta lite tråkigare eller mindre uppgifter.

Det fanns även tvetydigheter om parprogrammeringen i början. Att vissa tyckte att par-programmering var bra och andra tyckte tvärt om kan också ha med skillnaden i tid attgöra. Om de som inte tyckte att det fungerade även var de som inte lade ner lika myc-ket tid i början kan det nog ligga någonting i det. Skulle det kunna vara så att alla intevågade säga som de tyckte under mötena? I så fall kanske inte gruppen fungerade så brasom alla trodde. Gruppdynamiken handlar ju om hela gruppen och inte bara ett par personer.

I den andra enkäten var det enda nya, som togs upp att vara dåligt, att det lätt blev litelek och stoj i Akvariet på eftermiddagarna när gruppen arbetat hela dagen. Det är inte braför effektiviteten, men det kan vara bra för gruppens sammanhållning. Har alla roligt medsin grupp betyder det oftast att de har en bra dynamik. Dock kan det leda till oseriöst arbeteom det håller på för länge och för ofta.

C.6.2 Verktyg

Trello användes flitigt i början, men inte mycket alls i slutet. Det beror troligtvis på att denandra enkäten svarades på under en period då alla i gruppen hade fullt upp med dokument-skrivande.

Samma gäller även Unity och Blender. Mycket dokumentskrivande gjorde att dessa verktyginte användes lika mycket i slutet. Dock hade det uppstått lite problem med Unity vilket letttill att bara ett fåtal använt Unity över huvud taget.

Slack däremot fungerade lika bra i slutet som i början, men användes mer i slutet. Detpåverkades troligtvis inte lika mycket av dokumentskrivandet som de andra verktygen dåkommunikation alltid är relevant. Overleaf har använts under hela projektet och även desom förespråkade lokal dokumentering har tyckt att det fungerat bra.

C.7 Slutsatser

Gruppdynamiken var hög redan från början, men när gruppens medlemmar lärt kännavarandra mer har alla även vågat ta för sig mer. Gruppen har blivit mer och mer som ettkompisgäng istället för en projektgrupp och medlemmarna har kunnat ha roligt tillsammans.Ibland kanske lite för roligt. Gruppdynamiken har alltså bara blivit bättre och bättre i grup-pen under projektets gång. Vad det beror på är dock svårare att säga, men det skulle kunnabero på teambuildingen eller gemensamma intressen. Det är ofta genom liknande intressensom många vanliga kompisgrupper blir till.

Går man in på mognadsgraden i gruppen ligger den i det hanterade stadiet. Den har defini-tivt kommit förbi det första stadiet då det är flera som arbetar, de följer bestämda processeroch de arbetar med milstolpar och kontrollpunkter som kunden kan observera. Anledningentill att de inte nått det definierade stadiet är att de inte har gått in på detalj i deras utvecklings-processer utan de har bara gått framåt på de sätt de bestämde från början. De har möten varjevecka, men de ändrar inte deras processer mer än att de byter utvecklingsområden då och då.

Om man bara kollar på enkäterna som gruppen svarade på har det inte skett någon ut-veckling alls när det gäller verktygsanvändning. Det kan mycket väl bero på att den andraenkäten svarades på vid fel tillfälle eftersom de flesta hade fullt upp med dokumentskri-vande just då. Skulle man gett ut enkäten vid ett annat tillfälle kanske gruppmedlemmarnaskulle svara på ett annat sätt. Det är alltså svårt att säga hur utvecklingen av verktygsan-

47

C.7. Slutsatser

vändningen egentligen gick, men mellan just dessa två enkäter gick den bakåt för majoritetenav de valda verktygen.

48

C.8. Figurappendix

C.8 Figurappendix

Figur C.1: Enkätens frågor

49

Bilaga D

Jämförelse mellan komponenter och arvinom spelutveckling

Författare: Kevin Larsson Alm

D.1 Inledning

Valet av hur ens program ska se ut kan verka trivialt till en början, men när kodbasen växerkan det bli svårt att hålla koll på all kod. Detta gäller särskilt inom spel- och simuleringsut-veckling. Detta eftersom det förekommer mycket kod för att representera olika objekt somska finnas i den virtuella miljön. För att man inte ska behöva skriva om all kod vill man attarkitekturen ska vara modulär och återanvändbar. Två av de mest vanliga sätten att uppnådetta på är genom entitet-, komponent- och systemdesign och genom objektorienterat arv.Men vilken är att föredra i olika situationer? Vilka fördelar och nackdelar kommer valet mel-lan dessa två designmönster med? Det ämnar den här rapporten att svara på.

D.1.1 Syfte

Syftet hos rapporten är att jämföra entitets-, komponent- och systemdesign med traditionelltarv vid skapandet av olika objekt i spel. Det som kommer att ligga som fokus för rapporten ärmodulariteten och återanvändbarheten hos koden. Allmänt kommer fördelar och nackdelardiskuteras för att klargöra designmönstrens framträdande sidor och skillnader. Detta är tänktatt göras genom att först jämföra exempel av de båda mönstren som illustrerar problemensom de har för att sedan göra en analys på det.

D.1.2 Frågeställning

Frågeställningarna som kommer att svaras på i denna rapport är följande:

1. Vilka för- och nackdelar finns hos objektorienterat arv?

2. Vilka för- och nackdelar finns hos komponent-entitet- och systemdesign?

3. Hur skiljer sig de två designmönstren sig åt?

D.2 Bakgrund

I projektet har Unity använts för att skapa den VR-miljö som användaren ska kunna interage-ra med. Unity använder en entitet-komponent-design som inte är lika vanligt förekommandesom arv mellan objekt. Om man utvecklar spel i exempelvis Unity, kan valet av hur man ska-par sina spelobjekt spela en stor roll för både prestanda, modularitet och flexibilitet. För att då

50

D.3. Teori

förstå varför ett av designmönstren används krävdes en förståelse för vad designmönstrenhar för fördelar och nackdelar.

D.3 Teori

I detta kapitel följer information om de två olika designmönstren, kort om deras variationeroch övrig relevant teori.

D.3.1 Objektorienterat arv

I objektorienterade programspråk är arv den mekanism som tillåter objekt att utöka funktio-naliteten av ett eller flera objekt. Detta görs genom att fält och metoder definieras på sammasätt i objektet som ärver så som det definierats i det ärvda objektet. Dessa fält och metoderkan sedan utökas för att ge ny funktionalitet, men gamla metoder kan även överlagras för attomdefiniera grundläggande beteende hos objektet. En variation hos olika implementationerav arv är om möjligheten att ärva från flera objekt eller från bara ett objekt. Traditionellt ob-jektorienterat arv syftar på den senare varianten och återfinns i många olika programspråk,så som Java [39], C# [40] och HaXe [41]. Sättet som arv är definierat på kräver att alla klassersom ärvs ifrån en specifik klass är inladdade och del av det slutgiltiga systemet, även om desjälva inte används till något annat.

D.3.2 Entitet-komponent-system

Entitet-komponent-system (eng. Entity-Component-System), förkortat EKS, beskriver medsitt namn designens huvudobjekt, vilket är entiteter som består av komponenter som skötsav system. Tanken med designmönstret är att platta till hierarkin och slippa den mer rigidarelationen som kommer från arv mellan objekt. Exempel på EKS-design visas i figur D.1.

51

D.4. Metod

Figur D.1: Exempel på system och komponenter i EKS.

Entiteter i detta fall är behållare som bara består av den mest grundläggande logiken, såsom vad den har för namn eller id [43]. Komponenterna läggs sedan till på entiteter för attdefiniera data som entiteten har och dessa sköts av system som definierar logiken hos spelet.Dessa system och komponenter baseras oftast på en egenskap som ska finnas hos objekt, somtill exempel att kunna spela upp ljud. Några exempel på system i ett spel är ljuduppspelning,utritning på skärmen och fysiksimulering.

Det förekommer även en förenklad variant av designmönstret, där man inte har systemöver huvud taget. Denna design kallas entitet-komponent (EK) och den logik som innanskulle hört till ett system hör då istället till den grundläggande komponenten för det syste-met.

D.4 Metod

De varianter av designmönster som kommer att presenteras i denna rapport är traditionelltobjektorienterat arv och EKS-design. Dessa mönster kommer att beskrivas med hjälp av figu-rer för att illustrera deras fördelar och nackdelar. Designmönstren kommer att jämföras medavseende på hur modulär och återanvändbar kodbas de olika designmönstren ger upphovtill samt vilka fördelar och nackdelar de har. För att göra detta kommer olika exempel påhur kodstrukturen kan se ut när man använder de olika designmönstren tas fram. Figurernakommer illustrera implementationen av olika objekt som kan existera i ett spel, som till ex-empel olika typer av fiender. Dessa exempel tillsammans med källor om de olika mönstrenkommer att ligga till grunden för svaren på frågeställningarna.

52

D.5. Resultat

D.5 Resultat

I detta avsnitt presenteras de olika designmönstrens exempelkod samt diskussion kringmönstrens fördelar och nackdelar.

D.5.1 Traditionellt objektorienterat arv

Traditionell arvshierarki ger kod som oftast hamnar på djupet; man får objekt som hamnar ien trädstruktur, där föräldraobjekt krävs av sina barn för sin implementation.

Figur D.2: Exempel på hur ett arvsträd kan se ut, där pilar denoterar arv i pilens riktning.

I figur D.2 visas en exempelhierarki över ett antal objekt, där Entitet är det grundläggandespelobjektet. Fördelen med arv är att man slipper omdefiniera logik som kommer att återan-vändas av flera olika objekt. En metod hos föräldern finns även i deras barn och kan utökasvid behov. Detta gör att koden blir utökningsbar och vi kan då enkelt skapa nya spelobjektsom delar stora segment av samma logik. Denna typ av beroende av sin förälder kan dockhindra vissa intuitiva designval, som att skapa en ny fiende från en kombination av två exi-sterande fiender.

53

D.5. Resultat

Figur D.3: Exempel på arvsproblem med flera föräldrar, där pilar denoterar arv i pilens rikt-ning.

Antag att vi har en design enligt figur D.3, där det finns olika fiender som beter sig på olikasätt. Vi har den grundläggande fienden, en magisk fiende och en flygande fiende som allaimplementerar sin logik annorlunda. Om man nu skulle vilja att spelet skulle utökas med enfiende som är både magisk och flygande kommer man stöta på ett problem. Vid arv där baraen förälder tillåts blir detta arv då omöjligt då man skulle behöva ärva beteendet från tvåolika klasser. Om man kan ärva från två olika föräldrar får vi istället konflikter när det gällerimplementationen av logiken, som nu överlappar. Detta är ett problem som kallas diamond ofdeath [42].

54

D.5. Resultat

Figur D.4: Exempel på arvsproblem som skapar redundans, där pilar denoterar arv i pilensriktning.

Ett annat problem som uppstår vid traditionellt objektorienterat arv kan uppstå när mandesignar objekten genom sina egenskaper, vilket illustreras i figur D.4. Ett skäl till att manskulle vilja skapa en sådan struktur är för att kunna behandla olika spelobjekt beroende påvad de har för egenskaper. Som exempel skulle detta kunna vara att utritningssystemet barahar hand om utritningsbara objekt. I figuren visas det att både den sjungande fisken, sjung-ande blomman samt berättarrösten behöver förmågan att spela upp ljud. Om man skulleimplementera exemplet i figuren skulle man märka att kod kommer att behöva upprepas.Strukturen i detta exempel minskar modulariteten och återanvändbarheten hos koden ochsåledes hos arkitekturen. Detta kan göra koden svårare att hantera och organisera [43].

D.5.2 Entitet-komponent-systemdesign

Till skillnad från arv ger EKS-design kod som växer på bredden. Objekten man får bestårav olika komponenter, där bredden kommer från alla de olika komponenter som spelet kantänkas ha. Med detta val av design kräver grundobjektet bara de komponenter som den haroch inga andra.

55

D.5. Resultat

Figur D.5: Exempel på hur ett arvsträd kan se ut när EKS används.

I figur D.5 visas en exempelhierarki över ett antal objekt, där Entitet är det grundläggandespelobjektet. I figuren illustreras komponenternas tillhörighet till en specifik instans av enentitet. Denna kombination av flera komponenter och en entitet definierar ett spelobjekt.

Fördelen med komponenter är att varje spelobjekt designas genom sina olika komponenter.Att skapa nya spelobjekt handlar då om att kombinera olika komponenter med varandraistället för att göra en ny typ av objekt. Detta ger en isolerad modularitet hos objekten, varsegentliga logik istället finns i systemen som hör till komponenterna hos entiteten. En nackdelmed EKS är att uppdelningen av logik kan kräva att komponenter delas av flera systemsamtidigt. Detta behov av att dela data kan ge ökad komplexitet, särskilt om vissa system ärkänsliga för ändringsordningen av data som orsakas av andra system.

56

D.6. Diskussion

Figur D.6: Exempel på ett problem med EKS: ökad komplexitet hos delade komponenter.

I figur D.6 visas ett exempel på problemet med delad data, där positionen av ett objekt krävsav flera olika system. I detta exempel ser man att ordningen som data modifieras och läses,spelar roll. Fysiksystemet uppdaterar positionen hos en entitet, men om utritningssystemetläser av positionen innan det så ritas entiteten ut på den gamla positionen.

En viktig nackdel hos EKS är att det är ett separat mönster och implementationen av det kanvariera mellan olika ramverk. Detta ökar då risken för att mer tid behövs på ett projekt föratt gå igenom och lära sig hur just den implementationen av EKS fungerar.

D.6 Diskussion

En av de främsta skillnaderna mellan mönstren är hur arvsträden hos implementationernaser ut. Arv ger typiskt ett väldigt djupt träd då nya finesser skapar nya subklasser. EKS gerett bredare träd då nya finesser skapar nya komponenter. De djupa arvshierarkierna ledertill att kodbasen blir svårare att förstå, underhålla och testa enligt tips 29 i boken 60 Tips OnObject Oriented Programming [44].

Resultaten visar att det finns ett grundläggande problem hos arv som EKS ämnar att lö-sa, nämligen problemet med utökningsmöjligheterna hos olika implementationer. EKS kange en högre grad av modularitet då man separerar logik och data. Detta kommer med kost-naden av högre komplexitet då data kan behövas av flera system. Logiken hos olika systemmåste kunna samverka. Detta kräver att ordningen av systemens påverkan är känd eller attsystemen är helt isolerade från varandra. Detta problem undviks när arv används, eftersomdata och logik ligger på samma ställe.

57

D.7. Slutsatser

D.7 Slutsatser

Objektorienterat arv har visats ha några nackdelar så som kodredundans men är en relativtenkel mekanism för att återanvända kod och skapa struktur bland spelobjekt. Mekanismenär också ofta en del av objektorienterade språk, så inga externa bibliotek krävs för att uppnåstrukturen över spelobjekten. EKS har visats ha några fördelar så som plattare arvshierarkimen är ett designmönster som kräver mer av utvecklarna att implementera själva och förstå.Det finns som inkorporerad del i många spelverktyg och ramverk så som Unity men ominget sådant verktyg används kommer ett externt bibliotek behöva användas. Detta krävertotalt mer tid hos utvecklarna då de måste lära sig det biblioteket. Man kan se att EKS germer utökningsmöjlighet än arv då traditionellt arv begränsar utökningsmöjligheten hoskodbasen. Utökningsmöjlighet kan vara väldigt bra om spelet ska ha många olika objekt somdelar liknande logik. EKS har problemet att behovet av att dela data mellan system ger ökadkomplexitet vid implementationen av spelet.

Båda designmönstren har för- och nackdelar och det viktiga att komma ihåg är att kun-na anpassa sig efter vilken design som passar bäst i det projekt man ska arbeta i. Om manär ute efter en enkel mekanism som flera är vana vid kan arv vara att föredra. Det kan ocksåvara att föredra om man vet att spelet inte kommer ha så många olika spelobjekt som ärverfrån varandra, då det påverkar arvsträdets djup. Ytterligare ett fall som det kan vara värtatt använda arv är när konflikten med logik som blir reproducerad mellan olika delar avarvsträdet troligtvis inte kommer att uppkomma. Om man vet på förhand att man kommerha mycket logik som skulle reproduceras om man använder traditionellt arv kan EKS varaatt föredra. EKS kan även vara att föredra om man inte kan förutse hur framtida utöknings-möjligheter ser ut, då EKS ger upphov till en mer modulär och återanvändbar kodbas ocharkitektur.

58

Bilaga E

Teamledarens roll i agilmjukvaruutveckling

Författare: Anton Mo Eriksson

E.1 Inledning

I det här bidraget kommer teamledarens roll att diskuteras och analyseras genom projekts treolika faserna: före, under och efter [45]. Ett extra fokus på projektstyrningsteknikerna Scrumsamt eXtreme programming kommer även att inkluderas. Anledningen till att detta ämnehar valts grundar sig i ett intresse för rollen teamledare samt möjligheten att kunna hjälpanuvarande och framtida projektarbeten att prestera på högsta möjliga nivå.

E.1.1 Syfte och mål

Det övergripande syftet och målet med denna studie är att analysera och diskutera fram ettoptimalt tillvägagångssätt för teamledare i mjukvaruutveckling med projektstyrningstekni-ken Scrum kombinerat med eXtreme programming. Detta kommer göras med betoning påatt nå en så hög prestationsförmåga i gruppen på kortast möjliga tid.

E.1.2 Frågeställning

Hur skall en teamledare agera i projekt för att få gruppen att prestera på högsta möjliga nivå,med fokus på agil mjukvaruutveckling genom kombinationen Scrum och eXtreme program-ming?

1. Hur ska teamledaren agera i förefasen av projektet?

2. Hur ska teamledaren agera i underfasen av projektet?

3. Hur ska teamledaren agera i efterfasen av projektet?

E.2 Bakgrund

Bakgrunden till denna studie ligger i ett intresse för ämnesområdet samt att kunskaperna blirgenerella för framtida projektarbeten. Fortsättningsvis fanns det en uppsjö av forskning påområdet, så ett flertal akademiska skrifter och litteratur kommer vävas in i denna studie.

E.3 Teori

Nedan kommer väsentlig teori utförligt beskrivas för att ge intressenter de nödvändiga kun-skaperna för att följa resonemangen senare i studien.

59

E.3. Teori

E.3.1 Teamledare

Varför bör en projektgrupp ha en teamledare, varför inte förlita sig på att alla gör sin uppgifttill och med deadline utan problem? Sedan förutsätta att integrationen av de olika delarnagår smärtfritt. Det skulle vara naivt att tro att det skulle bli flödet för ett icke uppstyrt pro-jektarbete. Vikten av teamledaren kommer presenteras nedan [46].

Rollen teamledare ska inkludera följande:

• Coacha gruppen till att göra sitt absolut bästa för projektets framgång.

• Ytterst ansvar för projektet och dess godkännande av kunden.

• Identifiering av projektrelaterade risker samt att planera upp handlingsplaner för dessa.

• Genom branschmässiga utvecklingsmetodiker samt projektstyrningsmetodiker föraprojektet framåt i enlighet med fastslagen tidsplanering.

E.3.2 Projektfaser

Detta kapitel ska diskutera vad som en teamledare ska i de tre olika faserna sträva mot förförmågor samt hur teamledaren bör agera i olika fasspecifika situationer.

Före

Förefasen är den mest essentiella fasen i ett projekt, speciellt när projektgruppen sätts ihopav någon utomstående person, som en chef eller examinator. I början av ett projekt finnsdet ofta en förvirring om vad och hur slutmålet ska nås samt vem som är ansvarig för olikasaker och hur arbetsgången från start till mål ska se ut. Det här blir teamledarens uppgifti förefasen, att vägleda projektgruppen ut ur mörkret med diverse projektstyrningsmedelså som Scrum och eXtreme programming. Via dessa hjälpmedel ska en teamledare snabbtkunna leda projektgruppen in i ett effektivt arbetsflöde och där igenom ge projektet detinitiala momentumet det behöver [13] [47].

Enligt erfarenheter insamlade genom möten med andra teamledare för liknande projekt(andra kandidatgrupper) har bilden av den optimala teamledaren i förfasen av ett projektblivit följande:

• En duktig planerare – Att alltid komma med en plan för dagen och veckan framöverför att skapa en bild av vägen framöver för projektgruppen.

• En inspirerande personlighet – Egenskapen att skapa intresse för projektet och målaupp bilden av framgång i huvudet på alla projektmedlemmar.

• En drivande personlighet – Att kontinuerligt sätta upp mål för alla projektmedlemmarmellan alla gemensamma möten för att det alltid ska finnas arbetsuppgifter tillgängligaså att projektet aldrig stannar upp.

Teamledaren blir förstås också beroende av en del hjälpmedel för att effektivisera sitt arbeteoch förmedla en gemensam bild av projektet.

Essentiella dokument som bör tas fram under denna fas är följande:

• Projektplan – För att förmedla en gemensam bild av projektets helhet till gruppmed-lemmar, handledare och chefer.

• Gruppkontrakt – Ett potent dokument för att skapa auktoritet tidigt i projektet samt gelegitimitet till de drivande i projektet.

60

E.3. Teori

• Kravspecifikation – Ytterst viktigt för att skapa en gemensam bild angående slutpro-dukten mellan projektgrupp och kund.

Under

Underfasen syftar till utvecklingsfasen i projektet. I denna fas ska kravspecifikationen realise-ras, dokumentation ska skrivas och uppdateras i enlighet med projektets gång. Teamledarensfrämsta uppgift i underfasen är att skapa och upprätthålla en så hög effektivitet som möjligt.Denna effektivitet ska skapas genom att bygga en lagkänsla i projektgruppen som sedan skaupprätthållas genom att kontinuerligt sätta upp mål med både lång- och korttidsperspek-tiv. Flera karaktärsdrag som lyfts fram av artikeln The Effect of Team Leader Characteristics onLearning, Knowledge Application, and Performance of Cross-Functional New Product DevelopmentTeams är hur en teamledare ska agera för att vägleda sitt team från plan till produkt så smärt-fritt som möjligt. Dessa karaktärsdrag är demokratisk, inspirerande och erfaren [48].

• Demokratisk – Syftar till att teamledaren ska involvera sina gruppmedlemmar i projekt-relaterade beslut för att skapa en lagkänsla samt främja kreativitet och eget tänkandehos gruppmedlemmarna.

• Inspirerande – Syftar på att utveckla gruppmedlemmarna att tänka självständigt ochkreativt för att skapa nya lösningar.

• Erfaren – Att inneha förmågan att ingjuta auktoritet i sitt ledarskap. Erfarenhet ökarockså chansen att innehava interna och externa kontakter inom ämnesområdet somteamledaren kan förvärva kunskaper från och sedan distribuera ut till övriga projekt-medlemmar.

Efter

Efterfasen av ett projekt handlar främst om att samla ihop kunskap inom gruppen, som harförvärvats under projektets gång. Minst lika viktigt är det att utvärdera använda processersamt designbeslut. Detta för att kunna optimera liknande arbeten i framtiden. Det skullekunna liknas med två äldre ordspråk ”lär dig av dina misstag” eller ”övning ger färdighet”.De två ordspråken sammanfattar hela efterfasen väldigt bra.

E.3.3 Agil

Agil är ett relativt nytt ord och innebär i princip förmågan att snabbt anpassa sig efter situ-ationen. Hela processen med agil utveckling beskrivs i ett manifest på 12 punkter skrivet av16 oberoende mjukvaruutvecklare [49]. Av dessa 12 punkter lyser fyra stycken extra starkt.

• Individer och interaktion före processer och kommunikationsverktyg.

• Fungerande mjukvara före överflödig dokumentation.

• Kontinuerlig kundkontakt före kontraktsförhandling.

• Reaktion på förändring före följande av planer.

Dessa fyra punkter ovan utgör grunden i hela manifestet och ska ses som vägvisare fråntraditionell vattenfallsutveckling till modern agil utveckling.

61

E.4. Metod

E.3.4 Mjukvaruutveckling

Mjukvaruutveckling, ett relativt ungt arbetsområde, har i tidigt skede lånat flera modellerfrån mer traditionella ingenjörsområden. Dessa lånade modeller innefattar bland annat diver-se projektstyrningsmetodiker så som den klassiska vattenfallsmodellen. Vattenfallsmodellenvisade ej sig lämpad lika väl för just mjukvaruutveckling. Svaret på detta blev att nya metodi-ker togs fram och som nämnt ovan blev agil utveckling en branschfavorit. Fördelar med agilutveckling framför klassisk vattenfallsutveckling är framför allt att agil utveckling fokuserarpå att anpassa sig under projektets gång och förändra planen på hur mjukvarans slutformska se ut. Det kan tolkas som en levande organism. Mjukvara följer inte någon förutbestämdplan utan växer fram likt en träd som strävar efter solljus, där solljuset är synonym för vadkunden efterfrågar. Till skillnad från vattenfallsutveckling som istället spenderar mycket tidpå att exakt planera upp projektets gång. Det passar tyvärr inte för mjukvaruprojekt somkräver mer flexibilitet än klassiska ingenjörsområden [50].

E.4 Metod

Metoden som har använts för att samla in data till denna artikel har varit externa mö-tesanteckningar från möten med examinator och övriga 12 teamledare. På dessa mötendiskuterades det olika sätt en teamledare ska tackla vanliga problem som brukar uppstå igrupper samt hur den aktuella stämningen var i projektgruppen. Som komplement till dessaexterna möten har också interna möten utförts med tillhörande protokoll för att dokumen-tera problem och funderingar under projektets gång. Med dessa dokument i åtanke skafrågeställningen behandlas utförligt och nyanserat.

Vidare skiljer sig teamledarrollen i olika utvecklingsmetodiker då denna studie betonarden gruppspecifika varianten av en blandning av Scrum och eXtreme programming såkommer den främst jämföras mot en klassisk vattenfallsmodellen.

E.5 Resultat

Det resultat som har utvunnits ur insamlad data är öppet för tolkningar, det går att tolkapå både ett bra och dåligt sätt. Fynden visade på att i början av projektets förefas, när detär luddigt vad som faktiskt ska göras är det viktigt att teamledaren alltid har en plan påhur arbetet ska drivas framåt mellan gruppens möten. Planen syftar på att teamledarenska ha förberett en dagordning till mötet eller funderat kring vilka dokument som börarbetas på för att driva projektet i positiv riktning. En av de viktigaste sakerna som komfram ur teamledarmötena var att teamledaren skulle sätta upp mål mellan alla gemensam-ma arbetstillfällen för att skapa engagemang och arbetstillfällen för alla gruppmedlemmarna.

Insamlad data pekade sedan på att teamledaren skulle i underfasen av projektet förändra sittagerande i gruppen. Nu låg fokus på att släppa mer av ansvaret till gruppen. Teamledarenskulle mer övergå till en utvecklar och sedan sköta diverse administrativa uppgifter parallelltmed det.

Vidare till efterfasen och hur en teamledare bör agera där. I efterfasen blir teamledarage-randet förflyttad tillbaka till ett agerande likt förefasen av projektet. Då produkten är klarnär projektet går in i efterfasen kommer otydligheter i projektgruppen uppkomma kringvad som fortfarande behövs arbetas med. Teamledaren får då likt förefasen alltid kommaförberedd med den plan för att föra arbetet framåt.

Det stora problemet genom hela projektet var bristen på konkreta arbetsuppgifter, dethar tagits upp som ett problem i denna grupp samt andra grupper i liknande projektarbeten.

62

E.6. Diskussion

Denna grupp har däremot hanterat problem effektivt genom att frekvent fylla på projektetsbacklog med små nedbrutna hanterliga aktiviteter.

E.6 Diskussion

Hur ska då en teamledare agera för att skapa engagemang i övriga gruppmedlemmar? Ettav de främsta och mest effektiva medel för att skapa engagemang är att belysa glädjen iarbetet att få gruppmedlemmarna att tycka att det är spännande och intressant att jobba medprojektet. Om en teamledare lyckas med det är det hög chans att projektet lyckas genomförasmed hög kvalitet. Skulle ovan nämnda metoder inte fungera skulle ett bra komplement varaatt driva arbetet framåt med kort och långsiktiga mål, med kontinuerlig uppföljning för attsäkerställa att målen nås.

Ytterligare skulle en hypotes formuleras kring hur teamledaren bör agera i olika typerav krissituationer. En krissituation skulle kunna vara att produkten eller dokument inte ärklara till deadline. Hur bör en teamledare hantera en sådan situation? Teamledaren bör varaöppen med hur situationen ser ut och presentera förslag på hur den kan lösas och sedandemokratiskt med resten av projektgruppen välja den mest väl lämpade lösningen för situ-ationen. Där är den demokratiska processen ytterst viktig för att hela projektgruppen skakänna sig involverad och ansvarig för framgången av projektet.

Det för oss vidare till hur teamledarens roll förändras genom projektets gång och hurdet påverkar projektet med olika typer av ledarskapsstilar. Samtalen med de andra teamle-darna tydde på att det fanns en gemensam bild av hur en teamledare bör agera. Den planenformulerades på följande sätt. I början av projektet bör alltid en bra teamledare alltid haförberett en plan för de kommande arbetet samt ha en aktiv utdelande av uppgifter. Närprojektgruppen sedan har mognat ska teamledaren släppa fram en mer självständigt arbetefrån gruppmedlemmarna och på det sättet skapa en känsla av mer eget ansvar för sinaindividuella delar av projektet.

Agila utvecklingsmetodiker fokuserar på att hålla en flexibel plan och en platt organisation.Däremot lägger vattenfallsmodellen mer betoning på klassisk trädlinknande företagsstruk-tur med mer ”chef-anställd” förhållande samt mer hårdspikade planer. Där var ett av målenmed att effektivisera agil utveckling att eliminera denna ”chef-anställd” förhållande och bytaut det mot en mer jämställd relation. Forskare från Norge påvisade vikten av att teamledarenplanerar med projektgruppen i åtanke samt involverar projektgruppen i beslutsfattandet ibland annat deadlines för att skapa en bra lagkänsla i projektgruppen. Fortsättningsvis är detbra för hela gruppdynamiken visade den norska studien [51]. En av de centrala skillnadernamellan agil och klassisk utvecklingsmetodik är hur de ser på maktcentraliseringen i gruppen.Den agila utvecklingsmetodiken förespråkar en decentraliserad maktstruktur för att främjaeget ansvar och kreativitet. Alternativet till det blir vad den klassiska läran förespråkar,en formell ledare med främst administrativa ansvarsområden för projektet och endast ettöversiktsperspektiv över projektgruppen.

E.7 Slutsatser

De slutsatser som går att härleda utifrån denna studie är att det enskilt viktigaste agerandetfrån en teamledare var att upprätthålla engagemanget inom gruppen genom de olika fasernaav projektet. En teamledare gör det mest effektivt genom att skapa mål mellan arbetstillfällendär målen har satts upp av gruppen på ett gemensamt och demokratiskt vis. Den demokra-tiska processen är en av hörnstenarna i agil mjukvaruutveckling så som Scrum eller eXtremeprogramming. Anledningen till att den demokratiska processen är så viktig för dessa är

63

E.7. Slutsatser

att båda arbetsmetodikerna betonar utbytbara planer och planeringar. När då en plan skaförändras så bör det ske i samtycke med den utvecklare som är ansvarig för det specifikaområdet.

Det för oss tillbaka till en analogi som används tidigare i denna studie, att beskriva hurett mjukvaruprojekt bör utföras. Låt oss erinra att mjukvara ska tolkas som en levande orga-nism vars utveckling ej följer ett tydligt rakt flöde. Denna beskrivs bäst av ett växande trädsom skjuter mot höjden i strävan efter solljus. Där är grenarna synonymer för olika lösningaroch solljuset kundens efterfråga som hela tiden strävas efter. Det för oss tillbaka på hur enteamledare bör agera generellt över ett projekt. Det är som en coachande medarbetare somaktivt involverar projektgruppen på ett demokratiskt och rättvist sätt.

64

Bilaga F

Virtual Reality - Vad är verkligt

Författare: Seth Ramström

F.1 Inledning

När man pratar om Virtual Reality, VR, så pratar man om virtuell verklighet. Det vill sägaen virtuellt skapad värld som efterliknar den verkliga världen, men inte med samma konse-kvenser för hälsan som den verkliga världen kan ha. När man utvecklar spel till VR så är deti dagsläget svårt att veta hur detaljerad den virtuella världen behöver vara för att få använ-daren att känna sig som en del av den världen. Vad är det egentligen människor uppleversom verkligt och hur lätt är det att lura hjärnan?

F.1.1 Syfte

Syftet är att undersöka hur personer upplever virtuell verklighet och vad som upplevs somverkligt samt vad som upplevs som overkligt. Med verkligt menar skribenten livligheten ochgrafiken i miljön och inte varierande interaktionsnivå.

F.1.2 Frågeställning

Denna rapport kommer diskutera följande frågeställningar:

1. Vad upplever personer som verkligt inom virtuella miljöer?

2. Hur grafiskt overkligt kan man göra ett program och ändå få personer att uppleva nå-gon form av verklighet?

F.2 Bakgrund

Under projektet så har projektgruppen SurVive haft som uppgift att skapa en virtuell miljöför att hjälpa personer att bli mer bekväma i situationer då man behöver prata inför en gruppmänniskor. Men under hela projektet så har alltid frågan funnits hos gruppen, hur detaljeratmåste simuleringen vara för att få användaren att uppleva miljön som verklig? Det hardessutom inte funnits bra källor som pekar på hur man skapar en verklig VR-miljö, vilketfödde frågeställningarna i denna rapport.

En annan intressant fundering som fanns i gruppen var hur verkligheten i den virtuellavärlden kan påverka inlärningen eller vanan i en simulering. Detta för att Learn To SurVivehandlar om att göra personer bli mer bekväma och att de ska lära sig hur man håller presen-tationer. Vilket kan förstöras om matchningen mellan verklighet i ett spel och förväntning påverkligheten i spelet inte stämmer.

65

F.3. Teori

F.3 Teori

Definitionen av verklighet består ofta av interaktivitet och livlighet. Interaktivitet är huranvändaren kan manipulera sin omgivning till exempel genom att flytta objekt eller röra sigi rummet. Livlighet är i sin tur hur sinnena tar in information, det vill säga hur det grafisktser ut och ljud i omgivningen. [19]

Det viktigaste med virtual reality och definitionen av verklighet är att varje individ haren egen uppfattning om vad verklighet är vilket gör det svårt att få en bra definition påvad verklighet faktiskt är [19]. En person kan tycka att en bok är bättre på att förmedla enverklighet än vad en film kan förmedla samtidigt som en annan person kan tycka tvärt om.

Man brukar även prata om närvaro och att det som krävs för att skapa en sorts närvarobehövs upplösningar på över 1080p, man behöver ha ett brett synfält i spelet, hög uppdate-ringsfrekvens för att bilden inte ska bli suddig då ögat rör på sig. Om man inte har detta såkan man börja må illa och på så sätt förstöra närvaron i spelet. För att sedan skapa en totalnärvaro så behöver man ha fler nivåer av input såsom att sparka på objekt och att interageramed objekt med hela kroppen och inte bara några kontroller. [52]

F.4 Metod

För att kunna analysera hur användaren upplever olika VR-miljöer så kommer användarenatt utföra ett test. Testet går ut på att användaren får uppleva två olika virtuella miljöer somvarierar i detaljrikedom, men där båda miljöerna innehåller objekt som det går att interageramed. Efter testet så kommer användaren att svara på en enkät för att fånga upp hur använ-daren upplevde miljöerna.

F.4.1 Scenario

I detta avsnitt kommer de två olika VR-miljöerna att bli beskrivna samt vad användarenkommer att få göra i respektive miljö.

Miljö 1: Pusselspel

Den första miljön är ett pusselspel som heter ”The Price of Freedom” skapat av ConstructionStudio. Spelet har en hög detaljrikedom och livlighet, vilket syns i figur F.1. Användaren fåri uppgift att utföra de pussel som finns i spelet och spela klart spelet.

66

F.4. Metod

Figur F.1: Skärmbild ur ”The Price of Freedom”

Spelet går ut på att navigera genom olika rum i en lägenhet genom att klara olika pusselsom till exempel att hitta gömda nycklar och knappar. Under hela spelet så går det att hittabrev och journaler som man kan läsa och få en djupare inblick i historien av spelet och enanledning till varför karaktären i spelet är i lägenheten. För att få ett extra djup av livlighet såberättas även en historia med hjälp av en berättarröst.

Miljö 2: NewtonVR

Den andra miljön är en fysiksimulator som heter ”NewtonVR” och är skapat av TomorrowToday Labs. Spelet är mindre detaljerat och har en lägre nivå av livlighet, vilket syns i figurF.2. I denna miljö så kommer användaren att fritt kunna leka med ett antal objekt utan ettgivet mål.

67

F.4. Metod

Figur F.2: Skärmbild ur ”NewtonVR”

NewtonVR är ett öppet spel för att testa fysik och paketet är menat för att placeras i andraprojekt för att underlätta utvecklingen av andra VR spel. Spelet har en exempelbana därman kan testa alla föremål och se hur de interagerar med omvärlden. Det finns inte helleren historia att berätta eller någon form av föremål att läsa, utan enbart ett ställe att leka ochslänga runt föremål.

F.4.2 Genomförande av testerna

Under testet så kommer användaren att få interagera med miljön för att försöka leva sig ini den virtuella miljön. När användaren sedan står vid ett virtuellt bord så kommer använ-daren att få instruktionen att lägga ifrån sig handkontrollerna på en närliggande yta. Dennainstruktion ges som en del i vad användaren håller på att göra och inte en tydlig instruktionatt gå fram till bordet och lägga ifrån sig kontrollen.

Det är viktigt att instruktionen är så lik den interaktionen som användaren håller på med föratt det ska bli något impulsivt istället för något som tänkts igenom.

F.4.3 Enkät

Utöver testet så kommer användaren också att få svara på ett antal frågor om hur användarenupplevde den virtuella miljön, hur verklig miljön var och vad som kunde gjort miljön merverklig och livlig.

Frågor

Frågorna var:

• Vad var din erfarenhet av VR innan testet?

• Vad var skillnaden mellan de två miljöerna?

• Hur verklighetstrogen upplevde du att pusselspelets miljö var?

68

F.5. Resultat

• Hur verklighetstrogen upplevde du att fysiksimulerings miljö var?

• Vad anser du att man kunde göra för att göra någon av miljöerna mer verkliga?

F.5 Resultat

Här presenteras resultatet av de olika VR-miljöerna samt resultatet av enkäten.

F.5.1 Scenario

Antalet personer som medverkade i testet var fem personer. Under testet i pusselspelet närtestpersonerna blev uppmanade att lägga ifrån sig kontrollen på det närmaste bordet, vardet två av testpersonerna som funderade på att lägga den på det virtuella bordet. En avpersonerna kom så långt som att lägga kontrollen på det virtuella bordet men när handenåkte igenom bordet så kom testperson fram till att det inte skulle gå att lägga kontrollen pådet virtuella bordet. En av personerna funderade på att lägga kontrollen på bordet men närtestpersonen började utföra handlingen att lägga kontrollen på bordet så insåg hen att detinte skulle gå och avbröt handlingen innan personen ens var nära bordet. Dessa personerhade inte heller någon erfarenhet av VR och lät sig vara en del av den virtuella världen.

När testpersonerna fick testa fysiksimuleringen NewtonVR så var det ingen av testper-sonerna som ville lägga kontrollen på ett virtuellt bord och släppa, alla testpersonerna varväl medvetna om att de var inne i en virtuell värld. En av testpersonerna konstaterade att deupplevde en form av verklighet för att interaktionen kändes korrekt och exakt.

De personer som använt VR tidigare eller utvecklat program för VR var mer medvetnaom hur de kan interagera med den virtuella miljön och vilka begränsningar som finns.

F.5.2 Enkät

Efter testet så fick alla deltagare svara på enkäten där 3 av testpersonerna inte hade någonvana av VR innan testet. Alla testpersonerna upplevde att pusselspelet hade var mer verk-lighetstroget är fysiksimuleringen på grund av att det var grafiskt snyggt men också att detberättades en historia på vägen vilket hjälpte till att sjunka in i den virtuella världen.

En person upplevde att fysiksimuleringen var verklighetstrogen, detta på grund av attinteraktionen var väldigt exakt och pålitlig. 80% av testpersonerna tyckte inte att fysiksimu-leringen var verklighetstrogen på grund av att det inte var en verklighetstrogen grafik ochvisuell miljö.

På frågan om vad man skulle kunna göra med de två olika VR-miljöerna för att göra demer verkliga så tyckte många av testpersonerna att för att göra fysiksimuleringen mer verk-lig så behövdes mer bakgrundsljud och att göra miljön grafiskt snyggare. Det fanns ävenåsikter som att om fysiksimuleringen hade varit i ett rum så hade det varit mer verklighets-troget. För att göra pusselspelet verkligare så går det att förbättra bytet mellan scenerna föratt göra det mer verklighetstroget och att göra interaktionerna och fysiken bättre.

De specifika svaren för varje testperson går att ses i figur F.3.

F.5.3 Iakttagelser

Det var två av testpersonerna som skrev att fysiksimulatorn inte var speciellt verklighets-trogen men det som hände under testet var att dessa personer försökte interagera med den

69

F.6. Diskussion

virtuella miljön med hela kroppen genom att försöka sparka på vissa objekt, vilket är i en-lighet med att känna en sorts närvaro i simulatorn. De försökte sparka på objekten för attförsöka göra mer plats för deras ben eller för att det var roligt att sparka på objekten. Det varäven flera av testpersonerna som försökte gå runt vissa objekt till exempel runt dörrar.

I pusselspelet så var det 80% av deltagarna som försökte undvika vissa objekt när de kom förnära ansiktet till exempel dörrar som öppnades mot användaren eller mappar i pusselspeletsom öppnades av sig själva och flög in i testpersonens ansikte.

F.6 Diskussion

Det finns många saker som kunde ha gjorts för att detta test ska ge mer pålitlig data men somtidsmässigt inte ryms inom projektet.

F.6.1 Resultat

Ett av problemen med resultatet är att alla testpersoner har olika definitioner av vad som ärverkligt. Dessutom är det svårt att exakt veta vad personerna upplever som verkligt, vilkettas upp i Defining Virtual Reality: Dimensions Determining Telepresence [19].

Testet betraktades som lyckat om användarens första tanke var att lägga handkontroller-na på det virtuella bordet utan att fundera på om det vore möjligt. Detta för att det bevisaratt användaren och hens sinnen litar på att den virtuella miljön är verklig och går att fysisktinteragera med. Det vill säga att föremål i den verkliga världen kan ligga på föremål i denvirtuella världen. Anledningen till att den ses som lyckat enbart med första tanken är attden fysiska interaktionen med omvärlden kan göra att man blir medveten om sin plats iden riktiga världen. Vilket gör att användaren blir medveten om att det inte går att fysisktinteragera med den virtuella världen och därmed avbryta handlingen. Vilket inträffadevid ett av tillfällena att en av testpersonernas första tanke var att lägga handkontrollen pådet virtuella bordet men när hen börja förflytta sig så insåg testpersonen att det inte skulle gå.

Det var många av testpersonerna som fyllde i att de inte tyckte att fysiksimuleringenvar verklighetstrogen men som rent impulsivt reagerade på allting som inträffade. Det visaratt även om du får frågan på om något är verkligt eller inte så kommer du reagera olika.Detta kan även vara ett resultat på vad personer definierar som verkligt. Det som många avanvändarna reagerade impulsivt på var när ett objekt kom visuellt nära ansiktet eller att detvar ett objekt som de inte kunde gå igenom som till exempel en dörr.

F.6.2 Metod

Det hade gett bättre resultat om det funnits mer tid för att skapa miljöer som påminner omvarandra men med varierande livlighet. Det vill säga inte ha två olika virtuella miljöer därman gjorde olika saker utan två virtuella miljöer som har samma interaktioner men olikanivåer av livlighet och detaljrikedom för att se användarens upplevelse.

För att få pålitligare svar så hade man kunnat göra testerna på fler användare för att fåfler åsikter och därmed en mer korrekt bild av verkligheten.

F.7 Slutsatser

De slutsatser man kan dra av vad personer upplever som verkligt är att när man medvetetfår svara på vad som är verkligt så kommer den tillfrågade personen att luta mot att detsom är grafiskt snyggare är mer verkligt än det som är grafisk fulare. Men att det även finns

70

F.7. Slutsatser

vissa personer som värdesätter interaktion lika mycket som grafiskt snyggt, vilket gör attnågot som har en naturlig interaktion kan vara mer verklig än det som är grafiskt snyggt.Undermedvetet så kommer personer att instinktivt att reagera på objekt som är nära ansiktetoch att vi har lärt oss sedan födseln att solida objekt inte går att färdas igenom vilket gör attman vill ta sig runt solida objekt eller vilja flytta på de.

Detta gör att man kan säga att solida objekt anses som verkliga och kan skada oss omman försöker ta sig igenom de. Men även att en virtuell miljö som är grafiskt snygg medbakgrundsljud och en historia bakom sig är mer verklig än en miljö utan dessa objekt.

71

F.8. Figurappendix

F.8 Figurappendix

72

F.8. Figurappendix

Figur F.3: Svar på enkäten

73

Bilaga G

Testning vid spelutveckling i Unity

Författare: Noak Ringman

G.1 Inledning

Detta bidrag till kandidatrapporten kommer behandla hur testning av ett projekt utvecklati Unity kan utföras. Testning av grafiska miljöer blir annorlunda jämfört med mjukvara sominte har komplex grafik. Det är till exempel svårt att skriva testkod för att testa en specifikgrafisk detalj när enda möjligheten att kontrollera om det fungerar korrekt är att studera detunder faktisk körning. På grund av hur Unity är uppbyggt är det inte möjligt att köra Unity-kod utanför Unity:s utvecklingsmiljö. Det medför alltså att testning också måste ske medderas utvecklingsverktyg.

G.1.1 Syfte

Syftet för denna del är att titta på olika sätt att utföra testning av mjukvaruprojekt med kom-plex grafik med inriktning mot testning med grafikmotorn Unity.

G.1.2 Frågeställning

Rapportens frågeställningar är:

1. Hur kan testning utföras i Unity?

2. Vilka metoder och verktyg kan vara lämpliga för testning vid spelutveckling?

G.2 Bakgrund

Testning av mjukvara har blivit en väsentlig del i all typ av mjukvaruutveckling. Det tar myc-ket resurser att testa kod och det är alltid en balansgång vid utveckling hur mycket resursersom ska avsättas för testning. Det kan utföras på varierande sätt där olika metoder och verk-tyg passar olika typer av projekt. Den här rapporten kommer att ta upp olika sätt att utföratestning av mjukvara för projekt som till stora delar består av komplexa grafiska miljöer. Endel kommer att beskriva hur testning utfördes när simulatorverktyget utvecklades. Det kanifrågasättas varför personer under utveckling ska stanna upp och skriva tester för att se omspelet fungerar istället för att arbeta med nästa uppgift. En fördel är att utvecklare kan skrivaom stora delar av koden och ändå enkelt se att det har samma funktionalitet som tidigare.[53]

I projektet Learn to SurVive var det inte ett spel som spelas på en vanlig bildskärm somutvecklades. Istället användes ett VR-headset vilket gör att spelupplevelsen blir annorlunda.

74

G.3. Teori

Att utveckla mjukvara anpassad för VR skiljer sig inte särskilt mycket från att utveckla mjuk-vara för en 3D-miljö. Testning av VR blir också likt testning av 3D-miljöer. Det är möjligt attspela ett VR-spel på en vanlig skärm. Det som skiljer sig är avsaknaden av handkontrollernasom HTC Vive använder sig av för att bland annat kunna interagera med miljön. Att skapaen testbot till ett VR-spel borde inte vara någon svårighet. Istället för att en testbot styrmus och tangentbord får en testbot skapas som modellerar olika positioner av headset ochhandkontroller.

G.3 Teori

Följande rubriker förklarar olika koncept relaterade till testning.

Enhetstest

Enhetstester är den lägsta nivån av tester som brukar utföras. Syftet är att kontrollera att enliten del av koden, till exempel en viss metod eller klass, ger det förväntade resultat vid enviss indata.[54]

Integrationstest

Efter enhetstestning är vanligtvis integrationstestning nästa steg. Syftet är att integrations-testerna ska utformas så att flera olika delar av programkoden behöver kommunicera medvarandra. Om gränssnitt mellan olika kodmoduler inte är korrekt implementerade kommerdet att upptäckas.[54]

G.3.1 Kontinuerlig integration

Kontinuerlig integration (Continuous integration) är ett system som kontinuerligt slår sam-man ny kod och utvärderar resultat. Ett sådant system kan konstrueras på många olika sätt.Vanligen versionshanteras kod som skrivs av utvecklare. När versionshanteraren får en upp-datering av kod startas en byggprocess av all kod. Vid eventuella byggfel notifieras utveck-larna, ofta används ett program för det. När ett program lyckas bygga utförs tester, enhets-och/eller integrationstester, resultatet skickas till utvecklarna.[53]

G.3.2 Unity

Unity är en avancerad spelmotor med stöd för både 2D- och 3D-miljöer. Den hanterar allfysik som ljus, ljud och interaktion mellan föremål. Unity utvecklas av Unity Technologiesoch finns till flera olika plattformar, bland annat Linux, XOS, Windows och Android.[55].

G.4 Metod

Resultatet består av den kunskap som samlas in om utvalda metoder och verktyg för testning.Artiklar, webbsidor, videoklipp och böcker användes som kunskapskälla. Vilka metoder ochverktyg som behandlas valdes utifrån dess relevans till frågeställningarna. Under projektetLearn to SurVive utförde gruppen ett begränsat antal tester, hur dessa utformades kommerockså att beskrivas under resultatdelen.

G.5 Resultat

Här beskrivs verktyg som kan används för testning generellt samt testning i Unity.

75

G.5. Resultat

G.5.1 Testflödesdiagram

Testflödesdiagram (Test Flow diagrams) kan liknas vid en grafisk version av vägtäckning(path coverage), där det är tänkt att testa alla olika vägar som är möjliga att gå. Det är ettnaturligt sätt att testa programvara. Eftersom många spel är komplexa och beror på mångaolika parametrar blir det snart svårt att utföra testning med testflödesdiagram för hela spel.Det är ändå möjligt att testa begränsade delar, till exempel en viss scen, med testflödesdia-gram. I testflödesdiagram används händelser (events), verkan (action) och tillstånd (states).”Händelser” är det som spelaren utför och då är det förväntade svaret på den händelsen”verkan”. Beroende på vilket ”tillstånd” spelaren är i kommer olika verkan att ske för olikahändelser. Se figur G.1 för exempel [56].

Figur G.1: Exempel på ett testflödesdiagram

G.5.2 Unity generellt

Ur en viss synvinkel försvårar Unity testning av spel. Det beror på att en stor del av klassernaär beroende av att de implementerar gränssnittet MonoBehaviour och det går bara att köra iUnity:s utvecklingsmiljö. Det medför att testverktyg som annars skulle vara relevanta inte gåratt använda. Unity har istället skapat flera egna verktyg för att underlätta testning. Det finnspaket i Unity för enhetstestning, baserat på ramverket nUnit. Även verktyg för integrations-och systemtestning finns inkluderade i Unity via tillägg. Verktyget för integrationstestning ärkraftfullt eftersom det startar en hel scen i Unity och laddar in de objekt som testen ska utföraspå. Exempel på saker som kan testas med hjälp av detta verktyg är kollision mellan olikaobjekt och tid det tar innan vissa händelser sker. Testerna blir plattformsberoende eftersomhela Unity-motorn körs. Tanken är att det ska underlätta att köra integrationstester på olikaplattformar för att kunna upptäcka fel som bara uppstår på en specifik plattform.[53][57]

Integrationstestning i Unity

För utvärdering av hur integrationstester kan användas under projektet skapades några enklaintegrationstester. Det var bland annat att kontrollera huruvida spelobjekt kolliderade (gick igenom varandra grafiskt) med varandra eller inte. Simulationen har fiktiva studenter som går

76

G.6. Diskussion

från dörr till stol i salen. Ett test gick då ut på att kontrollera om studenterna kolliderade medde bord som finns i salen, alltså en grafisk bugg som inte kan uppträda i den riktiga världen.Testet fungerade bra och blev underkänt vid kollision och godkänt när kollision uteblev.[57]

Grafiskt testverktyg i Unity

För att kunna utföra grafiska tester har Unity ett verktyg med namnet Graphic TestsTool. Med detta verktyg ska utvecklare enkelt kunna sätta upp en specifik scen med spe-cifika parametrar och sedan godkänna en ögonblicksbild av scenen. Denna scen ska sedankunna köras automatiserat på valda hårdvaruplattformar. Resultatet från det automatiseradetestet, ögonblicksbilden från scenen, jämförs sedan med en tidigare godkänd ögonblicksbild.Om det finns förändringar kommer testet att markeras som misslyckat och det blir då upptill den testansvarige att jämföra bilderna för att besluta om ett oavsiktlig fel har upptäckts.Unity kan hjälpa testansvarige att hitta felet på bilden genom att endast visa skillnadernamellan bilder samt att snabbt byta mellan bilderna.[58]

Testautomation

Automatiserade tester går ofta hand i hand med kontinuerlig integration. Unity har gjortdet möjligt att skapa en miljö med kontinuerlig integration. Tanken är att både Unity:s en-hetstester, integrationstester samt Graphic Tests Tool ska kunna köras i en servermiljö somskickar återkoppling i form av kodens status. Unity har skapat en egen servermiljö mednamnet Unity Cloud Build. Det är det enklaste alternativet för kontinuerlig integrationav Unity men det finns mer avancerade alternativ när fokus är automatiserade tester. Enpopulär öppen källkodsmjukvara för kontinuerlig integration och automatiserade tester ärJenkins[59].[53]

G.5.3 Speltest

För att testa spel innan lansering används människor som spelar genom hela spelet. Det ärviktigt för utvärdering av funktionalitet som balans och underhållningsfaktor. Resultatet fråntesterna blir mer mjuk till skillnad från till exempel enhetstester. Hur speltester utförs kanvariera. Återkopplingen från spelaren kan vara i form av en enkel konversation eller så kanalla val som spelaren gör sparas och svara på en enkät. [56][60]

G.5.4 Testbot

Genom att skapa ett program (testbot) som spelar spelet i utvärderingssyfte har det visatssig vara tidseffektivt till skillnad från att ha flera människor som spelar. Nivån på testbotenkan variera mycket. De enklaste testbot:arna kan bara utföra slumpmässiga kommandon me-dan de mer avancerade har inslag av artificiell intelligens och utformats för att efterlikna enmänsklig spelare.[61]

G.6 Diskussion

Under projektet Learn to SurVive utfördes inte så mycket tester som det var planerat. Dettamedförde att endast vissa delar av Unity:s testverktyg användes. Det var framförallt enhets-tester som utfördes på de mer komplicerade funktionerna. På grund av att flera var obekantamed Unity sedan tidigare gick mycket tid åt till att förstå hur man bör bygga ett spel iUnity. För att kunna skriva bra enhetstester krävs en bra förståelse för hur Unity är tänktatt användas, förståelse kommer med utvecklingserfarenhet vilket gjort att enhetstesternaminimerades.

77

G.6. Diskussion

Under resultat sades att integrationstesterna fungerade bra fastän detta skapades det in-te några fler integrationstester, anledningen till det var flera. En av anledningarna var att detvar svårt att få studenterna att inte kollidera med ett enda bord. Även om kollision skeddeså var det ofta lite, så lite upplevs inte om ett problem och det såg fortfarande bra ut. Dethade antagligen varit möjligt att lägga mer tid för att få test som blev godkända fastän detblev en liten kollision men tidspåslaget upplevdes inte som motiverat. En av fördelarnamed integrationstester är att det blir enkelt att utföra flera ändringar samtidigt och av flerautvecklare. Det var inget som utnyttjades under projektet då arbetet delades upp på ett sådansätt så flera utvecklare inte arbetade på samma sak.

En svaghet med Unity:s integrationstester är att det inte är möjligt att se grafiken närtestet körs. Om det skulle vara möjligt blir det enklare att kontrollera att testet fungerarsom det är tänkt. För kontroll att en scen var korrekt fick den först köras som vanligt vidutveckling för att sedan lägga på de testscript som integrationstesterna kräver. Om änd-ringar behöver utföras bör dessa göras i en scen utan tester. Om integrationstester är tänktaatt köras på en annan dator eller server blir grafiken överflödig men så är nog inte alltid fallet.

Det verkar inte som att någon av de verktyg som tagits upp under Resultat hjälper ut-vecklarna att utvärdera huruvida spelet är underhållande eller inte. Det är den absolutviktigaste delen av ett spel, om få personer uppskattar spelet leder det till uteblivna intäkterför företagen. Antagligen måste det vara människor som utvärderar spelets underhållnings-faktor än så länge. Det kan finns möjlighet att mycket avancerade testbot:ar kan utvärderaunderhållningsfaktorn i framtiden men inte idag. Det finns företag som vid vissa milstenarskickat ut senaste versionen av spelet till alla på företaget. Det resulterade i mycket åter-koppling samt många nya förslag [62]. Att kunna ta hand om all återkoppling vid en sådansituation blir svårt med en vattenfallsmodell. Det är en av anledningarna till varför ett agiltarbetssätt är bättre vid spelutveckling. Enligt Patrick Stacey och Joe Nandhakumar fungerarspelutveckling i vad de ser som en boomerang. Man utgår alltid från speltester och beroendepå vilket resultat de ger kommer man gå vidare till antingen koncept, design eller kod.

Det är möjligt att skapa testbot:ar för ett spel i Unity. Det kan vara så att det går att konfigure-ra en testbot som spelar vissa dela av spelet med hjälp av Unity:s integrationstester. Genomatt skapa en eller flera testbot:ar som utför uppgifter i spelet kan antalet timmar som enmänniska speltestar antagligen minskas men som nämndes tidigare är det svårt för testbot:aratt utvärdera hur underhållande spelet är. Testflödesdiagram kan hjälpa testare att utformabättre integrationstest, testbot:ar och speltester. Väl definierade testflödesdiagram blir en bragrund för att skapa testbot:ar. Skapa testbot:ar som går igenom hela testflödesdiagram ochdå testat alla möjliga händelser, verkan och tillstånd kan vara ett bra arbetssätt.

Genom att använda Unity Test Tools tillsammans med ett program som hanterar kontinuerligintegration kan utveckling underlättas. Det är möjligt att köra Unity Test Tools tillsammansmed Jenkins [63]. Det är ett bra alternativ för att få en bra struktur av tester i Unity. Huruvidadet är möjligt att utöver Unity Test Tools köra någon form testbot tillsammans med Jenkinsär okänt. När alla tester är godkända och en testbot har genomfört uppgifter blir det möjligtatt ta den byggversionen och skicka ut för speltester. Eftersom Graphic Tests Tool inte är endel av Unity Test Tool är det också oklart om det även går att integrera det i Jenkins. Om detär möjligt få alla dessa delar att fungera i symbios ses det som ett komplett testverktyg förUnity.

78

G.7. Slutsatser

G.7 Slutsatser

Slutsatsen blir att för att en testledare ska kunna sätta upp ett komplett system för testning avprogramvara baserad på spelmotorn Unity krävs expertis inom både Unity:s uppbyggnad,versionshantering samt kontinuerlig integration. Självklart är det också möjligt att endastanvända vissa verktyg, till exempel integrationstesterna i Unity men det krävs fortfarandekunskaper om Unity. Erfarenheter som tas med blir att det är mer omständligt att testa mjuk-vara som bygger på Unity för den som är nybörjare inom Unity. Det bör också nämnas attäven om flera testverktyg används är speltester viktigt för att validera ett spel.

79

Bilaga H

Påverkan av att skriva lokalt eller viamolntjänster

Författare: August Uusitalo

H.1 Inledning

För att ett projekt skall lyckas på en betydelsefull nivå gäller det att projektet utvecklas i klaraoch tydliga steg. Oberoende av vilken utvecklingsmetodik som utnyttjas, så kommer projek-tets dokumentation spela en kritisk roll i hur uppbyggnaden av projektet går till. På grundav att det ligger en sådan vikt i hur väl utförd projektets dokumentation är, blir det viktigt attinte låta faktumet att hela gruppen deltar i skrivandet påverka kvaliteten på dokumentet. Attse till att dokumenten upplevs som skrivet av en författare, även om det är flera individersbidrag då en språkligt splittrad dokumentation kan upplevas som oprofessionell. Enigheteni dokumenten är viktig för att läsaren inte skall behöva anpassa sig utefter skrivstilen som dåkan skifta från stycke till stycke. Hur går det då till för att enkelt skriva, korrekturläsa, ochversionshantera dokument i grupper?

H.1.1 Syfte

Syftet med denna rapport är att utreda de positiva och negativa aspekter som förekommeri valet att skriva dokumentation lokalt eller att skriva över molnbaserade tjänster. Därefterställa dessa aspekter mot varandra för att avgöra hur stor inverkan det har på dokumentatio-nen.

H.1.2 Frågeställning

De frågeställningar som denna rapport kommer undersöka är som följer:

1. Vilka för- och nackdelar med att arbeta med dokumentation lokalt?

2. Vilka för- och nackdelar med att arbeta med dokumentation via molntjänster?

3. Hur stor inverkan har valet att skriva lokalt eller via molntjänster på dokumentskrivan-det i projektet varit i slutändan?

H.2 Bakgrund

Under projektet i kursens start bestämdes det för den stora mängden dokumentation somskulle produceras att alla dokument skulle skrivas i LATEX. Anledningen till detta var att trotsinlärningskurvan är resultatet värt det. Formatering och andra nödvändiga funktioner som

80

H.3. Teori

krävs för att färdigställa dokumenten är i slutändan mindre besvär än om man skulle ge-nomföra det i något WYSIWYG-verktyg, som till exempel Microsoft Word. Det enda proble-met med att använda LATEX var på vilket sätt det skulle göras på. Förslaget var ursprungligenatt utnyttja ShareLATEX men på grund av bristande Git-stöd så försvårade det skrivandet förgruppmedlemmar som föredrog att skriva lokalt. På så vis röstades det in testperioder för attskriva lokalt, men även för att skriva över molntjänster.

H.3 Teori

När man skriver i LATEX så finns det en stor mängd verktyg att välja från. I detta avsnitt finnsbeskrivningar av både LATEX men även de verktyg som utnyttjats under projektets gång.

H.3.1 LATEX

LATEX är ett typsättningssystem baserat på Donald Knuths typsättningssystem TEX. Syftetmed typsättningssystemet är att generera ett högkvalitativt dokument, samtidigt som manlåter användaren fokusera på innehållet och låta formateringen sköta sig själv. Användarenbestämmer och beskriver strukturen i dokumentet med kommandon som sedan tolkas ochformateras av LATEX. På grund av hur smidigt det är att formulera vetenskapliga begrepp ochmatematiska formler i LATEX till skillnad från texteditorer som Microsoft Word, så är LATEXvälanvänt inom akademiska syften [64].

Skriva lokalt

Oftast när man arbetar med individuella dokument så är det vanligaste sättet att arbetalokalt, det vill säga att köra en valfri text-editor på sin maskin. .tex-filen matas in i valfrittTEX-program med LATEX-macron inladdade och sedan genereras en fil, lämplig för förhands-granskning eller utskrift [64]. Denna metod fungerar oberoende av internetanslutning, menvalet av text-editor och TEX-program kan variera mellan operativsystem (exempelvis MacTEXför OS X, proTEXt för Windows samt TEX Live för Unix-varianter, GNU/Linux och Windows).

När det kommer till att skriva projektarbeten lokalt gäller det att synkronisera alla loka-la delar på ett lämpligt sätt. Ett exempel på detta kan vara via versionshanteringstjänster såsom GitHub [65]. En annan viktig aspekt av att skriva lokalt i grupp är att på ett tydligt sättfördela arbetsuppgifter, eftersom gruppmedlemmar antagligen inte kommer se varandrasbidrag förrän man lägger upp sitt färdigställda arbete. Detta innebär att textens innehållriskerar att överlappa om inte arbetsuppgifterna är väldefinierade.

ShareLATEX

ShareLATEX är en molnbaserad, online-editor för LATEX med stöd för samarbete i realtid [66].För att nyttja ShareLATEX behövs inget specifikt program installeras, utan det fungerar direkti webbläsaren. På så vis är tjänsten inte knuten till något specifikt operativsystem, men haristället ett beroende av internetanslutning.

ShareLATEX använder sig av en så kallad freemium-modell, det vill säga att det är gratisatt använda men det finns funktioner som är begränsade till betalande användare. Gra-tisanvändare kan bruka funktioner som publika och privata projekt, stavningskontroll,kollaboration i realtid samt PDF-generering. Betalande användare kan utnyttja dessa funk-tioner men har även tillgång till funktioner som ändringshistorik och synkronisering tillDropbox och GitHub, vilket i sin tur innebär att man kan fortsätta att arbeta med sina projektlokalt [66][67].

81

H.4. Metod

Overleaf

Likt ShareLATEX så är Overleaf en molnbaserad online-editor för LATEX med stöd för samarbetei realtid [68]. Det kräver heller inget speciellt program för att användas, då det bara är att körai webbläsaren. Detta i sin tur innebär att det heller inte är bundet till något operativsystem,men kräver internetanslutning.

Overleaf använder sig, precis som ShareLATEX, av en freemium-modell. Modellen skiljersig lite från ShareLATEX:s variant, men överlag så erbjuds liknande tjänster. De mest mar-kanta skillnaderna mellan modellerna är gratisanvändarnas funktioner. Exempelvis så ärprojekt inte nödvändigtvis privata, men ”hemliga”. Samtidigt så erbjuder Overleaf stöd förGitHub-synkronisering även för gratisanvändare [69]. Slutligen så finns det ett så kallat RichText Mode som formaterar texten medan man arbetar med den, för att ge lite mer av enWYSIWYG-känsla för nyare användare. Utöver detta så skiljer sig inte gratisvarianten avOverleaf sig så mycket från gratisvarianten av ShareLATEX. Betalande användare kan utöveralla dessa funktioner även ha tillgång till synkronisering till Dropbox, möjligheten att göraprojekt privata och slutligen ha tillgång till fullständig dokumenthistorik [68].

H.4 Metod

För att besvara frågeställningen huruvida det är bäst att skriva lokalt eller via molntjänstergenomförde projektgruppen två testperioder i den första iterationen av projektet. Detta föratt utvärdera och avgöra vilken skriftmetod som skulle brukas i resten av projektet.

Den första testperioden bestod av två veckor där hela gruppen skrev all dokumentationlokalt på sina egna maskiner. Dokumenten blev uppdelade i mindre delar som sedan deladesut som uppgifter med hjälp av Trello-kort. Därefter fick varje medlem skriva på valfritt sätt.Med jämna mellanrum så synkroniserades dokumenten med hjälp av GitHub, på så vis gickdet att hålla reda på hur nära dokumenten var att vara färdigställda.

Den andra testperioden bestod av två veckor där hela projektgruppen istället skrev övermolntjänster, en vecka i ShareLATEX och en vecka i Overleaf. Arbetsmetoden var uppdeladpå samma sätt som under den första testperioden, det vill säga att dokumenten deladesupp i Trello-kort som sedan genomfördes denna gången utan synkroniseringen från GitHub,eftersom alla arbetade i samma dokument.

Avslutningsvis, när testperioderna var genomförda, hölls ett ingående möte där beslutfattades för att ta fram den metod som fungerat bäst för dokumentskrivandet. Det togsfram en enkät för att konkretisera gruppmedlemmarnas åsikter och tankar angående helaproceduren, vilket illustreras i figur H.1.

H.5 Resultat

I detta kapitel redogörs de resultat som uppnåtts genom de undersökningar som genomförtsunder projektets gång.

Åsikterna var blandade angående vilket verktyg som fungerade bäst, men beslutet somfattades baserades på den lösning som kom med flest valmöjligheter i arbetsfrihet. Lösning-en blev att köra Overleaf på grund av att stödet för GitHub ingick i gratisfunktionerna. Det isin tur innebar att om lusten fanns för att skriva lokalt så fanns möjligheten att göra det ochsamtidigt tillåta synkronisering med dokumenten som annars skrevs på i molntjänsten.

En intressant iakttagelse var skillnaden i så kallade skrivdialekter. Ett dokument skrivet

82

H.6. Diskussion

av flera deltagare riskerar ofta att skilja sig i berättarröst när det är fler än en författare [70].Detta var ett fenomen som var tydligast under den första testperioden, då skrivandet varlokalt. När skrivandet sedan övergick till molntjänster tenderade skribenter att anpassa sigefter text redan skriven i dokumenten, eftersom texterna var synkroniserade över moln,vilket resulterade i en mer uniform skrivstil.

Fortsättningsvis så bidrog molnskrivandet till mer enhetliga texter genom att korrektur-läsningen blev lättare. Att ta sig igenom stora dokument i en grupp och göra ändringar irealtid visade sig vara enklare när allt låg synkroniserat över molnet. De ändringar somgenomfördes under korrekturläsningen, som då gjordes i grupp, bidrog till att ena alla skri-vardialekter till en, unison dialekt. Detta eftersom alla gruppmedlemmar delar sina åsikterångående skriften så när dokumenten blir korrigerade är alla eniga om att ändringen var fördet bästa.

En annan intressant iakttagelse var att skrivandet lokalt inte alltid gav effektivt arbete.På grund av att det inte gick att se varandras skrift i realtid, gick det aldrig veta vad somvar färdigskrivet och vad som fortfarande behövde göras. Även om arbetet var uppdelat iTrello-kort, hände det att gruppmedlemmar tog sig an fler uppgifter än vad som gick kla-ra av. Under samma tid som det krävdes för att färdigställa allt detta arbete, hann andragruppmedlemmar påbörja en del av samma uppgifter då arbetet var för omfattande för enperson. Fortsättningsvis är det svårt att uppskatta hur stora kapitel och delar kommer att bli.Dessa faktorer innebar att arbete ibland skrevs simultant på flera lokala ställen och sedankolliderade vid synkronisering.

H.6 Diskussion

Det verkar som att ett överliggande tema när det kommer till valet att välja rätt verktyg föratt skriva stora arbeten mest handlar om att inte välja det som är bäst, men att istället välja detsom är ”minst sämst”. Nackdelarna tenderar att väga tyngre än fördelarna, oavsett verktyget.

Det största problemet med lokalt skrivande är huvudsakligen att det är svårt att koordi-nera. Även om det styrdes upp med att dela upp uppgifter i Trello-kort så var påverkanav detta minimal. Oavsett om uppgifter var utdelade eller ej, så fanns det lite material attförhålla sig till när det inte gick att se vad andra gruppmedlemmar skrivit. Detta gjorde såatt närbesläktade stycken och kapitel tenderade att överlappa. Kapitel som blivit utdeladetill någon gruppmedlem blev färdigställda av någon annan gruppmedlem som hade råkatfå en oförväntat kort uppgift att ta hand om. Även om det egentligen skulle gå att åtgärdagenom att styra upp det så att Trello-korten skulle följas mer strikt, så återkommer problemetmed skrivdialekter. Att det inte går att se vad de andra skriver förrän de är färdiga ochsynkroniserat sitt arbete förstärker skillnaden i skrivdialekter. Fortsättningsvis så upplevsdet vara mer besvär att korrekturläsa i grupp när allting är skrivet lokalt vilket bidrar till attskrivdialekten skiljer sig ytterligare. Dessa två faktorer bidrar till att arbetet fördröjs på etteller annat sätt, då det tar längre tid att justera enhetligheten.

När det kommer till molntjänster så är problemen mer utspridda beroende på vilken tjänstman använder. Oavsett vilka problem som väger tyngst, så är roten till problemen densam-ma: att molntjänster utnyttjar freemium-modeller. På grund av att tjänsterna har utgifter (iform av serveruppehåll och dylikt) så kräver de också inkomster. Detta görs genom att knytafunktioner som gör arbete smidigt till kostnader, och låta gratisfunktionerna vara begränsadeså att arbetet endast går genomföras nätt och jämt.

De huvudsakliga problemen med ShareLATEX är att alla viktiga funktioner är avgränsade

83

H.7. Slutsatser

till betalande användare. Saker som synkronisering till GitHub och Dropbox, ändringshi-storik och antalet användare per projekt. Det sistnämnda var faktiskt en större faktor änförst förväntat. Att man inte kan ha medarbetare som delar på ett projekt utan att vara enbetalande användare var till en början inte ett så stort problem. Det visade sig senare att närflera delar på kontot och arbetar i ett gemensamt projekt och sedan vill använda en klassiskfunktion som ”Ångra”, så kunde man av misstag ångra en annan skribents arbete eftersomalla användare agerade under samma konto.

Problemen med Overleaf var inte nödvändigtvis att viktiga funktioner var avgränsade tillbetalande användare, utan snarare att de gratisfunktioner som fanns var av skiftande nivå ikvalitet. Till exempel så är det automatiserade PDF-genereringen av dokumenten en väldigtbehändig funktion till en början, men ju större projekt desto större problem med genereringenuppstår. De kompileringsfel som uppstår dyker upp för alla som skriver, oavsett om alla somskriver faktiskt kollar PDF:en. Utöver det så är genereringen ibland så pass långsam att manfår kompileringsfel för rättskriven syntax, då PDF:en inte hinner med att uppdatera allt somskrivits mellan genereringar och ger fel på grund av det som återigen besvärar alla skrivande.

Ett gemensamt problem för molntjänster som inte har att göra med freemium-modellenär faktumet att de kräver konstant internetanslutning. Egentligen är det ett förhållandevislitet problem, speciellt med tanke på att internet börjat räknas som en mänsklig rättighetså borde inte konstant internetanslutning vara ett problem [71]. Trots det så är behovet attförlita sig på nätverk för att ens kunna skriva alls en negativ aspekt av molnskrivandet.

H.7 Slutsatser

I detta kapitlet redogörs en sammanställning av resultat och diskussion med syfte att besvarafrågeställningarna.

H.7.1 För- och nackdelar med att skriva lokalt

De absolut starkaste fördelarna med att skriva lokalt är frihet. Man är inte på något sätt knu-ten till något speciellt program för att kunna genomföra sitt arbete, utan valfriheten blandbåde texteditor och TEX-program finns. Detta tillsammans med oberoendet av internetanslut-ning för att kunna skriva innebär att lokalt skrivande är väldigt portabelt och flexibelt. Dettakommer dock med kostnaden av strikt organisation för att få arbetet att fungera i grupp, dådet är väldigt enkelt hänt att arbete går förlorat om det råkar överlappa. Denna kostnad i sigär helt överkomlig, men tar upp mycket tid för att struktureras väl samtidigt som det krävsen väldisciplinerad grupp att följa strukturen.

H.7.2 För- och nackdelar med att skriva via molntjänster

Många av nackdelarna att skriva över molntjänster kommer huvudsakligen från utnyttjandetav freemium-modeller. Detta är huvudsakligen problem som är överkomliga om budgetenför projektet är hög och betaltjänsterna är värda nog att investera i för att förbättra projekt-kvaliteten och underlätta skrivandet. För grupprojekt så kommer molntjänster med mångafördelar, huvudsakligen i form av att det ger någon form av helhet i skrivandet för alla skri-benter. Det som finns i dokumentet är alltid uppdaterat till senaste version, så det finns alltidrelevant material att förhålla sig till. Utöver det så gör det kollektiv korrekturläsning mycketenklare. Dessa två faktorer bidrar till en mer unison skrivardialekt som ger en professionellkaraktär till dokumenten.

84

H.7. Slutsatser

H.7.3 Slutgiltig inverkan

Avslutningsvis så är den totala inverkan av valet av skrivmetod inte enorm. Huvudsakligenär många för- och nackdelarna hos bägge metoder aningen subjektiva vilket innebär att valetkommer ner till preferenser för gruppen, och hur man väljer att arbeta med dokumenten.

Med det sagt så är det värt att påpeka att vissa metoder är enklare, om inte bättre änandra, beroende på hur arbetet med dokumentationen bedrivs. För små eller individuelladokument spelar fördelarna med molntjänster inte någon större roll och bidrar med väldigtlite både i form av arbetsmetodik, men också rent innehållsmässigt. Det i sin tur innebär attskriva lokalt kanske är bättre lämpat för sådana uppgifter, och med tanke på portabiliteteni att skriva lokalt så innebär det att man heller inte är knuten till någon specifik plats för attgenomföra arbetet vilket är önskvärt för individuella skrifter.

Dokument som är lite större och skrivs i grupp kan dra större nytta av molntjänster ef-tersom fördelarna med molntjänster har mer fokus på att göra kollaborativt skrivandeenklare. Förlusten av flexibiliteten spelar inte lika stor roll för dessa projekt. Speciellt ef-tersom man ändå vill hålla någon form av konstant diskussion angående innehållet med singrupp i formulerandet av arbetet, vilket innebär att ha arbetet knutet till en specifik plats intenödvändigtvis är något negativt.

Slutligen så för ännu större projekt kanske det är lämpligast att dela upp arbetet till enkombination av kollaborativt- och individuellt skrivande. Denna kombination kan ävenöverföras till skrivmetoder så att individuella delar skrivs lokalt om så önskas, och gemen-samma delar kan utnyttja fördelarna med molntjänster och skrivas därefter. På så vis draman nytta av alla fördelar som finns till hands, samtidigt som man undviker så många avnackdelarna.

85

H.8. Figurappendix

H.8 Figurappendix

86

H.8. Figurappendix

87

H.8. Figurappendix

88

H.8. Figurappendix

89

H.8. Figurappendix

Figur H.1: Svar på enkäten angående skrivmetoder

90

Litteraturförteckning

[1] [www] Extreme Programming: A gentle introductionhttp://www.extremeprogramming.org/, hämtad 2017-05-23.

[2] [Artikel] Kangas Dwyer Karen, M. Davidson Marlina, Is Public Speaking Really More Fea-red Than Death?, Communication Research Reports, 2012–04;29(2):99-107.

[3] [Artikel] Deak Stefan, Kristoffersson Glenn, Rädslan för det som finns och inte finns: Enrandomiserad kontrollerad jämförelse av utfall mellan sedvanlig ensessionsbehandling och be-handling med virtuella stimuli mot spindelfobi, Stockholms universitet, publicerad 2015.

[4] [www] Randolph Keith, Sports Visualizations, publicerad 2002–05–15,http://www.llewellyn.com/encyclopedia/article/244, hämtad 2017–03–01.

[5] [E-bok] Spooner Edward, Catch the Magic: Athletics the Mental Game, ISBN-10:1630004766, publicerad 2013–08–06.

[6] [Bok] Hosseini, Hamid S, Contributions of Medieval Muslim Scholars to the History of Eco-nomics and their Impact: A Refutation of the Schumpeterian Great Gap, ISBN: 9780631225737,publicerad 2003.

[7] [www] Unity – Fast Facts,https://unity3d.com/public-relations, hämtad 2017–04–26.

[8] [www] DirectX – feature levelhttps://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx,hÃd’mtad2017--06--22.

[9] [www] SSE2 documationhttps://docs.oracle.com/cd/E18752_01/html/817-5477/epmpv.html,hÃd’mtad2017--06--04.

[10] [www] Unity – System reqiermentshttps://unity3d.com/unity/system-requirements, hämtad 2017–06-22.

[11] [Artikel] Tilkov S, Vinoski S. Node.js: Using JavaScript to Build High-Performance NetworkPrograms, IEEE Computer Society, publicerad 2010–11.

[12] [Bild] Lakeworks, Scrum process, publicerad 2009-01-09,https://commons.wikimedia.org/wiki/File:Scrum_process.svg, hämtad2017–05–02.

[13] [Artikel] Lei Howard, Ganjeizadeh Farnaz, Jayachandran Pradeep Kumar, Ozcan Pinar,A statistical analysis of the effects of Scrum and Kanban on software development projects, Ro-botics and Computer-Integrated Manufacturing 2015–12;43:59–67.

[14] [www] Flask Documentationhttp://flask.pocoo.org/, hämtad 2017–04–26.

91

Litteraturförteckning

[15] [www] What is MySQL?https://dev.mysql.com/doc/refman/5.7/en/what-is-mysql.html, häm-tad 2017–05–22

[16] [www] Sandahl Kristian, Föreläsningar i programutvecklingsmetodik vid LiU, publicerad2016–10–11,http://www.ida.liu.se/~TDDC88/theory/lectures.shtml, hämtad 2017–02–07.

[17] [Artikel] Bippa T.,Lepperb A., Schmeddingb D , Pair programming in software develop-ment teams – An empirical study of its benefits, Information and Software Technology 2008-02;50(3):231-240.

[18] [www] Git using brancheshttps://www.atlassian.com/git/tutorials/using-branches, hämtad2017–05–03.

[19] [Artikel] S Jonathan, Defining Virtual Reality: Dimensions Determining Telepresence, Journalof Communication 1992–12;42(4):73–93.

[20] [Artikel] Cervin A, Johnsson C, Robertsson A och Rydén T, Återkoppling som del i läran-deprocessen, LTHs 4de pedagogiska inspirationskonferens, 2006–06.

[21] [www] Epic Games, Unreal Engine 4 For Unity Developers,https://docs.unrealengine.com/latest/INT/GettingStarted/FromUnity, hämtad 2017–05–02

[22] [www] Kriegel Robert J. Ph.D., Taking Timeouts to Decrease Stress and Increa-se Creativity, http://www.huffingtonpost.com/robert-j-kriegel-phd/unplug-recharge_b_1333126.html, hämtad 2017–06–06

[23] [Artikel] Li, D., Halfond, W.G.J., An investigation into energy-saving programming practicesfor android smartphone app development, 3rd International Workshop on Green and Sustai-nable Software, GREENS 2014 - Proceedings, 2014–06-01:46-53.

[24] [Bok] Nagayama R. S., Seyama J.,Probing the uncanny valley with the eye size aftereffect,Presence: Teleoperators and Virtual Environments, 2009–10;18(5):321-339.

[25] [E-bok] Flanagan, David. Javascript: The Definitive Guide (6th ed), O’Reilly Media, ISBN10:1-4493-0212-2, publicerad 2011–04.

[26] [www] The Python Tutorialhttps://docs.python.org/3/tutorial/index.html, hämtad 2017–06–19.

[27] [www] Fielding Dissertation: Chapter 5.http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm, hämtad 2017–06–19.

[28] [www] Python Documentation: Thread-Based parallelismhttps://docs.python.org/3/library/threading.html, hämtad 2017–04–26.

[29] [www] Mozilla Developer Network: Promiseshttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise, hämtad 2017–04–27.

[30] [Bok] Ben Collins-Sussman, Brian W. Kirkpatrick, Michael Pilato, Version control withSubversion, O’Reilly Media, ISBN 10:0-596-00448-6, publicerad 2004.

92

Litteraturförteckning

[31] [Artikel] Daniel Kuhn, Distributed Version Control Systems,http://www.sonicwaves.de/downloads/publications/Distributed-Version-Control-Systems.pdf, publicerad 2014.

[32] [Artikel] Daniel Knittl-Frank, Analysis and Comparison of Distributed Version ControlSystems, publicerad 2014.

[33] [Artikel] Konrad Hinsen, Konstantin Läufer, George K. Thiruvathukal, Essential Tools:Version Control Systems, Computing in Science & Engineering, 2009–11/12;11(6):84-91.

[34] [Artikel] Stefan Otte, Version Control Systems,http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.172.867&rep=rep1&type=pdf, publicerad 2010.

[35] [Artikel] Brian De Alwis, Jonathan Sillito, Why are software projects moving from centrali-zed to decentralized version control systems, Cooperative and Human Aspects on SoftwareEngineering, 2009–05, ISBN: 978-1-4244-3712-2.

[36] [Artikel] Caius Brindescu, Mihai Codoban, Sergii Shmarkatiuk, Danny Dig, How DoCentralized and Distributed Version Control Systems Impact Software Changes?, Proceedings- International Conference on Software Engineering, 2014–05–31:322-333.

[37] [www] CMMI Maturity Levels,http://www.tutorialspoint.com/cmmi/cmmi-maturity-levels.htm, häm-tad 2017-04-24.

[38] [Bok] Shari Lawrence Pfleeger, Joanne M.Atlee, Software Engineering: theory and practice,Pearson, ISBN: 0138141819, publicerad 2010.

[39] [www] Inheritance: The Java Tutorials,https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html, hämtad 2017–05–08.

[40] [www] Inheritance in C# and .NET,https://docs.microsoft.com/en-us/dotnet/articles/csharp/tutorials/inheritance, hämtad 2017–05–08.

[41] [www] Inheritance, HaXe Manual,http://haxe.org/manual/types-class-inheritance.html, hämtad 2017–05–08.

[42] [Artikel] Vittoreo Romeo, Analysis of entity encoding techniques, design and imple-mentation of a multithreaded compile-time Entity-Component-System C++14 library, DOI:10.13140/RG.2.1.1307.4165, publicerad 2016–07.

[43] [Artikel] Hall Daniel, ECS Game Engine Design, United States: DigitalCom-mons@CalPoly, publicerad 2014–06.

[44] [Bok] Ganesh S.G., 60 Tips On Object Oriented Programming, McGraw-Hill Education,ISBN: 0-07-065670-3, publicerad 2007.

[45] [Bok] Svensson, Krysander, Projektmodellen LIPS, Studentlitteratur, ISBN: 9789144075259,publicerad 2011–08.

[46] [www] Eclipse OpenUP: Role: Project Manager,http://epf.eclipse.org/wikis/openup/core.default.role_def.base/roles/project_manager_E657F936.html, hämtad 2017–02–07.

93

Litteraturförteckning

[47] [Artikel] Yilmaz, O’Connor, Colomo-Palaciosd, Clarke, An examination of personality traitsand how they impact on software development teams, Information and Software Technology,2016–04–27;86:101-122.

[48] [Artikel] Sarin Shikhar, McDermott Christopher, The Effect of Team Leader Characteristicson Learning, Knowledge Application, and Performance of Cross-Functional New Product Deve-lopment Teams, Decision Sciences, 2003;34(4):707-739,33.

[49] [www] Agile Manifesto,http://agilemanifesto.org/, hämtad 2017–04–25

[50] [Artikel] Bassil Youssef, A Simulation Model for the Waterfall Software Development Life Cyc-le, International Journal of Engineering & Technology, 2012–05–31;2(5).

[51] [Artikel] Nils Brede Moe, Torgeir Dingsøyr, Scrum and Team Effectiveness: Theory andPractice, Agile Processes in Software Engineering and Extreme Programming - 9th In-ternational Conference, 2008;9:11-20.

[52] [Konferens] Abrash, Michel. What VR could, should, and almost certainly will be within twoyears. Steam Dev Days, Seattle, 2014.

[53] [Video] Peppers Jonathan, Continuous Integration with Unity, publicerad 2015,https://www.youtube.com/watch?v=kSXomLkMR68, hämtad 2017–04–10.

[54] [www] Software Testing Fundamentals, Software Quality Control,http://softwaretestingfundamentals.com/software-quality-control,hämtad 2017–06–21.

[55] [www] Unityhttps://unity3d.com/, hämtad 2017–04–25.

[56] [E-bok] Schultz Charles P., Denton Bryant Robert, Game Testing: All in One: Third Edition,Mercury Learning & Information, ISBN: 1942270763, publicerad 2016.

[57] [Video] Paszek Tomek, Unity Test Tools: Test automation in Unity now and in the future,publicerad 2015,https://www.youtube.com/watch?v=_OYojVTaqxY, hämtad 2017–04–11.

[58] [www] Bay Christian, Graphics tests, the last line of automated testing,publicerad 2016–12–21, https://blogs.unity3d.com/2016/12/21/graphics-tests-the-last-line\\-of-automated-testing, hämtad 2017–04–10.

[59] [www] Jenkins,https://jenkins.io/, hämtad 2017–04–28.

[60] [E-bok] Keith Clinton Agile Game Development with Scrum, Addison-Wesley Professional,ISBN-10:0321618521, publicerad 2010–10.

[61] [Artikel] Ortega Juan, Shaker Noor, Togelius Julian and Yannakakis Georgios N., Imita-ting human playing styles in Super Mario Bros, Entertainment Computing, 2012-01;4(2):93-104.

[62] [Artikel] Stacey Patrick, Nandhakumar Joe Opening Up to Agile Games Development, Com-munications of the ACM, 2008–12;51(12):143-146.

[63] [Video] Ramblingcoder Automatic Unit Testing and Integration Testing with Jenkins, publi-cerad 2014–06–11,https://www.youtube.com/watch?v=mMDrgm0ftSc, hämtad 2017–04–28.

94

Litteraturförteckning

[64] [www] The Comprehensive TEX Archive Network, What are TEX and its friends?,https://www.ctan.org/tex/, hämtad 2017–04–24.

[65] [www] Features For Collaborative Coding - Developers Work Better, Together | GitHub,https://github.com/features, hämtad 2017–05–18.

[66] [www] ShareLATEX, Online LATEX Editor, https://www.sharelatex.com/, hämtad2017–04–27.

[67] [www] Plans and Pricing, ShareLATEX, Online LATEX Editor, https://www.sharelatex.com/user/subscription/plans, hämtad 2017–04–27.

[68] [www] Plans and Pricing - Overleaf, https://www.overleaf.com/plans, hämtad2017–04–27.

[69] [www] Lees-Miller John, New: Collaborate Online and Offline with Over-leaf and Git(beta), 2015–01–15, https://www.overleaf.com/blog/195-new-collaborate-online-and-offline-with-overleaf-and-git-beta#.WQGknNyx_iw, hämtad 2017–04–27.

[70] [E-bok] Ede Lisa, Lunsford Andrea, Singular Texts/plural Authors: Perspectives on Collabo-rative Writing, Southern Illinois University Press, ISBN-10:0809314479, publicerad 1990.

[71] [Artikel] Bie Nanok, FN: "Internet en mänsklig rättighet", https://www.svt.se/nyheter/utrikes/fn-internet-en-mansklig-rattighet, publicerad 2011-06-08

95