A.7 Slutsatser
E.4.4 Unders¨ okning via webbformul¨ ar
Ut¨over studien av gamla projekt samlades det ¨aven in data fr˚an studenter som l¨aste kursen “Kandidatprojekt i programvaruutveckling” vid Link¨opings univer- sitet under v˚aren 2017. Data samlades in genom ett webbformul¨ar som skickades ut till kursens maillista den 28:e april 2017. En vecka senare st¨angdes webbfor- mul¨aret. De fr˚agor som skickades ut ¨ar samlade i bilaga 2.
E.5
Resultat
Resultaten fr˚an metoderna som beskrivs i avsnitt E.4 presenteras med samma rubriker nedan.
E.5.1 Insamling av tidigare projekt
Tabell 2: Insamlade tidigare projekt # Namn L¨ank 1 Knekt https://github.com/TDDD96-2016-Gr10/Knekt 2 JABE https://github.com/pfechd/jabe 3 Snowy https://github.com/SnowyApp/Snowy 4 Prediktionsreglering https://github.com/rubda/TDDD77 5 yamsLog https://github.com/droberg/yamsLog 6 Operation https://github.com/jcmandersson/Operation 7 treeD https://gitlab.ida.liu.se/tddd96-grupp9
Notera att kandidatprojektet “treeD” (#7) best˚ar av flera olika s˚a kallade re- positories. F¨or att begr¨ansa studien valdes enbart delprojektet som finns i repo- sitoryt “network-communication”, och antaganden om hela projektet ¨ar gjorda utifr˚an det.
E.5.2 Identifiering av projektets egenskaper och tillg¨angliga doku- mentation
De identifierade egenskaperna finns i Tabell 3.
Tabell 3: Egenskaper hos tidigare projekt
# Namn Operativsystem Spr˚ak Ramverk
1 Knekt Unix JavaScript, Closure jQuery
2 JABE Unix Python -
3 Snowy Unix Python, JavaScript Flask, React 4 Prediktionsreglering Windows C, Python MATLAB
5 yamsLog Multiplattform C++, Java, Obj-C Java, Android, iOS 6 Operation Multiplattform JavaScript, HTML Node
7 treeD Unix Python -
E.5.3 F¨ors¨ok att kompilera de olika projekten efter deras specifika- tioner
#1 Knekt - Knekt inneh˚aller en README med instruktioner f¨or att bygga projektet. I filen anges att projektet beror p˚a tv˚a externa program: en Closure- kompilator och HTML tidy [78] [79]. Allt eftersom projektet byggdes uppt¨acks det vissa fel som orsakats av hur ett av beroendena installerats. I en av filerna som anv¨ands under kompilering framg˚ar den korrekta installationsmetoden i en kommentar. N¨ar beroendet installerats korrekt g˚ar det att kompilera projektet. #2 JABE - JABE har en kortfattad men tydlig README som radar upp alla beroenden samt olika kommandon f¨or att kompilera projektet. I dokumentatio- nen inkluderas ¨aven ett kommando till ett skript i projektet som verifierar att alla beroenden ¨ar installerade. Projektet ¨ar skrivet i Python och d¨arf¨or instal- leras beroendena d¨arefter. En konsekvens av den kortfattade dokumentationen
blir att det inte finns n˚agra instruktioner f¨or att installera beroendena eller var de g˚ar att f˚a tag p˚a, bara vilka det ¨ar. F¨or en van Python-utvecklare inneb¨ar inte det h¨ar n˚agra problem men andra kan eventuellt uppleva instruktionerna oklara.
F¨or att sedan kompilera projektet anv¨ands GNU Make [80] vilket, f¨orutsatt att alla beroenden ¨ar installerade, med hj¨alp av ett enda kommando kan kompilera ett projekt. Det skript som finns f¨or att testa n¨arvaron av alla beroenden identi- fierar att alla krav ¨ar uppfyllda, vilket betyder att GNU Make borde fungera som det ska. Efter att ha k¨ort kommandot uppt¨acks det att alla beroenden inte alls ¨
ar installerade, utan ett program vid namn “pyuic5” saknas. N¨ar programmet sedan installerats kompileras projektet utan problem.
#3 Snowy - Snowy inneh˚aller precis som tidigare projekt ¨aven en READ- ME, och ¨aven denna med instruktioner f¨or att kompilera projektet. Sektionen i dokumentet heter d¨aremot ist¨allet “Installation”, s˚a det finns ¨aven steg f¨or att s¨atta upp databasen och starta diverse program. F¨or att begr¨ansa studien genomf¨ordes inte de h¨ar stegen.
Det f¨orsta steget ¨ar att installera Elasticsearch [81], vilket g¨ors med Ubuntus pakethanterare Apt. N¨asta steg ¨ar att installera alla JavaScript-beroenden och d¨ar utnyttjas ett av spr˚akens pakethanterare enligt instruktion. B˚ada dessa steg genomf¨ors utan sv˚arigheter. Efter detta f¨orbereds utvecklingsmilj¨on genom att installera och konfigurera en virtuell Python-milj¨o kallad “virtualenv” [82]. N¨ar ett stavfel i dokumentationen korrigerats genomf¨ors ¨aven detta utan n˚agra sv˚arigheter.
Sista steget ¨ar att installera de Python-beroenden som finns. ¨Aven h¨ar anv¨ands ett av spr˚akets pakethanterare, men under installationen av alla beroenden upp- st˚ar problem. Det identifieras ett antal externa beroenden som saknas i instruk- tionerna f¨or projektet. Med dessa beroenden installerade fungerar kompileringen som den ska. Dessa ¨ar listade utefter deras namn i Apt nedan:
• postgresql
• postgresql-server-dev-all • python-dev
#4 Prediktionsreglering - Prediktionsreglering ¨ar utvecklad f¨or operativsy- stemet Windows och ¨ar d¨arf¨or exkluderad fr˚an studien, se avsnitt E.4.2. No- terbart ¨ar dock att projektets n¨amner vissa beroenden som kr¨avs f¨or att k¨ora programmet. Det ¨ar oklart ifall fler eller andra beroenden beh¨ovs f¨or att kom- pilera projektet.
#5 yamsLog - yamsLog ¨ar uppdelat i ett par olika delprojekt. Till projektet medf¨oljer en README d¨ar det framg˚ar att instruktioner f¨or de olika projekten finns i deras respektive mapp. Projekten ¨ar upplistade i Tabell 4 tillsammans med dess identifierade huvudegenskaper.
Tabell 4: Delprojekt i yamsLog
Namn
Operativsystem
Spr˚ak
Bygginstruktioner
client-backend
Multiplattform
Java
Ja
server
Multiplattform
C++
Ja
protobuf
Multiplattform
Protobuf
Ja
android-client
Android
Java
Ja
Projektet “client-backend” ¨ar skrivet i Java och byggs med ant [83] varvid b˚ade byggverktyget och ant installeras tillsammans med ett JDK. Med detta instal- lerat g˚ar projektet att bygga enligt instruktion.
Projektet “protobuf ” inneh˚aller ett skript f¨or att kompilera s˚a kallade protobuf- specifikationer [84]. Specifikationerna kompileras med ett program vid namn “protoc” s˚a f¨orsta steget blev att installera detta. V¨al installerat dyker det upp fel som visar sig bero p˚a att det Java-bibliotek som de genererade filerna kompileras mot m˚aste vara av samma version som det “protoc” som anv¨ands f¨or kompilering. Eftersom det bibliotek som distribueras med k¨allkoden ¨ar 3 ˚ar gammalt byttes det ut mot ett nyare, varvid kompileringen fungerade.
Projektet “server” har en dokumenterad byggprocess som f˚ar det att framst˚a som att man bara beh¨over ett enda kommando f¨or att kompilera projektet. Efter att ha tagit reda p˚a vilka beroenden som kr¨avs p˚a egen hand och installerat dessa visar det d¨aremot sig att ytterligare ett kommando beh¨ovs f¨or att kompilera. H¨ar framkommer det att alla beroenden ¨annu inte installerats. Med fler beroenden installerade visar det sig att en fil som kompilerats i projektet “protobuf ” saknas. Den relevanta header-filen och dess implementation kopieras och d¨arefter lyckas kompileringen.
Projektet “android-client” ¨ar skapat i den f¨or Android nu f¨or˚aldrade utvecklings- milj¨on Eclipse [85]. P˚a grund av detta g¨ors inga f¨ors¨ok att kompilera projektet. #6 Operation - Operation ¨ar det projekt som har tydligast installationspro- cess. Det existerar en lista ¨over steg man beh¨over genomf¨ora f¨or att b¨orja ut- veckla tillsammans med steg f¨or att starta och ¨oppna projektet i webbl¨asaren. Projektet anv¨ander sig av npm [72] f¨or att hantera beroenden men skillnaden j¨amf¨ort med de andra projekten ¨ar att Operation faktiskt n¨amner att det m˚aste installeras. Fr˚an instruktionerna kan stegen fullf¨oljas utan problem och projek- tet kan kompileras.
#7 treeD - K¨allkoden f¨or treeD distribueras tillsammans med ett skript f¨or att kompilera projektet. Efter en liten korrigering i skriptet installeras ¨aven ett par beroenden som uppkommer vid kompilering. Med alla beroenden installerade g˚ar det att kompilera projektet.
E.5.4 Unders¨okning via webbformul¨ar
Unders¨okningen resulterade i svar fr˚an 19 personer som ¨ar delaktiga i 12 olika projekt. Resultatet fr˚an unders¨okningen i sin helhet finns i bilaga 2. En kortare sammanst¨allning av de mest relevanta delarna f¨oljer nedan.
Har ni haft i ˚atanke att projektet kan komma att vidareutvecklas? 11 av 12 projekt har vidareutveckling i ˚atanke.
1 av 12 projekt fokuserar p˚a annat.
Har ni en guide f¨or att kompilera och/eller k¨ora ert projekt? 7 av 12 projekt har en guide f¨or att kompileras.
5 av 12 projekt har inte en guide f¨or att kompileras, d¨aremot anger alla dessa projekt att de har vidareutveckling i ˚atanke.
Anledningarna till att inte ha en guide ¨ar f¨oljande:
• Workshop f¨or att l¨ara ut processen genomf¨ordes • De paket som beh¨ovs ¨ar dokumenterade
Det uppkom ¨aven projekt vars anledning till beslutet inte framgick. V¨arderingar av olika dokument
En sammanst¨allning av alla v¨arderingar som samlades in visar f¨oljande.
• N¨astan alla deltagare anser att dokumentation ¨over byggprocessen ¨ar vik- tigare eller lika viktigt som b˚ade arkitekturbeskrivning och projektplan. • Deltagarna f¨oredrar teknisk dokumentation, ju n¨armre dokumentet ¨ar ren
kod desto viktigare anses det vara
• Projektplanen ans˚ags minst viktig av de tillg¨angliga alternativen
• B˚ade ¨overgripande dokumentation och kommentarer utmed koden ans˚ags viktigast av deltagarna
Koppling mellan ramverk och dokumentation
Det syns en relation mellan ramverkets komplexitet och existerande kompile- ringsguide. Projekt som anv¨ander sig av simplare ramverk tenderar att inte ha n˚agon guide f¨or att kompilera projektet medan projekt som anv¨ander mer komplexa ramverk i de allra flesta fall tillhandah˚aller en guide.
Verifiering av kompileringsguiden
Alla projekt som har en kompileringsguide har antingen verifierat den genom testning eller har tester inplanerat. Det framg˚ar inte exakt hur testerna ge- nomf¨orts och d¨armed g˚ar det inte heller att garantera deras korrekthet.
E.6
Diskussion
Diskussionen av studien ¨ar uppdelad f¨or att separat behandla studiens resultat och den metod som anv¨andes.
E.6.1 Resultat
De insamlade projekt som studerats i det h¨ar arbetet inneh˚aller alla n˚agon form av hj¨alpmedel till kompileringsprocessen. Vad som tillhandah˚alls ¨ar allt ifr˚an en lista ¨over beroenden till steg-f¨or-steg processer. Det g˚ar inte att s¨aga ifall detta resultat beror p˚a att alla studerade projekt ¨ar licensierade under ¨oppen k¨allkod eller en konsekvens av allm¨ant god inst¨allning till dokumentation.
Vad som ¨ar mer intressant ¨ar de antaganden som verkar gjorts i framtagandet av de olika kompileringsinstruktionerna. N¨ar olika beroenden installeras kan det g¨oras p˚a ett flertal olika s¨att, d¨ar det finns l¨osningar som ¨ar mer eller mindre standardiserade, till exempel Apt, npm, och Bundler [68] [72] [73]. I ett flertal projekt framg˚ar inte vilket av alternativen som b¨or anv¨andas utan det l¨amnas till anv¨andaren att tolka. F¨or n˚agon oerfaren av pakethanterare kan misstolk- ningen att alla beroenden m˚aste kompileras p˚a egen hand g¨oras, n˚agot som tar mycket l¨angre tid. I andra fall kan en felaktig installationsprocess leda till att programmet eller kompileringen inte fungerar som den ska, vilket m¨arktes i projektet “Knekt (#1)”.
¨
Aven resultat fr˚an det formul¨ar som skickades ut indikerar p˚a att vissa studenter i kursen g¨or antagandet att det ¨ar sj¨alvklart hur man hanterar olika ramverk och beroenden, vilket bekr¨aftar v˚ar hypotes i avsnitt E.4.2. Att detta h¨ander i b˚ade de studerade projekten och i unders¨okningen tyder p˚a att det ¨ar en inte allt f¨or ovanlig f¨orekomst. Troligen sker detta eftersom de personer som gjort antagandena spenderat s˚a pass mycket tid med systemet att de inte l¨angre minns hur situationen s˚ag ut n¨ar de var helt oerfarna. N˚agot som ¨aven b¨or lyftas fram h¨ar ¨ar fr˚agan om det alltid beh¨over detaljeras exakt hur alla beroenden installeras.
Det finns i dagsl¨aget ett stort antal olika l¨osningar f¨or att hantera beroenden till mjukvara. Det enklaste ¨ar att lista alla beroenden i en lista och sedan l˚ata anv¨andaren avg¨ora hur de installeras. Ett mer h˚allbart alternativ ¨ar att anv¨anda n˚agon av de olika pakethanterare som finns. Pakethanteraren Bundler f¨or Ru- by anv¨ander ett speciellt system som skapar en lista ¨over vilka olika versioner som anv¨ants under utvecklingen, och som sedan anv¨ands i produktionsmilj¨on f¨or att garantera att saker fungerar likadant ¨aven d¨ar [86]. Med hj¨alp av detta tillv¨agag˚angss¨att minimeras den sortens problem vi st¨otte p˚a i kompileringen av protobuf-specifikationen i projektet “yamsLog (#5)”. Det troligtvis mest kom- petenta verktyget f¨or hantering av beroenden och utvecklingsmilj¨oer ¨ar Vagrant som n¨amndes i avsnitt E.3. Med Vagrant uppmuntras man att automatisera installationen av beroenden och kan vara s¨aker p˚a att systemet alltid beter sig likadant, oavsett var det anv¨ands [87]. Denna metod bidrar ¨aven till implicit dokumentation av hela kompileringsprocessen.
En av de saker som framkommer i unders¨okningen ¨ar att de som deltagit f¨oredrar teknisk dokumentation framf¨or ¨ovrig. Det b¨or noteras att det h¨ar inte ¨ar en definitiv uppt¨ackt d˚a formul¨aret som anv¨andes i unders¨okningen inte inkluderar all ¨ovrig dokumentation. Vad resultatet kan bero p˚a ¨ar att studenterna i studien f¨oredrar att programmera framf¨or att skriva texter till dokument, och d¨arf¨or ska resultatet inte tolkas som att vissa dokument ¨ar viktigare ¨an andra vid vidareutveckling utan snarare som att deltagarna i unders¨okningen tror sig veta vilka dokument som kommer vara viktiga. I en artikel h¨avdar Meisler B. att utvecklares of¨orm˚aga att skriva kvalitativ och l¨attf¨orst˚aelig dokumentation ¨ar roten till d˚alig mjukvara [88]. Fr˚an detta perspektiv ¨ar det h¨ogst relevant att kursen “Kandidatprojekt i programvaruutveckling” inneh˚aller krav p˚a olika typer av mindre teknisk dokumentation, d˚a unders¨okningen p˚avisar att studenterna troligen inte hade skrivit s˚adan dokumentation p˚a egen hand.
E.6.2 Metod
Att studera hur det ser ut p˚a dokumentationsfronten i f¨ardigst¨allda kandidatar- beten ger en hyfsat representativ bild ¨over hur situationen historiskt sett ut. Det faller naturligt att begr¨ansa studien till projekt som ¨ar licensierade under ¨oppen k¨allkod p˚a grund av juridiska sk¨al, men det ¨ar inte helt utan konsekvenser. Ar- beten som ska publiceras f¨or allm¨anheten tenderar att oftare inneh˚alla n˚agon sorts dokumentation ¨over byggprocessen. Ett alternativ hade varit att begr¨ansa studiens slutsats till projekt som licenseras under ¨oppen k¨allkod men det hade samtidigt begr¨ansat m¨angden svar i unders¨okningen som ocks˚a genomf¨ordes. Med samma resonemang blir studien aningen riktad ˚at program skrivna f¨or Unix. Studien begr¨ansades till enbart projekt som k¨ors p˚a ˚atminstone opera- tivsystemet GNU/Linux f¨or att vara genomf¨orbar utan ytterligare resurser. En konsekvens av detta ¨ar att operativsystemet som anv¨andes i studien inkluderat en pakethanterare som markant f¨orenklar installationen av diverse beroenden. Konsekvensen blir att multi-plattformsprogram som varit l¨atta att f¨orbereda f¨or kompilering i GNU/Linux inte n¨odv¨andigtvis ¨ar lika enkla att f¨orbereda f¨or kompilering i Windows.
Momentet i studien d˚a instruktionerna f¨or kompilering tolkades ¨ar ¨aven det under kritik d˚a momentet utf¨ordes av en enda person som dessutom ¨ar v¨al erfaren av olika ramverk. Det g˚ar inte att fr˚an studien g¨ora antagandet att andra personer tolkar instruktionerna likadant, eller att med de instruktioner som givits kan kompilera projekten. Med mer tid och fler frivilliga medlemmar i studien hade en mer kvantitativ unders¨okning kunnat genomf¨oras.
Ut¨over det att momentet f¨or att unders¨oka de olika kompileringsinstruktionerna saknar koppling till hur erfaren en utvecklare m˚aste vara gav det v¨ardefull data. De detaljer som uppt¨acktes under kompileringen m˚aste av n˚agon anledning mis- sats av de ursprungliga utvecklarna, eller s˚a har instruktionerna aldrig testats. Genom att inte starta upp ett helt nytt operativsystem f¨or testerna ¨ar det l¨att att missa beroenden som installerats n˚agon g˚ang tidigare. Det hade varit ett intressant till¨agg till rapporten att diskutera detta problem med andra grupper som l¨aser kursen samtidigt.
Det formul¨ar som skickades ut till de registrerade studenterna i kursen “Kandi- datprojekt i programvaruutveckling” var inte heller utan fel. Eftersom fr˚agorna som st¨alldes l¨amnade utrymme f¨or tolkning saknas v¨asentlig information som hade kompletterat svaren. Det ¨ar diskutabelt ifall det hade r¨ackt med att formu- lera om fr˚agorna eller om en annan metod hade kr¨avts. Att intervjua medlemmar i olika grupper hade givit mer kvalitativ information men kvantiteten hade som en f¨oljd minskat. Egentligen ¨ar m¨angden insamlad data redan alldeles f¨or liten f¨or att dra n˚agra generella slutsatser fr˚an, och vad den insamlade datan ger ¨ar endast en fingervisning om hur l¨aget ser ut i ˚arets omg˚ang av kursen. I det h¨ar arbetet v¨ager dock resultatet fr˚an den enskilda studien av gamla kandidatar- beten tyngre ¨an resultatet fr˚an unders¨okningen s˚a bristen anses inte vara lika allvarlig.
E.7
Slutsatser
Fr˚an studien kan det konstateras att blivande mjukvaruutvecklares inst¨allning till den typen av dokumentation som studien fokuserade p˚a ¨ar god. Det ¨ar inte n¨odv¨andigtvis s˚a att annan dokumentation anses vara oviktig, men mindre teknisk dokumentation ¨ar inte lika popul¨art. Bara f¨or att en sorts dokumentation anses viktig betyder tyv¨arr inte det att den ¨ar skriven, vilket unders¨okningen visar. Det ¨ar ocks˚a fr˚an studien sv˚art att s¨aga ifall studenterna i unders¨okningen har den h¨ar inst¨allningen av egen vilja eller f¨or att det kr¨avs av kursen. M˚anga som dokumenterar processen att kompilera deras projekt faller kort i signifikanta detaljer. Dessa detaljer tros i en del fall h¨arstamma fr˚an faktumet att de system som testerna genomf¨orts p˚a redan haft vissa beroenden installe- rade. Andra orsaker har varit att versioner inte dokumenterats tydligt eller att instruktionerna varit f¨or sparsamma. Endast ett av de sju insamlade projekten inneh¨oll tillr¨ackligt tydliga instruktioner f¨or att kunna genomf¨oras utan n˚agra f¨or¨andringar.
Studien av tidigare projekt tillsammans med unders¨okningen bevisar en hypotes om att popul¨ara ramverk tenderar att bidra till minskad dokumentation kring ramverkets anv¨andning. Detta g¨aller ¨aven komplexiteten i de anv¨anda ramver- ken. N˚agot som studien ifr˚agas¨atter ¨ar behovet av dokumentation f¨or de enklare och vanligare fallen. Eftersom alla projekt som unders¨oktes gick att kompilera utan allt f¨or stor anstr¨angning trots avsaknad av dokumentation kan det mycket v¨al vara s˚a att den inte ¨ar lika n¨odv¨andigt som tidigare trott. Sj¨alvklart ¨ar det viktigt att dokumentera noggrant i mer seri¨osa eller komplexa projekt men det kan vara av v¨arde att f¨orst unders¨oka dokumentationens behov f¨or att slippa l¨agga resurser p˚a on¨odigt arbete.
F
Virtual reality och cybersickness av Teo Tie-
fenbacher
Denna del ¨ar skriven av Teo Tiefenbacher som agerade VR-specialist under projektet.
F.1
Inledning
Den h¨ar rapporten kommer att handla om den ˚aksjuke-k¨anslan m¨anniskor upp- lever efter att ha anv¨ant virtual reality-system, som kallas cybersickness. Rap- porten kommer ¨aven att f¨ors¨oka svara p˚a hur det g˚ar att m¨ata effekterna av cybersickness samt vad som forskning s¨ager g˚ar att g¨ora f¨or att undvika eller minska effekterna av cybersickness.
F.1.1 Syfte
Syftet med rapporten ¨ar att f¨orklara vad cybersickness ¨ar, hur det g˚ar att m¨ata effekten av cybersickness samt beskriva metoder som g˚ar att anv¨anda f¨or att motverka eller minska cybersickness under och efter anv¨andning av VR-system.
F.1.2 Fr˚agest¨allning
1. Hur m¨ater man effekten av cybersickness?
2. Vad kan man g¨ora f¨or att motverka/minska cybersickness?
F.2
Teori
Som en introduktion till rapporten presenteras h¨ar vad Virtual Reality (VR) ¨ar samt sammanfatta vad cybersickness ¨ar och vilka symptom det ger.
F.2.1 Virtual Reality
Virtuell verklighet (VR) anv¨ands som samlingsord f¨or simulerade milj¨oer som ¨
ar skapade av en dator, oavsett visningsmedium. Oftast syftas det d¨aremot p˚a visningsmedier som ers¨atter hela den synliga verkligheten i st¨orre eller mindre grad. Dessa brukar vara i form av antingen en s˚a kallade Head-Mounted Display (HMD) som ¨ar en eller flera sk¨armar monterade framf¨or anv¨andarens ¨ogon eller Computer-Aided Virtual Environment (CAVE) som fungerar genom att proji- cera bilder p˚a flera stora sk¨armar, ofta i en del-sf¨ar, hel- eller delcylinder med