E.6 Diskussion
G.3.2 Rader kod som mätdata
Skrivna rader kod i ett program som mätdata kan användas för att mäta storleken på ett pro- gram och hur mycket resurser som krävst för att skriva programmet[62]. Det kan även använ- das för att försöka förutsäga kvaliteten men är inte speciellt effektivt för detta ändamål[64].
G.4
Metod
För att undersöka kodgranskning samlades data in från Git, för att undersöka användartester och utvärderingar granskades de dokument som producerats i samband med dem. Metoden för hur själva kodgranskningen och utvärderingarna gick till återfinnes i avsnitt 4.5.2 respek- tive avsnitt 4.7.
G.4.1
Kodgranskning
Alla projektets feature branches gicks igenom. Antalet rader kod som accepterats och blivit inflyttade till develop skrevs ner. Antalet rader kod som lagts till och tagits bort mellan den första kodgranskningen och att branchen var klar skrevs även det ner. Bara feature branches räknades, ingen kod som vi inte skrivit själva är alltså med i resultatet. Rader kod som tillkommit på grund av namnbyte av en fil räknades inte heller. Bara HTML-, CSS- och JavaScript-filer räknades.
G.4.2
Användartest
Anteckningarna från användartesten gicks igenom och synpunkter från användarna sam- manställdes till en lista. De saker i listan som implementerats i slutprodukten kryssades av. Synpunkterna klassificerades i kategorierna buggar, funktionella synpunkter och design- mässiga synpunkter utifrån vilken sorts synpunkt det var. Buggar inkluderade rena fel som hittats under testet, funktionella synpunkter var idéer som avändarna fick om hur program- met skulle kunna fungera och designmässiga synpunkter var sådant som rörde programmets grafiska utformning och utseende. Andelen åtgärdade synpunkter inom varje kategori räk- nades ut.
G.5. Resultat
G.4.3
Utvärdering
Resultatet av utvärderingarna i 2 gicks igenom. Från materialet sammanställdes siffrorna för antalet förbättringspunkter och för antalet åtgärder som planerades på det efterföljande mötet. Detta gjordes för alla tre utvärderingarna.
G.5
Resultat
Följande del behandlar resultatet från kodgranskningen, användartesten och utvärderingarna.
G.5.1
Kodgranskning
Nedanstående tabell visar storlek på varje feature samt antalet ändringar som gjorts på varje feature efter kodgranskning.
Tabell G.1: Ändringar per feature efter kodgranskning.
Feature- Tillagda rader Borttagna rader Tillagda rader kod Borttagna rader kod
nummer kod per feature kod per feature efter kodgranskning efter kodgranskning
1 188 6 6 5 2 63 363 77 83 3 625 4 7 11 4 150 10 16 19 5 140 1 3 3 6 15 12 4 23 7 30 26 0 0 8 9 4 0 0 9 223 9 0 0 10 254 86 16 10 11 257 84 38 70 12 59 39 97 116 13 352 15 206 220 14 44 77 10 10 15 72 20 0 0 16 254 80 4 10 17 167 42 0 0 18 208 44 0 0 19 27 14 25 72 20 8 18 0 0 21 66 38 0 0 22 153 1 0 0 23 377 109 13 15 24 545 33 36 17 25 60 9 0 0 Totalt 4350 1144 617 677
Tabellen visar att flera av kodgranskningarna ledde till förändringar i koden. Förändringarna bestod av både tillägg av nya rader kod, samt av borttagning av rader kod.
G.6. Diskussion
G.5.2
Användartest
Nedanstående tabell visar hur mycket av användarnas feedback och ideer som samlades in och implementerades.
Tabell G.2: Resultatet av användartest.
Funna Åtgärdade Funktions- Implementerade Design- Implementerade
buggar buggar förslag funktionsförslag förslag designförslag
1 1 5 1 11 8
Tabellen visar att flera av användarnas ideér blev implementerade, bara ett funktionsförslag blev implementerat. Under användertestet hittades även en bugg som åtgärdades.
G.5.3
Utvärderingar
Nedanstående tabell visar antalet punkter som kunde förbättrats som togs upp under varje utvärdering. Tabellen visar också antalet konkreta förslag som kom upp i samband med diskussionen.
Tabell G.3: Resultatet av utvärderingarna.
Utvärderings- Förbättrings- Förbättrings-
nummer punkter förslag
1 48 16
2 76 10
3 38 14
Ur tabellen ser man att många av de förbättringspunkter som togs upp under utvärderingarna faktiskt behandlades med konkreta förbättringsförslag.
G.6
Diskussion
Analys av kodgranskning använde sig av antalet tillagda och borttagna rader kod som mät- data, det säger ingenting om kvaliteten på koden som ändrats. Här har antagandet gjorts att de punkter som tagits upp efter en granskning har varit negativa för kvaliteten och att den nya koden har bidragit till högre kvalitet. Detta antagande är dock rimligt, eftersom de punkter som tas upp efter kodgranskning är potentiella brister, fel och avvikelser mot stilguiden. Att kodgranskningen resulterade i så pass mycket förändringar var inte heller särskilt märkvärdigt då gruppen ej bestod av erfarna webbutvecklare. Dock gör även erfarna webbutvecklare fel ibland.
Resultaten av användartesten och utvärderingarna är ej viktade. De säger inget om hur stor påverkan ett förslag eller en förbättringspunkt hade. Många av förbättringspunkterna från utvärderingarna löste sig själva eller utan något möte. Gällande användartesten så fanns det redan planer att testa några av användarnas förslag. Användartesterna utfördes dessutom på redan granskad och enhetstestad kod, vilket kan förklara varför bara en bugg hittades.
G.7
Slutsatser
Från resultatet av kodgranskningen kan man se att det förekom en hel del ändringar som kanske inte hade gjorts utan kodgranskningen. Ungefär 26 % av antalet ändrade rader kod
G.7. Slutsatser
som accepterats till developbranchen tillkom efter kodgranskning. Eftersom projektgrup- pens kodgranskning i första hand sökte efter designmässiga brister samt avvikelser från standarder och konventioner är det rimligt att dra slutsatsen att kodgranskning ökade den slutgiltiga produktkvaliteten.
Från resultaten av användartesten kan man se att förslag från användarna faktiskt imple- menterades. I testen hittades dessutom en ren bugg som kunde åtgärdas. Användarna var typiska för de som ska använda slutprodukten och flera förslag från dem implementerades. Utifrån detta är det rimligt att dra slutsatsen att användartesten påverkade den slutgiltiga produktkvaliteten positivt.
Utvärderingarna uppdagade flera förbättringspunkter. Dessa protokollfördes och följdes upp, under utvärderingsmötet gavs dessutom konkreta förbättringsförslag för att åtgärda dessa punkter. Utvärderingarna bidrog därför till kvaliteten hos utvecklingsprocessen. Mer effektiva möten, administration och utveckling gav mer timmar åt produktkvalitet och kvalitetssäkrande processer. Utifrån detta dras slutsatsen att även utvärderingarna påverkade den slutgiltiga produktkvaliteten positivt.
H
Kristoffer Tennivaara: Metoder
och processer för grafiska
användargränssnitt
H.1
Inledning
Ett grafiskt användargränssnitt kan beskrivas som en länk mellan användaren och den pro- gramvara som användaren arbetar med. Gränssnittet tillåter användaren att mata in infor- mation vilket ger användaren möjligheten att påverka systemet. Systemet i sin tur bearbetar den inmatade informationen och presenterar resultat i form av utdata till användaren. Målet med ett grafiskt gränssnitt är att öka effektiviteten och förenkla användningen av program- met. Hur bra gränssnittet gör detta beskriver måttet användbarhet. Denna rapport utforskar metoder och processer för framtagning och utvärdering av grafiska användargränssnitt i ett småskaligt utvecklingsprojekt.
H.1.1
Syfte
Syftet med rapporten är att jämföra och ta reda på vilka processer och metoder som lämpar sig bäst för att ta fram ett användargränssnitt i ett småskaligt projekt.
H.1.2
Frågeställning
Följande frågor ligger till grund för rapporten:
1. Vilka aspekter i kvalitetsmåttet användbarhet är viktigast för ett utbildningsverktyg? 2. Vad har olika sätt att fatta designbeslut på för effekt på användargränssnittet?
3. Vilken metod lämpar sig bäst för att utvärdera ett användargränssnitt i ett småskaligt projekt?
H.1.3
Avgränsningar
Fokus ligger enbart på webbaserade applikationer då utvecklingsarbetet endast skett för just en sådan.
H.2
Bakgrund
Idag implementerar de flesta program ett grafiskt användargränssnitt. En stor del av resurs- erna för att utveckla ett program eller tjänst går till att designa ett bra gränssnitt. [65] Om till exempel en hemsida har ett dåligt designat användargränssnitt finns risken att användaren lämnar sidan för att hitta en sida som har en bättre design.
H.3. Teori
H.3
Teori
I teoridelen presenteras de teorier som använts och motiveringar om varför.
H.3.1
Användbarhet
Användbarheten hos ett system är ett kvalitetsmått och ISO 9241-11 definierar användbarhet som:
“Den grad i vilken specifika användare kan använda en produkt för att uppnå ett specifikt mål på ett ändamålsenligt, effektivt och för användaren tillfredsställande sätt i ett givet sammanhang.” [66]
Detta ger kvaliteterna ändamålsenlighet, effektivitet och personlig tillfredsställelse. Utöver dessa har Nielsen [67] velat väga in tre andra kvaliteter i begreppet:
• Learnability: Hur lätt det är att lära sig använda programmet för en nybörjare.
• Memorability: Hur lätt det är att minnas hur man gjorde om man gör ett uppehåll och därefter börjar använda produkten igen.
• Errors: Hur många eller få fel som användarna gör.
H.3.2
Designbeslut
Enligt Jared M. Spool [68] finns det fem vanliga sätt att ta designbeslut på. De är baserade på hur mycket forskning som utförs innan besluten tas. I vissa projekt finns det inte tillräckliga skäl för att använda den tid och resurser det skulle kräva för att kunna göra omfattande an- vändarundersökningar. Samtidigt skulle andra projekt misslyckas om de inte utförde dessa. De olika beslutstyperna nedan återspeglar i stigande ordning, den mängd forskning som ut- förs innan ett beslut tas.
1. Unintended design är det som sker när man utvecklar en produkt utan att ta hänsyn till designen.
2. Self design är designresultatet som blir när projektmedlemmarna designar åt sig själva. Projektmedlemmarna ser då inte bortom sina egna erfarenheter när de fattar designbeslut.
3. Genius design är baserat på tidigare individuella erfarenheter hos projektmedlem- marna. Precis som i self design använder man sig bara av sina egna erfarenheter för att ta designbeslut. Detta fungerar bra för erfarna utvecklare som har utvecklat pro- dukter inom samma område tidigare.
4. Activity-focused design går ut på att planera och studera användarnas aktiviteter när de använder produkten. Man använder sig av denna design när projektmedlemmarna inte har någon tidigare erfarenhet av aktiviteterna i fråga. I forskningen använder man sig av aktivitetsbaserade tekniker som till exempel uppgiftsbaserade användartester. Dessa tester utförs genom att testanvändare får uppgifter som de ska lösa med hjälp av produkten. Denna teknik gör att man får kvalitativa insikter i vad som orsakar problem för användarna, vilket resulterar i att man kan förbättra designen därefter.[69]
5. User-focused design är den stil där man utför flest användarundersökningar. Man går ner på djupet och försöker se bortom aktiviteterna. Man tittar på mål, behov och sammanhang hos användarna. Den här stilen är nödvändig om projektgruppen är ute efter att skapa en så bra användarupplevelse som möjligt. För att göra detta använder man sig av användarcentrerade tekniker som till exempel en robust persona. Detta för att gruppen ska få en kontextuell förståelse av användarnas upplevelse.
H.4. Metod
Spool har undersökt de olika stilarna och kommit fram till att den mest effektiva projektgrup- pen hade erfarenhet i alla fem stilarna. De valde den stilen som bäst passade behoven och målen baserat på det projekt de arbetade på. Han kom också fram till att valet av design- stil har en faktisk effekt på designen. De grupper som producerade de bästa upplevelserna kände till alla designstilar och kunde snabbt växla mellan dem. De visste när det var dags att gå ner på djupet med användarcentrerad design i ett projekt. Samtidigt visste de också när det var viktigt att få ihop en snabb design, i vetskapen om att det skulle bli en oavsiktlig design.[68]