Forord. Aalborg Universitet, d. 5. januar 2001. Nikolaj Kolbe. Mike H. Hougaard. Flemming N. Larsen

Forord Denne rapport er skrevet af projektgruppe N4-211 ved Aalborg Universitet, afdeling for datalogi. Rapporten er baseret på gruppens arbejde foretaget ved VR-Center Nord og med brug af dette centers VR-faciliteter. Når der i rapporten anvendes ordene vi og vores refererer det til projektgruppen og dens aktiviteter. Rapporten henvender sig primært til projektgruppens medlemmer, vejleder og censor. Sekundært henvender den sig til personer med interesse i VR-applikationer og værktøjer til udvikling af sådanne applikationer. I rapporten er figurer nummeret fortløbende. Kildehenvisninger angives i kantede parenteser indeholdende en etiket der beskriver kilden. Beskrivelsen er sammensat af tre bogstaver samt kildens publiceringsdato, eksempelvis [Shn98]. Etiketterne kan findes i referencelisten, med en uddybende beskrivelse af kilden. Interne henvisninger angives i apostroffer, eksempelvis 1. Indledning. Referencer til registrerede aktiviteter i de udarbejdede dagbøger har deres egen notation. Disse referencer angives i tuborgklammer indeholdende de første tre bogstaver fra navnet i det udviklingsforløb som dagbogen beskriver, samt nummeret på en specifikke aktivitet. Eksempelvis {Div-9} for at henvise til aktivitet nummer 9 der er beskrevet i dagbogen for udviklingsforløbet omhandlende værktøjet Division. Projektgruppen vil gerne takke Gabriel S. Hansen, Carsten B. Larsen, Thomas D. Nielsen, Jesper Kjeldskov og Peer Ilsoe for velvillig og engageret assistance i forbindelse med gennemførelsen af projektet. Aalborg Universitet, d. 5. januar 2001 Mike H. Hougaard Nikolaj Kolbe Flemming N. Larsen

Indholdsfortegnelse 1. Indledning...1 1.1. Virtual reality...1 1.2. Problem...2 1.3. Afgrænsning...3 1.4. Rapportstruktur...4 2. Sammenligning af værktøjer...6 2.1. Metode...6 2.1.1. Kontrolleret eksperiment...6 2.1.2. Applikationsudvikling...7 2.1.3. Milepæle...10 2.1.4. Dagbogsskrivning...12 2.2. Hypoteser...14 2.3. Parametre...15 2.3.1. Arbejdsform...15 2.3.2. Tidsforbrug...19 2.3.3. Dialogform...20 2.4. Dagbog...21 2.5. Udviklerprofil...26 3. Opgavespecifikation...29 3.1. Kravspecifikation...29 3.1.1. Spilleregler...29 3.1.2. Udseende af labyrinten...29 3.1.3. Navigation af avataren og avatarens syn...30 3.2. Milepæle...30 4. Eksperiment...33 4.1. Forsøgsopstilling...33 4.1.1. Profiler...33 4.1.2. Omgivelserne...35 4.2. Udviklingsforløbene...37 4.3. Arbejdsform...39 4.3.1. Brug af dokumentation...39 4.3.2. Rådgivning...41 4.3.3. Genbrug af kildekode...43

4.3.4. Afprøvning...44 4.3.5. Angrebsvinkel...46 4.4. Tidsforbrug...48 4.4.1. Det akkumulerede tidsforbrug...48 4.4.2. Det totale tidsforbrug...49 4.4.3. Tidsforbrug per milepæl...51 4.4.4. Andet tidsforbrug...53 4.5. Dialogform...53 4.5.1. Definition af dialogformer...54 4.5.2. Klassifikation af værktøjernes dialogformer...54 4.5.3. Fordele og ulemper ved dialogformene...60 4.5.4. Opsummering...63 5. Anbefalinger...64 5.1. Personlige kvalifikationer...64 5.2. Kursusindhold...65 5.3. Ressourcer...68 6. VR-udvikling i forhold til almindelig IT-udvikling...70 6.1. Fremgangsmåde...70 6.2. Kategorisering af forskelle...71 7. Konklusion...76 8. Referenceliste...78 A. Værktøjer...80 A.1. CAVELib...80 A.2. VR Juggler...81 A.3. Division...81 B. Dataopsamling...83 B.1. Division...83 B.2. CAVELib...84 B.3. VR Juggler...86 B.4. Samlet...87 C. Dagbøger...89 C.1. Division...89 C.2. CAVELib...106 C.3. VR Juggler...118

1. Indledning Dette kapitel indeholder en beskrivelse af virtual reality som dette projekt beskæftiger sig med. Herefter beskrives det overordnede problem indenfor virtual reality, som vi vil arbejde med. Problemet afgrænses, og det præsenteres, hvad der mere konkret vælges at arbejde med. Til sidst i kapitlet beskrives rapportens grundlæggende struktur, der forklarer hvad der kommer i de efterfølgende kapitler. 1.1. Virtual reality Virtual reality (VR) er et begreb, der beskriver virkelighedstro simulering af tredimensionelle miljøer. Begrebet kan beskrives ved følgende definition: Virtual reality er simuleringen af et virkeligt eller tænkt miljø, som kan opleves visuelt i tre dimensioner - bredde, højde og dybde - og som yderligere kan give mulighed for en interaktiv oplevelse, og som er visuel tidstro og med lyd og muligvis med berøring og andre former for feedback. [Wha00] VR-systemer anvender computere til at fremstille simulerede tredimensionelle miljøer, som man kan tage del i og interagere med ved anvendelse af specielt udstyr som f.eks. briller og handsker. Der er en lang række anvendelser af VR, men den underliggende ide er at skabe mere intuitive måder for mennesker og computere at arbejde sammen på [Jon00]. Hovedområderne i virtual reality er, som det kan ses udfra ovenstående definition; simulering, 3D-visualisering, interaktion, realisme, lyd og berøring. Der er behov for en lang række faciliteter for at kunne anvende virtual reality. Disse faciliteter er; displays til visualisering, interaktionsenheder, audioanlæg og enheder som giver en fornemmelse for berøring (haptic devices). Der findes en lang række enheder til visualisering. Den mest almindelige er en monitor, som ofte anvendes fordi den er nem tilgængelig. Der findes også en stor mængde af mere avancerede displays, som passer bedre til virtual reality, fordi de har mulighed for en mere realistisk visualisering. Flere af disse avancerede displays har mulighed for helt at omgive en persons synsfelt (total immersion), og giver dermed mulighed for stor realisme. Eksempler på avancerede displays er head mounted displays og projektionssystemer, som begge forekommer i mange varianter [Sgi00]. Ud over displays findes der også en lang række enheder til interaktion og berøring. Eksempler på disse enheder er joysticks, pegeredskaber og handsker som ligeledes findes i forskellige varianter [Sgi00]. 1

Virtual reality er blevet mere udbredt i takt med, at de teknologiske muligheder er blevet større. Det skyldes, at de nye teknologier, giver større muligheder for at skabe realistiske omgivelser, hvilket er et grundlag for at lave virtual reality. VR-systemer har et stort potentiale rækkende fra medicinsk billedbehandling og design af interiør til videokonferencer og udforskning af fremtidige verdener. Til udvikling af VRapplikationer er der behov for værktøjer. Ligesom det er tilfældet for hardware rettet mod VR, så forekommer der udviklingssoftware rettet mod VR. Der findes en række værktøjer til VR-applikationsudvikling, herunder værktøjer til visualisering, modellering, animering og håndtering af audio [Sgi00]. 1.2. Problem Vi er datalogistuderende og beskæftiger os derfor med udvikling af software. Vi vil gerne undersøge området indenfor virtual reality mht. udvikling af VR-applikationer, fordi det ligger indenfor vores faglige område og fordi vi synes, at det er et spændende område at beskæftige sig med. Vi vil i det følgende, opridse nogle problemstillinger mht. VRudvikling, som beskriver de overordnede problemer vi vil arbejde med. Vi vil gerne undersøge, hvad der kendetegner udviklingsværktøjer inden for dette område, og se på deres anvendelighed for VR-udviklere. Vi er bevidste om, at forskellige værktøjer, har forskellige egenskaber. Nogle værktøjer er grafisk baserede, mens andre har en programmeringsorienteret tilgang. Hvilken indflydelse har det på værktøjernes egenskaber, og hvordan påvirker det eksempelvis udviklernes arbejdsform? Som ovenstående definition af virtual reality beskriver, så er der i VR krav om at kunne visualisere på en virkelighedstro måde, hvilket bl.a. stiller krav til hastigheden hvormed VR-applikationen eksekveres. Det vil ikke være virkelighedstro, hvis VR-applikationens visualisering ikke er flydende og forekommer med en tilpas høj opdateringsfrekvens. Selvom dette blot er et eksempel, så tyder det på, at der er forskelle mellem VRapplikationer og almindelige applikationer. Er der forskel mellem typerne af applikationer, så vil der muligvis også være forskel i udviklingen af de forskellige typer af applikationer. Derfor vil vi gerne undersøge om der er forskel på udviklingen af VR-applikationer i forhold til almindelige applikationer og i givet fald, hvilke forskelle der er. De ovenstående problemstillinger giver anledning til at undersøge en række spørgsmål som vi vil undersøge: 2

Hvad kendetegner udviklingsværktøjer og deres anvendelighed for udviklerne? Hvilke forudsætninger skal der være til stede ved udvikling af VR-værktøjer? Hvad er forskellen på udvikling af VR-applikationer i forhold til almindelige applikationer? 1.3. Afgrænsning For at reducere problemområdet, så afgrænses de problemer vi vil undersøge. De overordnede problemstillinger beskrevet 1.2. Problem afgrænses. Der eksisterer som allerede nævnt en række forskellige displays til visualisering af VRapplikationer. Vi har adgang til et projektionssystem kaldet Cave [Cav00b], som vi vil anvende på grund af dens avancerede visualiseringsform. Cave (CAVE Automatic Virtual Environment) er en relativ ny teknologi, som benyttes til kørsel af VR-applikationer. En Cave er en kvadratisk kube som kan anvendes til visualisering for en person som befinder sig indeni kuben. Den består af seks sider, hvor der kan projiceres billeder op på. Det gør Caven i stand til at visualisere et virtuelt miljø, som helt omgiver personen indeni. Personen anvender stereo Shutter glasses, som kan skabe en illusion af dybde i de billeder der vises på Cavens sider og det understøtter personen i at opleve den virtuelle verden som tredimensionel. Der er desuden mulighed for at anvende forskellige interaktionsenheder i Caven. Interaktionsenheder gør det muligt for personen indeni at interagere med det virtuelle miljø i det omfang som VR-applikationerne tillader det. Cavens avancerede visualiserings- og interaktionsmuligheder har været afgørende motivationsfaktorer for at arbejde med denne teknologi. Caven er som sagt en relativ ny teknologi, og der eksisterer kun et begrænset erfaringsgrundlag. En motivation for dette projekt er, at vi gerne vil medvirke til at udvide erfaringsgrundlaget indenfor applikationsudvikling rettet mod Caven. Der eksisterer et stort udvalg af udviklingsværktøjer til VR-applikationer, der kan anvendes i Caven. Af de eksisterende værktøjer, har vi valgt at se på følgende: CAVELib [Cav00a] VR Juggler [Vrj00] Division [Div00] 3

Disse værktøjer er fremtrædende værktøjer indenfor VR-applikationsudvikling. Vi anser CAVELib som et værktøj rettet mod avancerede udviklere med programmeringserfaring og behov for performance og fleksibilitet i deres VR-applikationer. VR Juggler er et relativt nyt værktøj, lavet af flere af de samme folk som står bag CAVELib. VR Juggler tænkes som efterfølgeren til CAVELib. VR Juggler har omtrent de samme faciliteter som CAVELib, men fokuserer på et åbent framework og bygger på objektorienteret programmering. Division er et grafisk baseret værktøj som retter sig mod mindre avancerede udviklere uden programmeringserfaring, der har behov for hurtigt og nemt at kunne fremstille en VR-applikation. I appendiks A. Værktøjer findes der en mere detaljeret beskrivelse af de enkelte værktøjer. Grunden til at vi har valgt netop disse tre værktøjer er, at de er fremtrædende VR-værktøjer, som repræsenterer forskellige dialogforme. Der er ét grafisk baseret værktøj (Division) og to programmeringsorienterede værktøjer (CAVELib og VR Juggler). Værktøjerne henvender sig til forskellige typer udviklere og opgaver, og derfor er disse aspekter interessante at undersøge nærmere. Værktøjerne repræsenterer også etablerede værktøjer (CAVELib og Division) og et ikke-etableret værktøj (VR Juggler) ved VRCN [Vrc00]. De etablerede værktøjer har været installeret, konfigureret og anvendt gennem et tidsrum, mens det ikke etablerede værktøj lige er blevet installeret og konfigureret og ikke har været anvendt i særlig grad. VR Juggler skal igennem en konfigurationsfase hos VRCN, som allerede er overstået for de etablerede værktøjer. Desuden vil andre problemer relateret til at værktøjet er forholdsvis nyt også afsløres. Det giver mulighed for også at opsamle erfaringer om bl.a. opsætningsfasen. 1.4. Rapportstruktur Rapporten er opdelt i otte kapitler og tre appendikser. Disse kapitler og appendikser beskrives efterfølgende. Kapitel 2 beskriver hvordan vi sammenligner værktøjerne. Det gøres ved først at beskrive metoden som anvendes. Metoden bygger på en eksperimentel tilgangsvinkel, og det beskrives, hvilke parametre der studeres og hvordan eksperimentet dokumenteres gennem anvendelse af dagbøger. Det beskrives også, hvordan eksperimentets deltageres forudsætninger dokumenteres. 4

Kapitel 3 beskriver en applikation, som skal udvikles under eksperimentet. Applikationen beskrives gennem en kravspecifikation og der specificeres en række milepæle, som anvendes under eksperimentet. Kapitel 4 beskriver det eksperiment, som er blevet udført, og de resultater der er udledt heraf. Kapitlet beskriver først forsøgsopstillingen og redegør derefter kort for, hvordan de enkelte udviklingsforløb foregik, og om de specielle forhold der har været. Herefter udledes resultater af eksperimenterne. Det gøres for tre emner; arbejdsform, tidsforbrug og dialogform. Arbejdsformen diskuterer, hvordan angrebsvinklen påvirkes af de værktøjer, der anvendes. Tidsforbruget beskriver, hvor der er markante forskelle i tidsforbruget mellem værktøjerne, og kommer med nogle mulige årsager til, hvorfor der er forskelle i tidsforbruget på de pågældende områder. Dialogformen, diskuterer om og hvorvidt bestemte dialogforme passer til bestemte udviklere og opgaver. Kapitel 5 beskæftiger sig med anbefalinger til fremtidige VR-projekter udledt af det aktuelle eksperiment. Kapitlet beskriver de personlige kvalifikationer og ressourcer der skal være til stede for at gå i gang med et VR-projekt. Desuden diskuteres det, hvordan et kursus kan indrettes, så det passer til de omstændigheder der er gældende for et givet VR-projekt. Kapitel 6 foretager en sammenligning mellem udvikling af almindelige projekter i forhold til VR-projekter. Her undersøges det, hvilke ligheder og forskelle der er, på disse typer af projekter. Kapitel 7 er den samlede konklusion for projektet. Kapitel 8 er en liste over de referencer der er anvendt igennem rapporten. Den sidste del af rapporten indeholder tre appendikser; A, B og C. Appendiks A indeholder en beskrivelse af de VR-værktøjer som undersøges. Appendiks B indeholder data der er opsamlet gennem eksperimentet i en relativ ubehandlet form og Appendiks C indeholder dagbøger fra udviklingsforløbene. 5

