Att skriva automatiska tester var en utvecklingsuppgift som ofta blev bortprioriterad. Mest eftersom det upplevdes som svårt att sätta sig in i testramverken och att bestämma exakt vad som skulle testas. Istället utförde utvecklaren några översiktliga manuella test av applikationen inför en push.
Idealt sett skulle det funnits automatiska test för varje funktionalitet som försäkrar att allt fungerar som det ska vid varje ny uppdatering av kodbasen. Systemet kan då även bli lättare att vidareutveckla eftersom tid kan sparas på att genomföra manuella tester av tidigare implementerad funktionalitet.
Utmaningen ligger då i att skriva robusta tester som är så oberoende av koden som möj- ligt. Ett problem som uppkom vid flera tillfällen under projektets gång var att tester misslyc- kades på grund av hur de i sig var skrivna. Problem i testerna upptäckes oftare än problem men den tillagda koden.
För en djupdykning i hur testning påverkar ett programvaruprojekt se appendix C.
6.2.4
Verifiering av kvalitetskrav
Verifiering av kvalitetskraven utfördes som beskrivet i kapitel 5.4.2. Ett av metoderna var att testa användbarhet utifrån System Usability Scale (SUS). SUS är en snabb och enkel metod för att mäta användbarhet vilket också innebär att det även har sina brister. Ett stort problem är att det SUS-testet endast visar oss ett värde på användbarhet utan att ge någon förklaring till varför testet gav det resultatet. Användarna behöver inte förklara varför de svarade på enkätfrågorna som de gjorde. Därmed så vet vi inte vilka aspekter av användbarheten som var bra eller mindre bra, och hur det bör åtgärdas.
En annan aspekt av SUS-testet som utfördes är användarna. Studenterna som fick använ- da systemet och sedan svara på enkätfrågorna enligt SUS var ej familjära med systemet sedan innan och behövde få en förklarande bakgrund innan systemet kunde användas. Ett passan- de alternativ hade varit att istället låta personer från Neue Labs eller Neue Labs kunder få använda systemet och genomföra SUS-testet.
6.2.5
Källkritik
De tre rapporterna som använts som källor i litteraturstudien för ett systems prestanda har varit tillgängliga i databasen DiVA. Dessa rapporter är ex-jobbsrapporter eller kandidatrap- porter skrivna av studenter från tekniska universitet i Sverige.
Att rapporternas författare är studenter innebär att de är personer som fortfarande är i ett lärande stadie och arbetena kan då innehålla vissa brister. Dock är rapporterna väl skrivna med mycket referenser för att stödja den information och de resultat som nås.
Syftet med rapporterna är att visa resultat och utbilda och de har inget motiv att vinkla information. Texterna har även, på grund av deras syfte som rapporter i studierna, granskats och godkänts av mer erfaren personal, som examinatorer eller handledare, vilket även stärker rapporternas riktighet. De tre källorna som användes i litteraturstudien visar även liknande resultat vilket stärker trovärdigheten ytterligare.
6.3
Arbetet i ett vidare sammanhang
I detta kapitel behandlas översiktligt hållbarhetsaspekter kopplade till projektet. För en dju- pare analys se appendix G
6.3.1
Etiska aspekter
Eftersom Playground Web är en plattform som är till för att utveckla IoT-applikationer är det relevant att diskutera några etiska aspekter som relaterar till detta.
6.3. Arbetet i ett vidare sammanhang
Det första och mest uppenbara handlar om datainsamling och lagring. De sensorer som applikationen kan kopplas till kan samla många olika typer av data, vilka potentiellt kan användas för att spåra människors beteende. Då är det viktigt att alla inblandade parter ger sitt samtycke till att data samlas in.
Ett kundföretag kan exempelvis använda plattformen för att skapa en IoT-lösning som observerar var anställda befinner sig eller vilka miljöfaktorer som de anställda utsätts för. Ansvaret för att få informerat samtycke från de anställda om datainsamlingen hamnar då på kundföretaget.
När det kommer till att lagra datan har dock Neue Labs ett ansvar för att detta sker på ett säkert sätt och att data endast finns tillgänglig till de som är behöriga. Plattformen har tillgång till att både läsa från och skriva till databasen. Det är därför viktigt att applikationen inte tillåter att skadlig data skickas till databasen, samt att endast autentiserade användare kan komma åt informationen. Den databas som används hanteras av AWS och autentisering sker med deras eget API. Ansvaret för att detta sker på rätt sätt ligger därför på AWS. Gäl- lande potentiellt skadlig data som kan skickas från applikationen finns inget utbyggt skydd i dagsläget, fritextfält bör exempelvis valideras innan datan skickas. Neue Labs äger rättig- heterna till plattformen och är på så sätt ansvariga att testa den utförligt innan den lanseras som en färdig produkt.
För mer information om säkerhetsrisker relaterade till IoT, se appendix D
Slutligen kan illvillig användning av IoT-produkter diskuteras. Det finns alltid en risk att en produkt kan komma att användas till brott. Ansvaret på företaget som säljer produkten ligger då i att samarbeta med polis eller andra rättsliga myndigeter om det finns skäl att misstänka att en användare använder plattformen på ett illegalt sätt.
6.3.2
Miljöaspekter
Det är svårt att komma undan från miljöfrågan med modern teknologi, framförallt när det kommer till hårdvara. I fallet av detta projekt är sensorn som kommer i kundens produktpa- ket en av de potentiellt stora bovarna.
Den består bland annat av ett chip i formen av ett kretskort med ett antal sensorer och verktyg för att göra den till en användbar källa och mål för signaler hanterade i mjukvaran. Paketet innehåller även batterier, lampor, kablar samt andra tekniska komponenter som kan kopplas ihop. Många av dessa komponenter som uppgör enheten kräver plast och ädelme- taller som inte bara kan ha en negativ miljöpåvärkan vid produktion, men kan också vara svåra att återvinna.
För mjukvaran i sig är det mest värdservrarna för hemsidan och databaserna som har miljöpåverkan. Kunden för detta projekt använder AWS för att hantera allt serverrelaterat och använder därför exklusivt Amazons nätverk av servrar.
Det är svårt att avgöra vilket alternativ på servermarknaden som skulle vara bäst i denna fråga. Amazon själva säger att det är miljövänligare att använda AWS än nästan alla andra serveralternativ, framförallt när det kommer till lösningar från många mindre servertjänster. De ska även ha investerat tungt de senaste åren i att etablera gröna energikällor i alla deras olika tjänsteregioner.
Med Microsofts samarbete med elbolaget Vattenfall för att förse deras Azure tjänst med grön energi, samt Googles fjärde år av att ha köpt grön energi i samma mängd som 100% av deras årliga konsumtion gör det svårt att sätta i perspektiv hur bra kundens val är jämfört med alternativen.
Stora serverhallar använder även ofta extrema mängder vatten för kylning vilket gör be- räkningen för miljöpåverkan ännu svårare.
För all potentiell negativ miljöpåverkan så kan det diskuteras att produkten också har potentialen att motverka negativa miljöaspekter.
Sensorer används extensivt inom energiindustrin samt andra miljöpåverkande sektorer. Vilket gör att bättre tillgänglighet samt billigare kostnader kan göra det lättare för mindre
6.3. Arbetet i ett vidare sammanhang
projekt och produkter att involvera sensorstyrda system i deras implementation. Ett exempel på att applicera en sådan lösning skulle kunna vara att ha termometrar som styr temperatu- ren i byggnader bättre och därmed minska elkonsumtionen.
7
Slutsatser
• Hur kan systemet Playground Web implementeras så att man skapar värde för kun- den?
Playground Web har implementerats som en webbapplikation med ReactJS och Redux som grund. Värdet det skapar för kunden är en möjlighet att nå ut till fler användare, jämfört med deras existerande iOS plattform.
En ytterligare värdfull faktor är att plattformen är byggd på ett av de mest populära JavaScript-biblioteken: React. Det finns därför goda resurser för vidareutveckling.
• Vilka erfarenheter kan dokumenteras från ett småskaligt programvaruprojekt som kan vara intressanta för framtida projekt?
Några av de viktigaste lärdomarna som gruppen tar med sig från projektet gäller ut- bildning, kommunikation och testning.
Gällande utbildning insåg gruppen vikten av att varva teori och praktik, och de mest uppskattade resurserna var praktiska övningsuppgifter som fanns tillgängliga på bland annat Redux hemsida.
När det kommer till kommunikation lärde sig gruppen nyttan av att ha frekventa statusuppdateringar. Med dagliga Scrummöten varje morgon fångades många frågor upp, och det var även ett bra forum för kunskapsutbyte.
Slutligen har gruppen lärt sig om hur viktigt det är att ha välskrivna tester. Ett pro- blem som dök upp under projektets gång var att testerna inte var tillräckligt robusta för att klara av ändringar i hur programkoden var skriven.
• Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?
En systemanatomi kan vara ett bra stöd i början av ett projekt för att skapa sig en tydlig bild över systemet som ska utvecklas. Det ger en visuell representation till hur olika krav på systemet hänger ihop och är på så sätt ett stöd när det kommer till planering av utvecklingen.
• Hur påverkar ReactJS tillsammans med Redux och arkitekturmönstret Flux en web- bapplikations prestanda?
Från litteraturstudien som gjordes i 5.3.2 kan slutsatsen dras att React är ett av de bättre ramverken att använda för att skapa en applikation med bra prestanda. Ramverket fick höga poäng i flera typer av tester av olika personer, bland annat i DOM-manipulering. Detta kan anses vara en fördel för Playground Web som skapar, uppdaterar och raderar data kontinuerligt.
Då tanken är att applikationen ska användas av Neue Labs och deras kunder efter detta projekt, är starttiden av applikationen viktig. React fick höga poäng för sin starttid och är mer passande för större applikationer, vilket kan anses vara det bästa ramverket för Playground Web.
Trots att litteraturstudien inte omfattade React tillsammans med Redux och Flux, uppmanar Redux-biblioteket och Flux till en appstruktur som förenklar hanterandet av dataflöden mellan olika delar av applikationen. Ingen slutsats kan dras angående Re- dux och Flux påverkan på prestandan, men biblioteket kan anses underlätta använd- ningen av React.
A
Scrum i jämförelse med andra
projektmodeller - Yen Dinh
A.1
Introduktion
Projektmodeller är ett bra verktyg att använda sig av för att uppnå effektiva projektresultat och att skapa den slutgiltiga produkt som önskats. Att använda sig av ett ramverk bidrar till att ett projekt styrs på ett effektivt sätt som hela gruppen är medvetna om. Med detta finns det ett antal olika ramverk och projektmodeller att välja på. När passar ett mer än något annat och vilka fördelar samt nackdelar kommer med varje ramverk eller projektmodell?
A.1.1
Syfte
Syftet med denna del är att ta reda på om den valda projektmodellen var den mest passande för projekt av denna skala.
Då Scrum användes som ett ramverk i detta projekt utan några problem, kan det anses vara det mest passande ramverket för ett projekt av samma skala. Detta undersöktes med hjälp av frågeställningarna som syns i kapitel A.1.2.
A.1.2
Frågeställningar
1. Vilka fördelar och nackdelar finns det med Scrum i jämförelse med andra projektmo- deller?
2. Vilken projektmodell passar mest projekt av samma skala som ett kandidatprojekt, och varför?
A.2
Teori
I detta kapitel presenteras och förklaras de olika projektmodellerna som ska jämföras med varandra i denna del av kandidatrapporten.
A.2. Teori
A.2.1
Scrum
I ett projekt som använder sig av Scrum, finns det ett Scrumteam som består av en produkt- ägare, ett utvecklingsteam och en Scrummästare. Detta team arbetar tillsammans i så kallade sprintar för att uppnå de mål som satts upp.
Sprintarna är en fastställd arbetsperiod på minst en vecka och max en månad. I dessa sprintar sätts delmål upp som ska bidra till att målet av hela projektet nås. Detta görs under sprintmötena som sker innan varje sprint. Efter varje sprint sker ännu ett möte där gruppen utvärderar och analyserar sprinten som varit. På detta sätt är hela gruppen medvetna om eventuella risker som kan ha upptäckts, samt vad som varit bra och mindre bra med arbets- perioden.
Utöver detta möte, sker ett dagligt Scrummöte där gruppmedlemmarna berättar vad de har gjort det senaste dygnet och vad de planerar att göra det närmsta dygnet. Alla möten som sker i och med användning av Scrum, hålls av Scrummästaren. För mer information om Scrum, hänvisas läsaren till kandidatrapporten, kapitel 3.1.1.
A.2.2
Vattenfallsmodellen
Denna metod är en av de vanligaste samt äldsta projektledningsmetoderna. Modellen fokuse- rar på att utföra projektets faser sekventiellt, vilket innebär att det finns en plan för ett projekt som följs i en enda riktning. [117] När en uppgift eller fas avslutas så kan inga ändringar ske för dessa i efterhand.
I Vattenfallsmodellen sker arbetet utifrån specifika faser som kan variera beroende på typen av projekt. De vanligaste faserna i denna typ av modell är:
• Kravspecifikation
Information om projektet samlas, som mål, krav och begränsningar och detta samman- ställs i en kravspecifikationen.
• Analys
Baserat på den första fasens dokument, analyseras projektet. Utifrån analysen skapas scheman och modeller för att undersöka hur projektgruppen ska gå tillväga för att få det önskade resultatet. Gruppen ska även i denna fas analysera kraven för att säkert veta vad resultatet ska vara. [117]
• Design
I denna fas skapas en design som är basen för arkitekturen av arbetet. Detta för att veta hur arbetet ska utföras för att nå projektets mål.
• Implementation
Utifrån den design som planerats, implementeras nu detta i denna fas. • Testning
I denna fas testas funktionerna för att se om några problem uppstår. Om resultatet är enligt kravspecifikationen och inga problem uppstår vid testning, levereras produkten till kunden och därmed avsluta projektet.
A.2.3
Spriralmodell
En spiralmodell är en modell som går under Software Development Life Cycle, (SDLC) där en riskhantering är ett steg i modellen. Namnet för denna modell kommer från hur diagrammet ser ut vid utritning. Detta kan ses i figur A.1. [113]
Varje varv i spiralen kallas för en fas, där antalet faser inte är specificerat och beror mestan- dels på storleken av projektet och hur komplext det är. Med de risker som upptäcks i projek- tet kan projektledaren välja att utöka spiralen ytterligare. Av denna anledning respresenterar
A.3. Metod
Figur A.1: Ett spiralmodellsdiagram. Bildkälla: [113]
radien kostnaden för projektet [113]. I figur A.1 syns det hur modellen är uppdelad i fy- ra kvadranter. Varje kvadrant representerar arbetsuppgifterna som måste göras innan nästa kvadrant påbörjas, likt faserna i Vattenfallsmodellen, A.2.2. Det som måste göras i varje kva- drant är följande:
• Mål och identifiering av alternativa lösningar
Krav samlas in från kunden för att projektgruppen ska kunna sätta, förklara och ana- lysera målen i början av varje fas. Även i denna fas kan gruppen föreslå alternativa lösningar till projektet. [113]
• Riskhantering
I denna kvadrant bestämmer gruppen den bästa lösningen för projektet, men identifi- erar även riskerna som kommer med den. Innan denna kvadrant avslutas ska riskerna ha lösts för att utvecklingen i nästa kvadrant ska gå så bra som möjligt.
• Implementation och testning
I denna del ska de bestämda funktionerna implementeras och testas. I slutet av denna kvadrant ska en ny version av produkten finnas.
• Redovisning, utvärdering och planering
Kunderna får nu en chans att utvärdera produkten. Projektgruppen kommer då kun- na avsluta projektet eller fortsätta planera en ny fas beroende på kommentarerna av kunden.
A.3
Metod
Den huvudsakliga metoden som använts i denna del är en litteraturstudie. Källorna som lästs i och med denna metod, behandlar de andra projektmodellerna som ej använts i denna kan- didatrapport mer. Då författaren och dess projektgrupp har tillämpat Scrum i detta projekt, kommer mycket av det ramverket beskrivas utifrån dessa erfarenheter.
A.3.1
Litteraturstudie
Genom en litteraturstudie har de källor som sökts upp i Google Scholar, Google samt IEEE Xplore använts som material för denna del. I Google Scholar och IEEE Xplore söktes källor upp med sökorden ”Scrum user experience”, vilket resulterade i flera artiklar som handlade
A.4. Resultat
mer om implementation av User Experience (UX) med hjälp av Scrum. Detta var inte relevant till arbetet och sökorden ”Scrum study” användes istället, vilket resulterade i 67 000 resultat i Google Scholar. Rubriken för de 10 första resultaten lästes och med detta användes artikeln A teamwork model for understanding an agile team: A case study of a Scrum project [95] och Using Scrum in Distributed Agile Development: A Multiple Case Study [112].
I Google Scholar användes även söksträngen ”Vattenfallsmodell studie” vilket gav 767 resultat. Av de första 10 resultaten valdes en rapport ut. Även söksträngen ”Spiral model di- sadvantages” har använts som resulterade i 110 000 resultat där en valdes baserat på dess rubrik och abstract. Andra sökstränger resulterade oftast i mer information angående mo- dellen än användarnas åsikter efter att ha använt modellen, vilket inte var intressant i denna studie.
Andra källor som använts har hittats via sökmotorn Google, där söksträngarna ”Spiral model” och ”Vattenfallsmodell” använts. Där har rubrikerna samt webbadresserna lästs för de 10 första resultaten. Utifrån dessa 10 valdes en källa för varje söksträng på hemsidor där redigeringsmöjligheter inte finns för vanliga användare.
A.4
Resultat
I detta kapitel presenteras de resultat som fåtts från litteraturstudien. Även i denna del pre- senteras författarens erfarenheter av Scrum.
A.4.1
Utvecklingsmetodernas för- och nackdelar
I detta delkapitel presenteras för- och nackdelarna med de valda projektmodellerna som syns i kapitel A.2.
A.4.2
För- och nackdelar med Scrum
Ett problem som projektgruppen hade i början av detta projekt var kommunikation med kunden. Utan krav och idéer om hur plattformen skulle se ut var det svårt att börja arbeta, vilket ledde till ineffektiva sprintar i början av projektet. I A teamwork model for understanding an agile team: A case study of a Scrum project [95] skriver Moe, Dingsøyr och Dybå om en sprint som krävde mycket mer arbete än vanligt på grund av kunden. De skriver att deras sprintar fungerat bra, men att det fungerat mindre bra när kunden inte levererade det de skulle [95].
Kommunikation kan anses vara en viktig del av Scrum. I rapporten Using Scrum in Di- strubuted Agile Development: A Multiple Case Study [112] skriver Paasivara, Durasiewicz och Lassenius att de hade svårt med detta i början. Då var deras dagliga Scrummöten korta och gruppmedlemmarna hade svårt att meddela resten om risker eller hinder de stött på. Även för Moe, Dingsøyr och Dybå var kommunikation svårt [95]. Det var problem med att slutföra backloggen och gruppmedlemmar var tysta under möten, vilket ledde till oproduktiva mö- ten. Medlemmar kunde också jobba på andra uppgifter än de som diskuterats under sprint- planeringen. [95] Dock skriver Paasivara, med flera, att när deras grupp blev mer bekväma med Scrum, som varit nytt för dem, blev arbetsprocessen och därmed kommunikationen bätt- re [112]. De ansåg att ett agilt arbetssätt var passande för distribuerade projekt på grund av den ofta och öppna dialogen bland gruppmedlemmarna. Detta bidrog till att alla utvecklarna var medvetna om vad som pågick under projektets gång och det ökade tilliten till varandra. [112] Med detta kunde risker och problem hanteras mycket snabbare.
A.4.3
För- och nackdelar med Vattenfallsmodellen
I En jämförande studie mellan agila modellen och Vattenfallsmodellen: Skillnaden mellan kraven i de båda modellerna skriver Nyström att modellen är bra för små system där verksamheten är känd och stabil [109]. Detta för, som skrivet i kapitel A.2.2, kan utvecklingen inte börja innan
A.5. Diskussion
en kravspecifikation skrivits. Nyström anser även att Vattenfallsmodellen är enkel att förstå vid första anblick [109].
Nackdelarna med Vattenfallsmodellen kan då ses vid större system där kraven inte är helt kända. Detta för att kraven kan ändras under arbetets gång och eftersom Vattenfallsmodel- len fortsätter röra sig framåt, uppdateras inte kraven. [109] Modellen är inte anpassad för förändringar och den saknar en riskanalys. Något annat som Nyström skriver är att det finns stora risker att slutprodukten kommer innehålla fel då det enbart genomförs tester i slutet av projektet. [109]
A.4.4
För- och nackdelar med Spiralmodellen
Spiralmodellen är en kombination av olika typer av Software Development Life Cycle, (SDLC).