Varje utvecklare i projektgruppen utför även egna undersökningar som ligger i den individuella delen.
• Daniel undersöker ingenjörens ansvar mot sin omvärld ur några väletablerade etiska teoriers synvinklar.
• Måns undersöker vilka faktorer som spelar roll då det kommer till konsumentvänlig utveckling av AR-produkter.
• Emil undersöker om datorspelande med virtuell verklighet kan vara beroendeframkallande hos användaren.
• Raymond undersöker testbarheten av AR-applikationer enligt teststandarden IEEE 829-2008 i sin individuella del.
• Joakim undersöker hur användarens hälsa påverkas vid användningen av en VR-hjälm. • Ludvig undersöker hur man skapar en bra användarupplevelse i AR för förstagångsanvändare. • Nils undersöker hur man når hög kvalitet inom ett mjukvaruprojekt.
• Jonatan undersöker hur antalet gruppmedlemmar påverkar utvecklingen av ett mjukvarupro- jekt.
• Mikael undersöker hur man bäst anpassar sin versionshanteringsstrategi beroende på grup- pens och uppgiftens sammansättning.
6
Diskussion
I det här avsnittet diskuteras det hur väl de resultat projektgruppen har producerat besvarar de frågeställningarna som har ställts i rapporten. I del 6.1 diskuteras hur väl Unity är lämpad för utveckling av mobila AR-applikationer. 6.2 täcker diskussionen för hur väl BioVision implementeras för att ge värde för BioOptico. De erfarenheter som kan vara värda att dokumentera för framtida projekt diskuteras och sammanfattas i del 6.3. Slutligen ger projektgruppen sina kommentarer kring SEMAT Kernel ALPHA:s stöd för utvecklingen av BioVision i del 6.4.
6.1
Frågeställning 1: Utveckling i Unity
6.1.1 Utvecklingen av BioVision
Då Unity är en grafisk utvecklingsmiljö för generell utveckling av bl.a. spel, leder det till att en del av processorkraften används för funktioner som inte behövs i BioVision, men som är inbyggda i Unity. Exempel på dessa är Unitys inbyggda motorer för fysik och ljushantering vilka är väldigt prestandakrävande, men ej nödvändiga för BioVision. Det går till viss del att motverka, genom att avaktivera fysikhantering för element i Unityscenen, men lite overhead kvarstår.
Unity har däremot ett färdigt stöd för utveckling av program för VR-hjälmar, vilket i det här fallet är helt avgörande för att projektgruppen skulle hinna utveckla BioVision inom den budgeterade tiden. Unitys uppbyggnad med en grafisk redigerare och scenstruktur leder till att gruppen snabbt kan komma igång med att bygga en prototyp utan att först lära sig spelmotorns alla funktioner.
Flera alternativa utvecklingsmiljöer till Unity finns, men eftersom Unity är den enda (som pro- jektgruppen vet om) som har stöd för Samsung Gear VR så var valet av Unity givet. Att utveckla applikationen i en utvecklingsmiljö som inte har färdigt stöd skulle också vara möjligt, men det skulle antagligen ta mycket längre tid. Projektgruppens ringa erfarenhet av utvecklande inom AR- området är också en faktor som spelar in på Unitys lämplighet, vilken på många plan därmed kan anses vara god trots sina nackdelar.
6.1.2 Jämförelse med andra utvecklingsmiljöer
En bättre metod för att besvara frågeställningen hade troligtvis varit att utvecklat applikationen i flera olika miljöer men på grund av kursens tidsomfattning är det inte görbart. Med den nuvarande metoden är det dock svårt att veta om utveckling i en annan miljö hade förbättrat det slutgiltiga resultatet även om vägen dit blivit svårare.
6.2
Frågeställning 2: Värde för kunden
I den här delen behandlas och diskuteras det hur väl BioVision implementeras och hur det ger värde för BioOptico. Alternativa implementationssätt kommer även att diskuteras i detta avsnitt.
6.2.1 Iterationsstruktur
Iterationsstrukturen som användes i projektet lämpade sig väl på många sätt för att kunna ge värde till BioOptico. I slutet av varje iteration fick de en demo av den senaste versionen av BioVision och möjlighet att lämnna feedback till nästa iteration. På så sätt fick BioOptico och gruppen en bättre möjlighet att förstå varandra och på vilket sätt de vill att projektet skall fortskrida. Det gav gruppen en god chans att skapa värde för BioOptico.
En eventuell nackdel med den struktur som användes är att mycket testningstid krävdes, något som gruppen ej ansåg skulle vara nödvändigt om någon annan struktur användes. Vanligtvis är det
en självklarhet att utföra testning av kod vid utveckling av ett mjukvarusystem, men på grund av projektets och gruppens utformning, var ej utförlig testning nödvändig. Varje ny funktion byggdes parallellt på en blivande slutprodukt. Om ett fel uppstod var det möjligt att isolera det i den nya funktionen för vidare fel- och avvikelsehantering. På så sätt var det enkelt att garantera BioVisions korrekthet utan utförlig testning. I ett storskaligt mjukvaruprojekt kanske det inte är lika lätt att hantera en avvikelse på detta sätt, men på grund av BioVisions relativt ringa omfång skulle testningen kunnat hållas till ett minimun utan att riskera låg kvalitet.
6.2.2 Kundkontakt
Eftersom mycket av kommunikationen har fungerat bra har projektet kunnat utvecklas väl. Under de demonstrationer som skett har BioOptico haft en god möjlighet att säga i vilken riktning projektet ska gå. Det har underlättat arbetet då det blivit enklare att hålla fokus på rätt saker. Hade inte projektet gjorts iterativt hade det mycket möjligt uppståt delade åsikter angående slutresultatet.
En möjlig förbättring av kontakten hade varit en mer frekvent mejl-kontakt. Mycket av kontakten under projektet gick ut på att boka möten och besvara olika typer av frågor. Hade det funnits mer samtal kring hur arbetet utvecklades veckovis skulle möjlighet att ett annat resultat uppstått.
De demonstrationer som hölls upplevdes som givande från båda parter. BioOptico fick möjlighet att se hur projektet hade gått och uttrycka sina åsikter. På samma sätt så fick utvecklarna möjligheten att veta vad som skulle fokuseras på till nästa demonstration. Genom att få en djupare förståelse för BioOpticos mål med projektet kunde arbetet ändra riktning naturligt. Det hade dock varit onödigt att ha dessa möten oftare eftersom det tog tid att utveckla de förbättringar som togs fram.
6.2.3 Systemutvecklingsmetoder
I det här avsnittet behandlas hur projektgruppen använt de utvecklingsmetoder som nämns i avsnitt 3.
Scrum Som tidigare nämnt i avsnitt 4 används fundamentala koncept från Scrum-ramverket som daily scrum, sprints, daily scrum, sprint review och sprint retrospective. Dessa element anser projektgruppen vara viktiga för all form av utveckling. Däremot anses Scrum som en lärdom och är i allmänhet överflödigt och tidskrävande att ge sig in på. Att lära sig Scrum är en aktivitet i sig och det går ändå att organisera ett mjukvaruprojekt som utvecklingen av BioVision har organiserats med tanke på BioVisions och projektgruppens skala. Därför kompromissas alla Scrum-komponenter så att de är anpassade för det här kandidatarbetet.
Kanban I det här kandidatarbetet ingår flertal element som kan återfinnas i Kanban. Git issue tracker används för att lägga upp alla milstolpar och tillhörande arbetsuppgifter för varje iteration. På så sätt är det möjligt att få rapporter via Slacks Gitbot angående alla milstolpar som sätts upp och vilka som uppfyllts. Det Kanban är bättre på är däremot att ge ett visuellt flödesschema och identifiera flaskhalsar. Projektgruppen har dock inte ansett att Kanban är nödvändigt på grund av BioVisions struktur. Eftersom det är relativt lätt att parallellisera utvecklingsarbetet är det därmed sällan flaskhalsar är ett problem. Vid utveckling av BioVision kan de flesta funktionerna implementeras oberoende av andra funktioner.
Extreme Programming En del regler som finns i Extreme Programming tillämpas i kandi- datarbetet. Projektgruppen jobbar iterativt, släpper små utgåvor av systemet som BioOptico kan använda, och kollektiv äganderätt på BioVision används. Men många element som ingår i Extreme Programming passar inte in i kandidatarbetets projektmodell. Projektgruppen anser att maximal utvecklingskraft erhålls om alla hålls sysselsatta och får ut någonting av sitt tilldelade arbete. I och
med att BioVisions arkitektur enkelt tillåter parallelliserad utveckling och att varje utvecklare har sina egna scheman, togs istället beslutet att utveckla separata komponenter. Varje utvecklare fick en eller flera komponenter som huvudsakligt ansvar. Varje komponent prioriterades efter övriga komponenters beroende till den, samt efter vilka funktioner som behövde vara utvecklade i slutet av varje iteration. Eftersom de flesta komponenterna var relativt oberoende av varandra kunde mycket av arbetet parallelliseras.
Några regler från Extreme Programming som skulle kunna ha varit till nytta för att garantera arbetets kvalitet finns. Utformning och användning av user stories hade kunnat vara ett lämpligt verktyg för att hjälpa projektgruppen att ta del av de realistiska scenarion som BioVision ska kunna hantera. BioOptico skapade inför detta kandidatarbete user stories i form av funktionella krav, men de kan ses som otydliga. Ett exempel från kravspecifikationen är: ”Det ska finnas en meny med inställningar på appen.” Hur ska menyn vara utformad? Vad ska finnas på menyn? Är det en sidomeny eller är den heltäckande? Det är svårt att veta hur man ska utföra ett användbarhetstest för att testa denna funktion. Därför är det lämpligare att utforma user stories för att minska tvetydigheten hos krav och undvika missförstånd.
Vattenfallsmodellen För att garantera att kunden får det system de egentligen vill ha så behövs demonstrationer av den faktiska produkten. Det är annars lätt att det uppstår missförstånd om vad som faktiskt beställts. Vid utveckling av BioVision ges feedback och krav av BioOptico på de olika demonstrationerna vilket ger större insikt i vad de vill ha. Genom att följa vattenfallsmodellen ges ingen plats för feedback från BioOptico. Vad skulle inträffa om utveckling av BioVision följde vattenfallsmodellen? Det skulle vara svårt att gå tillbaka till att formulera om krav. När kraven väl dokumenteras är det redan där lätt att tolka dem på olika sätt. Därför gäller det att bekräfta med kunden om ett visst krav är implementerat på det sätt projektgruppen och kunden har enats om.
6.3
Frågeställning 3: Dokumentering av erfarenheter
Många av resultaten pekar på liknande saker. Mer tid som läggs på planering leder till effektivare arbete och ger möjlighet att hantera oförutsägbara händelser. Det här leder till ett antal frågor: Går det att göra en perfekt planering? Går det redan innan arbetet börjar att lägga upp tiden på ett perfekt sätt och förbereda gruppen för allt oförutsägbart? Svaret på båda frågorna är förmodligen nej. Det som går att göra är att förbereda sig för att något kommer att hända genom att ha mer tidsmarginal på samtliga delar i arbetet. Att ha krav som är väsentliga och mindre väsentliga gör att utvecklingen kan anpassas under projektets gång. Att bli bättre på att planera är något som förbättras för varje projekt man gör. Att skriva dokument hade gruppens medlemmar mindre erfarenhet av vilket ledde till problem i dess tidsplanering.
6.4
Frågeställning 4: SEMAT Kernel ALPHA
SEMAT Kernel ALPHA ger projektgruppen viss hjälp, men inte tillräckligt med stöd för att anses användbart vid utveckling av BioVision. I kandidatarbetet med en grupp på nio personer kan SEMAT Kernel ALPHA framstå som överflödigt. Alla medlemmar känner att de har tillräckligt bra koll på BioVisions struktur och vilket tillstånd arbetet befinner sig i. Däremot tycker gruppen att tillvägagångssättet är användbart för större mjukvaruprojekt och större utvecklingsgrupper. En teori inom gruppen är att gruppen hade en negativ inställning till korten från starten av projektet och att detta hindrade dem från att använda korten till deras fulla potential och alltså gick miste om det stöd som korten skulle ha kunnat ge. En annan teori är att gruppen får undermedvetna fördelar under projektet av att regelbundet diskutera de olika tillstånden gruppen befinner sig i.