2. Sammenligning af værktøjer Dette kapitel beskriver, hvordan vi vil sammenligne de forskellige værktøjer. Den metode der vil anvendes til sammenligningen beskrives sammen med de parametre vi vil måle, form og indhold af dagbøger og metode til specifikation af udviklerprofil. Kapitlet fokuserer udelukkende på beskrivelse og diskussion af metoder mm. Selve eksperimentet og de resultater der er opnået beskrives i 4. Eksperiment. 2.1. Metode I dette afsnit beskrives, hvordan vi anvender og planlægger et kontrolleret eksperiment. Derefter beskrives og diskuteres, hvordan eksperimentet vil foregå gennem applikationsudvikling og ved anvendelse af milepæle. Desuden beskrives og diskuteres det, hvordan dagbogsskrivning anvendes til dokumentering af udviklingsforløbene i eksperimentet. Beskrivelserne og diskussioner er holdt generelle og den egentlige udførsel af eksperimentet er, som allerede fortalt, beskrevet i 4. Eksperiment. 2.1.1. Kontrolleret eksperiment I [Shn98] præsenteres en række metoder, som kan anvendes til evaluering af softwareprodukter; reviews, usability testing, surveys, acceptance tests, evaluering gennem aktivt brug og kontrollerede eksperimenter. Vi vælger at anvende kontrollerede eksperimenter til evaluering af værktøjerne. Det skyldes primært, at vi gerne vil prøve at anvende værktøjerne i praksis. Sekundært skyldes det at vores ressourcer er begrænsede i form af forsøgsdeltagere, tid og maskiner. Her er kontrollerede eksperimenter iflg. [Shn98] en tilgang, der kræver få ressourcer tilgang, som sikrer snævre, men pålidelige resultater. Metoden fungerer ved at gentage udførslen af den samme opgave flere gange. Med udgangspunkt i [Shn98] planlægges det kontrolleret eksperiment gennem syv opgaver: 1. Planlægning af den konkrete opgave. 2. Erklære hypoteser. 3. Identificere parametre. 4. Udvælge forsøgspersoner. 5. Håndtering af faktorer som skaber skævhed. 6. Udføre data analyse. 7. Giv anbefalinger. I det følgende gennemgås de opgaver, som er anbefalet til at planlægge eksperimentet ud fra. Det beskrives, hvordan vi har løst opgaverne og det indhold vi har lagt i dem. Indholdet 6

er beskrevet og diskuteret andre steder i rapporten, og derfor vil de efterfølgende beskriver henvise til disse dele. Ad 1. Planlægning af den konkrete opgave: Planlægning af den konkrete opgave sker i kapitel 3. Opgavespecifikation, hvor den applikation, der udvikles i de forskellige udviklingsforløb, specificeres. Der specificeres krav for applikationen og udviklingsforløbet opdeles i en række milepæle. Ad 2. Erklære hypoteser: I afsnit 2.2. Hypoteser opstilles en række hypoteser som projektet forsøger at afklare. Vi vurderer igennem behandlingen af data fra eksperimentet, i kapitel 4. Eksperiment, om hypoteserne er sande eller falske og i givet fald, i hvilken grad dette er gældende. Ad 3. Identificere parametre: I afsnit 2.3. Parametre opstiller vi en række parametre, som måles og vurderes i eksperimentet. Disse parametre udgør kernen af det datagrundlag, der benyttes til behandlingen af data. Ad 4. Udvælge forsøgspersoner: Der er kun få ressourcer tilgængeligt til det aktuelle projekt, i form af personer og tid. Derfor vælger vi at lade projektgruppen selv indgå som forsøgspersoner i eksperimentet. I afsnit 2.5. Udviklerprofil og 4.1.1. Profiler beskrives de enkelte udvikleres profiler. Ad 5. Håndtering af faktorer som skaber skævhed: I de afsnit, der beskriver metoden i dette kapitel, beskrives metodens fordele og ulemper. Ulemperne belyser de faktorer, der kan skabe skævhed i resultaterne. Skævhederne er ikke håndteret på anden måde end at oplyse omkring dem. Ad 6. Udføre data analyse: I afsnit 4.3. Arbejdsform, 4.4. Tidsforbrug og 4.5. Dialogform analyseres de data, som stammer fra eksperimentet. Analyserne giver anledning til projektets resultater. Ad. 7. Giv anbefalinger: I kapitel 5. Anbefalinger gives der anbefalinger på baggrund af det udførte eksperiment. 2.1.2. Applikationsudvikling I dette afsnit diskuteres applikationsudvikling, der vil blive anvendt i eksperimentet til at opsamle erfaring med værktøjerne, som undersøges. Afsnittet beskriver først formålet med applikationsudviklingen, herefter beskrives det, hvordan udviklingen foregår og dernæst 7

diskuteres fordele og ulemper ved at anvende applikationsudvikling til opsamling af erfaring. Sidst diskuteres kort et alternativ til applikationsudvikling. Formål I dette projekt sammenligner vi forskellige værktøjer til VR-udvikling (jvf. 1.3. Afgrænsning ). For at kunne sammenligne værktøjerne er det brugbart at have erfaring med dem. Derfor har vi valgt at udvikle applikationer i de forskellige værktøjer. Desuden vil vi gerne have førstehåndserfaring med værktøjerne. Det skyldes en holdning om, at førstehåndskendskab giver en dybere erkendelse end andenhåndserfaring. En anden grund til at anvende applikationsudvikling er, at projektgruppen har været interesseret i at opnå erfaring med udvikling af VR-applikationer. Beskrivelse Vi har valgt at lade det aktuelle eksperiment foregå ved at en række udviklere implementerer den samme VR-applikation ved brug af forskellige værktøjer. Der vil blive udviklet tre forskellige versioner af den samme applikation i form af en 3D-labyrint. Udviklingen er foretaget af tre forskellige udviklere, der hver har udviklet en version af applikationen i et af værktøjerne. Hver udvikler har på forhånd ingen eller begrænset erfaring med værktøjet som anvendes, men har erfaring med applikationsudvikling fra andre projekter. Udfordringen for udvikleren bliver derfor at lære at anvende værktøjet til at udvikle VR-applikationen. Applikationen skal danne et sammenligningsgrundlag for de forskellige udviklingsforløb. Derfor er det nødvendigt at den opgave, som udviklerne stilles, er den samme. Hvis opgaven er eller opfattes forskellig af den enkelte udvikler, vil dette kunne medføre et forringet sammenligningsgrundlag. For at sikre, at opgaven er den samme, specificeres kravene til applikationen i høj detalje i projektets indledende fase. Dette mindsker muligheden for fejlfortolkning og har til formål at sikre, at de applikationer der udvikles i høj grad er ens. Applikationen er specificeret i detalje i kravspecifikationen (jvf. 3.1. Kravspecifikation ). Kravspecifikationen inkluderer ikke design. Det skyldes at designet vil afhænge af det værktøj der anvendes. Anvendes et værktøj, som understøtter objektorienteret programmering (f.eks. C++ som i VR Juggler) vil der kunne gøres brug af en metode som understøtter objektorienteret analyse og design. Denne metode vil dog ikke passe til værktøjer, som kun understøtter struktureret programmering (f.eks. C som i CAVELib). En anden ting, der kan være med til at sikre et fælles sammenligningsgrundlag er et kontrolleret udviklingsforløb. Det er relevant at kunne sammenligne udviklingen af enkelte 8

dele af applikationen for at kunne sammenligne bestemte problemstillinger, f.eks. problemstillinger omkring kommunikation med hardware i de forskellige værktøjer. For at kunne sammenligne udviklingen af delene af applikationen, er det nødvendigt med en opdeling af applikationen i mindre dele, som er fælles for de tre udviklingsforløb. Dette har vi gjort ved at opdele udviklingsforløbet i et antal milepæle. Dette beskrives og diskuteres i nærmere detalje i afsnit 2.1.3. Milepæle. Fordele Væsentlige fordele ved applikationsudvikling beskrives og diskuteres efterfølgende: Applikationen fungerer som katalysator. Applikationen som udvikles, fungerer som katalysator for eksperimentet. Det vil sige, at den aktuelle applikation er uinteressant set som en selvstændig applikation. Applikationens formål er at give et grundlag for erfaringsopsamling og endvidere at skabe et fælles sammenligningsgrundlag for de forskellige udviklingsforløb. Applikationen kan derfor i princippet smides væk efter endt udvikling, fordi den vil have tjent sit formål. Dyb berøringsgrad. Praktisk udvikling vil gøre, at vi kommer i berøring med VRværktøjerne, og det vil hjælpe med at afsløre problemstillinger, som vi ellers ikke ville kunne opdage, hvis vi udelukkende arbejdede ud fra en teoretisk tilgangsvinkel. Eksempelvis vil vi blive mere kvalificerede til at udtale os om fordele og ulemper ved arbejdsformen i et givet værktøj, ved at vi selv har arbejdet med værktøjet. Erfaringer til fremtidig VR-udvikling. En anden grund til at applikationsudvikling anvendes er, at de erfaringer vi tilegner os og giver videre i denne rapport, vil være nyttig for fremtidige VR-udviklere, som typisk vil befinde sig i en situation meget lig den, vi placerer os i ved at anvende applikationsudvikling. Ulemper De væsentligste ulemper ved applikationsudvikling beskrives og diskuteres: Udviklerne påvirker eksperimentet. Da applikationen, som udvikles er den samme for de tre værktøjer, vil de varierende faktorer være værktøjet og udvikleren, hvilket betyder, at de målinger der foretages afspejler det anvendte værktøj og udvikleren. Vi ønsker at foretage vore undersøgelser udfra værktøjet, men ikke den udvikler der har anvendt det. Udviklerne påvirker eksperimentet i væsentlig grad, pga. udviklernes personlige kvalifikationer. Udviklerens arbejdshastighed, arbejdsform, erfaringsgrundlag og andre personlige faktorer påvirker udviklingsforløbet, men denne 9

effekt kan mindskes ved at udvælge og anvende udviklere som ligner hinanden. I vores projekt er alle udviklerne datalogistuderende, der befinder sig i den sidste halvdel af deres uddannelse. Applikationen belyser/skjuler bestemte problem områder. Den applikation der udvikles, er bestemmende for, hvilke problem områder, der vil blive arbejdet med under udviklingen. Applikationen skal vælges med omhu, for at sikre, at de problem områder, der ønskes belyst, kommer til at indgå i applikationsudviklingen. Der vil kun blive udviklet en applikation. Det medfører at erfaringerne der opnås, vil være bygget på et snævert grundlag. Et bredere grundlag kan opnås ved udvikling af en større eller af flere andre applikationer. Alternativ model En anden forsøgsopstilling i forbindelse med eksperimentet ville være at lade den enkelte udvikler udvikle i alle værktøjerne i et forsøg på at eliminere de personlige faktorer. Men det er ikke muligt, da udvikleren gradvist vil opnå erfaring gennem et enkelt udviklingsforløb og bevidst eller ubevidst kunne drage fordel af den opnåede erfaring i de efterfølgende udviklingsforløb. Det vil sige, at udvikleren opnår et større erfaringsgrundlag, des flere udviklingsforløb denne har været igennem. Dette gør sig især gældende, fordi applikationen er den samme ved alle udviklingsforløb. Derfor vil denne løsning være mindre egnet end applikationsudvikling. 2.1.3. Milepæle I dette afsnit beskrives og diskuteres de milepæle, som vil blive anvendt i eksperimentet, og som skal være med til at sikre et godt sammenligningsgrundlag mellem udviklingen i de forskellige værktøjer. Afsnittet beskriver først formålet med at anvende milepæle. Herefter beskrives hvordan milepælene benyttes i udviklingsforløbene og dernæst vurdere fordele og ulemper ved at anvende milepæle. Formål Formålet med at anvende milepæle er dels at skabe en fælles og ensartet struktur for udviklingsforløbene og dels af kunne opdele det samlede udviklingsforløb i mindre dele. En opdeling af udviklingsforløbene i mindre dele er er relevant for på en sikker og ensartet måde at kunne vurdere den opnåede tilstand af applikationen til et givet tidspunkt. Til et givet tidspunkt kan det dermed afgøres, hvilken tilstand applikationen er i, ved at se, hvilke milepæle, der er afsluttede. Hvis der eksempelvis er en milepæl der definerer, at applikationen er i stand til at visualisere en rød kasse midt på skærmen, så kan applikationens tilstand vurderes ud fra denne milepæl. Dette er et godt sammenlignings- 10

grundlag, fordi det er muligt at afgøre, hvor lang tid der er brugt på bestemte delopgaver under de forskellige udviklingsforløb, ved at måle tidsforbruget for en milepæl i de forskellige udviklingsforløb. Eksempel: Hvis erfaringerne fra eksperimentet viste at det tog 3 timer at få visualiseret en rød kasse i CAVELib og 1 time i Division, så ville en rimelig konklusion være: Det er hurtigere at få en rød kasse visualiseret i Division end det er tilfældet med CAVELib. Beskrivelse Milepælene bruges til at definere punkter i applikationsudviklingen, hvor applikationen er i en bestemt tilstand. Hele udviklingsforløbet kan opdeles i en mængde milepæle. Milepæle anvendes traditionelt i forbindelse med projektstyring [Pre97], men i dette projekt anvendes de til et andet formål; nemlig at registrere modenheden af den applikation, som er under udvikling. Modenheden af applikationen er ikke triviel at vurdere uden brug af metoder. Et eksempel på dette er 90-90-reglen [Pre97], som humoristisk udtrykker, at de første 90% af et system tager 90% af den tildelte tid. De sidste 10% tager også 90% af den tildelte tid. Hvis 90-90- reglen er sand, så er 90% ikke en præcis indikator til vurdering af modenheden. Dette tilkendegiver et problem om, at det kan være svært at vurdere modenhed af en applikation. I forbindelse med vores projekt er milepælene en metode, der hjælper til at kunne vurdere modenheden af den applikation som udvikles, fordi de netop afspejler opgaver som er løst og dermed er 100% færdige. Modenheden af applikationen kan vurderes og sammenlignes på tværs af udviklingsforløbene. Dette sker ved at afbillede, tidsforbruget der har været ved at opnå en given modenhed. Afbildningen sker ved en graf, hvor det akkumulerede tidsforbrug afbilledes som funktion (som angives på y-aksen) af den opnåede milepæl (som angives på x-aksen). Graferne, fra de forskellige udviklingsforløb, vil blive sammenlignet, for at få en dybere forståelse af, hvilke områder der er problematiske. De områder som sammenlignes bør være begrebsmæssige afgrænsede områder. Derfor mener vi, at det er en god idé at gruppere områderne efter emne. Et emne kan med fordel opdeles i en række milepæle, som tilsammen udgør emnet. Eksempelvis kan et emne være "opsætning af udviklingsmiljø". Dette emne kan opdeles i en række milepæle; eksempelvis "installation af software", "konfiguration af værktøj", "finde dokumentation", "kompilering og udførsel af demo" osv. 11

