Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
Vårterminen 2017 | LIU-IDA/LITH-EX-G--17/047--SE
Smart
inpasseringslösning
för
Gymsystem
–
Utveckling av inbyggda system och mobilapplikationer
A smart entry solution for Gymsystem
–
Developing embedded systems and mobile applications
Carl Folkesson, Hannes Haglund, Viktor Holmgren,
Felix Härnström, Yousif Touma, Jesper Westell & Olav
Övrebö
Handledare : Carl Brage Examinator : Kristian Sandahl
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut ensta-ka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva det-ta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admi-nistrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant samman-hang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Carl Folkesson, Hannes Haglund, Viktor Holmgren, Felix Härnström, Yousif Touma, Jesper Westell & Olav Övrebö
Sammanfattning
Detta dokument beskriver ett kandidatexamensarbete som har genomförts av sju civilin-genjörsstudenter från Tekniska högskolan vid Linköpings universitet. Syftet med arbetet var att utveckla en smart inpasseringslösning för företaget Zoezi AB och deras produkt Gymsystem. Systemet skulle dels bestå av en enkortsdator som styr ett lås och kommuni-cerar med Gymsystems servrar samt en mobilapplikation som kommunikommuni-cerar med denna enkortsdator. Den första delen av detta dokument beskriver hur utvecklingen av detta system gick till, hur väl de krav som ställts har uppfyllts samt gruppens gemensamma erfarenheter från att utveckla mjukvara i ett större projekt. Rapporten beskriver hur en sådan lösning kan implementeras så att den skapar värde för kunden, vilka erfarenheter som kan vara intressanta för framtida projekt, vilket stöd en systemanatomi kan ge, hur Arduinoplattformen kan användas för hårdvaruprototyper, vilket stöd Extreme
Program-ming kan ge, samt hur fördelningen av hållbarhetsdimensioner i ett sådant projekt kan
se ut. Följande slutsatser kan dras utifrån projektet: Det implementerade systemet som beskrivs i rapporten skapar värde för kunden. Agila utvecklingsmetoder rekommenderas varmt inför framtida projekt. En systemanatomi ger bra stöd vid aktivitetsformulering. Arduinoplattformen är en bra plattform för hårdvaruprototyper men innebär vissa pre-standabegränsningar. Extreme Programming ger bra stöd för en sådan projektgrupp som beskrivs i rapporten. Slutligen kan en skev fördelning av hållbarhetsdimensioner förvän-tas om dessa inte behandlas medvetet i projektets tidigare faser. Dokumentet senare del består av ett antal bilagor som innehåller individuella utredningar skrivna av gruppens medlemmar. Dessa bilagor utreder olika ämnen som i någon form har anknytning till antingen arbetet i detta projekt eller till mjukvaruprojekt i allmänhet.
Innehållsförteckning
Sammanfattning iii Innehållsförteckning iv Figurer vii Tabeller viii Ordlista ix 1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställningar . . . 1 1.4 Avgränsningar . . . 2 2 Teori 3 2.1 Utvecklingsverktyg . . . 3 2.2 Projektdrivningsverktyg . . . 4 3 Metod 6 3.1 Utvecklingsmetod . . . 6 3.2 Metod för erfarenhetsfångst . . . 73.3 Versionshantering av källkod och dokument . . . 8
3.4 Utvärdering av kravspecifikation ur ett hållbarhetsperspektiv . . . 8
4 Resultat 10 4.1 Systembeskrivning . . . 10
4.2 Erfarenheter intressanta för framtida projekt . . . 13
4.3 Värde för beställare . . . 13
4.4 Hårdvaruprototyper på Arduinoplattformen . . . 14
4.5 Extreme programming utan tidigare erfarenhet . . . 14
4.6 Utvärdering av kravspecifikation ur ett hållbarhetsperspektiv . . . 15
5 Diskussion 16 5.1 Resultat . . . 16
5.2 Metod . . . 19
5.3 Arbetet i ett vidare sammanhang . . . 20
6 Slutsatser 21 A Effekten från användning av Google Test i testdriven utveckling av Carl Folkesson 23 A.1 Inledning . . . 23
A.2 Bakgrund . . . 23 A.3 Teori . . . 24 A.4 Metod . . . 25 A.5 Resultat . . . 27 A.6 Diskussion . . . 28 A.7 Slutsatser . . . 30
B Utbyggbarhet hos delsystem av Hannes Haglund 32 B.1 Inledning . . . 32 B.2 Bakgrund . . . 33 B.3 Teori . . . 33 B.4 Metod . . . 34 B.5 Resultat . . . 34 B.6 Diskussion . . . 36 B.7 Slutsatser . . . 40
C Minnessäkerhet utan prestandaförluster; en jämförelse av Rust och C++ för systemutveckling av Viktor Holmgren 41 C.1 Inledning . . . 41 C.2 Bakgrund . . . 42 C.3 Teori . . . 42 C.4 Metod . . . 46 C.5 Resultat . . . 46 C.6 Diskussion . . . 47 C.7 Slutsatser . . . 48
D Agil utvecklingsmetodik i en distribuerad arbetsgrupp av Felix Härnström 50 D.1 Inledning . . . 50 D.2 Bakgrund . . . 51 D.3 Teori . . . 51 D.4 Metod . . . 53 D.5 Resultat . . . 55 D.6 Diskussion . . . 57 D.7 Slutsatser . . . 58
E Värdet av kvalitetsarbete i mjukvaruprojekt av Yousif Touma 60 E.1 Inledning . . . 60 E.2 Bakgrund . . . 61 E.3 Teori . . . 61 E.4 Metod . . . 62 E.5 Resultat . . . 63 E.6 Diskussion . . . 67 E.7 Slutsatser . . . 69
F Multiplattformutveckling av mobilapplikationer av Jesper Westell 71 F.1 Inledning . . . 71 F.2 Bakgrund . . . 72 F.3 Teori . . . 72 F.4 Metod . . . 72 F.5 Resultat . . . 73 F.6 Diskussion . . . 76 F.7 Slutsatser . . . 77
G Färdigutrustade mikrokontrollrar som utvecklingsplattformar för
kom-mersiella produkter av Olav Övrebö 78
G.1 Inledning . . . 78 G.2 Bakgrund . . . 79 G.3 Teori . . . 79 G.4 Metod . . . 80 G.5 Resultat . . . 81 G.6 Diskussion . . . 82 G.7 Slutsatser . . . 84
H Svar till enkät utförd av Felix Härnström 86
I Tabeller över praxisar och processer som använts i projektet 89
Figurer
4.1 En uppkopplad låsenhet. . . 11
4.2 Skärmdump av mobilapplikationens inloggningsskärm tillsammans med skärmen över listan med dörrar. . . 12
4.3 En skiss över produktens systemanatomi. . . 12
C.1 Flyttsemantik för variabelbindningar i Rust. . . 43
C.2 Flyttsemantik för funktioner i Rust. . . 43
C.3 Utlåning till funktioner i Rust. . . 43
C.4 Muterbar utlåning till funktioner i Rust. . . 44
C.5 Box-typen i Rust. . . 44
C.6 Motsvarande kod i C till figur C.5. . . 44
C.7 Exempel på traits i Rust. . . 45
C.8 Härledning av traits i Rust. . . 46
D.1 Svar till fråga 2a. . . 55
D.2 Svar till fråga 2c. . . 55
D.3 Svar till fråga 4. . . 56
D.4 Svar till fråga 16. . . 56
D.5 Svar till fråga 17. . . 56
D.6 Svar till fråga 18a. . . 56
D.7 Svar till fråga 18b. . . 56
D.8 Svar till fråga 18c. . . 56
D.9 Svar till fråga 20. . . 57
F.1 Skärmdump över vyn som implementerades för IOS, tillsammans med login-vyn som skapats i React Native. . . 75
Tabeller
3.1 Effektordningar och korta beskrivningar. . . 8
3.2 Hållbarhetsdimensioner och korta beskrivningar. . . 8
3.3 Matris över hållbarhetsbeteckningar för krav. . . 9
4.1 Icke-funktionella krav med hållbarhetsbeteckningar . . . 15
A.1 Enkätfrågor om Google Test och tillhörande svar i diskret skala. . . 27
A.2 Enkätfrågor om Google Test och tillhörande svar i fritext. . . 27
B.1 Faktorer som påverkar utbyggbarheten positivt respektive negativt hos kandidat-projektet. . . 39
F.1 Enkätfrågor och tillhörande svar. . . 74
H.1 Enkätfrågor och tillhörande svar. . . 86
I.1 Praxisar och processer för att säkerställa produktkvalitet . . . 89
Ordlista
Här definieras relevanta ord och begrepp för detta dokument.
API Förkortning för Application Programming Interface. En specifikation eller lista över de kommandon som ett visst program kan använda för att kommunicera med en specifik programvara [1].
AVR Atmel AVR är en serie mikrokontroller med 8-bitars RISC-arkitektur som vanligen används i inbyggd hårdvara [2].
AVR GCC Förkortning för AVR GNU Compiler Collection. Kompilatorsystem som inriktar sig mot AVRs. När man pratar om själva kompilatorn så används namnet avr-gcc [3]. Arduino Beskrivs av Arduino som: ”En elektronikplattform med öppen källkod baserad på lättanvänd hårdvara och mjukvara”. Det är även namnet på företaget som ligger bakom plattformen [4].
Assertion Påståenden som testar om ett uttryck är sant eller inte i kod, om uttrycket inte är sant termineras programmet med en felkod [5].
Blåtand Mest känd som Bluetooth. Protokoll för trådlös kommunikation med radiovågor [6]. CMake En familj av verktyg för att bygga, paketera och testa mjukvara på flera plattformar. Projektet är Open Source och utvecklas av Kitware [7].
Dödstest Test som testar om ett program avslutas som förväntat [8]. Ethernet Den mest använda teknologin för lokala nätverk [9].
FMC Förkortning för Free Microcontroller. Åsyftar i denna text en MC som förses från tillverkaren utan ytterligare periferier eller ingångar (endast med I/O-pinnar kopplade direkt till systemet). Denna beteckning används i texten för att strikt utesluta SBMC i omfattning. Git Ett versionshanteringsverktyg [10].
Google Scholar En söktjänst för vetenskapliga artiklar [11].
Gymsystem En produkt som säljs av Zoezi AB. En molntjänst som riktar sig mot gym. Omfattar bland annat kundhantering, passbokning, betalning och inpassering [12].
HTML Förkortning för HyperText Markup Language. Ett märkspråk för att specificera strukturen för en webbsida.
Tabeller
HTTPS Förkortning för Hyper Text Transfer Protocol Secure. En krypterad version av stan-dardprotokollet för kommunikation mellan webbläsare och webbsidor. Använder protokollen SSL eller TLS för att utföra denna kryptering [13].
IEEE Förkortning för Institute of Electrical and Electronics Engineers. IEEE är en icke-vinstdrivande branschorganisation inom data, elektronik och teknik. Deras mål är att driva teknisk utveckling framåt med sina standarder, publikationer och konferenser [14].
IoT Förkortning för Internet of Things. En term för den trend enligt vilken allt fler vardags-föremål blir trådlöst uppkopplade till internet eller till andra vardagsvardags-föremål.
Iteration En av omgångarna då stegen i den iterativa arbetsmodellen gås igenom.
Iterativ arbetsmodell En arbetsmodell där man arbetar på ett upprepande sätt. Det vill säga man utför samma steg flera gånger efter varandra.
Javascript Ett skriptspråk mest använt för webbsidor, men som också kan användas i andra sammanhang [15].
Kapplöpning En form av bugg som uppstår då två eller fler pekare opererar på samma min-nesposition vid samma tidpunkt, där minst en av dem skriver information och operationerna inte är synkroniserade [16].
MC Förkortning för Microcontroller. En programmerbar processor och vanlig plattform för utveckling av enklare styrlogik för hårdvara. En form av System on Chip.
Mockobjekt Objekt som är förprogrammerad med förväntningar över vilka anrop den kom-mer att få och vad den ska returnera vid dessa anrop [17]. Att använda ett mockobjekt istället för en riktig implementation kallas att mocka.
Mockramverk Ett kodbibliotek för att skapa mockobjekt och använda dem [17].
MVP Förkortning för Minimum Viable Product. Den minsta möjliga användbara version av produkten som kan släppas [18].
NPM Förkortning för Node Package Manager. Pakethanterare för Javascript. Tillhandahål-ler världens största ekosystem av öppen källkod [19][20].
Open source Öppen källkod, det vill säga programvara som är fri att läsas, redigeras och distribueras.
Planeringspoker En metod för tidsuppskattning av aktiviteter. Den går ut på att en akti-vitet tas upp för att tidsuppskattas varpå samtliga gruppmedlemmar får fundera någon minut för sedan uppskatta antal timmar man tror aktiviteten kommer ta att genomföra. Resultatet diskuteras sen och man kommer överens om en lämplig tidsuppskattning.
Product backlog En lista över alla saker som kan behövas i en produkt som är under utveckling. Listan är sorterad efter prioritet. I Scrum ska den ses som en dynamisk kravspeci-fikation [21].
Tabeller
RFC Request for Comments är en form av formellt dokument som beskriver specifikationer,
protokoll och procedurer som en del av en standard [22].
RFID Förkortning för Radio-frequency Identification. En samlingsterm för radiotekniker som används för trådlös identifiering och dataöverföring. Implementeras vanligen i form av trans-pondrar och minnen, även kallade taggar [23].
RISC Förkortning för Reduced Instruction Set Computing. En designprincip enligt vilken instruktioner i en processor kan utföras under en klockcykel [24].
SBMC Förkortning för Single Board Microcontroller. Åsyftar i detta fall en mikrokontroller som förses färdigutrustad med I/O-portar, ledlampor, programmeringsportar och dylikt, och som på så vis abstraherar bort en stor del av arbetet kopplat till att driva, koppla och/eller programmera enheten. Förses normalt med unikt bibliotek som även abstraherar interaktion med del av den inbyggda hårdvaran (exempelvis kommunikationsprotokoll för I/O-hårdvara). Exempel utgörs i denna text av en Arduinoplattform.
Scrum Ett agilt arbetssätt för genomförande av komplexa projekt [21].
Software metric Ett sätt att mäta till vilken grad ett mjukvarusystem eller en mjukvaru-produkt innehar en viss egenskap.
SPI Förkortning för Serial Peripheral Interface. Ett kommunikationsprotokoll ofta använt för kommunikation med periferier såsom mikrokontroller [25].
Sprint En period om två till fyra veckor där man arbetar med att utveckla de för tillfället högst prioriterade delarna av systemet [21].
Sprint backlog En utvald delmängd av Product backlog som gruppen tror är genomförbar under aktuell sprint.
Sprint retrospective Ett möte efter avslutad sprint där man utvärderar arbetet och skapar en plan för hur gruppen kan förbättra sitt arbete i framtida sprintar [21].
SSL Förkortning för Secure Sockets Layer. Ett kryptografiskt protokoll som kan användas för att säkert överföra information mellan två parter. Används bland annat som ett av kryp-teringsprotokollen i HTTPS [26].
TLS Förkortning för Transport Layer Security. Ett kryptografiskt protokoll som kan använ-das för att säkert överföra information mellan två parter. Används bland annat som ett av krypteringsprotokollen i HTTPS [26].
UART Förkortning för Universal Asynchronous Receiver Transmitter. Ett kommunikations-protokoll för seriell kommunikation mellan enheter [24].
XML Förkortning för Extensible Markup Language. Ett vanligt märkspråk för att beskriva strukturerad data.
XP Förkortning för Extreme Programming. Ett agilt arbetssätt för att få ut färdiga delar av produkten till kund så fort som möjligt [27].
Tabeller
Zoezi AB Företag i Linköping. Beställare till projektet som beskrivs i denna rapport. XUnit Ett samlingsnamn för flera testramverk med liknande struktur och funktionalitet. Stilen är objektorienterad och liknar programmeringsspråken Java och C# [28].
1
Inledning
Detta kapitel beskriver syftet med projektet och etablerar de frågeställningar denna rapport ämnar besvara.
1.1
Motivering
Målet med detta projekt var att ta fram en lösning för att låsa upp en dörr med en mobi-lapplikation. Produkten utvecklades på uppdrag av Zoezi AB och är därmed integrerad med deras existerande produkt Gymsystem. Utgångspunkten för produkten var att på sikt ersätta existerande inpasseringssystem som bygger på RFID-teknik. Produkten består av två delar: en mobilapplikation till Android och IOS samt en låsenhet som installeras för varje dörr som ska styras av systemet. Användaren väljer vilken dörr denna vill låsa upp i mobilapplikationen och låsenheten verifierar då användarens identitet och behörighet i Gymsystem och låser upp dörren. Flera låsenheter kan installeras på samma anläggning och dessa enheter fungerar helt oberoende av varandra; den enda gemensamma länken är anläggningens existerande databas i Gymsystem. Detta gör det lätt att lägga till eller ta bort enheter på en anläggning utan någon förändring i övrig infrastruktur. Låsenheterna lagrar användaruppgifter lokalt och bibe-håller därmed sin väsentliga funktionalitet även vid tillfällig nätverksförlust. I denna rapport beskrivs hur projektet bedrevs, de verktyg och miljöer som använts, tekniska utmaningar och implementationer samt hur produkten kan ersätta konkurrerande system.
1.2
Syfte
Denna rapport ämnar beskriva produktens ingående delsystem och hur dessa är uppbyggda. Vidare kommer rapporten ta upp hur projektet bedrevs sett till såväl generell organisation som mer specifika utvecklingsmetodiker och processer. Rapporten kommer också beskriva gruppmedlemmarnas reflektioner på deras erfarenheter under projektet och projektarbete i allmänhet.
1.3
Frågeställningar
1.4. Avgränsningar
1. Hur kan en smart inpasseringslösning med mobilapplikation och enkortsdator implemen-teras så att man skapar värde för kunden?
2. Vilka erfarenheter som kan vara intressanta för framtida projekt kan dokumenteras från utvecklingen av den smarta inpasseringslösningen?
3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?
4. Hur kan Arduino-plattformen användas för snabb utveckling av hårdvaruprototyper? 5. Vilket stöd ger Extreme Programming för en projektgrupp utan nämnvärd tidigare
erfa-renhet av denna utvecklingsmetodik?
6. Vilken fördelning av hållbarhetsdimensioner fås i en kravspecifikation då projektet saknar hållbarhetsfokus?
1.4
Avgränsningar
Denna rapport beskriver enbart en projektgrupp och gruppmedlemmarnas egna erfarenheter under ett specifikt projekt. Generella slutsatser om organisation, arbetssätt och verktyg är därmed begränsade till extrapolering utifrån slutsatserna för det beskrivna projektet.
2
Teori
I detta kapitel återfinns den grundläggande teorin för examensarbetet.
2.1
Utvecklingsverktyg
I detta kapitel beskrivs de verktyg och ramverk som användes för att utveckla systemet.
React Native
React Native är ett korsplattformsramverk i Javascript som utvecklas främst av Facebook. Ramverket bygger på React som används för webbutveckling. React tillhandahåller ett bra API för att rendera vyer i webbläsaren med klassiska HTML-komponenter. React Native gör samma sak men med egna komponenter byggda för att kunna rendera vyer för olika mobila plattformar med ett utseende som passar plattformen.
Med ett korsplattformsramverk kan alltså en enda kodbas användas för att bygga mot flera plattformar, i detta fall mot både Android och IOS [29].
JSX
JSX är en utökning av Javascript-syntaxen och är ett XML-liknande format för att beskriva komponenter i React och React Native [30].
Node.js
Node.js är en Javascript-miljö som bygger på Googles V8 Javascript-motor som använder sig av en asynkron, eventdriven modell [31].
Yarn
Yarn är ett pakethanteringsverktyg för Node.js. Det erbjuder betydligt bättre prestanda än den traditionella NPM-klienten samtidigt som det är extremt flexibelt då det använder sig av NPM:s paketregister, vilket är världens största ekosystem av öppen källkod [32][19].
2.2. Projektdrivningsverktyg
CMake
CMake är en familj av verktyg som kan användas för att hantera byggprocessen och är agnos-tiskt när det kommer till vilket operativsystem eller kompilator som används. Genom CMa-ke kan projektfiler för olika system och utvecklingsmiljöer såsom Visual Studio, XCode och QtCreator genereras automatiskt [33].
Travis-CI
Travis-CI är ett verktyg för kontinuerlig integration och stödjer en stor uppsättning av olika språk, testramverk och konfigurationer. Vidare har Travis bra integration med Github vilket gör det möjligt att automatiskt testa Pull Requests och förhindra att ändringar som inte passar i testsviten integreras.
Google Test
Google Test är ett ramverk för att testa program och kodstycken skrivna i C++ [17].
Jest
Jest är ett testramverk framtaget för att testa Javascript och likt React Native är det utvecklat av Facebook. Ramverket används av företaget för att testa inte minst React Native-kod [34].
Mocha
Mocha är, likt Jest, ett testramverk för Javascript. Det syftar till att ge utvecklaren god flexibilitet och samtidigt vara användarvänligt [35]
Enzyme, Chai och Sinon
Enzyme, Char och Sinon är bibliotek som syftar till att förse utvecklaren med diverse verktyg för testning av Javascript-kod [36] [37] [38].
2.2
Projektdrivningsverktyg
I detta kapitel beskrivs de verktyg som användes för att bedriva och organisera arbetet i projektet.
Slack
Slack är ett kommunikationsverktyg för projektgrupper och team. Det finns som webbapplika-tion och nativeapplikawebbapplika-tion till Windows, Linux, macOS, Android och IOS. Den huvudsakliga kommunikationen i Slack organiseras i olika kanaler som är avsedda för att behandla specifika ämnen. Användare kan även kommunicera direkt med varandra genom privata meddelanden. Kommunikationen sker i textform även om Slack även stödjer ljud- och videosamtal. Vidare har Slack även en stor uppsättning av integrationer, bland annat med Github [39][40].
Trello
Trello är ett webbverktyg som låter individer eller grupper organisera uppgifter och arbete. Detta görs genom att skapa och flytta kort mellan olika listor och tavlor (eng. boards) [41].
2.2. Projektdrivningsverktyg
GitHub
GitHub är ett verktyg för att underlätta samarbete för utvecklare genom versionshanterings-systemet Git. GitHub har även integrerat stöd för bugrapportering (Issues), kodgranskning av
3
Metod
I detta kapitel beskrivs de metoder som användes i projektet för att uppnå kundens krav på produkten.
3.1
Utvecklingsmetod
Under projektets gång har en iterativ arbetsmodell tillämpats. Projektet delades in i fyra iterationer där den första iterationen bestod av en förstudie. Under förstudien kom gruppen överens om att ett agilt arbetssätt skulle tillämpas utöver det faktum att projektet som helhet var indelat i iterationer. Det bestämdes även att det skulle genomföras veckovisa möten för att planera och delegera arbete, diskutera lösningar samt förbereda ämnen att diskutera med gruppens handledare.
Kvalitetssamordnaren och utvecklingsledaren fick ansvaret att specificera de praxisar och processer som skulle användas under projektets skarpa iterationer. Dessa nedtecknades i ett första utkast till en kvalitetsplan. Utöver denna nedtecknades även första utkast till en pro-jektplan, en testplan, en kravspecifikation samt en arkitekturbeskrivning. Syftet med dessa dokument var att ha en för gruppen överenskommen plan för hur projektet skulle genomföras och vad som skulle åstadkommas.
Under förstudien spenderades även tid på utbildning, utvärdering av lämpliga plattformar att utveckla produkten på och tillhörande verktyg för att underlätta exempelvis testning. Det som undersöktes var dels vilka hårdvaruplattformar som skulle fungera bra för att styra lås samt kommunicera med Gymsystems API. Utöver det undersöktes också vilka ramverk som fanns för att utveckla en mobilapplikation till flera plattformar. Då valet föll på React Native som plattform för att utveckla mobilapplikationen spenderades således också tid på utbildning inom Javascript i allmänhet och ramverket React Native i synnerhet.
De agila metoder som användes under projektets gång hämtades från de agila arbetssätten
Scrum och Extreme Programming (XP). Vi valde att inte tillämpa alla metoder som omfattas
utan endast de som bedömdes gynna gruppen utifrån parametrar som projektets utformning och längd samt gruppens sammansättning.
Från Scrum tog vi främst in metoder för att arbeta på ett så produktivt sätt som möjligt. Till att börja med använde vi oss av sprints för att dela in projektets större iterationer i kortare sådana. Vi hade även en product backlog med alla aktiviteter som behövde genomföras samt sprintplaneringsmöten i början av varje sprint där vi valde ut de viktigaste aktiviteterna och
3.2. Metod för erfarenhetsfångst
la dem i en sprint backlog för den kommande sprinten. Efter en genomförd sprint hölls även ett sprint retrospective där vi utvärderade den senaste sprinten samt identifierade möjligheter att förbättra våra arbetsmetoder.
Från XP hämtades metoder som var mer inriktade på hur utveckling av produkten ska gå till samt metoder för att säkerställa hög kvalitet på producerad mjukvara. Bland annat användes praxisar som parprogrammering, vilket innebär att all utveckling i största möjliga mån ska ske i par. På så vis delas kunskap om systemet mellan gruppens medlemmar sam-tidigt som antal mjukvarufel minimeras. Vi använde även testdriven utveckling, kontinuerlig integration samt principen att eftersträva en MVP. Alla dessa metoder användes i syfte att producera så högkvalitativ kod som möjligt med så få fel som möjligt samtidigt som vi levererar kontinuerligt förbättrade prototyper.
Inför den första utvecklingssprinten hade vi efter gediget förstudiearbete definierat akti-viteter vilka även hade tilldelats en grov tidsuppskattning. Metoden som användes för att tidsuppskatta aktiviteter var planeringspoker. Denna initiala tidsuppskattning gjordes för att få en uppfattning om huruvida projektet var genomförbart med de krav som då ställdes på produkten. Under ett sprintplaneringsmöte kunde sedan dessa tidsuppskattningar revideras till följd av insamlad erfarenhet kring hur lång tid liknande aktiviteter har tagit. Aktiviteter som uppskattats ta lång tid kunde även brytas ned till mindre aktiviteter innan de lades i aktuell sprint backlog.
För att hålla reda på alla aktiviteter samt för att enkelt kunna delegera aktiviteter till gruppens medlemmar använde vi oss av Trello. Vi använde ett Trello board för utveckling och ett för övrigt arbete som dokumentskrivning och diverse förstudiearbete. Våra listor på utvecklingstavlan var Product Backlog, Sprint Backlog, In Progress, In Review och Done. Under en utvecklingssprint flyttades sedan kort från Sprint Backlog till In Progress när arbete på aktiviteten inleddes. När arbetet ansågs färdigt lades kortet under In Review i väntan på att arbetet som gjorts granskats av en gruppmedlem som inte deltagit i arbetet med aktiviteten. När arbetet med aktiviteten sedan granskats och godkänts flyttades kortet till Done.
Vår metod för att granska kod var att utnyttja GitHubs Pull Requests. När en aktivitet anses slutförd görs en pull request vilket innebär att koden som skrivits kan granskas direkt via GitHubs webbgränssnitt. I samband med en pull request körs även skript som säkerställer att alla tester som finns passeras, vilket garanterar att regression i systemet undviks. Det innebär att tidigare testad och integrerad kod fortfarande fungerar som det är tänkt när nyutvecklad eller förändrad kod integreras. Verktyget som användes för att kontinuerligt integrera kod på detta sätt var Travis CI. För att underlätta och effektivisera arbetet med kodgranskning togs en mall fram för hur en pull request ska göras.
3.2
Metod för erfarenhetsfångst
Vi har jobbat väldigt mycket med att fånga erfarenheter under projektets gång. Detta gjordes för att det gynnar oss som individer i framtiden men också för att kontinuerligt förbättra gruppens förmåga att samarbeta för att producera en så bra produkt som möjligt. Då detta är viktigt i alla projekt och inte endast detta kandidatprojekt har vi nyttjat några etablerade metoder för att dels ge gruppens medlemmar en bra helhetsbild men även metoder för att garantera att vår arbetsmetodik är så bra som möjligt.
För att ge gruppens medlemmar en bra insyn i projektet som helhet använde vi oss av kodgranskning. I och med att granskning måste göras av någon som inte deltagit i arbetet med aktiviteten leder det till att man sprider kunskap om produkten som utvecklas, även om man inte deltar i utvecklingen av ett visst delsystem. Vi har även använt oss av Slack som kommunikationskanal. Slack bjuder in till spontana diskussioner där alla kan delta utan att maillistor eller liknande behöver användas. Detta medför att man enkelt kan ta upp problem som dyker upp under arbetets gång och tillsammans försöka lösa dem. När man löser ett
3.3. Versionshantering av källkod och dokument
problem så dokumenteras det automatiskt på ett lättillgängligt ställe vilket gör att alla enkelt kan ta del av erfarenheten.
Vi har även tillämpat några processer från IEEE Standard for Software Quality Assurance
Processes [43]. Dessa beskrivs i bilaga I. De vi har använt oss av är kopplade till att processer
som ska följas ska vara tydligt specificerade och beskrivna. I slutet av varje utvecklingssprint utvärderas processer och revideras vid behov. Allt detta arbete ska även dokumenteras i form av kvalitetsrapporter för att lärdomar ska kunna dras, dels under arbetets gång men även för framtida bruk.
3.3
Versionshantering av källkod och dokument
För att hantera all källkod och de dokument som producerats under projektets gång användes Git som verktyg för versionshantering. Den tjänst som nyttjades för att lagra alla filer var GitHub.
Arbetsflödet som användes för att utveckla produkten följde i stora drag arbetssättet Git-flow [44]. I vårt arbetssätt existerar en huvudgren, Master, vilken har en oändlig livstid och förväntas vara stabil. Från Master kan källkoden taggas med ett semantiskt versionsnummer när den uppnått ett tillstånd dugligt att släppas till kund. Själva utvecklingen sker i stödgrenar vilka förväntas raderas efter att de har integrerats med Master.
Stödgrenar kommer i två typer: Feature och Bugfix. I en Feature-gren sker utveckling av ny funktionalitet. När utvecklingen anses klar görs en Pull Request, varpå koden granskas och sedermera integreras till Master när den passerat granskning och regressionstestning. I en
Bugfix-gren löser man problem som upptäckts i den existerande kodbasen. En sådan gren bör
rimligtvis vara kopplad till en Issue, vilket är ett verktyg som GitHub tillhandahåller för att rapportera fel. För att förenkla arbetet med att rapportera fel togs det även fram en mall för hur en felrapport ska se ut.
3.4
Utvärdering av kravspecifikation ur ett hållbarhetsperspektiv
För att utvärdera våra icke-funktionella krav ur ett hållbarhetsperspektiv används ett ram-verk som beskrivs i ”Developing a Sustainability Non-functional Requirements Framework” av Raturi, Penzenstadler, Tomlinson och Richardson [45]. Varje icke-funktionellt krav i vår krav-specifikation ges dels en effektordning (tabell 3.1) och dels en hållbarhetsdimension (tabell 3.2). Detta görs enligt formatet som beskrivs i tabell 3.3.Tabell 3.1: Effektordningar och korta beskrivningar. Första ordningen indikerar direkta resultat av kravet.
Andra ordningen indikerar resultat av användning, indirekt av kravet. Tredje ordningen indikerar socioekonomiska påverkningar över lång tid.
Tabell 3.2: Hållbarhetsdimensioner och korta beskrivningar. Mänsklig hållbarhet berör mänskligt kapital som hälsa och utbildning. Social hållbarhet berör socialt kapital med fokus på samhällsaspekter. Ekonomisk hållbarhet berör ekonomiskt kapital.
Miljömässig hållbarhet berör miljömässigt kapital som bevaring av naturresurser och miljöskydd.
Teknisk hållbarhet berör vidareutveckling och underhåll av produkten.
Efter att varje krav tilldelats en beteckning studeras fördelningen för att undersöka om det finns några tydliga mönster i vilka effektordningar och hållbarhetsdimensioner som prioriterats.
3.4. Utvärdering av kravspecifikation ur ett hållbarhetsperspektiv
Tabell 3.3: Matris över hållbarhetsbeteckningar för krav.
Mänsklig Social Ekonomisk Miljömässig Teknisk
Första ordningen: 1-M 1-S 1-E 1-Mi 1-T
Andra ordningen: 2-M 2-S 2-E 2-Mi 2-T
4
Resultat
I detta kapitel presenteras resultaten som gruppen kom fram till.
4.1
Systembeskrivning
Det resulterande systemet består av två delar, som båda kan kommunicera med beställarens databaser. Det första systemet är en låsenhet som kan installeras vid ett gyms dörrar för att kontrollera ett magnetlås. Det andra systemet är en mobilapplikation som kan kommunicera med låsenheter i närheten.
Låsenheten
Låsenheten består av en Arduino Ethernet, vilket är en mikroprocessor med en inbyggd et-hernetmodul. Denna används för att kommunicera med beställarens API, för att enkelt kunna bestämma om en användare bör tillåtas åtkomst till en dörr. För att kunna kommunicera med mobiler i närheten används en Adafruit Bluefruit, en blåtandsmodul som krävs för blåtands-kommunikation. Låsenheten är även uppkopplad till det tidigare nämnda magnetlåset, som den ger ström till för att hålla dörren låst. En överblick över hur all hårdvara ser ut finns i figur 4.1.
Programkoden är skriven i C++. För att behålla funktionalitet, även då låsenheten inte har tillgång till beställarens API, har en cache implementerats. I denna cache sparas informa-tion om en användare har tillgång till dörren. Denna informainforma-tion kan sedan användas för att bestämma om dörren ska låsas upp för en användare, även om åtkomst till beställarens API saknas.
4.1. Systembeskrivning
Figur 4.1: En uppkopplad låsenhet.
Mobilapplikationen
Med mobilapplikationen kan en användare låsa upp dörrar kopplade till låsenheter i närheten, om åtkomst beviljas.
Innan mobilapplikationen kan användas måste ett gym-konto registreras på beställarens hemsida. Efter detta, och när mobilapplikationen startas för den första gången, kommer an-vändaren stöta på ett antal informationsskärmar, för att sedan kunna ta sig vidare till en inloggnings-skärm. Vid denna skärm behöver användaren välja det gym hen vill få åtkomst till, samt skriva in sina användaruppgifter. En skärmdump över denna inloggnings-skärm syns till vänster i figur 4.2. När användaren sedan har loggat in visas en lista över tillgängliga dör-rar, tillsammans med en knapp för att uppdatera listan, samt en knapp för att kunna logga ut. En skärmdump över denna lista syns till höger i figur 4.2. Om användaren väljer att klicka på en av dessa dörrar i listan kommer applikationen försöka kontakta låsenheten kopplad till den valda dörren. Om åtkomst beviljas kommer dörren låsas upp, samtidigt som ett dialogfönster bekräftar att dörren är upplåst. Om åtkomst inte beviljas meddelas användaren genom ett annat dialogfönster.
Applikationens mjukvara är skriven i Javascript, inuti ramverket React Native. Den finns tillgänglig till både Android och IOS.
4.1. Systembeskrivning
Figur 4.2: Skärmdump av mobilapplikationens inloggningsskärm tillsammans med skärmen över listan med dörrar.
Systemanatomi
I figur 4.3 beskrivs produkten ursprungliga systemanatomi som togs fram under förstudiefasen.
4.2. Erfarenheter intressanta för framtida projekt
Genom att jämföra denna systemanatomi med den slutgiltiga systembeskrivningen i kapitel 4.1 kan vi ser hur stor del av systemanatomin som realiserades i den överlämnade produkten. Vi kan se att alla komponenter implementerades på det sätt som de beskrivs i systemanatomin och med samma beroenden.
4.2
Erfarenheter intressanta för framtida projekt
I slutet av varje sprint har det genomförts en sprint retrospective där erfarenheter från den genomförda sprinten har dokumenterats. Dessa erfarenheter har till största del haft med olika utvecklingsprocesser att göra och dessa erfarenheter beskrivs under kapitel 4.5 nedan. De andra erfarenheter vi tar med oss till framtida projekt är att arbeta enligt de flesta av praxisarna som använts i detta projekt överlag har fungerat bra. Dessa praxisar inkluderar att arbeta i utvecklingssprintar, med fokus på en enkel design och enligt MVP [46].
Det är också bra att ha klara beskrivningar av processer som kan utvärderas och uppdateras under projektets gång. Om man arbetar enligt sprintar är det också bättre att lägga till lite för mycket i sprint backlogen, då detta säkrar att det alltid finns något för utvecklare att göra. Att estimera tiden en aktivitet skulle ta och multiplicera denna uppskattning med tre har fungerat bra under projekts gång, då detta gav en någorlunda verklig uppfattning av hur lång tid en aktivitet skulle ta.
4.3
Värde för beställare
Vår beställare kan erbjuda detta system till olika gym.
Gym kan med hjälp av produkten låta användare komma in utan att behöva dela ut fysiska taggar, samtidigt som kunder kan lätta på nyckelknippan. Om de kopplar sitt konto till applikationen då de blir medlemmar kan de komma in genom att bara klicka på dörren i en lista i applikationen. Gymmen kan administrera och bestämma öppettider via Gymsystems hemsida.
Sammantaget bedömer vi att dessa faktorer leder till en eftertraktad produkt. Förhopp-ningen är att vår beställare efter mindre vidareutveckling kan få ut produkten på marknaden och på så sätt öka sina intäkter.
Kravuppfyllande
Ett objektivt mått på värde för beställare är hur stor del av specificerade krav som uppfylls vid överlämning. Genom att verifiera funktionalitet med systemtester och relatera detta till de högst prioriterade kraven i den interna kravspecifikationen [47] ser vi att den överlämnade produkten uppfyller 32 av totalt 38 krav med prioritetsnivå ett (den högsta prioritetsnivån). Kravuppfyllandegraden är därmed 84%. Nedan följer en lista på kravnummer och tillhörande beskrivning för de krav som ej uppfylldes:
6. En administratör ska kunna öppna en dörr på håll.
11. En användare ska kunna ändra vilken mobil enhet som är associerad med deras konto. 28. Enheten ska bibehålla väsentlig funktionalitet vid tillfällig nätverksförlust.
29. Enheten ska kunna hålla dörren upplåst under vissa specificerade tider. 30. Enheten ska kunna hålla dörren låst under vissa specificerade tider.
4.4. Hårdvaruprototyper på Arduinoplattformen
4.4
Hårdvaruprototyper på Arduinoplattformen
Vår prototyp för låsenheten har utvecklats med hjälp av en Arduino Ethernet [48].
Vi kunde med hjälp av denna få en prototyp som till största del uppfyllde kravspecifi-kationen. Detta var dock inte helt utan problem, och kompromisser behövdes göras. Våra huvudproblem kan sammanfattas i tre punkter:
• Programminnet och dataminnet var mycket begränsat – i slutändan använde program-varan för låsenheten upp 98% av programminnet. Detta ledde till att vi behövde vara försiktiga i utvecklingen, det resulterade i ett antal underliga buggar, samt att vår cache inte kunde innehålla fler än en kund åt gången.
• Arduinon hade inte tillräckligt med processorkraft för att använda HTTPS, vilket kräv-des för att kommunicera med Gymsystems API. För att komma runt detta fick vi be vår beställare att sätta upp servrar med HTTP.
Av säkerhetsskäl är detta oönskat i en slutgiltig produkt, så det tvingar vår beställare att byta hårdvara om de ska kunna lansera produkten.
• Vi ville kunna bygga projekt mot Arduino utan ett kommersiellt IDE, mestadels så att vår beställare själva kan välja verktyg att vidareutveckla projektet med. För detta valde vi cmake [33], men det visade sig svårt att få det att fungera för alla. Det finns ingen officiell support för cmake, vilket leder till att man får använda program med bristfällig support.
Arduinoplattformen har också haft en rad fördelar.
• Enkel att utveckla för, med en rad lättanvända bibliotek. • Tillgång till elektroniskt IO.
• Inbyggt ethernet sparar jobb och omkostnader. • Den är billig.
4.5
Extreme programming utan tidigare erfarenhet
I utvecklingen av produkten så har gruppen använt sig av många av grundvärderingarna i
Extreme programming. Detta var något nytt för gruppens medlemmar.
Parprogrammering
Under projektets gång har gruppen använt sig av parprogrammering. Under sprintplanerings-möten har varje aktivitet tilldelats två utvecklare. Eftersom gruppen har bestått av sju med-lemmar har detta tyvärr varit svårt och många utvecklare har därför fått olika partners för olika aktiviteter. Dessa personer har sedan planerat in tid för att tillsammans jobba på ak-tiviteten. Att fullfölja dessa planer har för vissa utvecklare fungerat bra, medan andra har haft problem med detta i praktiken. Eftersom många utvecklare har fått olika partners för olika aktiviteter har dessa drabbats av schemakrockar. Då en person haft flera aktiviteter som behöver utföras samtidigt har det blivit svårt att parprogrammera.
Testdriven utveckling
Vi har i projektet använt Google Test för att bedriva enhetstestning på låsenheten, vårt inbygg-da system. För enhetstester för mobilapplikationen började vi använinbygg-da testramverket Mocha med biblioteken Chai, Sinon och Enzyme. Detta byttes senare ut mot testramverket Jest.
4.6. Utvärdering av kravspecifikation ur ett hållbarhetsperspektiv
Eftersom tester har skrivits innan implementation har många utvecklare känt sig säkra på sin kod samtidigt som ingen annan funktionalitet har lagts till förutom den som krävs för att klara testerna. För det mesta har denna utvecklingsmetod hållits. Till en början var det svårt att fullfölja testdriven utveckling fullt ut [46], då erfarenheten att skriva tester var väldigt låg. Detta ledde till att vissa komponenter först behövde implementeras för att undersöka om testerna var korrekt skrivna. Mot slutet av utvecklingsperioden var detta inte ett lika stort bekymmer och metoden var enklare att följa.
Kontinuerlig integration
För att säkerställa kvaliteten på produkten har kontinuerlig integration använts under ut-vecklingsperioden. Användningen av Travis CI har bidragit till förbättrad kod och enklare kodgranskningar [46]. Många utvecklare har känt sig säkra på att kod som godkänns av Travis CI fungerat som planerat och därmed kunnat integreras på ett korrekt sätt. Mindre problem med verktyget har uppstått. Bland annat använde sig Travis CI från början inte av en kom-pilator som stöder C++ version 11 vilket ledde till att den inte godkände viss korrekt skriven kod. Verktyget hade i vissa fall problem med att installera nödvändiga kodbibliotek. Utöver detta tog det även lång tid för Travis CI att godkänna kod, vilket ledde till att utvecklare ibland fick vänta en stund innan koden kunde integreras. Med det sagt, anser vi att Travis CI varit till stor hjälp under projektets gång.
Fokus på kodstandard
Gruppen har under utvecklingsperioden strävat efter att följa de kodstandarder som bestämts i arkitekturdokumentet [49]. Detta har lett till att vi inte haft några större konflikter mellan olika utvecklares bidrag. Här har kodgranskningar varit till stor hjälp. Innan kod integrerats har andra gruppmedlemmar som inte utvecklat koden fått möjligheten att läsa igenom och begära ändringar. Därför har eventuella konflikter åtgärdats innan koden integreras.
4.6
Utvärdering av kravspecifikation ur ett hållbarhetsperspektiv
De icke-funktionella kraven i kravspecifikation gavs beteckningar som specificerat i kapitel 3.4. Dessa beteckningar presenteras i tabell 4.1.Tabell 4.1: Icke-funktionella krav med hållbarhetsbeteckningar Nr Beteckning Kravbeskrivning
3 2-E En erfaren användare som är medlem ska kunna öppna dörren med applikationen på mindre än 20 sekunder då hen är nära dörren. 25 2-E Låssystemets mjukvara ska levereras som proprietär mjukvara. 26 1-M Låssystemet ska fungera i miljöer med temperaturer på intervallet
−20 grader celsius till+40 grader celsius.
27 1-M Enhetens hårdvara ska ska uppfylla IP54W (se [50]).
43 2-E Applikationen ska vara kompatibel med minst 80% av alla Android-enheter [51].
44 2-E Applikationen ska vara kompatibel med minst 80% av alla iOS-enheter [52].
46 2-E En erfaren användare som är medlem ska kunna öppna dörren med applikationen på mindre än 5 interaktionssteg då hen är nära dörren.
47 2-E Applikationen ska levereras som proprietär mjukvara. 55 1-E Gruppen ska arbeta 400 timmar per person.
5
Diskussion
I detta kapitel diskuteras de resultat vi har funnit under projektets utförande och litteratur-studie, de metoder vi har använt under arbetets gång samt hur resultaten samlades in. Vidare diskuteras projektet och produkten i ett vidare sammanhang där olika aspekter gällande håll-bar utveckling, etik och samhälle granskas.
5.1
Resultat
I detta kapitel diskuteras rapportens resultat och hur dessa kan relateras till frågeställningarna i kapitel 1.3.
Värde för beställare
I kapitel 1.3 beskrivs de frågeställningar som denna rapport ämnar besvara. För den första frågeställningen krävs ett mer specifikt mått på hur värde för kunden kan definieras. Utvärde-ringen av denna frågeställning kommer därmed utgå från följande mått på värde för kunden som ämnar ge en god helhetsbild över hur mycket som har levererats och hur mycket arbete som återstår för kunden:
• I hur stor utsträckning uppnåddes överenskommen kravspecifikation? • Hur utbyggbar är produkten för vidare utveckling?
• Hur mycket vidareutveckling krävs för att produkten ska nå ett leveransklart skick? Genom att applicera dessa mått på projektet bör vi få en god uppfattning om huruvida pro-dukten levererar värde till kunden. Först och främst utgår utvärderingen från kravuppfyllande. I kapitel 4.3 ser vi att vid tidpunkten då produkten lämnades över till kund uppfylldes 32 av totalt 38 krav med den högsta prioritetsnivån. För att leverera så mycket värde till kunden som möjligt bör självklart alla krav som beställaren och arbetsgruppen kom överens om vara uppfyllda. I fallet med detta projekt kan vi för merparten av icke-uppfyllda krav se att anled-ningen till detta är förväntningar på externa system (såsom Gymsystems API) och hårdvara (i synnerhet prestanda) som visade sig vara felaktiga.
5.1. Resultat
Vidare kan vi se att utbyggbarheten för produkten är god, enligt analysen av denna som beskrivs i bilaga B.
Slutligen bör ett mått på hur mycket arbete som återstår innan produkten kan levereras diskuteras. Det är arbetsgruppens gemensamma utlåtande att följande punkter bör åtgärdas av beställare innan produkten kan anses vara leveransklar:
• Byta till lämplig hårdvaruplattform som stödjer SSL. • Förbättra implementation av cache.
• Designa om UI-element så att dessa följer Gymsystems grafiska profil. • Producera installationsmanual för kommersiell installation av låsenhet. • Producera kretskort lämpliga för fast installation.
• Utveckla stöd för RFID-läsare.
Erfarenheter intressanta för framtida projekt
Anledningen till att det fungerar så bra med utvecklingssprintar är enligt oss att man kan bryta ner projektet i mindre delar som blir mer lätthanterliga och överskådliga [46]. Utveck-lingssprintar ger också möjlighet att sätta upp delmål under projektets gång som är enklare att uppnå än hela projektets övergripande mål.
Vi har också upptäckt att det tar mer tid än förväntat att sätta upp och lära sig att använda nya verktyg, vilket kan påverka val av verktyg och i synnerhet beslut gällande introduktion av nya verktyg under ett projekt. Anledningen till detta är främst bristande eller otydlig dokumentation och liknande resurser, vilket leder till en lång inlärningsperiod.
Vidare motverkades interna konflikter av att sätta upp tydliga beskrivningar av de olika processerna. Detta gjorde det enkelt att hänvisa till dessa beskrivningar om någon gruppmed-lem var osäker på hur en process var definierad.
Det fungerade bra att multiplicera vår tidsuppskattning med tre för att få en mer realistisk uppskattning, då vi ofta var optimistiska i våra tidsuppskattningar. Detta innebär dock inte att en sådan vana bör rekommenderas inför framtida projekt. Snarare visar faktumet att de tidsuppskattningar som multiplicerades med tre var mer träffsäkra på att gruppen hade svårt för att göra korrekta tidsuppskattningar. En intressant erfarenhet att ta med sig till framtida projekt bör då vara att aktiviteter kan vara svåra att tidsbedöma, men att de ofta tar mer tid än planerat. Inför framtida projekt bör man därför inte förlita sig på knep såsom att multiplicera tidsuppskattningen med tre, utan istället vara mer realistisk i sin ursprungliga tidsbedömning.
Stöd av systemanatomi
Den tredje frågeställningen gäller vilket stöd en systemanatomi kan ge då man utformar denna och sedan följer upp. I kapitel 4.1 beskrivs systemet och den ursprungliga systemanatomin. Vi kan se att systemanatomin implementerades utan några förändringar, vilket tyder på att vår uppfattning om produktens omfattning var god under förstudiefasen. Systemanatomin var också till god hjälp för att formulera aktiviteter och beroenden mellan dessa, då den ger en konkret bild över hur olika komponenter är sammankopplade.
Hårdvaruprototyper på Arduinoplattformen
Den fjärde frågeställningen gäller hur Arduinoplattformen kan användas för snabb utveckling av hårdvaruprototyper. Vi kan konstatera att Arduino är en fullvärdig dator, i betydelsen att det är en programmerbar maskin. Den har dock en låg minnes- och beräkningskapacitet jämfört med vanliga processorer i exempelvis mobila enheter och persondatorer. En Arduino
5.1. Resultat
kan utföra godtyckliga beräkningar samtidigt som den kommunicerar med utomstående system via dess in- och utmatningskretsar. Detta är naturligtvis en kraftfull kombination.
Plattformen kan alltså användas till allt en fullvärdig dator används till och dess hårdvaru-begränsningar tillåter. Frågan bör istället kanske vara vad plattformen lämpar sig till. Detta då varje alternativ har en rad konkurrenter; det går alltid att hitta någonting som utför en viss uppgift bättre än något annat.
Arduinoplattformen har ett antal fördelar gällande utveckling av hårdvaruprototyper. Vi kan av erfarenhet från projektet konstatera att:
• Den är billig [53]. Ett argument mot Arduinoplattformen är dock att priset är nästan detsamma som för Raspberry Pi, en konkurrerande plattform med kraftfullare hårdvara. • Den saknar operativsystem. Detta kan i vissa fall vara något negativt, men för hårdvaru-prototyper så kan det vara mycket gynnsamt att få större kontroll över enhetens resurser. Det blir dessutom lättare att byta till en annan AVR då produkten ska lanseras. • Det finns gott stöd för externa mjukvarubibliotek och hårdvarumoduler (så kallade
Shi-elds).
• Den stödjer både digital och analog I/O-funktionalitet.
• Vissa modeller av Arduino erbjuder ytterligare inbyggd funktionalitet. Exempel på sådan funktionalitet är nätverkskontroller och blåtandsmodul.
Plattformen har dock följande brister:
• Programminnet och dataminnet är mycket begränsat, som omnämnt i kapitel 4.4. • Begränsad processorkraft. Detta gör exempelvis användning av HTTPS praktiskt taget
omöjligt.
• Dåligt officiellt stöd för att bygga via kommandoraden. Till exempel finns det inget officiellt stöd för Cmake, vilket var jobbigt för arbetsgruppen under projektet, då det var det verktyget som valdes för utveckling till låsenheten.
• Stödjer officiellt endast en dialekt av C++.
De positiva punkterna pekar på att plattformen kan vara mycket användbar för generella, hårdvarunära ändamål. Biblioteksstöd och inbyggt gränssnitt till digitala kretsar är mycket användbart vid denna sort av prototypning. Faktumet att det finns tillgängligt utan krav på ytterligare moduler gör utvecklingen effektivare.
Speciell hänsyn måste dock tas gentemot kraven som sätts på minneskapacitet och proces-sorkraft. Om man lyckas försäkra sig om att plattformen klarar av den tänka uppgiften kan den visa sig mycket lämplig. I projektet misslyckades gruppen med att ta hänsyn till begräns-ningarna angående processorkraft, vilket bidrog till problemen gällande kravuppfyllande som beskrivs i kapitel 5.1.
Utvärdering av kravspecifikation ur ett hållbarhetsperspektiv
Resultatet i tabell 4.1 visar på en väldigt skev fördelning, inte bara i form av effektordningar utan även i hållbarhetsdimensioner. Nästan samtliga krav tillhör den ekonomiska dimensionen med ett fåtal undantag som tillhör den mänskliga. Inga krav tillhörde de miljömässiga, sociala, eller tekniska dimensionerna. Vidare tillhör majoriteten av kraven den andra effektordningen. Endast ett fåtal tillhör den första medan inga tillhör den tredje.
Faktumet att distributionen av effektordningarna bara är över den första och andra ser vi inte som ett direkt problem eller något oväntat. Detta är förväntat eftersom produkten inte
5.2. Metod
förväntas ha en storskalig samhällspåverkan, dels för att systemet inte fyller en samhällskritisk funktion och dels för att den inte kommer bli en substantiell del av många människors liv.
Hållbarhetsdimensionerna är dock av större intresse. Att hållbarhetsdimensionerna var skevt fördelade mot det ekonomiska var förväntat då vi inte hade något explicit hållbar-hetsfokus då kravspecifikationen togs fram. Denna fördelning ser vi som naturlig då företag i allmänhets primära intresse är att öka sin vinst. För att få in de andra hållbarhetsdimen-sionerna behövs det någon form av yttre motivation då de dimenhållbarhetsdimen-sionerna inte omedelbart gynnar företaget. Att hållbarhetsmomenten gavs sent i kursen bidrog till att hållbarhetstän-ket i projektet var minimalt. Vi tror dock inte att fördelningen av hållbarhetsdimensionerna hade förändrats avsevärt om hållbarhet varit ett fokus i ett tidigt skede, på grund av projek-tets begränsade omfång. Det finns dock en aspekt som vi i efterhand hade sett över: valet av låsteknik. Det magnetlås som vi använder för tillfället kräver konstant strömtillförsel för att hålla låset stängt vilket resulterar i betydligt större effektåtgång jämfört med exempelvis ett mekaniskt lås. Ett medvetet val av ett mekaniskt lås hade kunnat klassificeras som ett 1-MI krav.
5.2
Metod
I detta kapitel diskuteras metoden som beskrivs i kapitel 3 och hur denna kunde gjorts an-norlunda.
Metod för erfarenhetsfångst
Att vi använde oss av kodgranskning för att ge gruppens medlemmar en bra helhetssyn på projektet verkade som en väldigt bra idé, men i och med att medlemmarna blev väldigt speci-aliserade på antingen Arduinoplattformen eller mobilapplikationen, var det i praktiken svårt för de som specialiserade sig på den ena delen att kodgranska kod från den andra. Detta då dessa oftast inte förstod vad koden skulle göra.
Slack fungerade överlag väldigt bra som kommunikationskanal. Genom att dela upp kon-versationer i många olika kanaler kan dessa konkon-versationer specialinriktas mer än i ett annat kommunikationsverktyg som inte har denna funktion. För att fånga upp erfarenheter fungerade Slack också utmärkt, då allt som skrivs sparas så att det kan läsas igenom senare.
Hårdvaruprototyper på Arduinoplattformen
Erfarenhet infångades genom att använda Arduino som plattform för projektets ”låsenhet”. På så sätt får man en praktisk och verklig bild av hur plattformen är att använda. Å andra sidan så får man ingenting att jämföra med, förutom gruppmedlemmarnas tidigare erfarenhet. Detta kan leda till att vissa för- eller nackdelar saknas eller överdrivs.
Man kunde ha försökt införskaffa praktisk erfarenhet av andra plattformar. Exempelvis skulle andra plattformar kunnat beställas in och utvecklats på under början av utvecklingspe-rioden. Därmed skulle projektgruppen fått en bättre förståelse för vilken plattform som lämpats sig bäst för projektet. Detta skulle dock innebära större kostnader för beställaren samt mycket nedlagd tid på utveckling för plattformar som sedan inte används till slutprodukten.
Utvärdering av kravspecifikation ur ett hållbarhetsperspektiv
Som frågeställningen gällande hållbarhet är formulerad ska våra krav klassificeras enligt någon form av hållbarhetsramverk. Det finns därmed två aspekter som är uppenbara att kritisera: valet av ramverk samt hur klassificeringen sker. Till en viss nivå är valet av ramverk inte spe-ciellt avgörande då det är spridningen av dimensionerna som är av intresse. Ramverket måste endast stödja ett tillräckligt stort antal ortogonala hållbarhetsdimensioner för att spridning
5.3. Arbetet i ett vidare sammanhang
ska vara möjligt. Klassificeringen är mer problematisk då den, av naturliga skäl, är högst sub-jektiv samt att vi är partiska i egenskap av att ha skrivit kravspecifikationen. Detta kunde ha minimerats genom att antingen låta en större grupp klassificera kraven, eller låta utomstående personer med större erfarenhet göra det.
5.3
Arbetet i ett vidare sammanhang
I detta kapitel diskuteras arbetet utifrån etiska, samhälleliga och miljömässiga perspektiv.
Samhälleliga och etiska aspekter
Förenklandet av gymmedlemskap uppmuntrar förhoppningsvis fler människor till träning och kan därmed i teorin på sikt bidra till en förbättrad folkhälsa. Faktumet att detta system tillåter gym att enklare ha inpassering vid icke-konventionella öppettider medför också att fler människor får möjlighet att ta del av träningslokaler.
Vidare har det faktum att ett magnetlås, snarare än ett mekaniskt, använts lett till att personer inte riskerar att bli inlåsta vid ett strömavbrott.
Vissa tekniska egenheter hos systemet är dock problematiska. Av naturen måste person-uppgifter behandlas då tillgång efterfrågas, och som systemet ser ut vid leverans till beställare så finns det säkerhetsproblem. Exempelvis är kommunikationen mellan låsenheten och Gym-systems servrar okrypterad, vilket kan leda till att obehöriga kan ta del av användares unika identifikationsnummer. Detta kan åtgärdas av beställaren, men möjlighet saknades innan över-lämning.
Miljöaspekter
Som det har diskuterats i kapitel 5.2 så låg inte fokus på miljöaspekter vid formulering av krav-specifikationen. Trots detta har systemet relativt låg miljöpåverkan. Ett eventuellt problem är att magnetlåset kräver en konstant strömförsörjning. Den enkortsdator som används för att styra låset kräver å andra sidan relativt lite ström jämfört med de fullfjädrade datorer som används av det system som i nuläget erbjuds av vår beställare. Det gamla systemet använder sig också av plasttaggar för att identifiera användare. I och med att detta beroende flyttas till användares mobiltelefoner minskar behovet av att producera plasttaggar.
6
Slutsatser
Denna rapports syfte var att beskriva den produkt som vi utvecklat, de erfarenheter vi har fått under projektets gång samt att svara på de frågeställningar som presenterades i kapitel 1.3. Detta kapitel avser att återkoppla främst till de frågeställningarna.
Hur kan en smart inpasseringslösning med mobilapplikation och
enkortsdator implementeras så att man skapar värde för kunden?
De slutsatser som kan dras utifrån diskussionen i kapitel 5.1 är att vår implementation skapade ett visst värde för kunden, även om det kunde varit större. Detta då om man utgår från de mått på värde för kunden som beskrivs under kapitel 5.1 finns det vissa förbättringsmöjligheter för vår implementation. Till exempel uppfylldes bara 32 av 38 krav i kravspecifikationen och det skulle naturligtvis ge ännu mer värde till kunden om alla 38 krav uppfylldes. Det fanns däremot en anledning till att de inte uppfylldes vilket beskrivs i kapitel 5.1.
Utbyggbarheten för produkten värderades däremot till att vara god vilket skapar stort värde för kunden. Det bedömdes däremot finnas flera punkter som behövde åtgärdas innan produkten anses leveransklar vilket drar ner värdet för kunden.
Vilka erfarenheter som kan vara intressanta för framtida projekt kan
dokumenteras från utvecklingen av den smarta inpasseringslösningen?
Inför framtida projekt rekommenderar vi varmt en agil utvecklingsmetod såsom Extreme
Pro-gramming. Vi har också dokumenterat följande erfarenheter som kan vara intressanta för
fram-tida projekt:
• Användandet av sprintar har en rad fördelar och är ett logiskt sätt att bryta ner mål. • Att sätta upp och lära sig nya verktyg kan ta mer tid än förväntat.
• Interna konflikter kan motverkas genom att sätta upp tydliga beskrivningar av de olika processerna.
• Att tidsuppskatta aktiviteter kan vara svårt, men ger en ungefärlig bild av hur lång tid en aktivitet kan ta.
Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?
Från diskussionen i kapitel 5.1 kan man dra slutsatsen att om man skapar en bra systemanato-mi kan det ge en god uppfattning av produktens omfattning. En systemanatosystemanato-mi kan också vara till stor hjälp vid aktivitetsformulering, som en systematisk metod för att ta fram samband mellan aktiviteter.
Hur kan Arduinoplattformen användas för snabb utveckling av
hårdvaruprototyper?
Arduinoplattformen har ett antal egenskaper som underlättar vid utveckling av hårdvarupro-totyper, vilka diskuteras i kapitel 5.1. Bland de främsta av dessa är plattformens låga kostnad och minimala konfigurationsbehov, mycket tack vare att plattformen inte kör ett traditionellt operativsystem. Plattformen har också bra stöd med officiella mjukvarubibliotek och sådana från tredje part. Vidare har plattformen också bra hårdvarustöd med en stor mängd hårdva-rumoduler som kan användas för att utöka plattformens användningsområden.
Plattformens främsta nackdel som diskuteras i kapitel 5.1 visade sig under detta projekt va-ra rena prestandabegränsningar. Sådana begränsningar måste övervägas noga innan ett beslut gällande plattformens lämplighet kan tas.
Sammantaget kan man dra slutsatsen att om plattformens prestandabegränsningar ej be-döms vara ett hinder, kan Arduinoplattformen vara en mycket kompetent plattform för varuprototyper främst tack vare dess låga kostnad, minimala inställningsbehov och goda hård-och mjukvarustöd.
Vilket stöd ger Extreme Programming för en projektgrupp utan
nämnvärd tidigare erfarenhet av denna utvecklingsmetodik?
Från resultatet i kapitel 4.5 kan slutsatsen dras att flera av värderingarna inom Extreme
Pro-gramming ger bra stöd för en projektgrupp. Testdriven utveckling har gjort att många
utveck-lare känt sig säkra på sin kod samtidigt som bara den nödvändiga funktionaliteten har imple-menterats. Kontinuerlig integration har bidragit till förbättrad kod och enklare kodgranskning. Fokus på kodstandard har bidragit till att minska konflikter mellan gruppmedlemmar. Par-programmering har däremot inte fungerat så bra i gruppen då den bestod av ett udda antal personer med olika scheman, vilket gjorde det svårt att skapa bra par.
Allt som allt har Extreme Programming gett bra stöd till projektgruppen även om den också har tagit viss tid att lära sig och sätta sig in i.
Vilken fördelning av hållbarhetsdimensioner fås i en kravspecifikation då
projektet saknar hållbarhetsfokus?
Så som skrivs i kapitel 5.1 visar resultatet på en väldigt skev fördelning av hållbarhetsdimensio-nerna i vår kravspecifikation. Fördelningen är kraftigt viktad mot första och andra ordningens ekonomiska krav. Ur detta kan det dras slutsatsen att det är viktigt att tänka på hållbarhets-aspekter redan när man formulerar kravspecifikationen då det inte tillkommer naturligt. Det krävs också någon form av yttre motivation för att få in de andra hållbarhetsdimensionerna då dessa inte omedelbart gynnar projektet.
A
Effekten från användning av
Google Test i testdriven
utveckling av Carl Folkesson
A.1
Inledning
Under projektets gång har arbetssättet testdriven utveckling använts. Detta innebär att tester som mjukvaran ska uppfylla skrivs innan den funktionella koden skrivs [54]. Denna kod ska sedan skrivas så enkelt som möjligt för att uppfylla dessa tester. Detta arbetssätt bidrar ofta till bättre skriven kod och i längden bättre testade program. För att skriva enhetstester för den så kallade låsenheten har testramverket Google Test använts. Denna del av rapporten kommer att handla om effekten och erfarenheterna från detta val och arbetet det ledde till.
Syfte
Syftet med denna studie är att undersöka hur effektivt det är att använda Google Test i testdriven utveckling, speciellt vid utveckling av inbyggda system. Den ska också undersöka hur lätt det är att lära sig och börja använda Google Test i testdriven utveckling.
Frågeställning
De frågor som behandlas i denna studie är:
1. Hur svårt är det att lära sig använda Google Test?
2. Hur användbart är Google Test vid testning av inbyggda system?
3. Vad har det för effekt att använda Google Test vid testdriven utveckling?
A.2
Bakgrund
I utveckling av låsenheten i projektet valde projektgruppen att använda sig av testdriven utveckling. Låsenheten bestämdes bestå av en enkortsdator av typen Arduino. Detta är en elektronikplattform med öppen källkod baserad på lättanvänd hårdvara och mjukvara [4]. Utveckling på Arduino-enheter sker i programmeringsspråket C++. För att kunna skriva tester behövdes ett testramverk användas. Detta valdes att bli Google Test.
Google Test är ett testramverk för enhetstestning av kod skriven i C++. Det är utvecklat av Google och används i många olika mjukvaruprojekt, så som Chromium-projekten [55]. Det kan
