Front-end
Front-end består av en webbsida som är skriven i HTML och JavaScript. Beroende på vilken del av webbsidan som användaren interagerar med kommer olika data att skickas och erhål- las från back-end. Varje användare har ett eget konto på servern som används för att logga in och se data från olika sessioner. Inloggning på webbplatsen visas i figur 5.8 och en tidig version av hur data presenteras på webbsidan visas i figur 5.9.
Figur 5.8: Inloggningsfönster på webbsidan.
Figur 5.9: En tidig version av hur mätdata presenteras på webbsidan.
5.2
Gemensamma erfarenheter: Vilka erfarenheter har vi fått som är
överförbara till framtida projekt?
Detta avsnitt ämnas att presentera några av de erfarenheter som gruppen fått. Detta inklude- rar positiva erfarenheter kring arbetet samt några av de problem som gruppen stött på.
5.2.1
Teambuilding
Ett skäl till att gruppen fungerat så bra tillsammans har varit att gruppen känt sig som ett team. Detta tros ha påverkats av gruppens alla gemensamma aktiviteter vilket till exempel är grilldag, utelunch och tårtfika. Under projektet så har gruppen fått tillgång till en lokal vilket har blivit en naturlig samlingsplats för alla att arbeta i och har gjort att gruppen har kunnat dela erfarenhet och att be varandra om hjälp.
5.2.2
Animationer
Ett stort tekniskt bekymmer som uppstod under projektet vara animationer av 3D-modeller. Till en början visade det sig vara alldeles för tidskrävande att skapa alla animationer för hand, varpå några gratisanimationer från Mixamo användes. Det uppstod dock problem kring hur animeringssystemet i Unity fungerade, vilket ledde till att mycket tid i början av projektet las på att få animationer att fungera. Gruppen insåg även att arbetet för att få alla animeringar
5.2. Gemensamma erfarenheter: Vilka erfarenheter har vi fått som är överförbara till framtida projekt? att se perfekta ut skulle ta mycket mer tid än vad det kunde ge. Istället skapades en separat aktivitet för att förbättra animationerna senare i projektet, i mån av tid.
5.2.3
Sen ankomst
För att motverka sen ankomst infördes en kassa för fikapengar. Varje gång en person kommer sent utan god anledning till ett möte behöver den tillföra pengar i kassan. Reglerna var att om personen kommer mellan en och tio minuter försent får den en skuld på tio kronor. För varje ytterligare tio minuter sent ökar skulden med tio kronor med ett tak på 50 kronor per möte. Trots detta så har projektgruppen haft vissa problem med att flera personer kommer sent till möten. Vid flera möten togs det upp att gruppmedlemmar blev irriterade på personer som inte var i tid men trotts detta vid togs inte några åtgärder. Ur detta utvinns erfarenheten om att det är problematiskt med sen ankomst samt svårhanterat.
5.2.4
Datorproblem
Ett problem som uppstod under projektets gång var att det inte fanns tillräckligt många da- torer i arbetsrummet. Detta tillsammans med att en av simuleringsdatorerna inte gick att använda på grund av störande fläkt vilket skapade brist av arbetsstationer i lokalen. Proble- met löste sig genom att några i gruppen hade bärbara datorer som klarade av att köra Unity och att alla inte behövde arbeta i Unity. Den erfarenhet som skapades av detta problem var insikten av att det finns ett maximalt antal personer som kan arbeta vid samma datorplats. Parprogrammering löste detta problem för de som satt vid de större skärmarna men inte för de som arbetade på laptops. Skärmarna på dessa upplevdes som för små för att sitta mer än en person kring.
5.2.5
Git
Under projektets gång har gruppens samlade och individuella erfarenheter kring Git förbätt- rats markant. Vid starten av projektet använde gruppen sammanlagt tre grenar för att arbe- ta på. Det som skedde vid första demonstrationstillfället var att all utvecklad funktionalitet skulle integreras ihop till en fungerande simulering. Det resulterade i sin tur att en demon- strationsförberedelse gren skapade. Den grenen blev sedan kvar efter demonstrationen som en sekundär master-gren som flera jobbade på. Detta gav upphov till att den grenen aldrig blev färdigutvecklad och stoppade då effektivt gruppens förmåga att utföra pull request. Det problemet hanterades genom att under en tvådagarsperiod införa en feature freeze och enbart bearbetat redan utvecklad funktionalitet till att nå en tillräcklig nivå för att bli accepterad in i master-gren via en pull request.
5.3. Vilka val har tagits för att simuleringen ska hjälpa personen att bli mer bekväm?
Händelsen resulterade i att gruppen hädanefter implementerade en bättre Git-användning. Där en aktivitet ur backlog:en som ska arbetas med grenas av från master-grenen till en aktivitetsgren för att sedan när aktiviteten är färdigställd slå ihop aktivitetsgrenen med master-grenen. Detta för att säkerställa att master-grenen är kontinuerligt uppdaterad med ny testad och kommenterad kod.
I slutskedet av projektet hade gruppen nått en bra mogenhetsnivå i Git-användandet och arbetsflödet som illustreras i figur 5.10. Figuren är färgkodad för att tydligare beskriva hur olika grenar hör ihop. Gula pilar representerar en utcheckning av en gren till en annan och svarta pilar att man slår ihop aktivitetsgren till submodulgrenen. Detta arbetsflöde är precis det som beskrivs av Atlassian [18].
5.3
Vilka val har tagits för att simuleringen ska hjälpa personen att bli
mer bekväm?
Människorna i simuleringen är skapade för att vara lite ”dumma” men samtidigt levande. Tanken med att göra lite dumma studenter är att simuleringen inte ska vara för verklig. Om en simulering är för verklighetstrogen kommer användaren att upptäcka varje liten sak som avviker från den riktiga världen. Det är viktigare att skapa en levande simulering för att hjälpa personen att bli mer bekväm [19].
Ett försök att kunna hjälpa användaren att bli bättre är att samla in användardata under simuleringen. Den data som samlas in analyseras sedan och visas både i form av grafer samt uppmaningar som ska hjälpa användaren prestera bättre vid nästa tillfälle [20].
Alla personer är olika bekväma med att hålla en presentation. Därför kan simuleringen anpassas efter den svårighetsgrad som användaren vill ha. Personer som tycker det är krä- vande att hålla en presentation kan börja med en liten sal med få störande moment. När personen känner sig mer bekväm finns det möjlighet att öka storleken på rummet samt öka antalet störande moment. Moment som anses som störande är antalet frågor användaren får, antalet åskådare eller bakgrundsljud från till exempel fläktar.