Fordele og ulemper Efterfølgende diskuteres fordele og ulemper for anvendelse af milepæle. To aspekter undersøges: Antallet af milepæle og sekvensen af milepæle. Antallet af milepæle. Det er en udfordring at definere de enkelte milepæle. Er antallet af milepæle for lille, vil der være mangel på målepunkter, hvilket vil gøre sammenligningsgrundlaget mindre. Er antallet af milepæle for stort, vil udviklingen kunne føles som en spændetrøje for udviklerne. Med spændetrøje menes, at udvikleren får mindre frihed til at vælge alternative løsninger på bestemte problemstillinger under applikationsudviklingen. Flere milepæle medfører derved, at flere opgaver på forhånd vil blive fastlagt i større detalje. Udvikleren vil desuden have mindre frihed til at vælge i hvilken rækkefølge, de enkelte problemstillinger håndteres under applikationsudvikling, hvilket vil kunne hæmme udviklerens produktivitet. I dette projekt vil det være ønskeligt med mindst mulig valgfrihed, fordi dette giver et mere ensartet udviklingsforløb. Derfor er det fint med forholdsvis mange milepæle. Sekvensen af milepæle. Milepælene udføres i en bestemt rækkefølge, og det kan være problematisk for et eller flere af værktøjerne. Dette gør sig gældende, hvis det enkelte værktøj lægger op til anvendelse af en bestemt fremgangsmåde for at løse en konkret opgave. Et eksempel er, at objekter i første omgang indsættes uden textures og siden hen tilføjes textures. I bestemte værktøjer vil det kræve dobbelt arbejde, fordi objekterne skal indsættes to gange, hvilket kan være tidkrævende, hvis processen skal udføres manuelt. I denne situation, havde det været lettest at indsætte objekter med textures i første omgang. Det kan betyde at en omrokering af rækkefølgen på milepælene ville være mere optimal mht. brugen af værktøjet. 2.1.4. Dagbogsskrivning I dette afsnit beskrives og diskuteres dagbogsskrivning, som vil blive anvendt i eksperimentet til at dokumentere udviklingsforløbene. Afsnittet beskriver først formålet ved dagbogsskrivning, derefter beskrives, hvordan dagbogsskrivningen fungerer, og til sidst diskuteres henholdsvis fordele og ulemper ved metoden. Formål Ved at anvende dagbog bliver det muligt at fastholde de erfaringer, som løbende opsamles gennem udviklingsforløbene. Hensigten er, at hver enkel udvikler, hver dag noterer de erfaringer ned på papir, som er blevet opsamlet for på den måde at dokumentere udviklingsforløbet for eksperimentet. 12

Beskrivelse Dele af dagbogens indhold fastlægges på forhånd gennem en checkliste, der indeholder et antal punkter, som har særlig interesse. Checklisten har til formål at motivere udvikleren til hver dag at overveje en række af punkter der er fastlagt på forhånd. Det hjælper udvikleren til at registrere de aktiviteter der er foretaget og de erfaringer som er blevet opnået gennem disse aktiviteter. Dette imødekommer sammenligning mellem udviklingsforløbene, fordi de på forhånd fastlagte punkter gør det muligt at udlede aktiviteter og erfaringer som er relaterede til hinanden. Fordele I dette afsnit diskuteres væsentlige fordele ved at anvende dagbogsskrivning: Fastholdelse af erfaringer. Dokumentation af udviklingsprocessen. Dagbogsskrivning kan anvendes til at dokumentere udviklingsprocessen og dermed til at fastholde oplysninger og erfaringer fra processen. Oplysningerne bruges til at sammenligne værktøjerne ud fra og de gør det muligt at undersøge og efterprøve de konklusioner som drages i projektet. Dagbogsskrivningen vil benytte sig af en checkliste, som giver andre fordele under skrivningen: Guider udvikleren gennem dokumentationsprocessen. Checklisten sikrer, at udvikleren hver dag bliver opfordret til at tænke over en række emner og dokumentere de erfaringer der knytter sig hertil. Det kan medvirke til at lette dokumentationsprocessen, fordi den guider udvikleren igennem områder, som kræver særlig opmærksomhed. Gør det sværere at glemme. Checklisten gør det desuden nemmere at huske at notere erfaringer, der rammer indenfor checklistens områder, da udvikleren bliver gjort særligt opmærksom på punkterne. Ulemper Efterfølgende diskuteres en væsentlige faldgruppe ved dagbogsskrivning: Anderledes arbejdsgang. En fare ved dagbogsskrivning er, at det ikke er en del af udviklerens typiske arbejdsgang og det kan påvirke han arbejdsmåde. Desuden gør dagbogsskrivningen udvikleren mere bevidst om, at han deltager i et eksperiment, 13

hvilket kan påvirke hans arbejdsmåde. Udvikleren vil kunne optræde anderledes end denne normalvis gør, og det kan influere på resultaterne fra eksperimentet. Undlade at notere. Udvikleren kan undlade at notere oplysninger, som han synes virker banale eller viser, at han har haft problemer. Selvom det gøres klart for udviklerne, inden eksperimentets udførsel, at det ikke er dem personligt der bliver målt, så kan det ikke udelukkes at udviklerne enten bevidst eller ubevidst undlader at notere bestemte oplysninger eller pynter på resultaterne. Dagbogsskrivningen vil benytte sig af en checkliste, som kan medføre nogle ulemper: Glemsomhed. Det kan forekomme, at udvikleren glemmer at notere relevante ting. Især erfaringer, som ligger udenfor checklistens punkter, er udsatte for at blive glemt. Udvikleren kan foranlediges til at undlade at notere oplevelser eller erfaringer, hvis de ikke passer ind i checklistens overordnede punkter. Det kan foranledige ham til at overse eller tro, at det ikke er vigtigt i forhold til de problemområder som eksplicit er angivet i checklisten. Der er desuden risiko for at glemme større overordnede emner, hvis de foregår over lang tid. Dette skyldes, at udvikleren formodentlig vil fokusere på dagens egentlige mål. Tankegang dikteres. En ulempe ved checklisten er risikoen for, at udvikleren lader sig diktere af den tankegang der ligger bag, og ikke formår at tænke over og notere andre af dagens erfaringer, som ikke passer direkte ind i checklistens punkter. 2.2. Hypoteser For at få svar på en række formodninger om værktøjerne, så opstiller vi en mængde hypoteser, som vi vil forsøge at vurdere gennem en eksperimentel tilgang. Hypoteserne udtrykker generelle opfattelser, som virker plausible, men som vi gerne vil be- eller afkræfte. Vores hypoteser er: De udvalgte værktøjer lægger op til bestemte arbejdsformer, som udviklerne må tilpasse deres arbejdsstil efter. Værktøjet og de understøttende ressourcer har indflydelse på tidsforbruget for løsning af forskellige typer af opgaver. 14

Værktøjernes dialogform har indflydelse på værktøjernes egnethed til håndtering af bestemte typer af udviklingsopgaver 2.3. Parametre I dette afsnit beskrives de parametre, som bruges til sammenligning mellem udviklingsforløbene med de tre værktøjer. Først beskrives parametre, der fokuserer på den arbejdsform, som de enkelte applikationsudviklere gør brug af under udvikling af applikationen. Dernæst beskrives parameteren for tidsforbrug, der fokuserer på tidsforbruget mellem udviklingsforløbene og som sammen med de noterede aktiviteter fra dagbøgerne kan bruges til at indikere, hvor og hvorfor der er forskelle mellem de tre værktøjer. Denne parameter følges af en parameter, dialogform, som fokuserer på, om de enkelte værktøjers dialogform har indflydelse på værktøjets egnethed mht. håndtering af bestemte typer af udviklingsopgaver. 2.3.1. Arbejdsform Den arbejdsform de enkelte udviklere anvender under udviklingen af applikationen spiller en væsentlig rolle mht. eksperimentet. Hver enkel udvikler forventes at have sin egen personlige stil, der er blevet tillært gennem flere år. Denne stil vil sandsynligvis blive afspejlet i eksperimentet. Dog formoder vi, at de enkelte værktøjer lægger op til, at der anvendes en bestemt arbejdsform, som udvikleren mere eller mindre tilpasser sin stil efter. Formålet med at sætte fokus på arbejdsformen er, at gøre det muligt for os senere at kunne udtale os om, hvilke procedurer/rutiner, viden og arbejdsformer andre udviklere vil kunne drage fordel af ved løsning af opgaver ved brug af det pågældende værktøj. Da arbejdsform er et stort emne, har vi valgt at opdele arbejdsform i delparametre, som vi mener er både interessante og relevante i forbindelse med eksperimentet: Brug af dokumentation. Rådgivning. Genbrug af kildekode. Afprøvning. Angrebsvinkel. Disse fem delparametre beskrives i det følgende. 15

Brug af dokumentation Manualen og den yderligere dokumentation, der følger med til et givet værktøj, er ofte det primære udgangspunkt for en udvikler, som har til hensigt at finde frem til, hvordan en given opgave kan løses med et specifikt værktøj. Ved at undersøge denne parameter udfra beskrivelserne i dagbøgerne er det muligt at få indikationer af, hvor den samlede dokumentation er til det enkelte værktøj, og dermed hvordan det påvirker udviklerens arbejdsform. Rådgivning Med rådgivning menes den bistand, som en udvikler gør brug af for at få løst en konkret problemstilling mht. eksperimentet. Det er relevant at undersøge, hvor ofte og hvordan udvikleren opsøger og modtager rådgivning fra andre personer. Dette skyldes, at rådgivning kan accelerere den proces det er at få løst en konkret problemstilling, hvilket sparer tid for udvikleren med henblik på at skaffe sig nødvendig viden og forståelse omkring problemstillingen. Samtidigt kan hyppig brug af rådgivning fra eksterne personer være med til at indikere, om den medfølgende dokumentation til et værktøj samt muligheden for at få hjælp via andre kilder er mangelfuld. Brug af rådgivning kan desuden bruges til at indikere, hvilken personlig stil udvikleren har, dvs. om udvikleren er indadvendt eller udadvendt. Genbrug af kildekode Ved at tage udgangspunkt i eksisterende kildekode som udvikleren enten bruger direkte eller modificerer, kan udvikleren muligvis hurtigere få løst en til flere opgaver i forbindelse med applikationen, da udvikleren ikke behøver at bruge tid på at opnå den fulde forståelse for den genbrugte kildekode, udover at kende til dens overordnede funktionalitet. På lang sigt kan udvikleren dog risikere at miste tid, hvis det genbrugte kildekode ikke indeholder den forventede funktionalitet eller viser sig at indeholde fejl. Her vil udvikleren kunne blive tvunget til at bruge tid på at tilpasse det genbrugte kildekode eller at erstatte kildekoden med ny kildekode. I værste fald vil udvikleren risikere at bruge længere tid på at forsøge at genbruge kildekode, pga. førnævnte problemstilling, end hvis udvikleren fra begyndelsen havde startet fra bunden af med egen kildekode. Det er derfor interessant at undersøge om de forskellige værktøjer lægger op til at der gøres genbrug af eksisterende kildekode som indgang til at opnå viden om værktøjet og dets muligheder. 16

Afprøvning I det følgende skelner vi mellem: Målplatformen. Den platform, hvor den færdige applikation skal kunne udføres. I forbindelse med dette projekt er målplatformen Caven. Udviklingsplatformen. Den platform, som applikationen udvikles på, før den porteres til målplatformen. I forbindelse med dette projekt er målplatformen enten en PC med operativ systemet Windows eller en SGI-arbejdsstation med operativ systemet Irix. Med afprøvning menes test af applikationen på målplatformen dvs. i Caven. Det er interessant at undersøge, hvordan distancen mellem udviklings- og målplatformen påvirker udviklingen af applikationen i form af tidsforbrug, kvalitet og risici. Med distance menes den forskel der er mellem udviklings- og målplatformen mht. hardware og operativ system. Det er endvidere interessant at undersøge, hvilke strategier mht. afprøvning, der påvirker udviklingen af applikationen i form af tidsforbrug, kvalitet og risici. Vi har valgt at karakterisere strategierne gennem deres hyppighed, tidsmæssig placering og grundighed, hvor der især fokuseres på to forskellige afprøvningsstrategier: Regelmæssig afprøvning. hvor applikationen testes regelmæssigt på målplatformen undervejs i udviklingsforløbet. Afslutningsvis afprøvning. hvor applikationen først testes på målplatformen til sidst i udviklingsforløbet. Afprøvningsstrategien afhænger af distancen mellem udviklings- og målplatformen. Det er interessant at undersøge, om behovet for regelmæssig afprøvning er relativt lille, hvis distancen mellem udviklings- og målplatformen er lille, og omvendt om behovet for regelmæssig afprøvning er større, hvis distancen er stor. Angrebsvinkel Med angrebsvinkel forstår vi den fremgangsmåde eller de metoder, som den enkelte udvikler vælger at angribe forskellige former for problemstillinger på, der opstår under udvikling af applikationen. 17

Det er interessant at undersøge, om den fremgangsmåde de enkelte udviklere personligt foretrækker, med fordel kan bruges i relation til det værktøj, som de anvender i forbindelse med eksperimentet, og specielt om det enkelte værktøj påvirker udvikleren til at benytte bestemte fremgangsmåder. Som udgangspunkt for undersøgelsen har vi valgt at fokusere på to forskellige typer angrebsvinkler, som vi betegner som henholdsvis den analytiske angrebsvinkel og den eksperimenterende angrebsvinkel. Disse angrebsvinkler beskrives nærmere i det følgende. Analytisk angrebsvinkel En analytisk angrebsvinkel er kendetegnet ved, at udvikleren i forbindelse med et konkret problem først og fremmest foretager research ved at tage udgangspunkt i dokumentation eller ved at få hjælp i form af rådgivning fra andre personer, som kan bidrage med konkret viden med henblik på at kunne løse problemet. Udvikleren vil også i stor udstrækning så vidt muligt gøre brug af programeksempler fra dokumentationen ved implementation af applikationen. Den analytiske angrebsvinkel er illustreret på Figur 1. Angrebsvinkel Foretager research Eksperimenterer Implementerer Figur 1: Analytisk angrebsvinkel. Figur 1 viser tre tilstande (vist som cirkler), som en udvikler vil bevæge sig imellem under udvikling af applikationen: Foretager research. Tilstand, hvor udvikleren læser dokumentation eller får hjælp fra andre personer i form af tips og rådgivning. Under den analytiske angrebsvinkel, vil dette som regel være første trin, hvorefter der veksles frem og tilbage mellem de to andre tilstande. 18

Eksperimenterer. Tilstand, hvor udvikleren eksperimenterer med egen eller andre personers kildekode. Implementerer. Tilstand, hvor udvikleren arbejder på implementation af selve applikationen. Eksperimenterende angrebsvinkel En eksperimenterende angrebsvinkel er kendetegnet ved, at udvikleren i stor udstrækning eksperimenterer sig frem for at løse de forskellige problemstillinger, som opstår under udviklingen af applikationen. Her vil udvikleren bl.a. tage udgangspunkt i kildekode, som udvikleren modificerer og tilpasser evt. hjulpet af dokumentation for på den måde at få løst et konkret problem. Den eksperimenterede angrebsvinkel er illustreret på Figur 2. Angrebsvinkel Foretager research Eksperimenterer Implementerer Figur 2: Eksperimenterende angrebsvinkel. Figur 2 adskiller sig fra Figur 1 ved angrebsvinklen, hvor der her fokuseres på eksperimenter som første arbejdstrin. Vi synes det er interessant at se på, om den enkelte udvikler har størst succes med enten en analytisk eller en eksperimenterende angrebsvinkel i forbindelse med udvikling af applikationen. 2.3.2. Tidsforbrug Med denne parameter fokuseres der på tidsforbruget for udviklingsforløbene ved de tre værktøjer. Vi vil gerne finde frem til, om der kan ses en tendens i forskellene mellem udviklingsforløbene, samt på hvilke områder, udviklingsforløbene i så fald adskiller sig fra hinanden mht. tidsforbruget og evt. hvad årsagerne er til forskellene. Med områder menes det samlede tidsforbrug samt tidsforbrug ved milepæle og emner for udviklingsforløbene. 19

