Från detta arbete finns flera intressanta insikter om både teknisk implementation och utveck- lingsprocessen. Det utförda projektet presenterar en möjlig variant av agil utveckling som kan ge en värdefull slutprodukt. Detta visar att en mer avskalad variant av ett utvecklings- ramverk som Scrum kan passa bra för projekt av mindre skala.
Många dokument har producerats i projektet och skapat stöd för gruppmedlemmarna. Dessa dokument har på olika sätt kommit till nytta innan, under och efter utvecklingsarbetet. Vär- det hos olika sorters dokument är en nyttig insikt från det utförda projektet. Speciellt har det reflekterats över användning av systemanatomier. Denna typ av dokument, som till viss del skiljer sig från många andra systemmodeller, kan vara ett nyttigt verktyg att ta med sig till framtida projekt.
8
Översikt över individuella delar
Projektgruppens medlemmar har utfört mindre undersökningar av specifika aspekter hos projektet. Dessa presenteras som bilagor till denna rapport. Nedan följer sammanfattningar av de olika undersökningarna.
A Produktens miljöpåverkan av Joel Almqvist
Teamet utförde ett större projekt på 3200 arbetstimmar, under detta projekt så undersöktes många aspekter för att skapa en så bra produkten som möjligt. Men en aspekt som inte un- dersöktes var den miljömässiga som inte ställdes som krav av varken kunden eller teamet. Denna rapport försöker uppskatta hur mycket koldioxid som gruppen släppt ut under sin utvecklingsprocess och vad som skulle kunna ha gjorts för att minska denna siffra.
B Agil Versionshantering av Björn Detterfelt
Versionshantering är en viktig del av modern mjukvaruutveckling. Under de senaste tio åren så har det dykit upp många nya verktyg, tjänster och metoder. Borde man ha centraliserad el- ler decentraliserad? Hur ska man förgrena? Det finns många frågor och ännu fler svar. Genom att studera rapporter, artiklar och statistik försöker rapporten sammanställa de populäraste alternativen och dra några slutsatser om när de är lämpligast.
C Deepstream serialisering och rundturstid av Tim Håkansson
IoT är ett koncept som har stor utbredning i vårt samhälle idag. Med detta behövs bra algorit- mer och strukturer för att skicka och hantera data mellan en stor mängd enheter. Deepstream är en tjänst som erbjuder kommunikation samt hantering av data i realtid. I denna delen av rapporten granskas då denna tjänsten genom att göra en undersökning av hur deepstream serialisera sin data för minska nätverksbelastning och hur detta påverkar rundturstider. Efter att ha undersökt tjänsten så visade det sig att deepstream inte gör någon speciell serialisering utan skickar JSON-objekt i läsbart format. Dessutom såg man att RPC gick något snabbare att exekvera gentemot events, men att båda växer linjärt med datastorleken.
D Jest som testverktyg för spelutveckling av David Kjellström
Testning är något som alla vet är ett ont måste. Men måste det vara en utdragen process som man bara behöver få avklarad? Det den här studien kommer gå in djupare på är en undersökning i automatiska tester, speltestning och hur de lite mer knepiga testerna går till. Fördjupningen kommer ligga i Jest då det kommer grundas i många egna erfarenheter, men det kommer dras paralleller mellan olika testverktyg som Jasmine och Mocha. Jämförelser kommer göras som diskuterar skillnader mellan verktyg, vad som är grundläggande inom testvärlden och hur man kan få ut det mesta ur sina tester. De jämförda verktygen visar sig dock inte innehålla några stora skillnader, utan det kommer mer ner till vad man känner sig bekväm med för vilket syntax, där vissa verktyg har lite mer kött på benen gällande vilka bibliotek man använder sig utav i Javascript.
E En jämförelse av React och Angular av Axel Löjdquist
Utvecklingen av webbapplikationer har genomgått stora förändringar på bara de senaste 10 åren. Flera nya ramverk och bibliotek har introducerats för att underlätta utvecklingsproces- sen. En konsekvens av detta är att det har blivit svårare för en utvecklare att bestämma vilket ramverk eller bibliotek som lämpar sig bäst för sin webbapplikation. I denna delen av rappor- ten jämförs de två mest populära verktygen, React och Angular. Rapporten fokuserar på hur lätt det är för en utomstående utvecklare att bidra till ett projekt och jämför även strukturella skillnader. Baserat på erfarenheter som samlats från projektet, diskuteras att React passade bättre för det utförda projektet. Resultatet visar på att React är ett lättare verktyg att lära sig men att Angular har en tydligare struktur för hur något ska implementeras. Resultatet visar även på att Angular är ett lämpligare verktyg för större project medan React lämpas mer för mindre projekt, då användbarhet sätts i fokus.
F Beroenden till färdiga paket i open-source Javascript-projekt av Joel Oskarsson
Stora ekosystem av färdigskrivna paket med mjukvara har på senare år nått stor populari- tet. Det största arkivet av sådana paket är npm för Javascript. I detta arbete undersöks hur beroenden till färdiga paket påverkar utvecklingsprocessen och kvalitet hos slutprodukten för mjukvara skriven i Javascript. En kvantitativ analys av över 6 000 populära Javascript- projekt har utförts för att ta reda på hur utbredd denna praxis är. Resultaten från analysen visar att de undersökta Javascript-projekten i genomsnitt har 6.76 direkta beroenden. Baserat på projekterfarenheter presenteras också hur beroenden kan förändra mjukvaruutvecklings- processen. Slutsatser dras även om hur beroenden bör hanteras för att maximera säkerhet och tillförlitlighet hos ett system.
H Undersökning av typning i Javascript av Alexander Wilkens
Javascript, det primära programmeringsspråket gruppen utvecklat i, är ett dynamiskt typat språk avsätt för webbprogrammering. Den dynamiska typningen språket har leder till en mer uttrycksfull programmeringsupplevelse. Men hur påverkar egentligen den dynamiska typningen utvecklingsarbete i språket, och hur står det sig mot strikt typade alternativ som Facebooks Flow eller Microsofts Typescript? Undersökningen i denna del använder sig av forskning från tidigare studier för att bestämma detta, tillsammans med projektgruppens egna erfarenheter i Javascript. Resultatet från undersökningen pekar mot att utveckling i ett typat alternativ leder till färre publika buggar och reducerad utvecklingstid.
G Jämförelse mellan Scrum och Vattenfall utvecklingsmetodik i Studentprojekt
av Lieth Wahid
Dagens arbetsmarknad kräver ingenjörer som kan tillämpa teorin som de har lärt sig under sina högskolestudier i praktiken. För att förbereda sådana ingenjörer måste man ha hänsyn till utvecklingsmetodiken som används under studietiden. Vattenfallsmodellen är det mest använda utvecklingsmetodiken i projektbaserade kurser inom mjukvaruutveckling som ges vid högskolestudier. Scrum, å andra sidan, är ett ramverk som är väldigt populärt inom agil utveckling. Metoden har börjat används vid fler universitet runt om världen. Båda meto- derna har sina för-och nackdelar. Denna undersökning jämför vattenfall-arbetsmetoden med Scrum och diskuterar vilken som är mer fördelaktig för studentprojekt. Undersökningen an- vänder sig av rundfrågor samt ett frågeformulär mot en studentgrupp som består av åtta studenter. Resultatet från undersökningen visar att Scrum är den mest fördelaktig metoden för studentprojekt.
A
Produktens miljöpåverkan av Joel
Almqvist
A.1
Introduktion
Vid skapandet av produkten gjorde gruppen många avvägningar, vilken typ av arkitektur uppfyller produktens syfte bäst, hur bör vi arbeta för att vara så effektiva som möjligt, vilka kvalitetsfaktorer är viktigast för kunden. En aspekt som inte togs upp var dock den miljömäs- siga. Varken kunden eller gruppen satte upp miljörelaterade krav och denna aspekt hamnade helt i skymundan. Målet med denna rapport är att belysa denna bortprioriterade aspekt och noga utreda miljöpåverkan av teamets utvecklingsprocess.
A.1.1
Syfte
Syftet med denna rapport är att analysera utvecklingsprocessen ur ett miljömässigt perspek- tiv. Det som ska utredas är hur mycket koldioxid som genererats till följd av teamets utveck- ling av produkten. Dessutom så ska det utredas ifall det finns några åtgärder som teamet skulle kunna tagit för att minska koldioxidutsläppen.
A.1.2
Frågeställning
För att försöka uppnå rapportens syfte så har nedstående frågeställningar tagits fram. De har tagits med fram med åtankte given till att hålla de så konkreta och så mätbara som möjligt.
1. Hur mycket koldioxid har släppts ut till följd av utvecklingsprocessens strömanvänd- ning?
2. Hur mycket koldioxid har släppts ut till följd av teamets användning av molntjänster? 3. Vad i utvecklingsprocessen kunde gjorts annorlunda för att minska koldioxidutsläppen
A.2. Teori
A.1.3
Avgränsningar
Rapportens syfte är att mäta teamets miljöpåverkan, en väldigt komplicerat uppgift som kan göras oändligt detaljerad. För att förenkla problemet så mäter denna rapport miljöpåverkan endast i form av koldioxidutsläpp. Detta betyder att andra former av utsläpp såsom tungme- taller eller metangas inte undersöks.
A.2
Teori
Denna del avser att ge den information läsaren behöver för att förstå de uttryck och tekniker som används i denna rapport men inte i huvudrapporten.
Reguljära uttryck
Reguljära uttryck är en term ifrån datavetenskap samt formella språk och förkortas ofta till ”regex”. De beskriver strängar av en viss form och används ofta för att göra mer kraftfulla sökningar än vanliga exakta matchningar. Funktionalitet som sökningar av reguljära uttryck erbjuder är ett jokertecken som matchar vilket tecken som helst. Möjligheten finns också att låta en del av strängen repeteras noll eller oändligt många gånger med hjälp av en så kallad Kleene-stjärna. Ifall ”.” benämner jokertecknet och ”*” Kleene-stjärna kan följande exempel ges:
Du och (.)* andra har redigerat ett objekt
Denna sökning hittar då alla strängar som börjar på ”Du och ” och efterföljs av vilket tecken som helst, repeterat mellan noll och oändligt många gånger, och sedan avslutas med ” andra har redigerat ett objekt”. I praktiken så skulle denna sökning hitta alla strängar som börjar med ”Du och ” och slutar med ” andra har redigerat ett objekt” oavsett vad som står emellan dem. [27]
Greensofts modell
Greensofts modell är ett verktyg för att utvärdera och minska miljöpåverkan av mjukvara. Den innehåller processer och teorier för att både utvärdera och förebygga negativ miljöpåver- kan. I denna rapport så används framförallt koncepten om hur miljöpåverkan kan utvärde- ras. Först delas mjukvarans livslängd in i fyra perioder: utvecklingsfasen, distributionsfasen, användningsfasen och deaktiveringsfasen. Sedan så delas effekter på miljön in i tre nivåer, nivå ett är direkta effekter ifrån mjukvaran eller dess utvecklingsprocess. Nivå ett innefattar då saker såsom strömmen som utvecklarnas datorer använder eller bensinen som förbränns vid transport till jobbet. Nivå ett effekter kan också gälla användarna av produkten, såsom strömmen de använder eller miljöpåverkan att framställa hårdvara som köps för att köra pro- grammet. Nivå två effekter sker till följd av nivå ett effekter, de kan vara effekter såsom att hårdvaran vars primära syfte är att köra programet också kör andra program. Strömmen som dessa andra program sen använder sig av är en nivå två effekt. Det är svårare att hitta nivå två effekter jämför med nivå ett effekter, och ännå svårare att hitta nivå tre effekter. En nivå tre effekt uppstår till följd av en nivå två effekt. Ifall vi återanvänder exemplet ovan så kanske de andra programmen vi kör på hårdvaran ökar strömanvändningen till en sån mängd att elbolaget måste importera omiljövänlig el ifrån utlandet. Oftast så är dessa nivå tre effekter väldigt storskaliga och samhällspåverkande. Enligt Greensofts modell så får vi först en kor- rekt bild av mjukvarans miljöpåverkan efter att ha analyserat alla dessa nivåer och perioder. [28]
A.3. Metod
A.3
Metod
Metoden för sammanställa gruppens miljöpåverkan är tvådelad. Den första delen går ut på att uppskatta hur mycket elektricitet teamet använde sig av under utvecklingen. Detta kom- bineras sedan med en uppskattning på hur mycket utsläpp som genererats vid framställandet av denna mängd elektricitet. Den andra delen går ut på att sammanställa en uppskattning av teamets användning av molntjänster. Detta för att sedan slå ihop denna siffra med en approx- imation av hur mycket utsläpp varje användning av molntjänsten generar.
A.3.1
Utvecklingsprocessens koldioxidutsläpps
För att få en uppskattning av hur mycket elektricitet teamet använde sig så gjordes flera för- enklingar och antaganden. Dessa är i sig framförallt baserade på förstahandserfarenhet av hur teamets arbetsprocess såg ut. Med hjälp av dessa antaganden och förenklingar kunde en uppskattning av hur mycket tid teamet arbetade med sina datorer fås. Detta kombinerades sedan med information om hur mycket elektricitet en av teamets datorer drog för att då få en grov uppskattning av hur mycket elektricitet teamet använt sig av. Sedan så framställdes en approximation av hur mycket utsläpp framställning av denna elektricitet generade. Det- ta gjordes genom att ta storskalig statistik gällande energiproduktionen i hela Sverige och jämföra den mot koldioxidutsläppen energiproduktionen generade.
A.3.2
Approximera arbete utfört på molntjänster
De molntjänster som undersökts i denna rapport är de två molntjänster som gruppen använt flitigast, Git kombinerat med Github och Google Drive. Dessa tjänster erbjuder en historik över hur tjänsten har använts och med hjälp av denna kan en konkret siffra på hur ofta teamet förändrat deras databas tas fram. Sedan kombinerades denna siffra med en uppskattning av hur mycket koldioxid som släppts ut per operation. Då kan en approximerad siffra för hur mycket koldioxid teamet använt sig av till följd av tjänsterna ges.
Sammanställningen av historiken gjordes genom att mäta hur många gånger en ”push” gjorts mot Githubs servrar, detta gavs med hjälp av kommandot ”git reflog show origin/mas- ter”. Detta kommando ger ut alla lyckade förändringar av grenen ”origin/master”. Eftersom gruppen arbetade med ”pull-requests” så kunde inte master-grenen förändras lokalt utan detta kunde enbart ske genom Githubs servrar. Detta betyder alltså att varje förändring av master-grenen gjorts mot en molntjänst och genom denna metodik kan användningen av Githubs servrar approximeras.
För den andra molntjänsten teamet använde, Google Drive, kunde all historik fås som en sträng. Denna historik var detaljerad och innehöll varje förändring som varje teammedlem gjort på alla filer i den gemensamma mappen. För att kunna hantera en sådan stor sträng så användes en textredigerare med funktionalitet för sökningar av reguljära uttryck. Först så söktes namnet på operationen, vilket gav den totala mängden en operation uppkommit i historiken. Sedan så söktes ett reguljärt uttryck med operationens namn samt antal personer som utfört operationen. Detta eftersom i historiken på Google Drive så skrivs det ihop ifall flera personer förändrat samma objekt, det kan se ut på följande sätt: ”Du och 4 andra har redigerat ett objekt”. Genom att multiplicera med antal personer som utfört en operation så kunde sedan en siffra fås för hur många gånger en operation utförts.
A.3.3
Utsläpp per utfört arbete på molntjänster
A.4. Resultat
baserad på ett uttalande där de påstod att en sökning motsvarar utsläpp av 0.2 gram koldiox- id [29]. Denna siffra är dock en approximation och det faktiska utsläppet varierar beroende på flera faktorer. Bland annat så skriver Google själva att tid på dygnet och belastning påver- kar hur effektiva servrarna är [30]. Genom detta så påverkas naturligtvis även hur mycket utsläpp en sökning generar då mer effektiva servrar använder mindre elektricitet och därav generar mindre utsläpp.
Denna rapport undersöker dock förändringar på objekt sparade i moln, inte sökningar på Googles plattform. För en sökning så behöver ingen förändringar skrivas ner utan det räcker i teorin med att enbart läsa in data ifrån en databas och skicka den till användaren. Detta står i kontrast till processen att modifiera ett objekt där objektet först måste läsas in och sedan kan förändringar skrivas in i det. Denna process är mer krävande i form av tid och därav även elektricitet, vilket är vad som faktiskt generar koldioxidutsläppen som uppskattas. Dessutom så måste förändringar som görs propagera igenom flera maskiner då molntjänster sparar data på flera maskiner för att hantera ifall en maskin går sönder. Sammantaget så antas det i denna rapport att en förändring av ett objekt skulle kräva ungefär dubbelt som mycket arbete som en läsning. Då en läsning i form av en sökning generar 0.2 gram koldioxidutsläpp så antas det att en skrivning generar 0.4 gram koldioxidutsläpp. Men innan teamet modifierar ett objekt så laddas det alltid ned och inspekteras. Ett dokument läses igenom innan det redigeras och en Gitgren hämtas ned innan den kan förändras. För att hantera detta så antas varje förändring av ett objekt generera utsläpp av själva modifikationen och åtminstone en läsning. Sammantaget så antas det alltså att varje modifikation av ett objekt på en molntjänst generar ett koldioxidutsläpp på 0.2 ˚ 2 ` 0.2 “ 0.6 gram CO2.
A.4
Resultat
I denna del presenteras de resultat som framkom då metoden genomfördes, rent konkret så presenteras teamets koldioxidutsläpp till följd av utvecklingsprocessen samt användningen av molntjänster.s
A.4.1
Utvecklingsprocessens koldioxidutsläpp
Projektet var en del i en större universitetskurs som tog 400 timmar per teammedlem. Enligt teamets egna tidsrapportering så lades ungefär 30% av dessa 400 timmar på utveckling. Vil- ken dator teamet utvecklade på varierade stort och för denna rapport så tillåts en av dessa datorer representera alla de andra. Teamet kunde se att programering på en dator av typ ”Le- novo ideapad Y700” drog hela dess batteri ifrån 100% till noll på ungefär fyra timmar. Enligt dess tillverkade Lenovo [31] så har denna datormodell ett batteri med 60 watt timmar. En urladdning av detta på fyra timmar ger oss en timmes användning av 15 watt. Kombinerat med den uppskattade tiden fås följande ekvation fram:
400 ˚ 0.3 ˚ 8 ˚ 15 “ 14.4kW
Enligt statistik ifrån Naturvårdsverket som kan ses i figur A.1 så skapade Sveriges el och värmeproduktion ett koldioxidutsläpp på 4781 ˚ 109gram år 2016 [32]. Kombinerat med att
Sveriges energiproduktion detta år var 152 TWh enligt Energimyndighetens pressmeddelan- de[33], så får vi att varje kWh i genomsnitt skapade ett utsläpp på:
4781 ˚ 109{p152 ˚ 1012q « 31.45 ˚ 10´3gram CO2per kWh
Kombinerat med uppskattningen av hur mycket elektricitet utvecklarnas datorer drog så får vi följande approximerade utsläpp:
14.4 ˚ 31.45 ˚ 10´3
A.4. Resultat
Figur A.1: Statistik ifrån naturvårdsverket [32]
A.4.2
Molntjänsternas koldioxidutsläpp
En sammanställning av operationer teamet utförde mot Google Drive och Github ges i tabell A.1 och A.2. Operation i tabell A.1 syftar till hur ett objekt modifieras och de kategorier som finns är de namn som Google givit operationerna.
I avsnitt A.3.3 så togs en approximation fram för hur mycket koldioxid som generas vid varje operation. Multiplicerar vi denna med antalet operationer så får vi ut hur mycket koldioxid användning av molntjänster skapad.
A.5. Diskussion Operation Antal Redigera 262 Kopiera 43 Kommentera 4 Byta namn 40 Ladda upp 95 Skapa 92 Flytta 39 Ta bort 2 Totalt 577
Tabell A.1: Antal operationer teamet gjort på Google drive
Gitrepo Antal push operationer
UI 31 Kontroller 26 Services 12 Dokument 67 Server 0 Totalt 136
Tabell A.2: Antal git push operationer som gruppen gjort mot huvudgrenen på Githubs hem- sida
A.5
Diskussion
A.5.1
Metodikens problem
Metodiken som används i denna rapport innehåller många antaganden och storskalig sta- tistik använd på en mindre nivå. Till exempel så används statistik gällande hela Sveriges energiproduktion när koldioxidutsläppen för utvecklingsprocessen beräknas. Detta är inte helt korrekt då det som påverkade projektet var energiproduktionen i Linköping där det utfördes. Hur energin produceras varierar lokalt och rikssnittet behöver inte nödvändigtvis vara representativt för regionen. En annan förenkling är antagandet att hela datorns batteri går åt på fyra timmar, vilket är en grov approximation som dessutom varierar beroende på vilken aktivitet som utförs på den. Utöver detta så hade varje teammedlem en unik modell på sin arbetsdator. Sammantaget så bygger resultatet för teamets elektricitetsförbrukning på flera förenklingar. Till följd av detta så bör inte heller detta resultat ses som något annat än en