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 systemanatomi 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 hård- 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?