For at lette overblikket over tidsforbruget ved de tre udviklingsforløb, har vi grupperet milepælene fra afsnit 2.1.3 Milepæle i følgende emner: Opsætning: Milepæl 1 2. Implementation: Milepæl 3 8. Interaktionsenheder: Milepæl 9 12. Justering: Milepæl 13 14. Metode De områder, hvor der er forskel på tidsforbruget mellem værktøjerne vil blive brugt som indikator for, hvor der er nogle interessante tendenser at undersøge nærmere. For at finde frem til årsagen til en forskel i tidsforbrug, vil dagbøgerne for hvert enkelt værktøj blive brugt. Vi har valgt at opdele tidsforbruget i samlet tidsforbrug, tidsforbrug for emner, og tidsforbrug for milepæle, hvilket gør os i stand til at vurdere tidsforbruget for udviklingsforløbene på flere niveauer. Det samlede tidsforbrug for udviklingsforløbene kan bruges til at vurdere forskellene mellem udviklingsforløbene på et højt niveau, mens vi kan gå i detalje ved at vurdere tidsforbruget for et udviklingsforløb ved enkelte emner og milepæle, som skiller sig væsentlig ud fra de resterende udviklingsforløb. Målinger For at kunne sammenligne tidsforbruget for det enkelte udviklingsforløb på flere niveauer, er der behov for at kunne registrere de antal timer, der er brugt på de enkelte aktiviteter og milepæle, i dagbogen til et udviklingsforløb. De aktiviteter der ikke relaterer sig direkte til en bestemt milepæl registreres særskilt som andet tidsforbrug for at fjerne støj fra målingerne, da vi er interesseret i at måle det eksakte tidsforbrug per milepæl og emne. 2.3.3. Dialogform Med denne parameter fokuseres der på de tre værktøjers dialogforme, hvor vi vil undersøge, om de enkelte værktøjers dialogform har indflydelse på værktøjernes egnethed mht. håndtering af bestemte typer af udviklingsopgaver. Metode For at finde frem til, om de enkelte værktøjers dialogform har indflydelse på værktøjernes egnethed mht. håndtering af bestemte typer opgaver, undersøger vi først hvilke dialogforme, som benyttes i hvert af de tre værktøjer. Endvidere undersøges hvilken arbejdsgang, som det enkelte værktøj lægger op til, når en VR-applikation skal udvikles. 20

Dette gøres på baggrund af vores opnåede erfaringer i forbindelse med eksperimentet og den viden, vi har tilegnet igennem kurser i værktøjerne. Sidst undersøger vi, hvilke fordele og ulemper dialogformene i de tre værktøjer har. 2.4. Dagbog Dette afsnit beskriver de valg, vi har foretaget mht. strukturen og indholdet i de dagbøger, som bruges til opsamling af udviklernes erfaringer samt vigtige informationer, som knytter sig til forløbet for de forskellige udviklingsprojekter. Vi har valgt at opdele en dagbog i flere separate afsnit, hvor hvert afsnit som udgangspunkt afdækker en specifik tidsperiode varierende fra minimum et par timer til maximalt et par dage. Intentionen med opdelingen af dagbogen i separate afsnit er, at skabe en fælles struktur på dagbøgerne for udviklingsprojekterne.. På den måde sikres, at informationer omkring udviklingsforløbet af de enkelte projekter bindes til en specifik tidsperiode, hvilket er essentielt mht. at kunne sammenligne tidsforbruget for de enkelte milepæle i udviklingsforløbene mellem de tre projekter. Vi mener, at en tidsperiode varierende fra et par timer til et par dage er passende. Maksimum er højst et par dage, da vi ikke vil risikere at udvikleren glemmer at notere nogle af sine erfaringer. Derfor er tidsperioden relativ kort. Ved den fastsatte tidsperiode antager vi, at den enkelte udvikler løbene noterer sig de erfaringer og informationer som fremkommer i løbet af tidsperioden, som udviklingen skrider frem, og at udvikleren sidst i tidsperioden samler op på disse erfaringer og informationer ved at skrive disse ind i dagbogen. Vi har valgt at inddele et afsnit i dagbogen i fem særskilte dele, hvor de enkelte dele i et afsnit følger i den rækkefølge, som de er opstillet her: Hoved. Oversigt. Dagens erfaringer. Status. Eventuelt. I det følgende forklarer vi for indholdet i hver af disse dele. 21

Hoved For at kunne få et hurtigt overblik over et afsnit i en dagbog, forsynes hvert afsnit med et hoved, som indeholder følgende faktuelle informationer: Projekt. Specificerer hvilket udviklingsprojekt, dette afsnit af dagbogen er møntet på. Hvert projekt specificeres ud fra navnet på det VR-værktøj, der benyttes i forbindelse med et udviklingsprojekt. Derfor vil et projekt eksempelvis blive specificeret som Division. Periode. Specificerer hvilken tidsperiode, afsnittet afdækker i form af datoangivelse og antal timer. Hvis tidsperioden dækker en enkelt dag, specificeres denne dato som f.eks. 23/10. Hvis tidsperioden derimod strækker sig over flere dage, specificeres start- og slutdato for tidsperioden som f.eks. 2/11 3/11. Denne information bruges for senere at kunne finde frem til, i hvilken rækkefølge de enkelte afsnit i en dagbog er forekommet, og dermed i hvilken rækkefølge de enkelte milepæle nås i de enkelte projekter. Endvidere specificeres antallet af timer, som tidsperioden afdækker, som f.eks. 4,5 t (en kort notation, som betyder 4 timer og 30 min. ), og angives i parentes efter datoangivelsen. Denne information er nødvendig for at kunne få et overblik over antallet af timer, der samlet er brugt i tidsperioden, som afsnittet afdækker. Milepæl. Specificerer hvilken milepæl, som er opnået ved slutningen af tidsperioden, som angives med nummer og navn på milepælen som f.eks. 3. Visualisering. Formålet med at specificere den opnåede milepæl er, at give mulighed for senere at kunne sammenligne modenheden af applikationerne mellem de tre udviklingsprojekter. Tilsammen udgør specifikationen af milepæl og tidsforbrug (opsamlet under periode) et sammenligningsgrundlag, som giver basis for at kunne vurdere tidsforbruget for applikationen på tværs af de tre udviklingsforløb. Her gives et eksempel på, hvordan et hoved på et afsnit i en dagbog kan se ud: Projekt: VR Juggler Periode: 30/11 (6 t) Milepæl: 1. etablering af udviklingsmiljø. Oversigt Efter hovedet på et afsnit i dagbogen, har vi valgt at have en oversigt, for at kunne give et overblik over afsnittet mht. de aktiviteter, der er blevet foretaget af udvikleren i den pågældende tidsperiode. 22

Vi har valgt at kategorisere alle aktiviteterne i oversigten i temaer. Det tjener to formål. Et formål er at gøre det muligt senere at foretage en overordnet analyse af aktiviteterne mht. fordeling af tidsforbrug ved de enkelte temaer og den arbejdsform i forbindelse med et værktøj. Et andet formål er, at de enkelte aktiviteter i oversigten kan bringes ind under nogle overskrifter, som letter overblikket over de forskellige aktiviteter i oversigten. Overskrifterne er her navnene på de forskellige temaer, som indgår i udviklingsprojektet. Vi giver her vores definition af de enkelte temaer, som indgår i oversigten i dagbogen: Research. Tema som dækker over tilegnelse af viden gennem læsning af dokumentation, rådgivning fra andre personers og udviklerens egne eksperimenter, som foretages med henblik på at få løst en konkret opgave i forbindelse med en milepæl i udviklingsforløbet. Design. Tema som dækker over udviklerens overvejelser og beskrivelser vedrørende design under udvikling af applikationen ud fra den givne kravspecifikation. Implementation. Tema som dækker over overvejelser og beskrivelser vedrørende implementation af applikationen på udviklingsplatformen. Afprøvning. Tema som dækker over beskrivelse af problemstillinger vedrørende udførsel af applikationen i Caven med henblik på at foretage målinger, rettelser, justeringer m.v. Temaerne er inspireret ud fra de faser, som indgår i et typisk udviklingsprojekt. Udviklingsprojekter, som anvender en moderne metode som f.eks. objekt-orienteret analyse og design (OOAD) [Mat97], inddeler et projekt i faserne analyse, design, implementation og test. Da vores udviklingsprojekter på visse punkter adskiller sig fra typiske udviklingsprojekter, bl.a. fordi problemområdet i vores udviklingsprojekter er fastlagt på forhånd gennem kravspecifikationen, har vi valgt at tilpasse vores temaer specielt til eksperimentet. Temaerne adskiller sig væsentligt fra faserne fra OOAD ved at være meget overordnede mini-versioner af disse faser. Det vil sige, at de ikke nødvendigvis gør brug af de metoder, som anvendes under faserne fra OOAD. Temaerne adskiller sig yderligere fra faserne i OOAD, ved at de ikke nødvendigvis følger hinanden kontinuert. Det vil sige, at det er 23

muligt at springe imellem temaerne ved udvikling af applikationen i forbindelse med eksperimentet. For første og sidste fase fra OOAD har vi valgt en anden navngivning for det tilsvarende tema. Temaet research erstatter fasen analyse fra OOAD, og fokuserer på tilegnelse af viden og eksperimenter i forbindelse med at få løst en specifik opgave i forbindelse med casen. Temaet afprøvning erstatter fasen test fra OOAD, og fokuserer på udførsel af applikationen på målplatformen. Hver enkelt aktivitet bringes ind under en overskrift for en af disse fire temaer i oversigten, som eksempelvis: Research: [1] Opsætning (1,5 t). Startede med at læse dokumentation omkring installation og opsætning af Implementation: [14] Visualisering af firkant (2 t). Implementerede en funktion til visualisering af en firkant Hver aktivitet under et tema i oversigten specificeres ved: Mærke. Specificerer et unikt mærke, som gør det muligt at referere til præcis denne aktivitet i forbindelse med senere at kunne analysere de enkelte aktiviteter. Mærket specificeres i form af et nummer, som angives i firkantede parenteser, som f.eks. [2]. Titel. Specificerer en overordnet titel, som er sigende for delaktiviteten, som f.eks. Simpel navigering. Formålet med titlen er at kunne navngive aktiviteten som et alternativ til mærket, og for at lette læsning af oversigten med henblik på at danne sig et overblik over alle aktiviteterne. Tidsforbrug. Specificerer antal timer, som er forbrugt på aktiviteten. Det er nødvendigt for senere at kunne finde det samlede tidsforbrug brugt på hver enkelt milepæl og emne i udviklingsforløbet. Tidsforbruget specificeres f.eks. som 3 t (en kort notation for 3 timer ), og angives i parentes lige efter titlen. Tidsforbruget specificeret for perioden i hovedet på afsnittet, stemmer med det totale tidsforbrug for alle aktiviteterne i oversigten. 24

Beskrivelse. Er en overordnet beskrivelse af aktiviteten, der bruges til senere at kunne analysere udviklingsforløbet samt udlede eventuelle problemstillinger, som udvikleren møder i udviklingsforløbet. Her gives et samlet eksempel på, hvordan en aktivitet kan være specificeret: [1] Opsætning (1,5 t). Startede med at læse dokumentation omkring installation og opsætning af... Dagens erfaringer Dagens erfaringer er den centrale del af et afsnit i dagbogen, da denne del har til formål at opsamle alle de erfaringer, som er blevet gjort af udvikleren i tidsperioden mht. selve værktøjet. Desuden opsamles også problemstillinger, der opstår i forbindelse med de enkelte opgaver til en milepæl. I denne del beskrives erfaringerne i nærmere detalje, som er relevante i forbindelse med de udvalgte sammenligningsparametre. Det vil sige på et niveau, hvor det er muligt at udlede brugbare informationer mht. at kunne sammenligne informationerne på tværs af de tre VR-værktøjer. Vi har valgt at inddele denne del i de to emner Problemer og løsningsforslag og Plusser og minusser. Formålet med denne inddeling er at adskille erfaringer, som er specifikke for selve værktøjet, fra de erfaringer som knytter sig til konkrete opgaver under de forskellige milepæle i udviklingsforløbet. Emnerne beskrives i nærmere her i detalje: Problemer og løsningsforlag. Beskrivelse af erfaringer, som ikke er specifikke for værktøjet. Det vil sige en beskrivelse af problemstillinger der er opstået eller som formodes at opstå i den nærmeste fremtid mht. at få løst en eller flere konkrete opgaver i forbindelse med de fastlagte milepæle i udviklingsforløbet. Hvis det er muligt, skitseres eventuelle løsningsforslag til problemstillingerne. Plusser og minusser. Beskrivelse af erfaringer, som er specifikke for værktøjet. Det vil sige en beskrivelse af en række gode og dårlige erfaringer gjort i forbindelse med brugen af værktøjet, dokumentation af værktøjet el. lign. Ligeledes kan a-ha - oplevelser kommenteres. Med a-ha -oplevelser menes oplevelser, hvor der opnås forståelse af principper og sammenhænge, som forandrer eller udvider udviklerens tidligere forståelse af værktøjet, hvilket kan være af enten positiv eller negativ karakter. 25

Status Formålet med denne del af at give et overblik over den nuværende tilstand af udviklingsforløbet, og er sammensat af flere emner: Komponentstatus. Beskrivelse af hvilke dele af applikationen, der udvikles på ved slutningen af tidsperioden. Det vil sige, en beskrivelse af hvilke dele, der er blevet færdigudviklet, evt. hvilke dele som stadig mangler at blive implementeret, samt eventuelle løse tråde. Med løse tråde menes dele der er påbegyndt, men endnu ikke færdigudviklet. Formålet med denne beskrivelse er at give et overblik over, hvor langt udvikleren er nået i det samlede udviklingsforløb. Kvalitet. Beskrivelse af kvaliteten af de løsninger, som er valgt i forbindelse med udvikling af applikationen. I denne beskrivelse har udvikleren mulighed for at gøre opmærksom på, hvis der er blevet lavet en kortsigtet løsning, som ikke vil være praktisk anvendelig på længere sigt ved en evt. udvidelse eller omstrukturering af applikationen. Ligeledes har udvikleren mulighed for at beskrive de bestræbelser, der er foretaget for at udvikle genbrugelige komponenter, hvor udvikleren har valgt at tage højde for udvidelse og omstrukturering af applikationen. Formålet med denne beskrivelse er at give mulighed for at kunne udlede sammenhænge mellem tidsforbrug og kvalitet mht. udvikling af applikationen. Planer. Beskrivelse af udviklerens planlagte aktiviteter for den kommende tidsperiode. Formålet er at give mulighed for senere at kunne se hvilken arbejdsform, som udvikleren gør brug af igennem udviklingsforløbet. Eventuelt Formålet med denne del er at give udvikleren mulighed for at kunne notere observationer eller bemærkninger, som ikke umiddelbart vedrører nogle af de andre dele. 2.5. Udviklerprofil Dette afsnit beskriver, hvordan udviklerne som indgår i eksperimentet kan karakteriseres og hvorfor det er relevant. En del af et kontrolleret eksperiment er at beskrive udvikleren som indgår i forsøget, fordi udviklerne har indflydelse på de resultater som udledes af eksperimentet. Især i vores tilfælde, hvor der anvendes forskellige udviklere, er det vigtigt at få en forståelse af hver enkelt udvikler, fordi udviklernes kvalifikationer, erfaringer, stil m.m. uvilkårligt vil 26

