Den största skillnaden i ramverken kan ses på starttiden av applikationen. Projektet som använde sig av React hade störst byggstorlek, men snabbast starttid i jämförelse med de and- ra ramverken. Detta var något som förvånade författarna som trodde att byggstorleken skulle påverka starttiden och därmed prestandan [110]. Denna skillnad bidrog till att React ansågs vara det bästa ramverket när det kommer till prestanda, skriver författarna [110].
I JavaScript DOM-Manipulation Performance får Persson istället att Vue och React har lik- nande starttid och att Angular har längst starttid [115]. Författaren kommer också fram till att React är ramverket som är bäst på DOM-manipulering då det har bäst resultat i tre av de fyra tester som utfördes. Angular har liknande resultat som React och Vue är lite långsammare än båda dessa två med längst tid i tre av fyra test.
I rapporten Ramverk vs Vanilla JavaScript [50] kommer författaren fram till att ramverken Vue och React har likvärdig prestanda, genom att mäta på liknande sätt som Ockelberg och Olsson gör. Gustafsson väljer dock att fortsätta sin studie med hjälp av Vue, då hans applika- tion var av mindre skala, eftersom hans litteraturstudie antydde att React var bättre för större applikationer.
5.4
Processbeskrivning
Vid samarbetet med kursen TDDE46 bestämde kvalitetssamordaren och testledaren att pro- cessen Scrum skulle ligga i fokus under projektet. Samarbetet resulterade även i att ett antal kvalitetskrav bestämdes.
5.4.1
Scrum
Genom användningen av Scrum har gruppen fått en bättre överblick av hela arbetet och vad som behövt göras när. De dagliga Scrummötena har sett till att varje gruppmedlem alltid har haft något att göra. Det förhindrar även att gruppmedlemmar kör fast då kommunikationen vid morgonmöten försäkrar att de som behöver hjälp får det.
Mätning av processen
För att mäta utvecklingen av processen Scrum genomfördes en anonym enkät under varje sprint-planeringsmöte. Genom att samla in gruppens åsikter och tankar så kunde vi se hur bra processen fungerade och se om det behövdes göras några förbättringar. Enkäten bestod av följande frågor, där fråga 1,3,4,5 var obligatoriska:
1. Hade förra sprinten tydliga mål? 1-5 2. Varför var målen tydliga/otydliga?
3. Hur upplevde du att gruppen följde planeringen? 1-5 4. Hur upplevde du arbetets svårighet förra sprinten? 1-5 5. Hur roligt var arbetet i förra sprinten? 1-5
6. Vad fungerade bra under förra sprinten?
7. Vad fungerade mindre bra under förra sprinten?
8. Vilka var de största hindren för att nå förra sprintens mål? 9. Vad kan förbättras till nästa sprint?
Efter att samtliga gruppmedlemmar fyllt i enkäten var det kvalitetssamordnarens uppgift att bestämma om det behövdes ett gruppmöte för att diskutera hur gruppen kunde åtgärda problemen som enkätsvaren belyste.
5.4. Processbeskrivning
Processförbättring
Till en början var alla relativt ovana vid att använda Scrum samtidigt som gruppen inte kän- de varandra så bra. Detta bidrog till att processen inte fungerade utmärkt. Gruppen hade inte heller en bra kännedom om verktyget Jira eller hur det skulle användas på bästa sätt. Allt eftersom gruppen blev mer bekant med Scrum och fick en bättre gemenskap fungerade processen bättre.
Inledningsvis var Teamledaren Scrummästare då det kändes naturligt att den som är teamledare även tar den rollen i Scrumprocessen. När utvecklingen väl kom igång bestämde gruppen att det var mer passande att ha utvecklingsledaren som Scrummästare.
Utifrån de genomförda enkäterna belystes framförallt att gruppens användning av Jira kunde förbättras. Därmed så fokuserades processförbättringen på hur Jira användes som en del av Scrum. Resultatet från enkätens obligatoriska frågor 5.9 visar inte en tydlig förbätt- ring. Förbättringen av Jira kom främst utifrån textsvaren som “Vad kan förbättras till nästa sprint?”. Inledningsvis var gruppen mindre bra på att lägga till nya ärenden i Jira. Något som förbättrades avsevärt under senare delen av projektet. Tidigt i projektet kunde uppgifter påbörjas utan att det fanns ett ärende i Jira. Vilket i de värsta fall ledde till att två personer jobbade på samma uppgift samtidigt. Detta kunde även ske då gruppen missade att se över ärenden som redan fanns i Jira. Gruppen hade även en tendens att lägga till nya ärenden utan detaljerad beskrivning av uppgiften eller förklaring av problemet. Genom att i senare delen av projektet till exempel rapportera in buggar med tydliga videoklipp som visade problemet, blev ärendehanteringen mycket mer effektiv.
Figur 5.9: Grafer som visar gruppens svar på enkätens obligatoriska frågor under samarbetet med TDDE46.
5.4.2
Kvalitetskrav
Då projektet behövde inkludera mätbara kvalitetsmål bestämdes ett antal kvalitetskrav uti- från bestämda kvalitetsfaktorer. Kvalitetssamordaren tillsammans med testledaren valde att kvalitetsfaktorerna användbarhet och korrekthet skulle ligga i fokus. Därefter adderades un- derhållsmässighet som ett fokus efter förfrågan från kunden. Nedan följer varje kvalitetsfak- tor, dess relaterade kvalitetskrav samt hur kraven mättes.
Funktionalitet
Funktionalitetskravet handlade om att uppfylla kunden Neue Labs krav på systemets funk- tionalitet. Kravet var följande:
5.4. Processbeskrivning
Kravet verifierades genom projektets acceptanstest [69]. Underhållbarhet
Kravet på underhållbarhet berörde möjligheten till förståelse och vidareutveckling av syste- met. Kraven var följande:
• Alla funktionselement i systemet ska ha det modifierade LCOM4-värdet lika med 1. • Systemets källkodsfiller ska ha ett kommentarindex inom intervallet 1 och 1,5.
Lack of Cohesion of Method v.4 (LCOM4) är ett sätt att mäta sammandragning i ett system [111]. Ökad sammandragning i ett system gör det lättare att underhålla och vidareutveckla ett system. Varje funktionselement blir tilldelad ett värde beroende på hur många komponenter som är kopplade till kodobjektet. Där ett värde lika med 1 betyder att funktionselementet ingår i systemets sammahängande träd. Kravet verifierades utifrån acceptanstest [69].
Enligt 5.10 går det att se systemets kompetentträd. Vilket visar att alla komponenter är en del av ett sammanhängande träd.
Figur 5.10: Filhierarkin för systemets källkod.
Kommentarindex är ett värde skapat internt för att mäta hur väl systemet är dokumen- terat, vilket förenklar förståelseprocessen av systemet. Genom att antalet kommentarer i en