påvirke resultaterne. Vi antager, i vores eksperiment, at udviklernes kvalifikationer, erfaringer, stil m.m. er ens, men er klar over at dette er en meget grov antagelse. Derfor lader vi hver af udviklerne, beskrive sig selv ud fra en række punkter udvalgt fra [Shn98]: Uddannelse. Beskriver udviklerens uddannelsesmæssige baggrund. Kurser. Beskriver hvilke kurser udvikleren har haft, som er relevante for det aktuelle eksperiment. Udvikleren kan eksempelvis have haft kurser i 3D-programmering, hvilket kan hjælpe ham i udviklingen af den aktuelle VR-applikation. Projekter. Beskriver tidligere projekter der har bidraget med erfaring der kan anvendes i den aktuelle applikationsudvikling. Værktøjer. Beskriver erfaring med værktøjer som er relevante for projektet. Personlig stil. Dette punkt beskriver udviklerens personlige stil. Dette er f.eks. relevant i forhold til den arbejdsform udvikleren har anvendt. Er der eksempelvis tale om en udvikler, som er ekstroverteret, da vil denne udvikler sandsynligvis have større tendens til at bede om rådgivning frem for en introverteret person, og det vil derfor påvirke udviklerens arbejdsform. Udviklerens personlige stil beskrives ud fra en række egenskaber, som udvikleren vurderer og angiver, hvordan han opfatter sig selv. Egenskaberne der beskriver den personlige stil er følgende: o Intro- eller ekstroverteret. Beskriver om udvikleren opfatter sig selv som indadvendt eller udadvendt af natur. o Tidlig eller sen ibrugtager af teknologier. Er udvikleren tidlig eller sen til at tage nye teknologier i brug, som evt. kan anvendes til at løse et problem. Dette står i modstrid med at udvikleren vil prøve at løse problemet med de teknologier han allerede er bekendt med eller som er tilgængelige for ham. o Risikovillig eller risikouvillig. Beskriver om udvikleren opfatter sig selv som en, der tør og er villig til at løbe en risiko eller han er modvillig til at løbe en risiko, når han står over for et valg. 27

o Systematisk eller opportunistisk. Opfatter udvikleren sig selv som systematisk når han arbejder, eller som opportunistisk, og dermed lader sine handlinger bestemme af, hvad der i et givet øjeblik er mest fordelagtigt. o Analytisk eller eksplorativ. Beskriver om udvikleren opfatter sig selv som analytisk, og dermed studerer og analyserer problemer inden han forsøger at løse problemer. Eller opfatter udvikleren sig som eksplorativ, og dermed som en person der anvender praktisk eksperimentering til løsning af problemer. Selv om de ovenstående egenskaber lægger op til en kontrastfyldt beskrivelse af udvikleren, så kan udvikleren vælge at beskrive sig selv mere nuanceret ved at beskrive sig selv ud fra en blanding af de opstillede egenskaber. 28

3. Opgavespecifikation I dette kapitel beskrives de formelle rammer omkring den konkrete opgavespecifikation for eksperimentet beskrevet i 4. Eksperiment. Kapitlet starter med en kravspecifikation, og afsluttes med en gennemgang af de milepæle som er blevet specificeret for eksperimentet. 3.1. Kravspecifikation I dette afsnit beskrives den konkrete kravspecifikation for den VR-applikation, der skal udvikles vha. de tre forskellige værktøjer. Kravene til den opgave at udvikle VRapplikationen er helt overordnet at konstruere et spil i form af en 3D-labyrint beregnet for Caven, hvor en bruger vha. 3D-interaktionsenheder kan bevæge sin avatar rundt i labyrinten. I det følgende beskrives først spillereglerne for spillet. Dernæst beskrives kravene til udseende af labyrinten, og til sidst kravene til navigation og bevægelse i labyrinten. 3.1.1. Spilleregler Ved spillets start placeres avataren i et rum i midten af labyrinten. Spillerens opgave at bevæge sin avatar rundt i labyrinten via såkaldte "kanaler" for at finde "udgangsdøren". Spillet slutter ved, at når udgangsdøren er blevet fundet og berørt af avataren. 3.1.2. Udseende af labyrinten Labyrinten opbygges af et antal ensartede 6-sidede terninger (kuber). Størrelsen på en sådan terning skal indstilles, så dets virtuelle omfang svarer til Cavens størrelse. Det vil sige, at når avataren står i midten af Caven, og virtuelt er placeret i midten af en terning, så skal terningens sider kunne dække siderne på Caven. En ternings flader dækkes med textures i forskellige farver, så top og bund er røde, venstre og højre er blå, og frem og tilbage er grønne. Disse terninger er anbragt i et kubisk gitter med dimensionerne 10x10x10 terninger. Ved at fjerne et bestemt antal terninger opbygges et antal indbyrdes forbundne "kanaler" i labyrinten, som gør det muligt for spillerens avatar at bevæge sig igennem. For at gøre udfordringen større for spilleren opbygges der, udover den rigtige rute til udgangsdøren, et antal blinde ruter som er forbundne med den rigtige rute. I labyrinten anbringes et antal lyskilder, som er foruddefineret sammen med ruterne og udgangsdøren i labyrinten inden opgaveløsningen påbegyndes. 29

3.1.3. Navigation af avataren og avatarens syn Repræsentationen af spillerens avatar i labyrinten er et punkt, som kan have en vilkårlig orientation. Avataren kan kun bevæge sig igennem kanalerne i labyrinten, og kan derfor ikke bevæge sig igennem siderne på disse kanaler. Det er ikke muligt for avataren at se igennem siderne på de kanaler, som denne bevæger sig hen ad. Avatarens navigation gennem labyrinten foregår vha. interaktion med spilleren ved brug af en kombination med både en Wanda og Shutterglasses, som er spilleren bærer under spillet. Wanda en er et analogt joystick med knapper, hvorpå der er påmonteret en positionstracker. Der er også påmonteret en positionstracker på spillerens Shutterglasses. Mulighederne for navigation af avataren er følgende: o Syn. Avatarens syn afhænger af avatarens orientering og styres vha. de Shutterglasses, som spilleren bærer. Den orientation, som spillerens Shutterglasses har i Caven overføres til avatarens orientering og syn i labyrinten. Dvs. at avataren ser i samme retning som spilleren. o Bevægelse fremad. Hvis det analoge joystick på Wanda en føres fremad, flyttes avataren fremad ud fra den retning spillerens Shutterglasses peger i. o Bevægelse tilbage. Hvis det analoge joystick på Wanda en føres tilbage, flyttes avataren tilbage ud fra den retning spillerens Shutterglasses peger i. o Orientation. Avatarens orientering i labyrinten kan ændres ved at spilleren trykker ned på en bestemt knap på Wanda en. Mens knappen trykkes ned, har spilleren mulighed i at se i en vilkårlig retning. Når knappen slippes ændres avatarens orientering til at pege i den retning, som spilleren så i før knappen blev sluppet. Spilleren vil nu se labyrinten ud fra avatarens nye syn og orientation i labyrinten. Hvis f.eks. spilleren trykker på knappen og ser ned på gulvet i Caven, vil spilleren efter at have sluppet knappen igen kunne se det tidligere gulv ved at se lige fremad i Caven. 3.2. Milepæle I dette afsnit beskrives de milepæle, som er blevet fastlagt med henblik på at kunne måle på de enkelte udviklingsforløb fra eksperimentet, og dermed danne grundlag for sammenligning mellem de udvalgte værktøjer. 30

Milepælene er defineret som følger: 1. Etablering af udviklingsmiljø. Udviklingsmiljøet for værktøjet etableres på udviklingsplatformen, som omfatter installation og opsætning af selve værktøjet og tilhørende hjælpeværktøjer. Milepælen opnås ved at en præfabrikeret demo til værktøjet kan udføres gennem udviklingsmiljøet. 2. Forbindelse til Cave. Der skal skabes kontakt til Caven, hvor succeskriteriet er, at der kan udføres en præfabrikeret demo til værktøjet på Caven. 3. Visualisering. Det er muligt for udvikleren at visualisere en enkelt terning via sin eget kildekode. 4. Lyskilder. Visualiseringen af terningen udbygges med en enkelt lyskilde, som skal belyse terningen korrekt. 5. Labyrint. Applikationen er i en tilstand hvor hele labyrinten forekommer, som den er specificeret i kravspecifikationen. Alle terninger visualiseres med de specificerede farver, men dog uden brug af textures. 6. Simpel navigering. Visualiseringen af labyrinten sker ud fra et flytbart øjepunkt som fungerer som avatar. Avataren kan navigeres rundt i labyrinten ved tastetryk. 7. Kollisionsdetektion. Applikationen er i stand til at detektere, når avataren støder ind i en af siderne på en kanal eller udgangsdøren i labyrinten. 8. Kollisionshåndtering. Applikationen er i stand til at forhindre at avataren kan navigere igennem siderne på kanalerne i labyrinten, og afslutter spillet når avataren berører udgangsdøren i labyrinten. 9. Kontakt til Wanda. Applikationen kan aflæse og fortolke input fra en Wanda korrekt. 10. Navigering via Wanda. Applikationen kan anvende en Wanda til simpel navigation af avataren. 31

11. Kontakt til Shutterglasses. Applikationen kan aflæse og fortolke input fra Shutterglasses korrekt. 12. Navigering via Shutterglasses. Applikationen kan anvende Shutterglasses til navigation af avataren, som beskrevet i kravspecifikationen. 13. Textures. Alle terninger i labyrinten kan visualiseres gennem brug af textures. 14. Kalibrering. Visualisering af labyrinten gennem avataren justeres således at siderne på en terning i labyrinten kan dække siderne i Caven. Desuden justeres applikationen således at visualisering af labyrinten og navigation af avataren i labyrinten forekommer ens på tværs af de forskellige applikationer, der udvikles i de tre udviklingsforløb. 15. Færdig. Udviklingen på applikationen er fuldført.. 32

4. Eksperiment I dette kapitel beskrives det eksperiment, der er blevet foretaget i forbindelse med dette projekt. Først beskrives den forsøgsopstilling, som har været anvendt til eksperimentet. Dernæst beskrives hvordan udviklingsforløbene fra eksperimentet foregik i praksis, og om de specielle forhold, der har gjort sig gældende ved de enkelte udviklingsforløb. Herefter udledes resultaterne fra eksperimentet for de tre emner; arbejdsform, tidsforbrug og dialogform, hvilke er beskrevet i afsnit 2.3 Parametre. 4.1. Forsøgsopstilling I dette afsnit beskrives den forsøgsopstilling, som har været anvendt i forbindelse med eksperimentet. Først gives en profil for hver enkelt udvikler, som har deltaget i eksperimentet. Dernæst beskrives omgivelserne for udviklerne under eksperimentet. 4.1.1. Profiler I dette underafsnit beskrives profilerne for de udviklere som har deltaget i eksperimentet. Profilerne er beskrevet ud fra den metode som er beskrevet i 2.5. Udviklerprofil. Profilerne anvendes senere i rapporten til bl.a. at forklare årsagen til flere uventede resultater, som forekommer pga. udviklernes tidligere erfaringer og kvalifikationer m.m. Profil for udvikleren tilknyttet CAVELib Uddannelse o Datalogi-studerende på 9. semester med hovedfag indenfor programmeringssystemer. Kurser o CAVELib programmering Grundlæggende principper under CAVELib. Pilotkursus (kort studiekursus) af ca. en halv dags varighed. o Computer Vision og Virtual Reality Grundlæggende 3D-teknikker og begreber. Studiekursus af et semesters varighed. Projekter o En autonom navigerende agent i et virtuelt miljø [Giz98] 3D-visualisering. Kollisionsdetektion. Studieprojekt af et semesters varighed. 33

o Realtidsberegnet 3D-grafik. Implementering af 3D-engine. Fritidsprojekt gennem ca. 3 år. Værktøjer o OpenGL. Moderat kendskab gennem et halvt års projektarbejde med værktøjet. o Glut. Moderat kendskab gennem et halvt års projektarbejde med værktøjet. o 3DStudioMax. Moderat kendskab gennem fritidsbrug. o C/C++. Omfattende kendskab gennem fritidsbrug og projektarbejde. Personlig stil o Introverteret. o Risikovillig. o Blanding af tidlig og sen ibrugtagen af teknologier. o Blanding af systematisk og opportunistisk. o Eksplorativ. Profil for udvikleren tilknyttet Division Uddannelse o Datalogi-studerende på 7. semester Kurser o Division programmering Grundlæggende principper under Division. Pilotkursus (kort studiekursus) af ca. en halv dags varighed. o Computer Vision og Virtual Reality Grundlæggende 3D-teknikker og begreber. Studiekursus af et semesters varighed. Projekter o Virtual Soccer [Vir00] 3D-visualisering. Studieprojekt af et semesters varighed. Værktøjer o 3DStudioMax. Moderat kendskab gennem fritidsbrug. o Perl. Moderat kendskab gennem fritidsarbejde. Personlig stil o Ekstroverteret. o Blanding af tidlig og sen ibrugtager af teknologier, men mest sen. o Blanding af risikovillig og risikouvillig, men mest risikouvillig. 34

o Systematisk. o Analytisk. Profil for udvikleren tilknyttet VR Juggler Uddannelse o Datalogi-studerende på 9. semester med hovedfag indenfor databaser. Kurser o Computer Vision og Virtual Reality: Grundlæggende 3D-teknikker og begreber. Studiekursus af et semesters varighed. Projekter o En autonom navigerende agent i et virtuelt miljø [Giz98]: 3D-visualisering. Kollisionsdetektion. Studieprojekt af et semesters varighed. o Realtidsberegnet 3D-grafik. Implementering af 3D-engines. Fritidsprojekt gennem ca. 5 år. Værktøjer o OpenGL. Grundlæggende kendskab gennem projektarbejde og fritidsprojekter. o C/C++. Ca. 7 års omfattende kendskab gennem studiearbejde, fritidsbrug og projektarbejde. o Unix: Grundlæggende kendskab gennem projektarbejde. o Windows: Ca. 5 års omfattende kendskab gennem både som bruger og mht. programmering gennem studiearbejde, fritidsbrug og projektarbejde. Personlig stil o Ekstroverteret. o Risikovillig. o Tidlig ibrugtager af teknologier. o Blanding af systematisk og opportunistisk. o Blanding af analytisk og eksplorativ. 4.1.2. Omgivelserne I dette underafsnit beskrives omgivelserne for eksperimentet. Det sker ved en beskrivelse af udviklings- og målplatformen for de tre udviklingsforløb samt andre ressourcer som har været anvendt. 35

Udviklingsplatforme o Division SGI O2-arbejdsstation installeret med operativsystemet Irix og med interaktionsenhederne Polhemus Fasttrack, Shutterglasses og Wanda. Division var blevet installeret og konfigureret før eksperimentet blev påbegyndt. o CAVELib SGI O2-arbejdsstation installeret med operativsystemet Irix og med interaktionsenhederne Polhemus Fasttrack, Shutterglasses og Wanda. Standard PC installeret med operativsystemet Windows NT 4.0 og med interaktionsenheder som mus og tastatur. CAVELib var blevet installeret og konfigureret på SGI O2- arbejdsstationen før eksperimentet blev påbegyndt, men ikke på PC en. o VR Juggler Standard PC installeret med operativsystemet Windows 2000 og med interaktionsenheder som mus og tastatur. VR Juggler var ikke installeret og konfigureret på PC en før eksperimentet blev påbegyndt. Målplatform o En Cave med 6 sider på hver 2,5x2,5 meter [Cav00b]. o Interaktionsenhederne som Polhemus Fasttrack, Shutterglasses og Wanda. o En central SGI ONYX2 In-finite Reality grafikserver (kaldet "monster"). Serveren har 6 grafik-pipes, som anvendes til visualisering på Cavens 6 sider. o Division og CAVELib var blevet installeret og konfigureret før eksperimentet blev påbegyndt. Dette har dog ikke været tilfældet for VR Juggler. Andre ressourcer o Mulighed for at få rådgivning fra følgende persongrupper: To programmører med tilknytning til VRCN, som har erfaring med opsætning og programmering mht. Division og CAVELib. To personer, som har arbejdet med interaktion med Division. 36

4.2. Udviklingsforløbene I dette afsnit opsummeres og præsenteres en række af de vigtigste fakta omkring udviklings-forløbene fra eksperimentet, som det er beskrevet gennem dagbøgerne i appendiks C. Dagbøger. Periode Eksperimentet blev oprindeligt planlagt til at strække sig over tre uger, da det i planlægningsfasen blev vurderet, at alle udviklingsforløb kunne afsluttes indenfor denne periode. Det har været varierende fra dag til dag, hvor meget tid der kunne afsættes til eksperimentet, hvorfor der ved nogle dage er blevet arbejdet intenst med eksperimentet, mens der på andre dage ikke har været mulighed for det. Da VR Juggler ikke var etableret på målplatformen (Caven) ved VRCN før en uges tid efter starten på udviklingsforløbene, blev udviklingsforløbet for VR Juggler forlænget med tre dage. Tidsperioden blev forlænget for at kompensere for den tid, der skulle bruges på at etablere VR Juggler, og for at kunne gøre det muligt at nå så mange milepæle som muligt for dette udviklingsforløb. Hensigten med den ekstra tid var at gøre sammenligningsgrundlaget på tværs af udviklingsforløbene større. Beklageligvis var det ikke muligt at fortsætte udviklingsforløbet for VR Juggler efter disse tre dage var gået, da målplatformen (Caven) hos VRCN skulle opdateres og omkonfigureres i ugerne herefter. Det har medførte, at ikke alle milepæle blev nået under udviklingsforløbet for VR Juggler. Afvigelser fra milepæle Målet for alle udviklingsforløb var at gennemføre alle milepæle trinvist i løbet af eksperimentet for på den måde at kunne sammenligne tidsforbruget for hver enkelt milepæl. Som beskrevet i dagbøgerne, lod dette sig dog ikke gøre for alle udviklingsforløb pga. forskellige problemer og besværligheder, som kort er opsummeret i det følgende: Svært at gennemføre milepæl lineært: For nogle projekter var det ikke muligt at gennemføre milepælene i den angivne rækkefølge. Et eksempel er udviklingsforløbet for Division, hvor det blev nødvendigt at lægge textures på terninger tidligt i forløbet, for at visualisere labyrinten tydelig og gøre de efterfølgende milepæle mulige i praksis {Div-20,38}. Umuligt/besværligt at udføre milepæle: I udviklingsforløbet for Division blev det efter mange timers forgæves arbejde besluttet at droppe milepælene om kollisionsdetektering og kollisionshåndtering {Div-24-30,40}. Dette skyldes, at det ville give så 37

store problemer disse milepæle, at der var risiko for at en fortsat jagt på løsninger ville betyde, at der ikke ville være tid til rådighed til at gennemføre de resterende milepæle. Problemer med bookning af Cave: Det var nogle gange nødvendigt at hoppe en milepæl over og påbegynde senere milepæle, fordi det ikke var muligt at booke Caven til at gennemføre den aktuelle milepæl {Div-31,33} {VR-dag-09/11/00}. Tekniske problemer i Cave: Problemer med konfigurationsfiler og kompilering i Caven betød at nogle milepæle måtte droppes eller ikke kunne gennemføres på det pågældende tidspunkt {VR-dag-26/10/00} {VR-32-34}. Tidsmangel til sidst i projektet: Ved udviklingsforløbet for VR Juggler blev det afgørende, at opdateringen og omkonfigureringen af VRCNs netværk lå lige efter vores tre ugers periode for eksperimentet {VR-dag-13/11/00}. Havde der været mulighed for at fortsætte eksperimentet en uges tid endnu, ville det have givet flere gennemførte milepæle ved dette udviklingsforløb, som kunne danne et bedre sammenligningsgrundlag med de øvrige udviklingsforløb. Review Der blev planlagt og afholdt et internt review en uge inde i eksperimentet. Formålet med reviewet var at vurdere de enkelte udvikleres dagbogsform for den forløbne periode, og på den måde have mulighed for at rette op på eventuelle misforståelser og uklarheder, som udviklerne måtte have omkring dagbogsskrivningen. Reviewet viste små uoverensstemmelser mellem forståelsen af enkelte punkter fra checklisten, og gav anledning til diskussion og efterfølgende uddybning af formålet med disse punkter. Resultaterne fra reviewet var dermed medvirkende til ikke bare at rette op på afvigelserne i dagbøgerne for den første uge, men også at virke som en god rettesnor for de kommende ugers dagbogsskrivning. Slutresultater På kort form blev slutresultatet for udviklingsforløbene: CAVELib: Alle milepæle blev gennemført. Navigationen blev dog en smule anderledes, end det er specificeret i kravspecifikationen, fordi denne navigations-form føltes unaturligt/ubehagelig under afprøvning. Derudover blev lys håndteret på en anden måde end specificeret, pga. en begrænsning på max. 8 lyskilder i verdenen. 38

Division: Ikke alle milepæle blev gennemført, men den færdige applikation er brugbar i forhold til opgavespecifikationen. Grunden til at nogle milepæle ikke blev gennemført, skyldes at Division i nogle tilfælde ikke kunne håndtere dem (milepæl 4 og dele af milepæl 6), og i andre tilfælde at det ville tage for lang tid at implementere dem ud fra den tildelte tidsperiode for udviklingsforløbet (milepæl 7 og 8). VR Juggler: Stoppede reelt ved milepæl 9 pga. problemer med en konfigurationsfil til Caven og pga. opdatering og omkonfigurering af målplatformen (Caven), hvilket medførte, at milepæl 2 ikke blev nået. 4.3. Arbejdsform I dette afsnit beskrives resultaterne omkring den arbejdsform, der har været anvendt under eksperimentet for hvert udviklingsforløb, som er udledt fra dagbøgerne. Resultaterne er vurderet ud fra de delparametre, som er beskrevet i afsnit 2.3.1. Arbejdsform. 4.3.1. Brug af dokumentation Som beskrevet i 2.3.1. Arbejdsform er hensigten med denne delparameter at få en indikation af hvor god dokumentationen er til det enkelte udvalgte værktøj, og hvordan det påvirker udviklerens arbejdsform. Division Udviklingsforløbet for Division har været kendetegnet ved at den medfølgende onlinemanual har været brugt næsten dagligt, af udvikleren, for at udvikleren har kunnet sætte sig ind i tankegangen bag løsningen af en konkret opgave {Div-3,9,18,20,24,27,32-34,36,39}. Selvom langt de fleste af Divisions muligheder burde kunne udnyttes via dets grafiske brugergrænseflade, har der i flere tilfælde været behov for at studere manualen grundigt for at forstå, hvilke parametre og input der gav mening til en specifik dialogboks i Division {Div-9,16}. Desuden er der ofte brugt tid på at lede omhyggeligt i manualen for at undersøge, om der eksisterer en given action (en handling et objekt skal udføre, når der forekommer en bestemt hændelse) eller event (en hændelse), som der er behov for {Div- 3,18,24,32,33}. Det er en styrke, at alt dokumentation er samlet i en manual med en del relevante krydsreferencer. Dog har det i flere tilfælde været et stort problem for udvikleren, at manualen har været den eneste form for dokumentation, som er tilgængelig. I disse tilfælde har der ikke været mulighed for at læse alternative forklaringer af et specifikt emne med andre indgangsvinkler. Eksempelvis hvis forklaringer i manualen ikke har været udførlige 39

nok, eller har givet mulighed for fejlfortolkninger. Specielt har det været et problem, at udvikleren to gange {Div-28,36} har fundet deciderede fejl i angivelsen af parametre til events og actions i manualen, efter at have brugt tid på at dens anvisninger. Når manualen er den eneste kilde til information omkring et bestemt emne, mener vi at det er vigtigt, at dens forklaringer og eksempler er korrekte. En ulempe omkring dokumentation til Division er, at udover online-manualen er det ikke lykkedes for udvikleren at finde nogen former for yderligere dokumentation, debatforums eller FAQs (Frequently Asked Questions). Det er usædvanligt i forhold til andre værktøjer, som vi har erfaring med at bruge. CAVELib Hvor der for Divisions tilfælde kun eksisterede dokumentation i form af en online-manual, har udviklingsforløbet for CAVELib derimod nydt godt af at CAVELib bygger ovenpå et standardiseret programmeringssprog som C og API er som OpenGL og Performer. Der er ikke blevet brugt til på at gøre brug af dokumentation omkring C, OpenGL og Performer, da udvikleren som har anvendt CAVELib har kunne gøre direkte brug af erfaringer fra tidligere projekter, og at der eksisterer adskillige tutorials, eksempler og officielle beskrivelser omkring C, OpenGL og Performer. Det er et plus for CAVELib, at det bygger ovenpå standarder, som også bruges i andre forbindelser end til VR-applikationer til en Cave. Bl.a. fordi der eksisterer en stor brugerskare, der er villig til at dele deres erfaringer omkring disse standarder. Dokumentationen til CAVELib [Cav00a] har været tilstrækkelig og uden samme form for fejl, som i visse tilfælde præger manualen til Division. VR Juggler Udviklingsforløbet for VR Juggler har i forbindelse med brug af programmeringssproget C++ og OpenGL ligesom for CAVELib haft stor gavn af en stor mængde tilgængelig dokumentation, og at udvikleren som har anvendt VR Juggler har erfaring med C++ og OpenGL fra tidligere projekter. Med hensyn til de indledende faser, hvor VR Juggler skulle installeres og konfigureres, har der dog været store problemer med dokumentationen for VR Juggler [Vrj00a]. Der mangler basale dokumenter og forklaringer på, hvordan VR Juggler installeres og konfigureres skridt for skridt {VR-2,5,19,20} Udvikleren der har anvendt VR Juggler har også erfaret, at nogle af de medfølgende eksempler og demoer ikke fungerer efter hensigten {VR-11}, og at der mange steder på VR Jugglers hjemmeside er links og sider der ikke fungerer 40

ordentligt {VR-15}. Til gengæld har udvikleren været tilfreds med oversigten over API en, som er veldokumenteret {VR-12}. Ved at læse grundigt på afsnit fra den Master Thesis [Vrj00b] som omhandler VR Juggler, og ved at forsøge at kombinere eksempler fra denne med dele fra demoer til VR Juggler, lykkedes det efter lang tid for udvikleren at få sin egen programkode til at køre på udviklingsplatformen. Dette arbejde er dokumenteret fra {VR-2} til og med {VR-21}, som i alt tog 39 arbejdstimer. Hvis dokumentationen ikke forbedres, så denne opstartsfase kan håndteres nemmere og hurtigere, er det nok tvivlsomt hvor mange potentielle udviklere, der vil have mod på at bruge lige så lang tid på det, som udvikleren gjorde i dette tilfælde. I måneden efter afslutningen på eksperimentet er der dog sket ændringer i mht. dokumentation på VR Jugglers hjemmeside [Vrj00a], hvor der er lagt fokus på bedre dokumentation omkring de nødvendige trin i opstartsfasen. Der er dog stadig manglende links og forklaringer på hjemmesiden. Opsummering Erfaringerne fra eksperimentet beskrevet i det foregående kan kort opsummeres som: Dokumentationen for Division er nogenlunde, men på visse punkter mangelfuld. Dokumentationen for CAVELib er tilstrækkelig. Dokumentationen for VR Juggler er i den nuværende udgave mangelfuld på mange områder. 4.3.2. Rådgivning Som beskrevet tidligere i 2.3.1. Arbejdsform, er en af årsagerne til at se på brug af rådgivning fra eksterne personer, at denne parameter kan bruges til at indikere om den medfølgende dokumentation og muligheden for at få hjælp via andre kilder er tilstrækkelig eller mangelfuld. Division Udvikleren som har anvendt Division har i mange sammenhænge følt sig nødsaget til at gøre brug af rådgivning fra personer, som tidligere har arbejdet med Division {Div- 7,15,18,22,26,31,35}. Brugen af rådgivning var nødvendig, da den fornødne hjælp eller forklaring til at løse en konkret problemstilling ikke kunne findes i manualen for Division, eller at manualens forklaring ikke har været korrekt. 41

På grund af manglende alternativ dokumentation til manualen, har udvikleren ofte været i et dødvande, hvor det har været svært eller meget tidskrævende at finde en god løsning uden at rådspørge personer, som tidligere har arbejdet med lignende problemstillinger. I flere tilfælde (f.eks. {Div-18}) viste det sig, efter at have spurgt om råd, at ønskelige løsninger ikke kunne opnås i Division, eller at det ville være for tidskrævende at arbejde videre med, taget i betragtning af den mængde tid, som har været til rådighed til eksperimentet {Div- 26}. I andre tilfælde har der været uoverensstemmelse mellem manualens forklaring af standard-indstillinger og opsætningen på målplatformen (Caven). Uden rådgivning ville det have været meget svært at opdage, hvor en fejl umiddelbart opstod {Div-15}. CAVELib Det har ikke været nødvendigt for udvikleren som anvendte CAVELib at gøre brug af rådgivning fra andre personer, hvis der ses bort fra de timer, som er blevet brugt på det indledende pilot-kursus til Caven. Det skyldes at CAVELib var etableret på både mål- og udviklingsplatform, og ikke mindst at de problemer der derudover er opstået, har kunne løses ved at læse på tilgængelig dokumentation. Derudover ligner CAVELib de værktøjer, vi tidligere har arbejdet med i forbindelse med andre projekter. VR Juggler Udvikleren der var tilknyttet VR Juggler har to gange haft kontakt til Cavens teknikere for at undersøge, hvilke bestræbelser der har været gjort for at etablere VR Juggler i Caven. VR Juggler var installeret, men lod ikke umiddelbart til at være konfigureret korrekt, hvilket medførte at applikationen, som blev udviklet under VR Juggler, ikke kunne visualiseres i Caven {VR-28,35}. Opsummering Erfaringerne mht. rådgivning kan kort opsummeres som: Ved Division har rådgivning været nødvendig i forbindelse med at opnå en bedre forståelse af dette værktøj. Ved CAVELib har der ikke været behov for rådgivning, da den tilgængelige dokumentation omkring CAVELib har været tilstrækkelig. Ved VR Juggler har der mht. forståelsen af selve værktøjet ikke gjort brug af rådgivning fra andre personer. Dog har der været behov for rådgivning mht. installation og konfiguration af VR Juggler på Caven. 42

4.3.3. Genbrug af kildekode Som beskrevet i 2.3.1. Arbejdsform er det interessant at undersøge, om de forskellige værktøjer lægger op til genbrug af kildekode som tilgang til viden omkring et værktøj og dets muligheder. Division I arbejdet med Division blev der hovedsageligt arbejdet dets grafiske brugergrænseflade i forbindelse med modellering. Her er det forholdsvist svært at genbruge eksisterende kildekode fra andre VR-applikationer. Den primære erfaring mht. modellering vha. Division er, at en tekstbaseret editering af VDI-filer, hvor en VDI-fil åbnes og behandles i en teksteditor, i visse tilfælde er bedre, fordi det gør det muligt at genbruge kildekode {Div- 12,13,17,19,20,23,28}. De eksempler på kildekode der følger med Division har dog ofte været så store og uoverskuelige for udvikleren, at der kun i et enkelt tilfælde er blevet genbrugt kildekode fra disse. I andre tilfælde er dette blevet opgivet pga. kompleksiteten og størrelsen af de pågældende VDI-filer {Div-25}. Da det ikke har været muligt at finde eksisterende VDI-filer med eksempler, har der ikke været mulighed for at gøre brug af andre personers erfaringer med VDI-filer {Div-24}. Det er et minus for Division, at der tilsyneladende ikke eksisterer kildekode og eksempler omkring VDI-filer til Division. I forbindelse med gennemførsel af milepæl 6 blev der gjort genbrug gennem udvidelse af de eksisterende body-filer til Division {Div-30,37}. En fordel for Division er, at der findes mange eksempler på opbygning og brug af body-filer, som beskriver opbygningen af en avatar navigation af denne, som har sparet tid for udvikleren {Div-28}. Det er dog problematisk, at man som udvikler bliver nødt til at arbejde med body-filer vha. en teksteditor for at kunne ændre på foruddefinerede indstillinger, i stedet for at gøre det via den grafiske brugergrænseflade i Division, hvilket vil kunne lette dette arbejde. CAVELib Som dagbogen for CAVELib beskriver, blev der i mange sammenhænge anvendt eksisterende kildekode (bl.a. {Cav-4,6}). Eksisterende kildekode blev brugt til at opbygge den grundlæggende del af udviklerens egen kildekode. Eksisterende kildekode blev desuden brugt til at finde løsninger på opståede problemer og til hurtigere at løse en specifik opgave. Dette var muligt pga. den store mængde af eksisterende eksempler, der benytter C, OpenGL og Performer. Udover kildekode blev der også genbrugt dele og idéer fra forskellige konfigurationsfiler til Trackd og make-filer {Cav-24,12} for at udvikleren hurtigt kunne skabe kontakt til interaktionsenheder samt kompilere applikationen på målplatformen. Her er erfaringerne og 43

eksemplerne fra det fulgte pilotkursus værdifulde, men kunne måske have haft endnu mere værdifuld, hvis der fra VRCNs side havde eksisteret færdiglavede konfigurationsfiler til opsætning af forskellige former for visualisering i Caven. På den måde ville udvikleren kunne tage udgangspunkt i disse konfigurationsfiler og umiddelbart opnå kontakt med det samme til Trackd en, uden først selv at skulle være tvunget til at oprette sin egen konfigurationsfil samt forstå, hvordan sådan en fungerer. VR Juggler På grund af de indledende problemer med at få installeret VR Juggler og få visualiseret simple 3D-objekter, gjorde udvikleren i starten stort brug af eksisterende kildekode for at minimere risikoen for fejl {VR-13-15}. Efter et stykke tid viste det sig dog, at være svært at gennemskue dele af denne kildekode, og udvikleren startede derfor forfra med meget små stykker kildekode, som byggede på eksemplerne fra Master Thesis en [Vrj00b] for VR Juggler {VR-16-21}. Efter at de disse små stykker af kildekode kunne bruges til at visualisere objekter på udviklingsplatformen, kunne der ligesom det var tilfældet ved CAVELib, drages stor fordel ved at gøre brug af eksisterende kildekode, idet den dette kildekode kunne anvendes til mange af de efterfølgende dele af applikationen. Opsummering De forskellige udviklerne har hver især gjort brug af og haft gavn af at genbruge andres kildekode. Ved udviklingsforløbene for CAVELib og VR Juggler har udviklerne her haft stor gavn af eksisterende eksempler på kildekode, mens udvikleren for Division udelukkende har kunnet gøre brug af materiale som forefindes lokalt ved VRCN. 4.3.4. Afprøvning Som beskrevet i kapitel 2 har vi valgt at sætte fokus på delparameteren afprøvning for at undersøge, om eksperimentet peger på at den enkelte udviklers afprøvningsstrategi afhænger af distancen mellem udviklings- og målplatformen. Division Udviklingsforløbet for Division var det forløb, hvor der var den mindste distance mellem udviklingsplatformen og målplatformen, idet den udviklede VR-applikationen blev kørt på en SGI-maskiner ved begge platforme, og som havde næsten identiske enheder tilknyttet. Dette var en stor fordel for udviklingen, men der blev alligevel hyppigt afprøvet på målplatformen under forløbet {Div-6,7,23,25,31,35-38,40}. Dette skyldes bl.a., at der til den aktuelle applikation var behov for en speciel navigationsform samt fokus på kollisionsdetektion og -håndtering. Visualiseringen på en almindelig computerskærm på udviklingsplatformen gjorde det svært for udvikleren at få et indtryk af, hvordan størrelsen 44

og navigation af avataren ville tage sig ud i Caven, og blev derfor ofte afprøvet i Caven. I forbindelse med mere simple navigation var mulighederne på udviklingsplatformen dog ret gode, og det gav udvikleren en ekstra tryghed at vide, at der var meget lidt forskel på de to platforme, og dermed også på visualiseringen med applikationen. CAVELib I modsætning til udviklingsforløbet for Division har forløbet for CAVELib haft en større distance mellem udviklings- og målplatform. Udviklingen er foregået delvist på en PC og en SGI O2-arbejdsstation. På O2-arbejdsstationen var det muligt at anvende en simulator til CAVELib, som kan simulere applikationer rettet mod Caven. Dette var en stor fordel, da udvikleren løbende kunne få visualiseret resultatet, som det ville tage sig ud i Caven. Desuden gav simulatoren mulighed for at simulere den hardware, der eksisterer til Caven. Tilsammen medvirkede dette til en tryghed for udvikleren at vide, at programmet ville fingere i Caven. Efter vanskeligheder med især at få Trackd en til at fungere korrekt {Cav- 30-32}, manglede der kun at blive foretaget justeringer på størrelsen af objekter, bevægelseshastighed osv., før at applikationen fungerede i Caven efter hensigten {Cav-36}. Simulatorens formål med at reducere afstanden mellem udviklings- og målplatform virker derfor som det har været tiltænkt. Det største problem var at portere kildekode mellem PC en og SGI en. PC en blev anvendt i den først halvdel af udviklingstiden, mens SGI en blev anvendt den anden halvdel. Portering af kildekode mellem de to platforme gav lidt ekstra arbejde for udvikleren i form af platformspecifik kildekode, som skulle etableres {VR- 3,12,19,25,27,28}. Det at anvende to platforme i udviklingsfasen kræver som sagt ekstra ressourcer, men har dog været nødvendigt i mht. vores eksperiment, da der kun har været en enkelt SGI-maskine stillet til rådighed til deling mellem alle udviklere. Konklusionen er har, at der kan holdes en lille distance mellem målplatform og udviklingsplatform ved udvikling af VR-applikationer til Caven, hvis der anvendes en SGI-maskine sammen med simulatoren til CAVELib. Anvendes en PC til udviklingen er afstanden stor, og det har medvirket et større arbejde med at portere kildekode fra PC en til SGI en. VR Juggler For udviklingsforløbet med VR Juggler har det været afgørende, at dette var et pionerprojekt, hvor installeringen af VR Juggler i Caven kun blev udført pga. eksperimentet for dette projekt, og at teknikerne til Caven ikke havde tilstrækkelig tid til at finjustere og prøvekøre opsætningen af VR Juggler i Caven tilstrækkelig grad, inden applikationen for VR Juggler skulle afprøves. Det betød at afprøvning i Caven først kunne forsøges til sidst i 45

udviklingsforløbet, og eksperimentet derfor ikke giver noget reelt billede af, hvordan afprøvning ville have foregået med VR Juggler i udviklings-forløbet. VR Jugglers anvendelse af forskellige former for simulatorer med tilhørende konfigurationsfiler virker gennemtænkt, idet der er mulighed for udviklere at abstrahere sig væk fra de tekniske bestanddele, således at der f.eks. ikke er forskel på, om navigation foregår via et alm. tastatur på udviklingsplatformen eller med en Wanda på målplatformen. Opsummering Erfaringerne fra eksperimentet giver ikke nogen entydig indikation af, om distancen mellem udviklingsplatform og målplatform har direkte indflydelse på, hvilken afprøvningsstrategi der vælges af udvikleren. De indsamlede erfaringer giver indtryk af, at det afhænger af udviklerens personlige stil mht., hvor ofte applikationen afprøves på målplatformen. 4.3.5. Angrebsvinkel Som beskrevet i 2.3.1. Arbejdsform er det interessant at undersøge, om det er muligt at udpege hvilken effekt forskellige angrebsvinkler har haft på de enkelte udviklingsforløb, og dermed hvilke angrebsvinkler der kan anbefales til udvikling af VR-applikationer. Som forventet har erfaringerne fra de tre udviklingsforløb vist, at det ikke er muligt præcist at forudse, hvilken angrebsvinkel en udvikler med fordel vil kunne bruge for at løse en specifik opgave til hvert af de tre værktøjer. I de tre udviklingsforløb har hver enkelt udvikler skiftet mellem den analytiske angrebsvinkel, den eksperimenterende angrebsvinkel og en blanding af disse afhængigt af opgaven. Betragtes resultaterne overordnet, vurderer vi at det er muligt at dele de tre forløb op i to overordnede grupper udfra primær brug af angrebsvinkel. Division I den første gruppe som består af Division, har udvikleren ofte valgt en analytisk angrebsvinkel, hvor der først læses store dele af manualen, hvorefter den opnåede erfaring og eksempler afprøves i værktøjet, og hvor der så igen vendes tilbage til manualen. Hvis udvikleren efter et længere stykke tid ikke finder en tilfredsstillende løsning, tages denne kontakt til eksterne personer for at få hjælp i form af rådgivning. Når man tænker på, at der for udvikleren til forløbet for Division ikke har været andre måder at skaffe dokumentation på end manualen og rådgivning, kan denne fremgangsmåde virke logisk i den pågældende situation, da udviklingsforløbet ellers vil kunne risikere at gå i stå. 46

Generelt kan man sige, at udvikling i Division handler om at opdage, hvordan producenten bag Division har fundet det naturligt at implementere eller give mulighed for specifikke faciliteter. Der har ofte været tilfælde, hvor udvikleren med tilknytning til Division har forventet at kunne højreklikke på et objekt, og give det visse egenskaber, men hvor der i stedet skal benyttes en action for at opnå denne effekt. Det resulterer i at research får en vigtig rolle, når der er behov for at bruge krævende effekter i en VR-applikation. CAVELib og VR Juggler I den anden gruppe som består af CAVELib og VR Juggler, lægges der vægt på at benytte eksisterende kildekode, som der eksperimenteres med for at tilpasse kildekoden til den aktuelle opgave. Når der opstår problemer, forsøges det ofte at finde løsninger via andre personers eksempler i form af kildekode. Først hvis disse forsøg på at finde eksisterende kildekode fejler, begynder udvikleren at læse dokumentation. VR Juggler er dog lidt udenfor denne gruppe, fordi der i størstedelen af udviklingsforløbet for VR Juggler er blevet foretaget research for at udvikleren kunne forstå selve grundstrukturen i dette værktøjs virkemåde, og derfor er der blevet læst en del dokumentation omkring VR Juggler. Hvor i gruppen med Division nogle gange handler om at forstå tankegangen bag visse faciliteter, handler det i denne gruppen med CAVELib og VR Juggler mere om at eksperimentere med OpenGL for at overvinde forskellige problemstillinger, som opstår i VR-miljøet. Derfor har eksperimenter og brug af andre personers erfaringer stor betydning for at løse sådanne spidsfindigheder, som f.eks. at vide at 3D-objekter bør have tildelt et materiale, før de kan visualiseres. En vigtig detalje omkring angrebsvinklen i denne gruppe er, at udvikleren i denne gruppe ofte kan bruge sine erfaringer med programmeringssprog fra tidligere projekter. Der resulterer i at han udfra disse erfaringer med sproget ofte kan løse specifikke opgaver uden at skulle læse dokumentationen til det konkrete værktøj. Det er f.eks. tydeligt i forbindelse CAVELib-projektets løsning omkring kube-array [Cav-dag-7] og kollisionsdetektion [cavdag-7], hvor brug af sprogets indbyggede datastrukturer implementerer disse funktionaliteter simpelt, uden at der er behov for at benytte 3D-funktionalitet fra værktøjet. 47

4.4. Tidsforbrug Dataopsamlingen for tidsforbruget for de enkelte udviklingsforløb for de tre værktøjer kan ses i appendiks B. Dataopsamling, som også viser tidsforbruget for de tre udviklingsforløb opstillet samlet. Som beskrevet under 4.2. Udviklingsforløbene, stoppede udviklingsforløbet for VR Juggler ved 9. milepæl, og 2. milepæl blev ikke gennemført. Derfor er udviklingsforløbet for VR Juggler i dette afsnit blevet udeladt ved sammenligning af tidsforbruget for 2. milepæl og alle milepæle fra 9. milepæl. Det samme gør sig gældende for emnerne implementation (3. - 8. milepæl), interaktionsenheder (9. - 12. milepæl) og justering (13. - 14. milepæl). 4.4.1. Det akkumulerede tidsforbrug For at få et overordnet overblik over tidsforbruget for de tre udviklingsforløb, har vi ud fra dataopsamlingen akkumuleret tidsforbruget for de enkelte milepæle for hvert af udviklingsforløbene. Figur 3 viser det akkumulerede tidsforbrug for de tre udviklingsforløb. VR Juggler På Figur 3 ses det tydeligt, at de tre udviklingsforløb adskiller sig meget fra hinanden. Især udviklingsforløbet for VR Juggler adskiller sig væsentligt ved at have et tidsforbrug, der er langt større end tidsforbruget for udviklingsforløbene for Division og CAVELib. Division Udviklingsforløbet for Division har haft et langt mindre tidsforbrug i starten af udviklingsforløbet, dvs. fra 1. til og med 4. milepæl, sammenlignet med CAVELib og VR Juggler. Derfra er tidsforbruget for Division fra 4. til og med 7. milepæl blevet langt større. Til gengæld er tidsforbruget for Division relativt lille fra 7. til 15. milepæl set i forhold til udviklingsforløbet for CAVELib. CAVELib Udviklingsforløbet for CAVELib har forløbet meget jævnt. Det vil sige, at tidsforbruget har været nogenlunde ens ved de enkelte milepæle. 48

80 70 60 Antal timer 50 40 30 Division CAVELib VR Juggler 20 10 0 2. Forbindelse til Cave 3. Visualisering 4. Lyskilder 5. Labyrint 6. Simpel Navigering 7. Kollisionsdetektion 9. Kontakt til Wanda 10. Navigering via Wanda 11. Kontakt til Shutterglasses 12. Navigering via Shutterglasses 13. Textures 14. Kalibrering Figur 3: Det akkumulerede tidsforbrug for udviklingsforløbene for Division, CAVELib og VR Juggler fordelt på milepæle. 4.4.2. Det totale tidsforbrug Det totale tidsforbrug for milepæle under udviklingsforløbene for Division og CAVELib er på henholdsvis 37,75 og 42,25 timer, hvorfor tidsforbruget her kun adskiller sig med 12%. Det totale tidsforbrug for udviklingsforløbet for VR Juggler er på 74 timer, hvilket er 75% mere i forhold til udviklingsforløbet for CAVELib. Udviklingsforløbet for VR Juggler adskiller sig derfor væsentligt i forhold til udviklingsforløbene for Division og CAVELib ved de milepæle, som blev afsluttet ved udviklingsforløbet for VR Juggler. Det er derfor interessant at finde frem til årsagen til denne store forskel, hvilket bliver gjort i det følgende. Tidsforbrug per emne Ser man nærmere på tidsforbruget fordelt på emner mellem de tre udviklingsforløb (se Figur 4), viser det sig, at udviklingsforløbet for VR Juggler igen adskiller sig væsentligt i forhold til udviklingsforløbet for Division og CAVELib. 54,5 time er brugt på implementation ved VR Juggler, hvilket er 257% mere end ved CAVELib, hvor der er brugt 15,25 time, og 79% mere end ved Division, hvor der er brugt 30,5 time. 49

Alle tre udviklingsforløb adskiller sig også meget fra hinanden mht. opsætning (1. og 2. milepæl), hvor der er brugt flest timer ved VR Juggler, nemlig 19,5 time. VR Juggler har her et tidsforbrug der er 420% større end ved Division, hvor der er brugt 3,75 time, og er 62,5% større end ved CAVELib, hvor der er brugt 12 timer. Årsagen til, at VR Juggler har et langt højere tidsforbrug ved opsætning skyldes, at VR Juggler ikke har været etableret på målplatformen, hvilket har været tilfældet for både Division og CAVELib. 50

kunne skabes via programmering af rutiner/procedurer til håndtering af disse interaktionsenheder i applikationen {Cav-20,21,22,23,24,34}. Udviklingsforløbene for Division og CAVELib adskiller sig ikke meget fra hinanden mht. justering, hvor der er blevet brugt 3 timer ved Division og 6 timer ved CAVELib. Ved Division er alle 3 timer blevet brugt på at eksperimentere med textures (13. milepæl), og får vist textures korrekt i applikationen {Cav-20,34,39}. Der har ikke været behov for kalibrering (14. milepæl) mellem udviklings-platformen og målplatformen. Ved CAVELib blev der brugt 1,5 time på textures (13. milepæl), hvor der blev programmeret en rutine/procedure til at hente textures ind i applikationen, hvor disse textures kan visualiseres via OpenGL {Cav-17}. Derudover er der brugt 4,5 time ved kalibrering (14. milepæl), hvor der bl.a. var nogle problemer med skalering af størrelsen på kuberne i labyrinten {Cav-33), og hvor der blev eksperimenteret med labyrint-størrelse, lyskilder og hastigheder i Caven {Cav-36}. 4.4.3. Tidsforbrug per milepæl Figur 5 og Figur 6 viser tidsforbruget ved de enkelte milepæle for de tre udviklingsforløb. Det ses tydeligt, at udviklingsforløbet for VR Juggler har haft langt det største tidsforbrug ved 3. milepæl (visualisering) i forhold til udviklingsforløbene for Division og CAVELib. Der er flere årsager til dette store tidsforbrug: 13 timer er brugt på at eksperimentere med kildekode med udgangspunkt i programeksempler {VR-13,14,15,19,20}. 8 timer er brugt på at læse dokumentation for VR Juggler {VR-12,16,17,18}. 7 timer er brugt på at læse dokumentation for OpenGL {VR-22,23}. 3 timer er brugt på udvikling af egen kildekode {VR-21,24}. Ved udviklingsforløbet for VR Juggler er blevet brugt forholdsvis meget tid på at eksperimentere med kildekode (13 timer i alt), hvor der bl.a. har været gjort et forsøg på at omstrukturere en demo ( Cube ), som følger med til VR Juggler-programpakken {VR- 13,14,15}, hvilket har taget 9 timer og som ikke lykkedes. De resterende 4 timer er blevet brugt på at få et eksempel til at fungere fra den Master Thesis [vrj00b], der er skrevet i forbindelse med VR Juggler {VR-19,20}. 51

52

4.4.4. Andet tidsforbrug I appendiks B.4. Samlet er andet tidsforbrug blevet opsamlet, som viser det tidsforbrug, der har været brugt på andre områder end milepælene under de tre udviklingsforløb. Det vil sige det tidsforbrug under de tre udviklingsforløb, som ikke har haft direkte indflydelse på tidsforbruget for de enkelte milepæle. Division Ved Division er andet tidsforbrug på 10,75 time, hvor bl.a. 5 timer er blevet brugt i forbindelse med kursus {Div-1,2}, og hvor 4,75 time på praktiske problemer i forbindelse med Caven, skærme og Fasttrack {Div-21,22,31,35}. CAVELib Ved CAVELib er andet tidsforbrug på 14,5 time, hvor der bl.a. 4 timer er blevet brugt på kursus {Cav-1}, hvor 6,5 timer er brugt på Performer programmering {Cav- 25,26,27,28,29}, og hvor 3 timer blev brugt på eksperimenter med interaktion {Cav-38}. VR Juggler Ved CAVELib er andet tidsforbrug på 5,59 time, hvilket er forholdsvis lille sammenlignet med andet tidsforbrug for udviklingsforløbene for Division og CAVELib. Her er bl.a. 2 timer blevet brugt på at læse dokumentation som introduktion til VR Juggler {VR-1}, og 2,5 time er blevet brugt på environment-variabler under Cygwin under Windowsplatformen {VR-5,8}. 4.5. Dialogform Dialogformen beskriver den måde, hvormed en udvikler anvender et givet værktøj. Dialogformen er interessant, fordi den er knyttet til udviklerens forudsætninger og den måde, udvikleren arbejder på og dermed kan bruges til at vurdere værktøjets egnethed til løsning af bestemte typer opgaver. Generelt set er disse forhold interessante, fordi de udtaler sig om fordele og ulemper ved forskellige dialogforme. Dette kan eksempelvis være brugbart ved valg og design af fremtidige brugergrænseflader for VR-værktøjer. Konkret set er forholdene interessante, fordi de beskriver hvilket værktøj, der egner sig bedst til en given opgave. Den information kan anvendes for fremtidige projekter rettet mod VRapplikationsudvikling til valg af værktøj. I dette afsnit definerer vi først de forskellige typer dialogforme, som anvendes til at klassificere værktøjernes dialogform. Herefter vurdere og beskriver vi, hvilke dialogforme, der anvendes i de forskellige værktøjer. Næst vurderes den tredje og sidste af projektets hypoteser, som antager at værktøjernes dialogform har indflydelse på deres egnethed til 53

håndtering af bestemte typer af udviklingsopgaver. Afslutningsvis forekommer der en konklusion, som opsummerer resultaterne fra undersøgelsen omkring dialogformen. 4.5.1. Definition af dialogformer I dette afsnit defineres de forskellige dialogformer. Der tages udgangspunkt i Shneiderman [Shn98], som definerer fem primære dialogformer: Direkte manipulation. Karakteriseret ved at brugeren, ved at anvende en interaktionsenhed (mus eller lignende) kan pege på og manipulere visuelle repræsentationer af objekter og derved få udført opgaver og se effekten af objekternes handlinger med det samme. Menuvalg. Karakteriseret ved at brugeren ud fra en liste af punkter i en menu, foretager et valg ved at vælge et menupunkt og kan se effekten af dette valg. Form-udfyldning. Kendetegnet ved en dialogform, der retter sig mod indtastning af data, hvor brugeren udfylder data i en række felter. Kommandosprog. Dialogform, som fungerer ved, at brugeren benytter et dedikeret sprog med en bestemt syntaks til at udføre handlinger, som ønskes foretaget. Naturligt sprog. Interaktion, hvor brugeren udtrykker sig gennem naturligt sprog og der igennem udtrykker de handler, som ønskes foretaget. Det kan enten være tekst eller tale. Dialogformerne er grundlaget for klassifikation af de dialogforme som de forskellige værktøjer anvender. 4.5.2. Klassifikation af værktøjernes dialogformer I dette afsnit beskrives dialogformene for de tre værktøjer, som har været anvendt i eksperimentet. Formålet er at kunne anvende erfaringerne fra værktøjerne til at undersøge fordele og ulemper ved de dialogforme, som værktøjerne benytter sig af. Vi har fordelt værktøjerne i to grupper. Dialogformen i CAVELib og VR Juggler er den samme, mens den adskiller sig fra dialogformen i Division. Derfor beskrives grupperne hver for sig. 54

CAVELib og VR Juggler Den første gruppe består af CAVELib og VR Juggler, som begge benytter kommandosprog som den primære dialogform. Det skyldes at både CAVELib og VR Juggler er programmeringsværktøjer som tilgås via en API (application programming interface). En API anvendes til at tilgå de programrutiner, som værktøjerne stiller til rådighed. Tilgangen til API erne foregår gennem programmeringssprog, hvor udviklernes programmer kan anvende en række operationer, som er defineret for henholdsvis CAVELib og VR Juggler. De operationer som API erne stiller til rådighed beskæftiger sig med initialisering af Caven, tilgang til hardware-enheder osv. Editere kildekode C/C++ kildekode Kompilere kildekode Applikation Eksekvere applikation Figur 7: Arbejdsgangen I CAVELib og VR Juggler. I Figur 7 ses arbejdsgangen for gruppens brug af værktøjerne i denne gruppe. Udvikling begynder ved at editere kildekode i en almindelig teksteditor eller en integreret programmeringsomgivelse. Dette resulterer i en mængde kildekode, som i værktøjernes tilfælde er skrevet i C/C++. Denne kildekode kompileres og kædes sammen (link es) med værktøjernes biblioteker, hvilket resulterer i en applikation som kan eksekveres. Kompilering af kildekoden kan resultere i kompileringsfejl, hvorfor udvikleren må editere kildekoden for at fjerne fejlene. Er kildekoden fri for syntaktiske fejl, så oversættes programmet, og kan nu eksekveres. Eksekveringen kan afsløre bl.a. semantiske fejl, hvorfor udvikleren går tilbage til at editere kildekoden for at fjerne disse fejl. Arbejdsgangen ved anvendelse af CAVELib og VR Juggler ligner den arbejdsgang, som anvendes under typisk programmering, hvor dialogformen er kommandosprog. Da dialogformen er den samme som ved typiske programmeringsværktøjer, så er det nemt og naturligt for en person med programmeringserfaring at anvende værktøjerne. Til begge værktøjer medfølger en simulator, hvor det er muligt at eksekvere og visualisere den udviklede applikation på udviklingsplatformen. Udviklingsplatformen anvender en almindelig monitor og mus, og her kan simulatoren emulere Cavens visualisering samt den hardware som Caven gør brug af. 55

(a) Figur 8: Screen dump af CAVELib-simulatoren. Henholdsvis (a) fra lang distance og (b) og tæt på. Applikationen der eksekveres er ikke applikationen fra eksperimentet. (b) I Figur 8 ses et screen dump af simulatoren i CAVELib. Den fungerer ved at emulere visualiseringen og hardware som det forekommer i Caven. Gennem en række menuvalg kan den emulerede visualisering og hardware styres. Menuerne i simulatoren gør det muligt at flytte og rotere avatarens position og orientering, visualisere ud fra avatarens synsvinkel, samt visualisere en synsvinkel udefra Caven, som viser både Cavens sider og avatarens position og orientering. Dialogformen i simulatoren er menuvalg i modsætning til kommandosprog som anvendes under programmeringen. Værktøjerne benytter altså en kombination af to forskellige dialogforme. Dialogformen for CAVELib og VR Juggler er primært kommandosprog, fordi den største del af udviklingstiden, ifølge vores erfaringer, bruges på at editere og kompilere kildekoden. Sekundært består dialogformen af menuvalg, fordi simulatoren anvendes regelmæssigt til at afprøve den applikation som udvikles. Division Division udgør den anden gruppe, som anvender en blanding af menuvalg, formudfyldning, direkte manipulation og kommandosprog igennem en grafisk brugergrænseflade. Menuvalg anvendes bl.a. til navigering og manipulering af 3D-objekter. Form-udfyldning kan anvendes til at specificere vinkler, koordinater osv. for 3D-objekter og avataren. 56

Direkte manipulation kan anvendes til simple transformationer på 3D-objekter - eksempelvis skalering, forskydning og rotation. Kommandosprog kan anvendes i form af et script-sprog til avanceret brug af værktøjet. Størstedelen af tiden er anvendt ved brug af menuvalg som dialogform, mens de andre dialogformer er anvendt i relativt kort tid. Derfor karakteriseres dialogformen for Division primært som menuvalg. Division er beregnet til modellering af VR-miljøer, hvor der tages udgangspunkt i 3Dobjekter som er modelleret udenfor Division, der tillægges adfærd i form af handlinger de skal foretage, når bestemte hændelser indtræffer. I Figur 9, vises den arbejdsgang der anvendes til udvikling af VR-miljøer i Division: Modellere 3D-objekter 3D-objekter Modellere VR-miljø VR-miljø Beskrivelse (VDI-fil) Eksekvere VDI-fil Editere VDI-fil Figur 9: Arbejdsgangen i Division. Figur 9, viser arbejdsgangen i Division. Den første opgave er at finde eller fremstille 3Dobjekter som skal anvendes i det VR-miljø som fremstilles. Hvis der ikke allerede eksisterer 3D-objekter, som kan anvendes, fremstilles disse ved at modellere 3D-objekterne i et 3D-modelleringsprogram. Division har ikke sit eget modelleringsprogram til 3Dobjekter. Til gengæld understøtter Division de mest udbredte 3D-formater, så det er muligt at anvende de fleste gængse 3D-modelleringsprogrammer. I vores tilfælde har vi anvendt 3DStudioMax til modellering af 3D-objekter. DVmockup er et program i Division-programpakken, som anvendes til modellering af VRmiljøer vha. en grafisk brugergrænseflade, som ses i Figur 10. I Division kan 3D-objekter tilpasses og samles i et fælles miljø. Dette gøres ved at tilpasse 3D-objekternes position, orientering, skalering, indsætte lyskilder osv. Division understøtter interaktion med 57

avataren i VR-miljøet, hvilket sker gennem hændelser (events) og handlinger (actions). 3Dobjekterne kan tilknyttes en adfærd, hvor det bestemmes hvilken handling 3D-objekterne skal udføre, når bestemte hændelser forekommer. Eksempelvis kan et objekt have den handling at det skifter farve (action), når det berøres af avatarens hånd (event). Figur 10: DVmockup er en grafisk brugergrænseflade i Division, som kan anvendes til at modellere og interagere med VR-miljøer. Hovedvinduet viser den samlede VR-miljø, som i dette eksempel er en motorblok. Vinduet, nederst til venstre, er en navigationsmenu og vinduet, nederst til højre, er til visning af beskeder. Gennem DVmockup er det både muligt at modellere og interagere med VR-miljøet. Interaktionen sker gennem en avatar, som kan flyttes rundt og interagere med miljøets 58