Modernisering av ett 3D-scanningssystem - Simple...

Linköpings universitet | IDAKandidatuppsats, 15 hp | Datateknik/Mjukvaruteknik

Vårterminen 2016 | LIU-IDA/LITH-EX-G–16/039–SE

Modernisering av ett 3D-scanningssystem

Utmaningar och lärdomar av ett projekt

Felix Haavisto, Henrik Henriksson, Niklas Hätty, Johan Jansson, Fabian Petersen,David Pop, Viktor Ringdahl, Victor K. Sehlin, Sara Svensson

Handledare Lena BuffoniExaminator Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – un-der 25 år från publiceringsdatum under förutsättning att inga extraordinära om-ständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ic-kekommersiell forskning och för undervisning. Överföring av upphovsrätten viden senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten, sä-kerheten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsmani den omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förla-gets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possiblereplacement – for a period of 25 years starting from the date of publication barringexceptional circumstances.

The online availability of the document implies permanent permission foranyone to read, to download, or to print out single copies for his/hers own useand to use it unchanged for non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional upon the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to be mentionedwhen his/her work is accessed as described above and to be protected againstinfringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity, pleaserefer to its www home page: http://www.ep.liu.se/.

c©Felix Haavisto, Henrik Henriksson, Niklas Hätty, Johan Jansson, Fabian Petersen,David Pop, Viktor Ringdahl, Victor K. Sehlin, Sara Svensson

i

Till minne av

Victor Karlsson Sehlin

Sammanfattning

Ett styrsystem för 3D-scanning har moderniserats av en projektgrupp pånio personer. Under utvecklingsarbetet följdes en arbetsprocess som lik-nade vattenfallsmetoden. Arbetsprocessen fungerade bra, bland annat dåprojektgruppen utnyttjat både tidigare och nya erfarenheter för att för-bättra arbetssättet.

Systemet som utvecklades ersätter ett tidigare styrsystem baserat på Mat-lab, men behåller samma grundläggande uppsättning hårdvara. En av-ståndskamera, en linjärenhet och ett rotationsbord utgör grunden till sy-stemet. Med hjälp av denna hårdvara möjliggör systemet 3D-scanningarav mindre objekt. Styrsystemet är utvecklat med Python och ROS, RobotOperating System. Valet av ROS ledde till en komplex arkitektur på grundav skillnader i systemkrav hos ROS och hårdvarudrivrutiner. Utan dessasystemkrav tros ROS ha varit ett ypperligt val. Den utvecklade arkitek-turen jämförs med en alternativ hypotetisk arkitektur, vilken uppvisadelägre komplexitet och större portabilitet. Den är dock inte lika lättanvändtillsammans med andra ROS-system.

Under utvecklingsarbetet har modularitet, vidareutvecklingsbarhet ochrobusthet varit i fokus. Även om det fullständiga systemet inte är så ro-bust som önskats så anses de ingående modulerna uppvisa en önskadnivå av robusthet. Systemet uppvisar även en hög grad av modularitet.Den utförligt dokumenterade koden tillsammans med de väl separerademodulerna har lett till att systemet bör vara lätt att vidareutveckla.

Förord

Vi fick möjlighet att genomföra projektet tack vare Institutionen för System-teknik vid Linköpings universitet. Vi vill tacka Maria Magnusson ochAndreas Robinson för ett gott samarbete.

Vi vill rikta ett stort tack till vår handledare Lena Buffoni för hennes stödoch feedback under projektets gång.

Under arbetet gick vår vän Victor Karlsson Sehlin tragiskt bort. Vi ärdjupt tacksamma för allt engagemang från studenter, universitetet, frivil-liga skallgångssökare och myndigheter. Hans bidrag till både rapport ochprojekt har haft stor betydelse, varför Victor står som posthum författare.Våra tankar går till familjen.

vii

Innehåll

Innehåll ix

I Gemensam rapport 1

1 Inledning 31.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Teori 72.1 Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Designprinciper . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Metod 113.1 Erfarenhetsinsamling . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Metod för arkitektur . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Robusthetsanalys . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Resultat 134.1 Övergripande systembeskrivning . . . . . . . . . . . . . . . . 13

4.2 Värde för kunden . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3 Tekniska resultat . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4 Arkitekturförslag . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6 Gemensamma erfarenheter . . . . . . . . . . . . . . . . . . . 22

4.7 Områden med förbättringspotential . . . . . . . . . . . . . . 24

4.8 Processrelaterade resultat . . . . . . . . . . . . . . . . . . . . 25

ix

4.9 Robusthetsanalys . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.10 Översikt av de individuella bidragen . . . . . . . . . . . . . . 29

5 Diskussion 315.1 Arbetsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3 Arkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.4 Robusthet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.5 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.6 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . 37

6 Slutsatser 396.1 Tekniska resultat . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2 Gruppens arbete . . . . . . . . . . . . . . . . . . . . . . . . . 40

TestutvärderingFelix Haavisto 41

1 Inledning 411.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2 Teori 422.1 Slumptestning . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.2 Systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.3 Testprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3 Metod 43

4 Resultat 444.1 Testfall och genomförande . . . . . . . . . . . . . . . . . . . . 44

4.2 Buggar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3 Testernas påverkan . . . . . . . . . . . . . . . . . . . . . . . . 45

5 Diskussion 465.1 Testbrister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Förbättringsförslag . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Slutsatser 47

Konsistensanalys av dokumentkod och typografiHenrik Henriksson 49

1 Inledning 49

x

1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2 Teori 50

3 Metod 513.1 Analys av existerande källkod och dokument . . . . . . . . 51

3.2 Att undvika problem . . . . . . . . . . . . . . . . . . . . . . . 51

4 Resultat 514.1 Kod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 Typografi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5 Diskussion 555.1 Hur undviker man felen? . . . . . . . . . . . . . . . . . . . . 56

5.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6 Slutsatser 57

Återanvändning av delsystem vid rekonstruktionNiklas Hätty 59

1 Inledning 591.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

2 Teori 602.1 Avståndskameran SICK IVP RULER E2111 . . . . . . . . . . 60

2.2 Linjärenheten . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

2.3 Systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3 Metod 623.1 Metod för att bestämma begränsningar . . . . . . . . . . . . 62

3.2 Metod för att bestämma fördelar vid ombyggnation . . . . . 62

4 Resultat 634.1 Begränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2 Hypotetisk analys av ombyggnad . . . . . . . . . . . . . . . 63

5 Diskussion 64

6 Slutsatser 65

xi

En säkerhetsanalys av ett distribuerat systemJohan Jansson 67

1 Inledning 671.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

2 Teori 68

3 Metod 68

4 Resultat 68

5 Diskussion 695.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2 Projektplan och kund . . . . . . . . . . . . . . . . . . . . . . . 70

5.3 Public-key verification . . . . . . . . . . . . . . . . . . . . . . 70

5.4 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.5 Allmänt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Slutsatser 71

Svårigheter vid TidsplaneringFabian Petersen 73

1 Inledning 731.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

2 Teori 742.1 Planering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

2.2 Gruppdynamik . . . . . . . . . . . . . . . . . . . . . . . . . . 74

2.3 Tidsplaneringsmetoder . . . . . . . . . . . . . . . . . . . . . . 75

3 Metod 763.1 Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.2 Tidsplanering . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4 Resultat 774.1 Pokerplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.2 Top-down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5 Diskussion 78

6 Slutsatser 79

xii

Automatisering av systemtestningDavid Pop 81

1 Inledning 811.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

2 Teori 82

3 Metod 833.1 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.2 Systemtester . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4 Resultat 844.1 Testsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.2 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5 Diskussion 865.1 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.2 Automatiserade tester . . . . . . . . . . . . . . . . . . . . . . 87

6 Slutsatser 88

En metod för att modernisera gamla, utdaterade systemViktor Ringdahl 89

1 Inledning 891.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

2 Teori 90

3 Metod 91

4 Resultat 924.1 Tillvägagångssättet . . . . . . . . . . . . . . . . . . . . . . . . 92

4.2 Metoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5 Diskussion 94

6 Slutsatser 94

xiii

Grupprums påverkan på utvecklingsarbetet i en projektgruppSara Svensson 97

1 Inledning 971.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

2 Teori 982.1 Hemarbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

2.2 Satellitkontor . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

3 Metod 100

4 Resultat 1014.1 Arbetsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.2 Gruppdynamik . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.3 Effektivitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5 Diskussion 1045.1 Arbetsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.2 Gruppdynamik och effektivitet . . . . . . . . . . . . . . . . . 105

5.3 Undersökningens trovärdighet . . . . . . . . . . . . . . . . . 106

6 Slutsatser 106

Litteratur 109

A Intervjufrågor - Erfarenheter och arbetsmetodik 113A.1 Tidigare erfarenheter . . . . . . . . . . . . . . . . . . . . . . . 113

A.2 Arbetsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

B Intervjufrågor – testning 114B.1 Som testare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

B.2 Som utvecklare . . . . . . . . . . . . . . . . . . . . . . . . . . 114

B.3 Generellt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

C Intervjufrågor - Grupprums påverkan på utvecklingsarbetet ien projektgrupp 115

xiv

Del I

Gemensam rapport

1

Inledning

Denna kandidatrapport är framtagen i samband med ett projektarbete ikursen TDDD96, Kandidatprojekt i programvaruutveckling, vid Linköpingsuniversitet. I kursen har projektgruppen, bestående av nio personer, arbe-tat mot kund och därmed fått erfarenhet av att utföra ett projekt utifrånkundens önskemål och krav. Kunden till detta projekt har varit Institutio-nen för Systemteknik vid Linköpings universitet.

Projektgruppens uppgift i denna kurs har varit att modernisera ett styr-system för 3D-scanning bestående av ett rotationsbord, en linjärenhet ochen laserscanner. Styrsystemet var tidigare uppbyggt i Matlab, men gjordesunder projektets gång om så att det nu använder sig av Python och ROS,Robot Operating System [1]. I figur 1.1 visas en bild på systemet.

1.1 Syfte

Med denna rapport avses att undersöka den arbetsmetodik som använtsoch de tekniska resultat som erhållits i samband med genomförandet avett kandidatprojekt. Gruppens arbetssätt och möjliga förbättringar av det-ta är relevant inför framtida projekt, likaså en analys av det utveckladesystemet.

En beskrivning av det utvecklade systemet ska ge läsaren en bild av sy-stemets design, arkitektur och funktionalitet. Läsaren ska även få en bildav utvecklingsarbetet och projektgruppens erfarenheter kring detta.

1.2 Frågeställning

Det redan existerande systemet och kundens krav ledde till många be-gränsningar i arkitekturen för systemet. En av dessa begränsningar var

3

1. Inledning

Figur 1.1: Bild på systemet i dess helhet.

att systemet skulle använda sig av ROS. Hur hade arkitekturen skiljt sig frånden nuvarande arkitekturen om systemet byggts utan ROS?

I projektbeskrivningen innan projektets start var ett önskemål att det nyasystemet skulle hålla en högre nivå av robusthet. Hur välanpassat är syste-met för att hålla en hög nivå av robusthet?

Från början var avsikten att projektet skulle utföras agilt. Vad som fak-tiskt har gjorts bör undersökas. Hur har gruppen arbetat och hur kan dettaförbättras inför framtida projekt?

Gruppen gjorde i början av projektet en sammanställning av erfarenheterfrån tidigare projekt, där alla gruppmedlemmar fick dela med sig av braoch dåliga upplevelser. Hur har gruppens medlemmar använt sig av erfaren-heter från tidigare projekt?

1.3 Bakgrund

På Institutionen för systemteknik vid Linköpings universitet fanns behovav att modernisera ett system för 3D-scanning. Denna 3D-scanningsmetodbygger på att en linjelaser förflyttas över ett objekt under tiden som enkamera avläser avståndet. Den gamla implementationen använde sig avMatlab, version 2007a, på Windows XP, något som krävde modernisering.

Det tidigare systemet bestod av en kombinerad linjelaser och kamera, enlinjärenhet och ett rotationsbord. Dessa var anslutna direkt till en Win-dows XP-dator. Genom mjukvara skriven i Matlab kunde användare ge-nomföra 3D-scanningar och visualisera resultatet av dessa. Systemet var

4

1.3. Bakgrund

även svåranvänt, då det krävde att användare använde Matlabs komman-doprompt. Kunden önskade att mjukvarudelen implementerades om full-ständigt med hjälp av Python och ROS. Syftet med detta var att göra pro-dukten mer robust, lättare att använda och lättare att uppgradera.

5

2

Teori

Detta avsnitt är avsett till att ge den teoretiska bakgrund som krävs för attförstå resten av rapporten. Det redogörs för scanning, ROS och projektetsdesignprinciper.

2.1 Scanning

Ett objekt kan med systemet scannas fullständigt. Resultatet från en scan-ning presenteras sedan som ett punktmoln. När ett objekt scannas skerdet genom att avståndskameran börjar skicka mätdata samtidigt som lin-järenheten flyttar kameran i sidled. Varje mätning som avståndskamerangör skapar en profil. Punktmolnet byggs sedan av alla uppmätta profi-ler. Detta utgör en scanning från en specifik vinkel. För att sedan byggaupp en komplett 3D-scanning kan man rotera och vinkla objektet medrotationsbordet och utföra en till scanning, för att till sist sammanfogaflera punktmoln till ett komplett 3D-modell med någon form av featurematching.

2.2 ROS

ROS, eller Robot Operating System, är inte ett operativsystem i sig, utanen miljö som noder kan köra i. ROS underlättar kommunikationen mellannoder genom att det erbjuder ett standardiserat sätt för kommunikation.Dessa noder kan vara vilka program som helst som använder sig av bibli-oteken som ROS erbjuder. Genom att göra det, behöver programmen inteköras på samma fysiska enhet för att kunna kommunicera med varandra.

ROS erbjuder två olika sätt för noder att kommunicera med varandra. Detförsta är genom en namngiven informationskanal, en så kallad topic. Det

7

2. Teori

andra sättet är genom att en nod anropar funktionalitet i en annan nodgenom en så kallad service.

En topic är en kanal som har ett unikt namn inom systemet. Denna kanalkan bara en nod skicka data på, men flera noder kan lyssna på kanalenoch ta emot data som skickas på den. Data som skickas på kanaler ärstrikt och starkt typade. På en kanal kan meddelanden av endast en typskickas. På detta sätt är det en nod som agerar sändare och en eller fleraandra noder som lyssnar. Detta visas i figur 2.1.

ROS-nod Topic

ROS-nod ROS-nod ROS-nod

Figur 2.1: Exempel på hur en topic i ROS kan se ut.

Till skillnad från en topic följer en service liknande principer som ett van-ligt funktionsanrop. En nod i systemet kan anropa funktionalitet på enannan nod i systemet. Dessa tjänster är strikt typade. En service kommeratt returnera data som svar till anropet så snart det är tillgängligt. Ävensvaret är strikt typat. Då en nod anropar en tjänst på en annan nod kom-mer den anropande noden vänta tills tjänsten kört klart och returneratinnan körningen av den anropande noden fortsätter. Services illustreras ifigur 2.2.

ROS-nod ROS-nodROS-nod

ROS-nod

ServiceService

Service

Figur 2.2: Exempel på hur en service i ROS kan se ut.

Alla ROS-noder i ett nätverk har unika namn som används för identifika-

8

2.3. Designprinciper

tion. För att noderna ska kunna hitta varandra måste roscore vara igångpå en dator i samma nätverk. roscore är en server som noderna använ-der för att hitta varandra. ROS-programmen behöver därför inte kännatill varandra eller var alla andra noder finns i nätverket, utan de behöverbara känna till var denna server befinner sig. När en nod startas regi-streras denna hos roscore tillsammans med alla topics och services somnoden erbjuder. Alla andra program i nätverket kan sedan utnyttja des-sa. Kommunikationen mellan noder sker dock inte igenom roscore utandata skickas direkt mellan dem. Detta visas i figur 2.3.

Roscore

ROS-nod ROS-nod

Registrering R

egistrering

Kommunikation

Figur 2.3: Diagram över relationen mellan noder och roscore.

2.3 Designprinciper

Det finns ett antal principer som har styrt hur produkten har designatsoch utvecklats. Här ges en kort teoretisk bakgrund till vad dessa betyder.

Modularitet är en designprincip som har tagits hänsyn till igenom alla fa-ser i projektet, från design till implementation och testning. Modularitetdefinieras som graden till vilken ett program är indelat i flera diskretamoduler så att en ändring i den ena har minimal påverkan i dem and-ra [2]. Detta medför att en del i systemet kan bytas ut mot en annan medminimala ändringar i resten av systemet.

Robusthet är en egenskap som kunden tidigt önskade att systemet skulleuppvisa. Denna betyder graden till vilken programmet kan fungera rättäven då fel inmatningar eller påfrestande externa förutsättningar inträf-far [2].

Produkten var avsedd att styra en viss specifik uppsättning av hårdvaru-delar. Därför var produkten beroende av dessa unika enheter och design-arbetet styrdes väldigt mycket av detta beroende.

9

2. Teori

Lager-designmönstret är en designprincip enligt vilken funktionaliteten iett program delas upp i olika abstraktionsnivåer eller så kallade lager.Det har bestämts att utveckla produkten på ett sådant sätt för att det gördet lättare för programmet att designas, implementeras och testas på detsättet.

Klient-server är ett designmönster som betyder att ett program delas i oli-ka delar där några delar agerar som servrar och några delar agerar somklienter. Det har bestämts att utveckla produkten enligt denna princip ef-tersom den passade väldigt bra till det faktiska projektet som skulle beståav ett distribuerat system.

2.4 Trello

Trello [3] är en virtuell Kanban-tavla [4] som används för att ge geogra-fiskt spridda arbetsgrupper möjlighet att övervaka projektets utvecklings-process. Tavlan delas in i kolumner med rubrikerna att göra, utförs, redo atttestas och klart.

10

3

Metod

Materialet i rapporten kommer i första hand från gruppmedlemmarnasegna erfarenheter under projektet. Insamling av resultat kring erfarenhe-ter och arbetsprocesser har skett genom en intervjustudie, medan det förrobusthets- och arkitekturanalyser har genomförts experiment.

3.1 Erfarenhetsinsamling

För att samla in och behandla gruppmedlemmarnas erfarenheter från pro-jektet utfördes en intervjustudie och ett gruppmöte. Målet med dessa varbåde att ta fram resultat för projektets arbetsmetodik och gruppmedlem-marnas tidigare erfarenheter. Hur dessa erfarenheter har använts var ock-så av intresse.

Två gruppmedlemmar tog fram frågor och genomförde tillsammans inter-vjuer på de andra gruppmedlemmarna enskilt. Frågorna var uppdelade itvå teman, tidigare erfarenheter och arbetsmetodik. För framställning av frå-gor och genomförande följdes en introduktion för nybörjare [5] i hur mangenomför intervjuer. De frågor som ställdes kan ses i appendix A. De tvåpersoner som genomförde intervjustudien blev var för sig intervjuade avtvå andra gruppmedlemmar.

Gruppen höll därefter ett möte för att gå igenom resultatet från inter-vjustudien i syfte att vidareutveckla och diskutera detta. Under mötetvar alla medlemmar närvarande. De två intervjuledarna antecknade un-der mötet. En fri diskussion kring en sammanställning av intervjuernahölls. De resultat som presenteras i denna rapport kommer både från in-tervjustudien och detta möte.

11

3. Metod

3.2 Metod för arkitektur

För att jämföra det utvecklade systemet med ett hypotetiskt system utanROS beskrevs först det nuvarande systemet i en systembeskrivning, var-vid ett förslag på en alternativ arkitektur lades fram. Dessa jämförs sedani diskussionsdelen.

För att få en funktionellt liknande arkitektur ställdes några krav på arki-tekturförslaget:

• Det kompletta systemet ska exponeras genom ett enhetligt python-bibliotek.

• All kommunikation med hårdvara ska kunna ske över nätverk.

• Systemet ska ha en generell server som klienten använder över nät-verk.

En uppskattning av tidsåtgång och rimlighet gjordes genom att skapaen prototyp med en del av den funktionalitet denna annars hypotetiskaarkitektur har.

3.3 Robusthetsanalys

Systemet analyserades och utvärderades för att undersöka till vilken graddet kunde anses som robust. Varje del i systemet har gått igenom testerför att säkerhetsställa att delen fungerar enligt en intern kravspecifikation.För att analysera robustheten gjordes en teoretisk analys av det som inteomfattas av dessa tester.

Fortsättningsvis gjordes ett mindre experiment där ett antal fel simulera-des genom att aktivt få en del av systemet att fungera felaktigt genom attframkalla undantag, exceptions, i koden och observera hur systemet hante-rade felet. Experimentet utfördes på tre av systemets delar, linjärenheten,avståndskameran samt nätverkskommunikationen mellan dator med Li-nux och Windows XP. I samtliga fall placerades felet i för en scanningkritiska delar av koden som betydde att en scanning på något sätt inteblev komplett.

12

4

Resultat

I detta avsnitt presenteras resultatet av de undersökningar och den ana-lys som gjordes för rapporten. Det utvecklade systemet beskrivs, likasåen alternativ hypotetisk arkitektur. Ytterligare redogörs för gruppens er-farenheter under projektet relaterat till bland annat arbetsprocess och ar-betsmetodik.

4.1 Övergripande systembeskrivning

Det utvecklade systemet består av sju olika klart separerade moduler ochhårdvaruenheter. För att styra hårdvaruenheterna har ett Python-bibliotektagits fram för var och en av dem. Den hårdvara som används i systemetär en linjärenhet, en avståndskamera och ett rotationsbord.

För två av hårdvaruenheterna finns endast drivrutiner för Windows, me-dan ROS enbart har stöd för Linux. Systemet är därför distribuerat överminst två datorer med olika operrativsystem. De pythonbibliotek som styr

Hårdvarusystem

Kamera

Linjärenhet

Bord

Nätverkskommunikation

ROS-styrnodROSkommunikation

ROS-klientROS-klientROS-klient

Figur 4.1: Översikt av systemet.

13

4. Resultat

Figur 4.2: En inscannad leksakspolisbil. Bilden är efterbehandlad.

hårdvaruenheter används genom ett bibliotek för nätverkskommunika-tion som utvecklades under projektet.

En ROS-baserad styrnod ansvarar för att koordinera hela systemet och ex-ponera relevanta delar genom ett ROS-API. Till denna styrnod kan ROS-noder ansluta för att utnyttja systemet. För produkten har ett kommando-radsgränsnitt, CLI, utvecklats. Gränssnittet tolkar användarens komman-don och meddelar styrnoden att utföra dem. För kommunikation mellanCLI och styrnod används ROS. Figur 4.1 innehåller översiktlig illustrationöver systemets arkitektur.

4.2 Värde för kunden

Det moderniserade systemet har stora fördelar jämfört med sin föregång-are. Enligt kundens önskemål lades stort fokus på att göra systemet ro-bust, modulärt och för att underlätta framtida utvecklingar. Samtidigt harfunktionaliteten från den föregående systemet behållits, och i vissa fallförbättrats. Mer konkret har samtliga hårdvarukomponenter en extra ab-straktion för att systemet ska bli mer modulärt, vilket får effekten att detendast behövs skrivas om kod på ett ställe om en komponent byts ut. Fort-sättningsvis öppnar användandet av CLI upp för stora möjligheter till attsjälv styra systemet med diverse skript, vilket underlättar vid fullständiga3D-scanningar. Exempel på scanningsresultat visas i figur 4.2 och 4.3.

Arkitekturen i projektet byggde på ROS, vilket har en del fördelar somförbättrar utvecklingsmöjligheten. ROS främsta styrka är att det lätt kanläggas till fler noder, vilket kan vara användbart i systemet. Exempelviskan en ny hårdvaruenhet läggas till och styras med hjälp av ROS. ROS

14

4.3. Tekniska resultat

Figur 4.3: Ett inscannat leksaksflygplan. Bilden är efterbehandlad.

gör det även betydligt enklare att möjliggöra användandet av flera klientersamtidigt.

Slutligen har omfattande dokumentation av systemet skapats, vilket in-te existerade tidigare. I urval har arkitekturbeskrivning, användarmanualoch teknisk dokumentation skapats.

4.3 Tekniska resultat

Systemet är modulärt uppbyggt. Här redogörs de olika resultaten för mo-dulerna. Både resultat för de olika hårdvaruenheterna men även för demellanliggande lagren från hårdvara till användagränssnitt.

4.3.1 ROS-styrnod

ROS-styrnoden är, som namnet antyder, en ROS-nod som agerar länk mel-lan klienterna och hårdvaran. Denna nod är unik i systemet, till skillnadfrån klientnoderna som kan vara flera. Styrnoden skickar data till klien-terna både genom meddelanden i form av topics och genom svar till ser-vices. I motsatt riktning kommunicerar styrnoden med hårdvaran genomatt ifrån ett nätverkslager anropa funktioner i respektive hårdvaruenhet.

Styrnoden skriver data till flera kanaler:

• debug, en kanal för felsökningsdata.

• points, en kanal som används för att skicka punktmolnet från enscanning.

15

4. Resultat

• started, en kanal som används för att meddela att en scanning harstartat.

• done, en kanal som används för att meddela att en scanning är klar.

Noden erbjuder även klienterna services:

• scan, en service för att utföra en scanning. Returnerar en flagga somsäger om scanningen har startat.

• set, en service för att sätta en inställning till ett visst värde. Retur-nerar ifall det gick att ändra inställningen.

• get, en service för att hämta det aktuella värdet av en inställning.

• reset, en service för att ställa hårdvaruenheterna till standardin-ställningar.

För att kommunicera med hårdvaran använder noden sig av tre olika nät-verksobjekt, ett för varje enhet. Vad dessa objekt har för funktioner finnsdefinierat i en konfigurationsfil för respektive hårdvaruenhet. Var dessakonfigurationsfiler finns samt vad de olika funktionerna heter finns de-finierat i en gemensam konfigurationsfil. När styrnoden startas, skaparden ett objekt för varje enhet. Den laddar in den gemensamma konfi-gurationsfilen och sedan de andra filerna för hårdvaruenheterna. Sedanförsöker noden att med hjälp av objekten ansluta sig, genom nätverket,till de olika enheterna. Efter det är noden klar att ta emot kommandonfrån klienterna.

Kommandon från klienterna kommer i form av anrop av services. Bero-ende på vilket kommando tas emot, kommer styrnoden att anropa rättfunktioner i de olika enheterna för att utföra det. Svar skickas tillbakadirekt genom en service returvärde och mer data kan eventuellt skickasgenom meddelanden som skickas på informationskanaler.

ROS-styrnoden bör köras under all användning för att systemet ska fun-gera. Klienter kan då ansluta sig till den och använda sigaav systemet.

4.3.2 Klient

För att styra systemet byggdes ett kommandoradsgränsnitt, CLI för attkommunicera med resten av arkitekturen. Kommandoradsgränsnittet ärkopplat till kontrollnoden genom ROS, som beskrivs mer ingående i av-snitt 2.2. Kommandoradsgränsnittet tolkar användarens argument till kom-mandon som vidarebefordras till styrnoden. Kommandoradsgränsittet ärbyggt i Python med hjälp av biblioteket click [6].

Kommandon ges på formen

16

4.3. Tekniska resultat

treed <kommando > [valfri lista av <flaggor > och <värden >]

<kommando> motsvarar ett kommando, exempelvis scan. Efter komman-dot kan det förekomma ett godtyckligt antal flaggor och parametrar i en-lighet med standardformatet i GNU/Linux [7]. För att göra systemet merlättanvänt för slutanvändaren finns till alla kommandon hjälpflaggan -heller --̇help.

4.3.3 Nätverkskommunikation

De krav kunden hade på tekniker, främst ROS, skapade ett behov av tvådatorer för att förverkliga systemet, en dator med Linux som kör en ROS-nod och linjärenheten samt en Windows-dator som kör rotationsbordetoch den avståndskamera som utnyttjas. En nätverksbaserad lösning val-des för att sköta kommunikationen mellan de två datorerna då det är ettgenerellt och vida tillgängligt sätt att skicka data i höga hastigheter mellandatorer och fungerar oberoende av operativsystem.

Kunden uttryckte att en uppgradering av systemet till nyare hårdvaruen-heter kan vara aktuellt inom snar framtid, något som gjorde att mycketenergi lades på att göra nätverkskommunikationsdelen så modulär sommöjligt, det vill säga få den att fungera med olika hårdvaruenheter obe-roende av enhetens funktionalitet. Systemet måste givetvis ändras om enhelt ny enhet introduceras, men endast på ett eller ett fåtal ställen.

Övergripande utformning Nätverkskommunikationsdelen är utformadsom ett server/klient system där hårdvaruenheten agerar server för klien-ten, alltså ROS-styrnoden på Linux-datorn. För att utföra nätverksanropenoch få ett asynkront beteende utnyttjas det inbyggda Python-biblioteketasyncio. Valet av asyncio istället för en trådbaserad lösning gjordes dels pågrund av en önskan att testa nya tekniker och dels en ovisshet kring hurtrådsäkert ROS är. Ett antal synkroniseringsproblem skulle kunna uppstånär flera trådar vill ändra delad data.

Både klient och server ärver den Protocol-klass som ingår i asyncio, dessainstansieras sedan i enheterna som utnyttjar dem. Varje klient-serverparanvänder varsin anslutning. Körs flera enheter instansieras flera objekt.

Nätverkets server — Hårdvaruenheterna Denna del ansvarar för att kö-ra de funktioner som en specifik hårdvarukomponent tillhandahåller. Närett meddelande inkommer från en klient tolkas det och verifieras. Vilkameddelanden som är giltiga och vad för funktion som ska exekveras be-stäms av en fil med inställningar.

Godkänns meddelandet som inkommit påbörjas exekveringen som ut-förs asykront så att eventuellt nya meddelanden som inkommer också

17

4. Resultat

behandlas. Argument till funktionerna hämtas ifrån meddelandet sominkommit. När exekveringen av en funktion är slutförd kontrolleras re-sultatet. Är resultatet ett undantag, exception, anses funktionsanropet va-ra misslyckat och information om detta skickas tillbaka till ROS med etterror-meddelande. Annars skickas resultatet tillbaka med ett success-meddelande. Meddelandet debug kan skickas när som helst och innehållerdebugdata, antingen som information, varningar eller fel. Ett meddelandeutgörs av ett pickle-objekt som mottags och sedan tolkas.

Nätverkets klient — ROS-Styrnoden Den andra delen i nätverkskom-munikationen är ROS-styrnoden. Denna skickar de meddelanden somservern sedan tolkar och utför. När en klient instansieras registreras defunktioner som anges i inställningsfilen. När dessa körs genereras ettmeddelande som skickas till servern. Alla argument som inte är namn-givna skickas med den funktion som genererat meddelandet till servern.

Serverns svar kontrolleras. Om det var ett success-meddelande exekverasen valfri callback och nästa uppköade meddelande om ett sådant finns.Inkom istället ett error-meddelande körs en felfunktion. Om ett debug-meddelande inkom körs en loggningsfunktion. Dessa funktioner angesnär en server instansieras.

4.3.4 Kamera

Avståndskameran fungerar genom att en linjelaser projiceras på det objektsom ska scannas. Kameran mäter sedan avståndet till linjelasern och tarreda på intensiteten i träffpunkten.

Kameran styrs med hjälp av ett pythonbibliotek, skrivet som en wrapperkring kamerans bibliotek. För att kunna använda kamerans bibliotek, skri-vet i C, användes pythonbiblioteket ctypes som tillåter att man anroparC-funktioner från Python och även hjälper utvecklaren att hantera de da-tatyper som förekommer i C.

När en scanning sker så läses ett visst antal profiler beroende på hur längeman scannar. Dessa profiler delas in i buffertar, varje sådan buffert kansedan hämtas när de är fyllda. En inläst linje av punkter kallas för profil.Den data som fås för varje punkt är 3D-koordinater och intensitet.

4.3.5 Linjärenhet

Linjärenheten används för att förflytta linjelasern över det objekt som skascannas. Den linjärenhet som användes var en Origa System Plus, driven avett servo från Technosoft. Ett pythonbibliotek har under projektet utvecklatsför att styra detta servo.

18

4.4. Arkitekturförslag

Figur 4.4: Schematisk bild över linjärenhetens rörelse.

Den kontroller som styr servot tar emot assemblyprogram över en seriellka-bel och exekverar dessa. På så sätt kan man styra servot. Kontrollern äravancerad och endast en bråkdel av dess funktioner används. Vid använd-ning skickar Python-biblioteket ett assemblyprogram för att köra servot ien trapezoidrörelse enligt figur 4.4. Biblioteket tillåter användaren att stäl-la in position, hastighet och acceleration.

För att bibliotekets användare ska veta när rörelsen är färdig beräknasutifrån hastigheten v, accelerationen a och rörelselängden d hur lång tidutförandet kommer ta enligt

t =2va

+|d| − 2v

av

.

De försök att få kontrollern att signalera vid färdig rörelse misslyckades,därför beräknas istället tiden. Resultatet är tillräckligt exakt för använd-ning inom projektet.

4.3.6 Rotationsbord

Rotationsbordet används för att justera objektets position. Den ger använ-daren möjligheten att scanna objekt från olika vinklar med högre precisionjämfört med en manuell förflyttning. Den automatiserade förflyttningengör det även enklare att scanna ett objekt flera gånger och få snarlika re-sultat.

Kommunikationen med hårdvaran sker genom tillverkarnas mjukvara somkommunicerar genom en seriell anslutning. Den wrapper som är skriveni projektet är byggd på samma sätt som kamerans wrapper .

4.4 Arkitekturförslag

För arkitekturförslaget behölls delar av systemet identiska med den ar-kitektur som framtogs med krav i beaktning. Hårdvaruenheterna lämnas

19

4. Resultat

Figur 4.5: Översikt av arkitekturförslaget.

utan vidare modifikation, medan nätverksarkitekturen modifieras något.All arkitektur som rör ROS anses som borttagen. Även den ROS-baseradeklienten tas bort. En översikt av den nya arkitekturen visas i figur 4.5.

4.4.1 Nätverkskommunikation

Ett problem med den nuvarande arkitekturen var att data behövde be-handlas av nätverkskod, en kontrollnod, en klientnod och ROS. Det skullevara fördelaktigt och mycket mer strömlinjeformat om data enbart behöv-de behandlas en gång när den skickas eller tas emot över nätverket. Det ärönskvärt att den kod som använder hårdvaruenheterna inte behöver pratadirekt med dessa, utan att trafiken passerar något annat först. I nuvarandedesign passerar all trafik en ROS-baserad styrnod.

Nätverkskommunikationen kan modifieras för att stödja vidarebefordringav data. På så sätt är det möjligt att ha en väldigt enkel server som “slårihop” data från hårdvaruenheter och vidarebefordrar denna utan modi-fikationer till klient. Denna server, kallad router, kan också ta emot datafrån klient och vidarebefordra till rätt hårdvaruenhet. Routern kan hål-las väldigt enkel då den inte rör någon faktiskt data utan enbart skickarvidare till rätt mottagare.

4.4.2 Pythonbibliotek

För att styra hårdvaran skapas ett pythonbibliotek, libtreed, som expo-nerar hårdvara och scanningsprocedurer för utvecklare. Detta API abstra-herar bort detaljer i nätverkskommunikationen och styrningen av hårdva-ran. All kod för kontroll av systemet samlas på en plats.

20

4.5. Installation

Den interna strukturen av libtreed innehåller tre bibliotek för kontrollav linjärenhet, kamera och rotationsbord. Dessa kan automatgenereras ut-ifrån de konfigurationsfiler projektets nätverkskommunikation använder.Det hypotetiska biblioteket libtreed innehåller även funktionalitet för attgenomföra kompletta scanningar, med alla parametrar och inställningarsom krävs för detta.

Detta Python-bibliotek skulle sedan kunna utnyttjas av andra system skriv-na i Python som vill bygga vidare på den funktionalitet biblioteket erhål-ler.

4.4.3 Klient

En klient i denna arkitektur behöver inte ha någon kunskap om hur nät-verkskommunikationen sköts, klienten behöver endast använda libtreed.Klienten kallar då endast på de funktioner som finns i biblioteket libtreedutifrån de kommandon som passats till programmet. Det enda relaterattill nätverket som användaren av systemet (det vill säga klienten) behöverhålla reda på är IP-adressen till routern, och se till att denna är startad.

4.4.4 Experiment

För att få mer data att grunda denna hypotetiska arkitektur utfördes etttest där en del av arkitekturen implementerades. Detta gjordes med ut-gångspunkt i en delmängd av de moduler som existerar i det riktiga sy-stemet. Att utgå från detta ansågs rimligt då modulerna inte beror påvarandra. Den del som valdes för implementation var hela libtreed för-utom den del som hanterar en hel scanning.

På fyra timmar kunde två programmerare få en extern dator att styra sy-stemets hårdvaruenheter över nätverket till samma grad som det vanligasystemet.

4.5 Installation

Förutom de vanliga modulerna finns det en som har hand om en komplettinstallation av systemet. Modulen är i sig inte relevant för den diskussionsom förs mellan en föreslagen arkitektur och den nuvarande, men be-skrivs här för att ge en helhetsbild av systemet. En liknande metod kanutnyttjas oberoende av system.

Installationsmodulen använder sig av Puppet [8] och innehåller manifestoch relaterade skript för att automatisera installationen. Appliceras ma-nifestet i en kompatibel miljö installeras alla de program och biblioteksom projektet använder sig av. Att valet blev just Puppet var då kunskap

21

4. Resultat

om detta verktyg ansågs vara vanligt förekommande på universitetet ochframtida underhåll av systemet kan således underlättas.

4.6 Gemensamma erfarenheter

Data kring tidigare erfarenheter är till största delen baserad på utfördaintervjuer och en gruppdiskussion. Här beskrivs hur gruppen upplevdedokumentstruktur, versionshantering och kommunikation samt vilka nyaerfarenheter gruppmedlemmarna samlat.

4.6.1 Tidigare projekt

I tidigare projekt upplevdes det att kommunikationen inom projektgrup-perna fungerade väldigt bra och att detta var väsentligt för kvaliteten påarbetet. Därför eftersträvades det att i även detta projekt hålla en konse-kvent och öppen kommunikation både inom gruppen och med kundenoch projekthandledaren. Detta innebar att personer inom gruppen kun-de ge positiv eller utvecklande feedback utan att någon tog illa upp. Dettycktes även fördelaktigt med flera olika medier att bli kontaktad igenom.

I tidigare grupparbeten tycktes arbetsfördelningen vara väldigt bra, menatt det delades ut för stora uppgifter på en gång. Därför försöktes det idetta projekt att göra en mer detaljerad planering och dela arbetet i mind-re uppgifter. Det upplevdes ibland svårt att jobba enskilt. Därför bestäm-des det att arbetet och ansvaret skulle fördelas på ett sådant sätt att varperson behövde arbeta själv så lite som möjligt. Ojämn arbetsbelastningskulle också undvikas genom en noggrannare planering, till exempel såatt det inte skulle bli så att någon vid ett tillfälle inte hade något att göraoch vid ett annat tillfälle hade för mycket jobb.

Arbetsflöde för versionshantering var någonting som togs upp flera gång-er som något som kan förbättras jämfört med tidigare projekt. För dettaändamål bestämdes att åsidosätta tid för utbildning i Git [9] och bestäm-ning av arbetsflöde.

I vissa fall kändes det svårt och jobbigt att integrera de olika delarnai projektet till en slutprodukt. I det här projektet skulle det eftersträvasatt göra detta lättare genom en bättre planering och en mer detaljeradarkitekturbeskrivning.

Slutligen upplevdes stämning och gruppanda i tidigare projekt som god,vilket ansågs eftersträvansvärt även i detta projekt.

22

4.6. Gemensamma erfarenheter

4.6.2 Inverkan av tidigare erfarenheter

De erfarenheter gruppen har tagit med sig från tidigare projekt har påver-kat stora delar av projektet, särskilt med avseende på projektstruktur ocharbetsmetodik.

LiPS En erfarenhet som återkom flera gånger i intervjuer var en projekt-kurs där projektmedlemmar arbetat i grupper om sex för att konstruera enrobot. I denna kurs tillämpades projektmodellen LiPS [10]. I både intervju-er och efterföljande diskussionsmöte framkom att denna modell påverkatstora delar av projektet.

För många av gruppmedlemmarna var denna kurs det första och enda ti-digare tillfälle då de arbetat i en något större grupp. Många av de metodersom presenterades fördes över till detta projekt. Som exempel nämndesatt den projektplan som utvecklades i detta projekt är baserad på den typav projektplan som specificeras av LiPS. Under diskussionsmötet fram-fördes att delar av den dokumentstruktur och det dokumentinnehåll somspecificeras av LiPS användes, då det var mer lättillgängligt och naturligtän IEEE-standarder. Det framfördes även att många i gruppen användesig av LiPS-standarden för att de kände att de inte hade något bättre atttillgå.

Versionshantering Under intervjuer och diskussionsmöten framkom attmedlemmar haft varierande erfarenheter kring versionshantering. Särskiltunder intervjuer framfördes ofta erfarenheter av dålig versionshanteringi tidigare projekt. Versionshanteringen ansågs av medlemmarna ha storvikt för projektarbete. Då gruppen redan från början enats över vikten avgod versionshantering togs ett rigoröst arbetsflöde för versionshanteringfram väldigt tidigt i projektet. Det framfördes under intervjuer att pro-jektets arbetsflöde fungerat bra, bättre än i många tidigare projekt. Detansågs av enstaka personer att arbetsflödet till och med varit för rigoröst.

Uppfattningar kring andras tidigare erfarenheter Under intervjusessio-nerna ställdes det frågor kring uppfattningen av andras tidigare erfaren-heter. Gruppen ansågs ha tagit tillvara tidigare erfarenheter, även om fleraintervjuobjekt hade svårt att peka ut specifika områden. Det ansågs attgruppmedlemmarna fått roller som passade deras tidigare erfarenheteroch att de utvecklades i dessa roller. Det uppfattades som om gruppendelade ut arbete på ett sätt som passade gruppmedlemmarnas erfarenhe-ter och dessutom att de kände till varandras erfarenheter så att de hademöjlighet att be relevanta personer om hjälp då så krävdes.

23

4. Resultat

4.6.3 Gruppens kommunikation

Utifrån intervjuerna och det efterföljande diskussionsmötet som genom-fördes kom det fram att alla i gruppen ansåg att den övergripande kom-munikationen inom gruppen hade fungerat bra och gruppen var överensom att kommunikationen hade varit öppen och ärlig. Det fanns dock vissaproblemområden som kunde förbättras.

Det använda verktyget Slack fungerade bra för att få en översikt över vadsom hade sagts tidigare, eftersom det i verktyget finns en historik [11].Det tog dock ibland tid för medlemmar att svara på meddelanden somskrevs. Det var även svårt att veta vilka som tagit del av informationen.Information kring när och var möten skulle hållas ansågs vara bristfällig,vilket åtgärdades med en gemensam kalender.

Det ansågs svårt att hålla ordning på vad de olika medlemmarna i grup-pen gjorde, då man saknade digital information om detta. Istället använ-des en fysisk kanbantavla i gruppens projektrum.

Det sades även att det var svårt att se över information kring vad somgjordes då gruppen slutade använda Trello [3], vilket var det verktyg somanvändes i början för att strukturera aktiviteter.

4.6.4 Nya erfarenheter

Gruppen fick en hel del nya erfarenheter av att både skriva alla doku-ment till projektet men även från projektet i sig. En majoritet nämnde attprojektet varit välstrukturerat.

Intervjuobjekt påpekade även att man blivit bättre på formalia, användaversionshantering i större projekt och även att jobba utifrån någon annanskrav. Detta var första gången som man jobbat i en större grupp och ävenförsta gången man blivit tilldelad personer att jobba med som man intekände sedan innan. Intervjuobjekten hade även blivit trötta på att skrivadokument och hårdvara ansågs inte roligt att arbeta med.

4.7 Områden med förbättringspotential

Projektet har överlag gått bra, men det har funnits problemområden. Trel-lo har försummats, tidsplaneringen har inte uppdaterats kontinuerligt ochgruppen har legat efter i antal nerlagda timmar.

4.7.1 Trello

Trello som verktyg fungerade bra men problemet var att gruppmedlem-marna glömde att uppdatera korten. Det var därför svårt att få en korrekt

24

4.8. Processrelaterade resultat

överblick i och med att det inte var klart om tavlan faktiskt stämde. Dettaledde till att Trello inte fungerade för utvecklingsarbetet. Därmed upp-stod en nedåtgående spiral där allt färre gruppmedlemmar uppdateradekorten tills det att ingen längre uppdaterade korten. Eftersom mycket avarbetet skedde på plats, så tyckte många att det inte var någon poäng medatt uppdatera korten eftersom man i många fall även tog det muntligt.

4.7.2 Tidsplanering

Problemet med tidsplaneringen var att tidsuppskattningar gjorda i börjanav projektet avvek kraftigt ifrån tiden det tog att utföra uppgiften. Tidigauppskattningar var dåliga då de var baserade på vilda gissningar, pro-jektets omfattning var inte känt. Bristen på träffsäkra tidsuppskattningarledde till att tidsplaneringen behövde revideras efter varje uppgift ochtappade därigenom mycket av syftet. Att uppdatera de Gantt-schemansom gjorts tjänade därför inget syfte.

4.7.3 Tidsåtgång

Generellt sätt låg gruppen efter antalet timmar som skulle läggas och pro-blemen syntes redan från början. Under första iterationen ansågs det svårtatt hinna med alla timmar och samtidigt inte ligga efter i samtidiga kurser.Att gruppmedlemmarna sedan inte kom ikapp berodde på att det redanvar planerat att nästa lägga heltid på detta.

4.8 Processrelaterade resultat

Den arbetsmetodiken som använts under projektet beskrevs under inter-vjuerna som vattenfallsmetoden, om än lite mer flexibel. Den användametoden hade under projektets gång både fördelar och nackdelar, ochblev under projektets gång gradvis förbättrad.

4.8.1 Projektets arbetsmetodik

Som nämnts ovan beskrivs den använda arbetsmetodiken av intervju-objekten som en halvflexibel vattenfallsmetod. Ett exempel på detta varatt gruppen ofta hade möten. Utvecklingen av dokument beskrevs som“scrum-liknande”.

4.8.2 Fördelar med arbetsmetodiken

De flesta påpekade att den använda arbetsmetodiken passade bra för justdetta projekt då det inte enbart var mjukvarubaserat utan även förlitade

25

4. Resultat

sig på hårdvara. En annan sak som sades var att gruppen hade träffatsefter varje iteration för att omorganisera arbetet. Även ändringen till attträffas varje vecka för att planera noggrannare upplevdes som bra.

4.8.3 Nackdelar med arbetsmetodiken

När det kommer till nackdelar var något som togs upp att det tog långtid innan något kunde testas. Det gjordes inga iterationer över produkten.Det sades att de Gantt-scheman som skapats aldrig gjordes om och attdetta ledde till att det var lite svårt att hålla koll på hur man låg till. Påintervju sades av de flesta även att Semat Alpha-korten var något somknappt användes.

4.8.4 Förbättring av arbetsmetodiken

När det kommer till förbättringar och ändringar av arbetsmetodiken ver-kade de flesta hålla med om att riktiga iterationer av något slag hade variten ändring de skulle velat göra. Det nämndes även att mötena har varit li-te för långa och på så sätt blivit ineffektiva, detta ansågs kunna förbättratsgenom att korta ned dem. En ändring av vad som skulle vara klart eftervarje “iteration” önskades. Samtidigt påpekades det av några att integre-ring mellan de olika delarna skulle gjorts tidigare. Det påpekades även attde flesta dokumenten inte använts så väl som de borde. De har endast an-vänts för bland annat testmallar och kodstandarder som PEP8 [12]. Dettaär något som önskades ändras.

4.8.5 Versionshantering

Det lades stor vikt på god versionshantering i projektets uppstart, varvidrigorösa processer för hantering av både kod och dokument tidigt togsfram. Versionshanteringen av dokument och kod skiljde sig något ochbeskrivs därför separat. All versionshantering sköttes med verktyget Git,då alla gruppens medlemmar var bekanta med detta.

Kod För att hantera kod valdes ett relativt omfattande arbetssätt. Ef-tersom systemet var väldigt modulärt delades projektet redan från börjanupp i flera submoduler. En submodul är en länk från ett git-repository tillen commit i en annan. På så sätt kan en struktur av flera git-repositorybyggas ihop. Figur 4.6 visar den resulterande strukturen.

För varje submodul användes en master-branch innehållande kod somvar färdig för demo och leverans, en dev-branch med testad och funge-rande kod och en eller flera feature branches för ny otestad funktionalitet.För att föra in kod i dev krävdes att koden testats och granskats, både

26

4.8. Processrelaterade resultat

Figur 4.6: Git strukturen.

med avseende på funktionalitet och kodstandarder. Kod fördes vidare inpå master då innehållet i dev ansågs vara stabilt och väl testat. Projektetsutvecklingsledare hade huvudansvaret för att sköta dessa merges.

I början av iteration tre förändrades arbetssättet genom att dev togs bortoch ersattes med att föra in kod direkt på master, detta då projektet varså pass modulärt att dev inte bidrog till att öka kvaliteten på varken kodeller funktionalitet.

Figur 4.7: Dokumentstrukturen.

27

4. Resultat

Dokument För att versionshantera dokument användes en annorlun-da strategi. Varje ny version av ett dokument utvecklades på en egenseparat branch. Då det av dokumentens författare ansågs att dokumen-ten var färdiga meddelades dokumentansvarige. Det färdiga dokumentetgranskades av dokumentansvarige och lades in på master efter att eventu-ell feedback korrigerats av författaren. Innehållet på master bestod alltsåav granskade dokument av senaste version. Hur strukturen för dokumen-ten är upplagd kan ses i figur 4.7.

Alla dokument tilldelades, enligt överenskommelse mellan dokumentan-svarige och författare, ett versionsnummer vid merge till master. Ytter-ligare fanns i alla dokument korta noteringar om vad som hänt mellanolika versioner för att öka spårbarheten. Dessa noteringar skrevs i sam-band med merge till master.

4.8.6 Testning

För att testa systemet valdes först en testperson av utvecklaren. Testper-sonen och testledaren planerade sedan tester som skulle utföras. Testernaskulle utforska testobjektets gränser, fel indata, exakthet och stress därapplicerbart. Testpersonen tillsammans med valfri assistent utförde sedantesterna och dokumenterade de i ett kalkylark för utvecklaren att läsa. Omnågot av testfallen misslyckades fick utvecklaren i uppdrag att lösa dem.

Efter varje iteration utfördes ett acceptanstest med kunden. Då har team-ledaren och analysansvarig planerat de funktioner som ska visas för attsedan antecknat kundens reaktioner och frågor. Detta för att vid fortsattutveckling ha kundens önskemål i åtanke.

4.9 Robusthetsanalys

De tester som utförts på olika delsystem anses som relativt omfattande.Implementationen av avståndskameran är skapad från ett API som fråntillverkaren av hårdvaran. Detta API hanterar alla fel gällande hårdvaraoch mjukvara, och kan även meddela okända fel. Ett okänt fel har dockaldrig framkommit under projektets gång när diverse testscanningar harutförts. Därmed fanns redan en existerande och omfattande felhanteringsom även används i den nya implementation. Vid dessa fel får användarengöra om det senaste steget för att fortsätta med en scanning.

Linjärenheten och rotationsbordet är mindre komplexa än avståndskame-ran, och innehåller därför färre saker som kan gå fel. Båda är testade föratt hantera de fel en användare kan göra, och kan vid okända fel åter-ställas till ursprungsläget för att göra om en scanning om något skulle gåfel.

28

4.10. Översikt av de individuella bidragen

Efter experimentet som gjordes för att medvetet framkalla fel kan en delsaker konstateras. Vid samtliga framkallade fel slutade systemet fungeraunder en scanning utan att ange något felmeddelande för klienten. Vidsamtliga experiment påverkades inte nästkommande scanning då felettogs bort, vilket betyder att även om en scanning misslyckades löstes pro-blemet genom att göra om en scanning med felet borttaget.

4.10 Översikt av de individuella bidragen

Under kandidatarbetet har ett individuellt arbete utförts av var och enav studenterna i projektgruppen inom ett valfritt område. Dessa arbetenbeskrevs i individuella rapporter som i detta dokument finns direkt efterden gemensamma delen. Rapporterna behandlar följande:

Testutvärdering Rapporten diskuterar testningen som har utförts underprojektets gång. Hur bra testningen anses ha utförts samt vad som kanförbättras i testprocessen tas upp.

Konsistensanalys av dokumentkod och typografi I denna rapport ana-lyseras hur LATEXanvändes i projektet då de flesta var oerfarna i typsätt-ningsverktyget. Problemområden analyseras och lösningar på problem fö-reslås.

Återanvändning av delsystem vid rekonstruktion Den här delen be-handlar hur ett system påverkas av beslutet att återanvända ett delsystemvid rekonstruktion av hela systemet. Som exempel tas produkten som ut-vecklades under projektets gång där en kommunikationslänk mellan tvåhårdvaruenheter återanvändes från det gamla systemet.

Säkerhetsanalys vid användning av utdaterad mjukvara Säkerhet togsinte hänsyn till varken före eller under utvecklingen av produkten somtogs fram i kandidatprojektet. Vad detta kan ha för följder samt hur manbör tänka på ett systems säkerhet tas upp i den här rapporten.

Svårigheter vid tidsplanering Tidsplanering är en viktig faktor för lön-samheten av ett mjukvaruprojekt. Tyvärr är det ofta svårt att göra tidsupp-skattningar för utvecklingen av en produkt, främst om gruppen är nybil-dad och oerfaren i området. Denna rapport behandlar olika metoder förhur tidsplanering kan utföras.

29

4. Resultat

Automatisering av systemtestning Under projektets gång testades sy-stemet av en testperson genom att kommandon matades in manuellt föratt se om programmet beteende sig som förväntat. Denna rapport un-dersöker hur denna process kan underlättas genom automatisering avsystemtester.

Modularisera gamla, utdaterade system Detta individuella arbete un-dersökte hur ett system kan byggas om på ett sådant sätt så att systemetkan vidareutvecklas i framtiden utan att en ny total uppgradering behövs.En metod för utveckling av ett nytt modulärt system från ett gammalt sy-stem föreslås. Metoden föreslås främst för små till medelstora projekt därmjukvara-hårdvara relationer ligger i fokus.

Grupprums påverkan på utvecklingsarbetet i en projektgrupp Dennarapport undersöker hur att arbeta tillsammans i ett gemensamt rum harpåverkat projektarbetet för en grupp. Undersökningen genomfördes påandra projektgrupper som samtidigt utförde ett kandidatarbete vid Lin-köpings universitet. Påverkan av ett tilldelat rum jämförs med olika sättatt arbeta på hos andra företag.

30

5

Diskussion

I detta avsnitt förs en diskussion kring de resultat som erhållits. Dennadiskussion förs i fyra delar, en om den arbetsmetodik som använts, enom hur tidigare erfarenheter använts, en om de arkitekturella valen somgjorts och alternativ till dessa samt en där systemets grad av robusthetbehandlas.

5.1 Arbetsmetodik

Gruppmedlemmarna verkade vara överens om att projektet utförts enligtnågon form av vattenfallsmodel. Även andra aspekter pekar på detta, tillexempel den utförliga planeringen och dokumentationen. Arkitekturpla-ner och kravspecifikationer togs fram tidigt i projektet och följdes sedan.Från resultatet kan man också sammanfatta att dokumentationen har varitbetungande för utvecklingsarbetet.

5.1.1 Vattenfall

Att göra arbetet mer agilt var under intervjuerna ett vanligt förekomman-de ämne, även om få av intervjuobjekten trodde att det skulle fungera.Något som skulle kunna göras är att låta planeringen uppdateras ofta-re. Det skulle även vara möjligt att detaljplanera bara någon veckan in iframtiden löpande, alltså ett “glidande vattenfall”.

5.1.2 Dokumentation

Den tunga dokumentationen ansågs sakta ner projektet, särskilt i början.Ett mycket intressant förslag var möjligheten att direkt vid projektstart

31

5. Diskussion

helt ignorera större delen av dokumentationskraven, för att helt koncen-trera sig på att utveckla ad hoc1 i någon vecka. Efter denna period utandokumentation kan gruppen tänkas ha större kunskaper om projektet,varför de bättre och snabbare kan ta fram nödvändiga dokument.

Under intervjuerna kom det fram att relativt lite av den dokumentationsom togs fram användes aktivt under projektet. Den dokumentation somanvändes var i huvudsak relaterad till mallar och standarder samt arki-tektur. Att koncentrera dokumentation till dessa områden kan tänkas varafördelaktigt beroende på projekttyp och projektlängd.

5.1.3 Möteseffektivitet

De möten som hållits under projektet ansågs vara ineffektiva och dra utpå tiden. Gruppen valde att ha ett till två större möten på ungefär entimme, ibland längre, varje vecka istället för fler men kortare möten. Detgrupprum som användes bidrog till att det gick bra att kommunicera ävenutanför mötestid, varför antalet möten fungerade bra. En vilja att göra mö-ten kortare och effektivare är inte något nytt för detta projekt. Att striktarefölja mötesagenda och att aktivt undvika att diskussioner går utanför äm-net bör höja effektiviteten.

5.2 Erfarenheter

Att ha diskuterat erfarenheter från tidigare projekt i början av arbetet ver-kar ha haft en positiv påverkan vad som gäller kommunikation, gruppan-da, projektstruktur och versionshantering. Ett intressant mönster har lagtsmärke till över hur utvecklarna ser på sin personliga effektivitet.

5.2.1 Kommunikation

Gruppens kommunikation fungerade under projektet väl och mycket kantas med till andra projekt. Under projektets gång hölls flera möten dåkommunikationen i gruppen diskuterades. Då ett problem upptäcktes fö-reslogs en lösning. Det tros vara anledningen till varför kommunikationeni gruppen ansågs god.

5.2.2 Effektivitet

En mycket intressant observation som gjorts var hur majoriteten av in-tervjuobjekten ansåg att deras personliga effektivitet var lägre än andra itidigare projekt, samtidigt som de ansåg att gruppens arbete som helhet

1Något som görs med ett specifikt ändamål.

32

5.3. Arkitektur

var effektivare. Anledningen till detta är oklar. Det kan tänkas att någonpsykologisk effekt har påverkat objektens uppfattning, men detta ansesligga utanför rapportens omfattning. En möjlighet är att en liten del avgruppen genomfört en oproportionerligt stor del av uppgiften, alltså attarbetsfördelningen varit ojämn. Under intervjuerna ansågs det dock attarbetsfördelningen varit jämn. En ojämn arbetsfördelning är alltså antag-ligen inte anledningen till skillnaden i uppfattning kring gruppens effekti-vitet respektive den personliga effektiviteten. Detta bör undersökas vidarei andra projekt och grupper.

5.2.3 Projektstruktur

Att strukturera upp arbetet tidigt ansågs av intervjuobjekt vara viktigt.Att tidigt specificera hur arbetet ska gå till verkar vara till fördel för detfortsatta arbetet. Något som kommit till användning flera gånger underprojektet var specifikationer för hur förändring ska hanteras. Hur juste-ras ansvarsfördelning? Hur förändras processer? Dessa frågor, med fler,besvarades tidigt i projektet och kunde därmed ge stöd för senare föränd-ringar. Tidiga överenskommelser kring till exempel versionshantering ochstilguider för kod har även dessa påverkat projektet positivt.

5.2.4 Versionshantering

Att god versionshantering är av största vikt för utvecklingsarbete i störregrupper var alla intervjuobjekt överens om. De kunskaper och erfaren-heter gruppmedlemmarna hade kring versionshantering sedan tidigarevarierade kraftigt. Detta ledde till en situation där delar av gruppen kän-de till versionshanteringsverktyget Git väl, medan verktyget var nytt förandra. Den interna utbildningen hjälpte till att jämna ut nivåerna, men varinte heltäckande. Att ge god versionshantering större vikt i undervisningpå grundläggande universitetsnivå skulle kunna avhjälpa många vanligafel och även den allmänna ovanan med versionshantering.

5.3 Arkitektur

En ny arkitektur föreslås i avsnitt 4.4 där ROS inte används. Denna ar-kitektur diskuteras och jämförs i detta avsnitt mot den arkitektur somlevererats till kund. Fördelar och nackdelar med de båda arkitekturernautreds, och resultatet för denna diskussion leder vidare till ett svar påfrågan om en annan arkitektur än en som använder ROS skulle vara för-delaktig att använda. Det gamla systemet kallas i denna text det gamlasystemet, resultatet av uppgraderingen det nya systemet eller nya arkitektu-ren och en realisation av den föreslagna arkitekturen det föreslagna systemet

33

5. Diskussion

eller föreslagna arkitekturen. Till grund för de argument som förs ligger detexperiment som utfördes.

5.3.1 Beroenden

Ett av de största problemen med den arkitektur som använts är att denutan att använda virtualisering kräver två datorer, en som kör Linux ochen som kör Windows då ROS endast officiellt stödjer Ubuntu utan experi-mentella versioner och två av hårdvaruenheterna kräver Windows. UtanROS skulle systemet kunna köras på endast en dator med Windows.

Önskas Linux fortfarande medför det dock även några fördelar när denföreslagna arkitekturen används. Fler versioner av Linux stödjs då Pythonär den enda teknologi som systemet utnyttjar, något som finns för majo-riteten av alla operativsystem som realistiskt kommer att vilja användas.Detta gäller även för klienten som då kan köras på valfritt operativsystemdär Python stödjs.

5.3.2 Vidareutvecklingsbarhet

Då stor vikt lades på att framtidssäkra och möjliggöra det nya systemetför vidareutveckling är det systemet väl anpassat för uppgradering avhårdvaruenheter. Det föreslagna systemet offrar inget mot det nya, i ochmed att även det bygger på samma princip av modularitet där konfigu-rationsfiler avgör vilka funktioner som finns tillgängliga att utföras. Bådasystemen medför alltså en stor grad av uppgraderbarhet när det kommertill hårdvaruenheterna.

Även vidareutveckling är möjlig i båda systemen, men hur detta görs ärnågot som skiljer sig åt. I den nya arkitekturen görs detta främst genomatt lägga till fler topics och services som klienten eller andra ROS-noderkan prenumerera eller kalla på. I det föreslagna fallet görs detta iställetgenom att bygga vidare på det bibliotek som används, libtreed. Detta ärett mycket enklare och mer naturligt sätt i och med att inga meddelande-filer behöver läggas till och kompileras hos klienter för att de ska kunnautnyttja funktionaliteten. Fördelen med ROS är dock att i fall då systemetska interagera med robotar stödjs redan ROS och integrering med restenkan göras snabbare. Detta är troligtvis inte relevant i detta fall, men inteallt för långt ifrån ett möjligt användningsområde.

Både det nya och det föreslagna systemet kan vidareutvecklas och utnytt-jas genom att skripta systemet i bash eller dylikt genom att kalla på detCLI som finns.

34

5.3. Arkitektur

5.3.3 Komplexitet

Strukturen i den föreslagna arkitekturen blir förenklad i och med att ettantal delar ej längre behövs. Till exempel behövs endast en del som sköterkommunikation istället för två i det nya systemet (där ROS ej kan använ-das mellan datorn med enheterna och styrnodsdatorn). Den arkitekturenmedför i sin tur att systemet enklare kan vidareutvecklas i och med attdet går fortare att sätta sig in i koden.

5.3.4 Utvecklingstid

En enklare arkitektur medför naturligt också en kortare utvecklingstidvilket medför att systemet kan utvecklas billigare eller med fler funktionerför samma kostnad. Detta syntes tydligt i experimentet där det tiden dettog att få ROS fungera överhuvudtaget till och med var längre än den dettog att få en grundläggande och något avskalad version av den föreslagnaarkitekturen.

5.3.5 Problem med undersökningen

Argumenten grundar sig på ett experiment utfört efter det att systemet tillstörsta del var klart. De kunskaper som erhållits under systemets utveck-ling applicerades naturligt då det föreslagna systemet implementerades.För att få en helt rättvis bedömning av hur stor påverkning ROS haft påutvecklingen skulle en oberoende grupp med liknande kunskapsnivå somarbetat på samma sätt behöva implementera det föreslagna systemet, nå-got som inte är realistiskt att undersöka i detta sammanhang.

5.3.6 Helt andra arkitekturval

Även om det är en hypotetisk arkitektur utan ROS som ligger i fokus fördenna rapport är det även intressant att se på arkitekturen ur ett bredareperspektiv. De främsta delarna som är värda att röra vid är språkvaletPython, användandet av nätverkskommunikation och valet på gränssnittsom ett kommandoradsprogram och inte ett grafiskt sådant.

Python Ur en slutanvändares synvinkel är Python som språk ett bra valdå det är ett relativt enkelt språk att sätta sig in i. Språket används ävenofta inom forskning med bibliotek som Numpy2 och Scipy3. Vidareutveck-ling mot hårdvara är dock något som hindras av valet. Modulen ctypessom används för att interagera med Windows-drivrutiner har inte stöd för

2http://www.numpy.org/3https://www.scipy.org/

35

5. Diskussion

klasser, något som flitigt används i moderna drivrutiner. Detta medfördeatt ett utdaterat C-API istället fick användas av kameran. Hade iställetC++ använts hade systemet kunnat använda ett modernare kamera-API.

Nätverkskommunikation Systemet körde i och med användandet avROS distribuerat på två datorer. Utan ROS behövs inte denna uppdel-ning utan systemet kan på så sätt köras helt lokalt som ett självständigtprogram utan behov av servrar och klienter. Detta hade i sin tur medförtatt systemet blivit enklare att underhålla och utveckla då all funktionalitetutförs på samma ställe. Även uppstart och installation skulle förenklats,behovet av Puppet för att göra denna rimlig skulle försvinna.

Gränssnitt Att använda ett kommandoradsgränsnitt medför att syste-met endast riktar sig till en viss typ av användare - de med datorvana.Denna grupp av användare är antagligen de enda som skulle ha någonstörre nytta av systemet så valet kan inte anses ha allt för stora konse-kvenser i och med att antalet olika kommandon programmet har inte ärspeciellt stort, även utan en man-sida skulle dessa enkelt kunna memore-ras.

5.4 Robusthet

Analysen av systemets nivå av robusthet visade att de enskilda delarna isystemet var väl testade och kunde anses som robusta. Eftersom systemetsom helhet visade på en del brister vid experiment är det intressant attdiskutera till vilken grad detta sänker robustheten på hela systemet. Up-penbarligen beror det på när ett fel i systemet uppkommer, eftersom allaenheter i systemet har en omfattande felhantering. De flesta problem somsystemet inte är byggt för att hantera sker alltså vid kommunikation mel-lan enheter. En framtida utveckling av systemet kan således vara att utökafelhanteringen till att hantera systemet som helhet för att göra systemetmer robust, vilket inte bör vara särskilt komplicerat.

5.5 Metod

Metoderna som användes för att besvara frågeställningarna kan ha brister.Huvudsakligen intervjun, testet av en ROS-fri arkitektur och robusthetsa-nalysen ska analyseras.

5.5.1 Erfarenhetsintervju

Intervjun gjordes enskilt med varje gruppmedlem. De två personer somhöll i intervjuerna hörde allas svar på frågorna innan de själva blev in-

36

5.6. Arbetet i ett vidare sammanhang

tervjuade. De hade kanske svarat annorlunda om de blivit intervjuadeförst eller någon utomstående höll i intervjun. En mall som alla kunde hafått fylla i hade kanske gett svar mindre influerade av andra. Detta hadedäremot medfört att inga följdfrågor kunde ha ställts.

5.5.2 Robusthetsanalys

Att skapa fel för att se hur systemet klarar dem är vettigt för att kontrollerahanteringen av de felen. Testades alla kritiska delar? Är alla kritiska delarkända? Det var nog en bra metod för att kontrollera de kritiska delar somtestades då de utsattes för faktiska fel, och om systemet hanterade dempå ett robust vis borde systemet vara robust.

5.6 Arbetet i ett vidare sammanhang

Mjukvaruprojekt har allt större betydelse även i andra sammanhang utan-för projektet. Bland annat är det värt att nämna miljöaspekter samt sam-hälleliga och etiska aspekter.

Samhälleliga aspekter 3D-scanning har fått fler och fler tillämpnings-områden, även utanför industrin. Vanliga konsumenter kan skapa 3D-modeller utifrån till exempel mobilkamerabilder. Detta kan inverka påflera områden, till exempel konst, spel, och replikering av fysiska objektgenom 3D-utskrifter.

Miljöaspekter Systemets uppsättning består av två datorer och ett antalhårdvaruenheter. Det är ett mindre system som endast körs när det be-hövs. Det finns därmed inte några betydande miljöaspekter att ta hänsyntill.

Etiska aspekter Då systemet är tänkt att användas i akademiska syften,ses inga etiska aspekter som kan vara till varken nackdel eller fördel.

37

6

Slutsatser

I detta avsnitt presenteras de slutsatser som kan dras av resultatet. Dessaslutsatser delas upp i rubrikerna tekniska resultat, där robusthet och ROSbehandlas, samt gruppens arbete, där projektgruppens arbetsmetodik ocherfarenheter sammanfattas.

6.1 Tekniska resultat

Ett mål med projektet var att uppnå ett robust system. Systemet som hel-het är inte så robust som projektgruppen önskat, vilket det utförda experi-mentet visat. De enskilda moduler som systemet består av anses däremotvara relativt robusta, eftersom de har gått igenom ett fleratal tester ochhar i övrigt fungerat väl. Även om det integrerade systemet inte är fullt såstabilt och felsäkert som önskat är det en bra grund att bygga vidare påför att skapa ett mer robust system.

ROS är ett mycket lämpligt verktyg för utveckling av distribuerade sy-stem. I vårt fall hade ROS varit ett mycket bra teknikval om det inte voreför avsaknaden av stöd för Windows. I vår arkitektur innebar detta attkommunikationsvägen från användargränssnitt till hårdvaruenheter blevonödigt lång och komplicerad. Dessutom ställde ROS väldigt specifikasystemkrav, något som den alternativa arkitekturen undvek till förmånför ökad portabilitet. Den ROS-baserade arkitekturen som utvecklades ärdock lätt att använda tillsammans med andra ROS-baserade system, tillskillnad från den hypotetiska arkitektur som har presenterats. Huruvi-da ROS skulle ha utelämnats till förmån för en annan arkitektur lämnasosagt, då det beror mycket på hur systemet kommer användas i framti-den. Detta visar på hur viktigt det är att göra bra teknikval redan i börjanav projektarbeten.

39

6.2 Gruppens arbete

Den vattenfallsmodell som gruppen arbetat enligt har inte varit perfekt,men har fortfarande fungerat bra för projektet. Att projektet haft en sta-bil kravspecifikation, varit hårdvarunära och inriktat mer på kodläsningoch förståelse än programmering har bidragit till att en vattenfallsmodellhar fungerat. Att arbetsprocessen uppdaterats under arbetet har varit enbidragande faktor till att arbetsupplägget har fungerat bra.

Gruppen har utnyttjat sina tidigare processrelaterade och gruppdynamis-ka erfarenheter för att förbättra arbetsprocessen, både tidigt i projektetoch kontinuerligt under arbetet. Versionshantering, planering och kom-munikation är exempel på områden där tidigare erfarenheter haft en storinverkan och positivt bidragit till projektet.

De tekniska erfarenheter som funnits i gruppen har legat till grund förmånga tekniska beslut och teknikval som tagits under projektets gång.LATEX, dokumentationsupplägg, asyncio, Puppet, Slack och Git är alla ex-empel på lyckade teknikval som gjordes grundat i tidigare tekniska erfa-renheter.

Gruppmedlemmarna har även ansett att de har vågat fråga och ta hjälpav varandra. Individernas styrkor har varit kända och utnyttjats.

40

TestutvärderingFelix Haavisto

Det utvecklades ett system som testades. Tester bör göras för att säkerställa att ettsystem uppnår de krav som ställs på det. Den här rapporten utvärderar hur bratesterna var och vad som skulle kunna göras bättre.

Ju mer tid som läggs på testande desto fler fel hittas, men för att spendera dentiden effektivt bör man till exempel inte låta utvecklaren vara testperson.

1 Inledning

En testledare ser på testning som en process där man försöker förstöranågot. För att på bästa sätt förstöra objekten i projektet skrevs en testplan.Testplanen hade som syfte att ge riktlinjer till gruppens medlemmar omhur projektets komponenter skulle testas, med målet att minska antaletfel i produkten. Den skrevs baserat på tidigare erfarenheter och det finnsmed stor sannolikhet mycket som kan göras bättre. Det kan därför varaintressant att behandla vad som inte fångades upp i testningen och föreslåförbättringar.

Systemet som testades var ett 3D-scanningssystem i kursen TDDD96 vidLinköpings universitet. Testningen gjordes i form av variant av random-testning eller slumptestning.

1.1 Syfte

Denna individuella rapport önskar att diskutera hur bra testningen gickoch vad som kunde förbättras. Den önskar även utvärdera metoden föratt uppnå kundens krav på robusthet och en utvärdering av testprocessen.Detta görs för att få mer erfarenhet om just testning genom att analyseravad testningen inte fångade upp.


Det blev mer uppenbart att testerna aldrig kunde bli fullständiga och täc-ka alla aspekter, även om det var målet. Genom projektet hittades fel, nyatester som borde ha gjorts i testobjekt som ansetts godkända. Det kan

41

bero på många olika aspekter, som de olika erfarenheterna hos testarna,hur testplanen utformades, vad det var som testades och vad för typ avtest som gjordes. Vad fångades inte upp av testningen och varför? Hur kantestningen förbättras? Hur påverkades produkten av testningen?

1.3 Avgränsningar

Andra faktorer utöver erfarenhet, testplan, testobjekt eller testtyp kommerinte att behandlas. Bara tester gjorda i projektet behandlas. Acceptanstestbehandlas inte.

2 Teori

Projektets funktionalitet testas för att kontollera att de uppfyller de kravsom ställts av kunden. Det testades med hjälp av slumptestning

2.1 Slumptestning

Slumptestning är när till synes slumpvalda indata används för att testaen funktion. Testplanen är skriven i ändamål att välja de indatan så attde täcker mycket av funktionaliteten som möjligt. Till exempel ska enfunktions gränser utforskas när de är definierade, då det är typiskt att feluppstår där. Inte nödvändigtvis gränstestning då minst ett testfall mellangränserna ska göras, som är slumpat. Testplanen önskade ge riktlinjer förvilka typer av tester som väljs i ett försök att välja mera kvalificeradevärden än helt slumpade. Generellt gäller att ju mer tid som läggs påslumptestning desto fler fel hittas och det planerades att 15 procent avtiden för en given aktivitet skulle läggas för att testa den. [13]

2.2 Systemet

Systemet som testades var ett 3D-scanningssystem bestående av en lin-järenhet, avståndskamera och rotationsbord. De kontrolleras tillsammansav två datorer genom ett CLI. Systemet ska föra kameran längs med linjä-renheten så att kameran kan mäta avstånd och intensitet på objektet somsitter på rotationsbordet.

Kameran skickar fulla bufferts tillbaka till användaren. Mängden profilerper buffert bestämmer hur många avläsningar kameran gör på en scan-ning.

42

Tabell 2.1: Exempel på testfallsredovisning.

# Typ Funktion Förväntat utdata Staus Kommentar

CEABE7 Test av wrapper förSickIVP-Kamera

1 Klant Starta kameran innan den blivitinitialiserad.

Kasta error som sä-ger att kameran är ifel tillstånd.

Godkänt2016-04-12

2 Fel Initialisera kameran med fel pa-rametertyp, en initialisering perparameter.

Kasta AttributeEr-ror/TypeError.

Misslyckat2016-04-12

Misslyckas init så ini-tiliseras fortfarandekameran trots att detär fel. Klagar inte pånågon konstig indatapå timeout. Konstigterror 6100 för kons-tiga parametrar förprofile_per_bufferoch buffer_size.

3 Fel Initialisera kameran med fel ip-address, orimligt stor profil-perbuffer, orimligt liten buffer.Kontrollera tillstånd innan ochefter.

Kasta att kameran in-te blir initialiserad.

Misslyckat2016-04-12

Se kommentar förtest 2.

4 Gräns Initialisera kameran med givnavärden. Kontrollera tillstånd in-nan och efter.

Tillståndet ändratstill stopped.

Godkänt2016-04-12

2.3 Testprocess

När utvecklaren hade skrivit klart en komponent valde utvecklaren eneller flera testpersoner och meddelade sedan testledaren. Testledaren ochtestpersonen skrev sedan ett antal testfall baserat på information från test-planen. Testningen genomfördes av testpersoner som hade ingen till väl-digt lite koll på hur funktionera var byggda, med s.k. blackbox-testning.Blackbox-testning är när en testare vet vad som systemet borde ge för ut-data vid givet indata men vet inte vad som händer inuti. Motsvarighetenwhitebox-testning är när testpersonen läser koden under testet. I tabell 2.1visas hur testfallen redovisades med de fyra första testfallen från ett fak-tiskt test. I det fallet då testet inte blev godkänt meddelades utvecklarensom fick laga felen. Samma tester kördes sedan igen från början.

3 Metod

Felen som uppstått i funktioner som ansetts godkända kommer att analy-seras. Det gjordes flera tester av olika personer, för att göra det möjligt attjämföra olika felmängder som släpps igenom. Det är möjligt att testernablir bättre täckande mot slutet av projektet relativt i början och att det ären fråga om erfarenhet, och uppdatering av testplanen som skett över tid.

Utöver testerna som utfördes gjordes en intervju med gruppens medlem-mar om testningen. Intervjun skrevs med hjälp av introduktion om hurman skrivet intervjuer [5]. Under intervjun ställdes frågor om hur täckan-

43

de testningen upplevdes, vad som kan förbättras och vilka buggar somkan ha tagit sig igenom. Intervjufrågorna återfinnes i appendix B.

4 Resultat

Den generella åsikten om testning i gruppen är att det tar mycket tid ochär jobbigt men krävs för att säkerställa kvalitet och de krav som uppställdaför projektet. Att göra ett formellt test ansågs nödvändigt. Gruppen ansågäven att de test som gjordes var “ganska noggrant”, och en tyckte atttestningen var bristfällig då det under ett acceptanstest behövde starta omsystemet.

Utvecklarna hade delade åsikter om de hade gjort ett bättre jobb om detestat sina egna objekt i ett formellt test. Där en utvecklare tyckte att dennevisste om alla buggar som testpersonen hade hittat när utvecklaren påstodsitt arbete vara redo att testas. På frågan om varför utvecklaren lämnatifrån sig något som fortfarande hade buggar blev svaret att de var felsom systemet aldrig skulle utsättas för och det fanns inte tid att fixa dem,några fångades upp och andra smet igenom.

4.1 Testfall och genomförande

Alla testpersoner önskade sig tydligare testinstruktioner från utvecklarna,men informationen var bra. De använde sig inte av testplanen mer än engenomläsning. De känner att det finns buggar som kan ha fallit igenom,men kan inte riktigt berätta vad för fel det skulle kunna vara. De kändeatt processen skulle kunna förbättras och en föreslog att flera personerkunde skriva testfall.

Av alla testfall misslyckades 14 stycken. Bland annat felsatta gränser ochen konstig timeout. Totalt testades sex testobjekt med runt tio fall var. Tvåav objekten blev godkänt vid första testningen varav ett behöves testasigen med fler fall och misslyckades då.

4.1.1 Utvecklare som testare

Utvecklarna i gruppen kände generellt att de hade hittat fler buggar äntestpersonerna, även om några uppskattade angreppssättet som en test-person som inte utvecklat koden har. Testpersonerna ansåg att de gör alla“användarmisstag” som en utvecklare inte gör.

44

4.2 Buggar

Enligt intervjupersonerna finns det två kända buggar som inte fångadesupp av testningen. En av dem som inte testades var när man har mångaprofiler per buffert och linjärenheten rör sig snabbt så kan systemet intehinna med att behandla alla punkter. Mängden profiler per buffert be-stämmer hur många avläsningar kameran gör på en scanning. Många pro-filer per buffert ger en noggrannare scanning. Det i sin tur sades genereraen krash utan någon vidare hantering.

Den andra är en buffert som finns i styrenheten. Om ett meddelandemisslyckas att läsas så kompenserar inte bufferten för det. Då kommerbufferten försöka läsa meddelandet, men kommer aldrig lyckas. Det sombehövs göra är att skicka tillbaka något till Windows-datorn för att talaom att något gått snett och sedan rensa bufferten.

Även om det fångades upp i testningen så hanterades det aldrig att bordetmystiskt får timeouts. Det tros bero på att den ibland står still för längeoch sedan slutar svara.

4.2.1 Möjliga buggar

Under intervju frågades gruppen om vad som kan innehålla buggar. Detsades att det troligen inte är fel i hårdvaruenheterna och att det var fel ifelhanteringen sades flera gånger.

4.3 Testernas påverkan

Gruppen ansåg att testningsprocessen var givande. Den tidsuppskattning-en som gjordes i början ansågs vara en bra uppskattning och är ganskanära den tiden som lades på testning. Även om det ansågs jobbigt attstanna och testa komponenterna tros det ha gjort produkten bättre. Attutvecklaren inte fick vara testperson gjorde att minst en bugg hittades dådet vid testning av kameran hittades buggar som utvecklaren hävdar attdenne helt missat.

Det går inte annat än konstatera att fel hittades i testerna. Även om allainte fixades och berodde på aspekter som tid mellan körning. Många avfelen åtgärdades dock.

4.3.1 Förbättringsförslag

Det upp kom ett förbättringsförslag under intervjun. Istället för att bara haen eller flera testpersoner som inte har varit med och utvecklat koden, ut-föra testet tillsammans med utvecklaren. Även att göra whitebox-testning

45

i konjunktion med den blackbox-testningen som gjordes. “Det finns ettantal ställen man kan förstöra om man vet hur det fungerar.”Att minsttvå eller tre personer som testar istället för minst en var också ett förslag.

5 Diskussion

Det många som tyckte att testningen var ganska noggrann. Det har haft enpositiv inverkan på produkten, men var den positiva inverkan tillräcklig?

5.1 Testbrister

Det var människor som skrev och utförde testet och de gjordes utifrån enguide på en mall som även den gjordes av en människa. Det är även up-penbart att ju mer testning som görs, desto fler fel hittas [13] och mallenvar designad för att spara tid i byggandet av testet. Var bristerna i mallenför testet eller i personerna som utförde testet? Det märktes, av testleda-ren, en tydlig skillnad mellan de olika testpersonerna, som inte försöktekontrolleras utan uppmuntrades. En del var väldigt noga och skrev flerfall än vad som krävdes när andra ville följa testplanen så noga som möj-ligt och gjorde inte mycket mer än vad som stod.

Skillnaderna mellan personer spelar roll även om alla i stora drag följdetestplanen. Men varför fångades inte de fel som utvecklarna visste omupp? Det var antingen i väldigt specifika fall som något gick fel eller attnågot inte går som planerat, som att ett meddelande inte går att läsa. Hursimuleras det att något inte går som planerat? Det går att dra ut en sladd,det går att ge fel indata men varför skulle det spela någon roll om bordetstått stilla för länge? Och den buggen fångades upp av testningen, menåtgärdades inte och passerade nästa test då tid mellan kommandon intevar något testarna tog hänsyn till.

Buggen med för hög profileer per buffert testades inte, men borde hatestats. Att kunna ändra hastigheten på linjärenheten var inte ett krav ochdet fanns därför inga tankar på att en snabbare linjärenhet kunde genererafel. Detta var även känt av utvecklaren innan det lämnades för testning.Det är svårt att tro att om utvecklaren medvetet lämnat ifrån sig en buggatt denne hade rapporterat buggen vid ett formellt test.

Det gjordes några felhanteringstester och även om det aldrig är kul medfel bedömdes det som att de gav tillräckligt med information till använ-daren för att klassas som robust. Det är svårt att testa allt som kan gå fel,men fler fel hittas ju längre man testar [13].

46

5.2 Förbättringsförslag

Två personer i gruppen föreslog att man kunde använda whitebox-testningistället för eller i konjunktion med den blackbox-testningen som gjordes.Ännu fler ansåg att de hade hittat fler buggar än testpersonerna som tes-tade deras kod och bara en ansåg att en bugg bara hade hittats om det varnågon annan än utvecklaren som gjort testet.

Whitebox i konjunktion hade resulterat i att utvecklaren närvarat vidtestet. Alltså minst en som inte kan koden och en som kan den. Det skulleutvecklaren göra i första versionen, men det avskaffades då det ansågsonödigt då informationen utvecklaren behövde dela med sig lika gärnakunde skrivas ner. Att utvecklaren är med och testar det denne ansernödvändigt med kunskap om sin kod är dock ett rimligt förslag. Denuppenbara nackdelen är tiden. Som det var formulerat kunde en personensam testa ett objekt. Om utvecklaren måste närvara så blir det minsttvå. Att vara fler än minst en person var också ett förbättringsförslag frånintervjun. Var det då för få som testade och inte fel personer? Troligenhade fler idéer om hur objekten kunde utmanats blivit föreslagna om flerpersoner tagit del i skrivandet av testfallen. Kanske var det värt tiden?

Bara whitebox-testning hade det blivit om utvecklaren hade lärt och visatkoden för testpersonerna. Även där är det uppenbara problemet tiden,då testpersonerna måste lära sig koden de testar, istället för att fokuserapå det som är viktigt, det vill säga funktionaliteten mot kraven. Troligtär att den tiden överstiger den utsatta 15 procent i bara utlärande. Attbara utvecklaren testar löser det problemet, men får då konsekvensen attutvecklaren kan vara blind för sin egna kod.

6 Slutsatser

Det var en del fel som inte fångades upp av testningen. De hade nog intefångats upp av att utvecklaren testat systemet då utvecklarna lämnadeifrån sig buggarna från början. Det skulle kunna vara för att kraven intetäckte vad som gjordes.

Det kan varit värt att ha mer resurser på testning, och även om testproces-sen går att ändra tolkas resultatet som en resursfråga. Whitebox-testing ären bra idé. Problemet är den grundtiden det skulle ta för en utomståendeatt lära sig koden. Att göra det i konjunktion var tanken från början, mendet slopades då flera utvecklare kände att de kunde göra samma jobb medhjälp av en mall.

Det hittades buggar, gruppen kände att testningen gav något. Testningengav, utan tvekan, en positiv effekt på produkten.

Testning ansågs vara tidskrävande och kan avbryta utvecklingsflödet. Detär väldigt viktigt men “man gör hellre annat än testa”.

47

Konsistensanalys av dokumentkod ochtypografi

Henrik Henriksson

Under ett projekt användes LATEX som typsättningssystem för all dokumentation.Nästan alla i projektgruppen var nya med detta system men lärde sig det snabbt.Under projektet utvecklades olika dokument av olika människor på olika sätt, därsärskillt kod och typografi skiljde sig åt. Dessutom fanns kod i projektet som i vissmån kunde anses vara felaktig. De dokument som utvecklades under projektetanalyserades med fokus på konsistens och korrekthet, varvid förbättringar föreslåsför funna fel och inkonsistenser. De uppmärksammade felområdena var enkla i sinnatur; det är troligen den stora mängden av möjliga fel som ställer till problemför skribenter.

1 Inledning

Tidigt i projektet gjordes valet att använda LATEX som typsättningssystem.Många i projektgruppen var nya och oerfarna med detta system, någotsom märktes i tidiga dokument. Särskilt noterades hur två olika skriben-ter ofta löste samma problem på två olika sätt. Dessutom fanns mångaregelrätta fel i kodbasen. Går detta att undvika?

1.1 Syfte

Denna individuella rapport avser att identifiera de problem som nybörjarestöter på när de börjar LATEX, med syfte att föreslå metoder för att mitigeraeller helt eliminera dessa problem i framtida projekt. De problem som iförsta hand behandlas är konsistensproblem i LATEX-kod, alltså då olikaskribenter försökt genomföra samma sak med olika kod.


För att kunna identifiera problemområden utnyttjas den kodbas som ska-pats under projektets gång. Vilka kodmässiga inkonsistenser och problem ex-isterar i vår kodbas? Dessa problem bör kunna lösas på något sätt för attanalysen ska vara till nytta. Hur kan dessa problem undvikas?

49

1.3 Avgränsningar

För att hålla rapporten inriktad mot tekniska aspekter kommer språk säl-lan att behandlas. Vissa språkliga aspekter kan behandlas översiktligt dåde anses vara relevanta till struktur eller typografi.

Versionshantering och samarbete i större projekt är ett ämne som de flestaprogrammerare är väl insatta i. Versionshantering av dokumentens käll-kod och samarbete i dessa dokument anses därför vara ett, i samman-hanget, löst problem.

Språk som utgör alternativ till LATEX, till exempel Markdown1 och Troff 2 harbåde fördelar och nackdelar jämfört med LATEX. Dessa alternativa språkkommer inte behandlas.

2 Teori

Att kalla LATEX för ett språk är egentligen något missvisande, då LATEXär ett macropaket byggt ovanpå typsättningsspråket TEX1. LATEX bygger påprincipen att författaren inte ska formatera dokumentet, utan istället spe-cificera dokumentets struktur, varvid typsättningssystemet ansvarar föratt typsätta detta på ett korrekt sätt. Detta kan självklart missbrukas ochförbigås, vilket är anledningen till att denna rapport finns.

I LATEX används kommandon och miljöer för att specificera både strukturoch formatering. Kommandon skrivs som

\maketitle % Kommando utan argument\emph{Kommando med argument}

medan miljöer skrivs som

\begin{equation}e^{-i\pi} = -1

\end{equation}

för att till exempel typsätta ekvationer. Det finns hundratals kommandonoch miljöer, och det är dessutom fritt fram för användaren att definieraegna. All text som inte utgör kommandon eller miljöer behandlas somlöptext. Före själva innehållet i dokumentet börjar finns en preamble, därdet går att specificera inställningar, variabler och använda paket.

1http://daringfireball.net/projects/markdown/2http://www.troff.org/1Språket TEX skapades av på slutet av 1970-talet av Donald Knuth för att typsätta bokse-

rien The Art of Computer Programming, då han inte hittade något annat som uppfyllde hanskrav.

50

3 Metod

I huvudsak har data tagits fram genom en analys av den LATEX-källkodsom skrivits i samband med projektet. Källkoden har hanterats med ver-sionshanteringsverktyget git [9], något som lett till att det funnits en nog-grann fullständig versionshistorik för alla dokument i projektet.

3.1 Analys av existerande källkod och dokument

För att hitta inkonsistenser och problem användes två huvudsakliga me-toder. Dels en konsistensanalys av källkod, både senaste versionen ochhistorisk1, med avsikt att identifiera platser där skribenter har löst sammasak på olika sätt, och dels en jämförelse av delar av koden mot rådandepraxis. Allmänna uppenbara felaktigheter noterades även med avsikt attundvika dessa i framtida projekt. Som referens för gällande praxis använ-des The LATEX Companion [14]. Då intressant data blev funnen noteradesdetta för att få en samling problem och inkonsistenser som kunde analy-seras.

3.2 Att undvika problem

För att ta fram ett förslag för att undvika upptäckta problemområdengjordes en jämförelse mot rådande praxis. Liksom i analysen användesThe LATEX Companion [14]. Då flera olika implementationer för ett visstproblem fanns ansågs det sätt som föreslogs i denna bok vara praxis.Detta hade till avsikt att föreslå en av de använda metoderna för framtidaanvändning.

4 Resultat

De framtagna resultaten är uppdelade i problematik dels relaterat till denbakomliggande källkoden och dels relaterat till typografi.

4.1 Kod

Vanliga problem ifrån källkod i andra programmeringsspråk kan hittasäven i projektets kodbas. Kodformatering, namngivning, syntax och kom-mentarer är alla identifierade som problemområden.

1git log –all –graph –oneline -p användes flitigt, då kontext ofta inte var nödvän-digt.

51

4.1.1 Kodformatering

I kodbasen återfanns flera sorters formatering av LATEX-koden. Indenteringav källkoden var inte konsekvent genom hela kodbasen, utan flera sortersindentering användes. Figur 4.1 är ett exempel på de två huvudsakligaindenteringsstilar som har använts, men även blandningar av dessa stilarhar förekommit. Hur kod är indenterad och visuellt upplagd tros påverkaläsbarheten av källkoden och har varit av intresse under lång tid [15].

Ett mindre problem har varit hur vissa gruppmedlemmar har föredragit ejradbruten löptext i koden, medan andra har föredragit löptext radbrutentill ungefär 80 tecken. Denna inkonsistens bör vara enkel att undvika medhjälp av interna standardiseringsöverenskommelser.

I de kodexempel som presenteras i The LATEX Companion används oftast enindenteringsnivå på ett blanksteg, även om detta frångås vid vissa tillfäl-len till fördel för djupare indenteringsnivåer.

\begin{itemize}\item Lorem

\begin{itemize}\item Ipsum\item Dolor

\end{itemize}\item Sit\item Amet

\end{itemize}

\begin{itemize}\item Lorem\begin{itemize}\item Ipsum\item Dolor\end{itemize}\item Sit\item Amet\end{itemize}

• Lorem

– Ipsum

– Dolor

• Sit

• Amet

Figur 4.1: Två till betydelsen identiska kodstycken tillsammans med detkompilerade resultatet.

4.1.2 Namngivning

Under utvecklingen har namngivningsstandarder för figurreferenser, styc-kesreferenser och citationer saknats. Detta kan i teorin leda till problemsom är svåra att upptäcka då sådana namn ligger i en global namnrymd.Krockar kan leda till felaktiga referenser om författaren inte aktivt läserfelmeddelanden och varningar från kompilatorn. I praktiken har inga pro-blem uppkommit eftersom antalet figurer har varit relativt lågt.

Vid namngivning av referenser används ibland prefix för att annotera typ.Tabell 4.1 innehåller ett förslag på namngivning. Detta kan standardiserasnoggrannare efter behov.

4.1.3 Citationstecken

En skillnad mellan LATEX och de flesta andra verktyg är hur citationstec-ken skrivs i kod. “Normala” citationstecken, ", leder oftast till ett helt

52

Tabell 4.1: Förslag på namngivningsprefix.

Typ Prefix

Figur fig:Tabell tab:Appendix app:Kapitel chap:Sektion sect:

felaktigt resultat. I LATEX-kod används istället ‘‘text’’. Detta, för många,abnormala beteende kring citationstecken har lett till vissa problem i ko-den under projektets gång. Figur 4.2 demonstrerar de typer av felanvän-da citationstecken som förekommit. Notera att citationstecken kan varieraberonde på vilket språk texten skrivs med.

‘‘Korrekta citationstecken ’’ \\’’Inkorrekta citationstecken ’’ \\’’Mer inkorrekta citationstecken ‘‘ \\"Mycket inkorrekta citationstecken" \\

“Korrekta citationstecken””Inkorrekta citationstecken””Mer inkorrekta citationstecken“Mycket inkorrekta citationstecken"

Figur 4.2: Exempel på felaktig användning av citationstecken. Skillna-derna mellan de tre första raderna är små, medan den sista raden intefungerar alls.

4.1.4 Textformatering

En fördel med LATEX är att skribenten kan specificera vad text represen-terar, istället för att specificera hur den ska vara typsatt. Själva typsätt-ningen kan sedan specificeras separat. Ett exempel på detta tänk är dennågot subtila skillnaden mellan betoning och kursivering. Även om detkompilerade resultatet mellan betoning och kursivering oftast är identisktkommer en betoning fungera även i kursiverad text, ett exempel på dettafinns i figur 4.3. Detta fel, men även andra liknande fel, förekom i kodba-sen.

Det förekom även inkonsistent användning av textformatering, till exem-pel referenser till interna dokument både med och utan skrivmaskinstyp-snitt och kursiva typsnitt. Då användning av betoningar, kursiv text ochskrivmaskinstypsnitt skiljer sig mycket beroende på språk, ämnesområdeär det svårt att ge svar på hur skribenten bör göra.

53

Lorem \emph{ipsum} dolor \\Lorem \textsl{ipsum} dolor \\\textsl{Lorem \textsl{ipsum} dolor} \\\textsl{Lorem \emph{ipsum} dolor} \\

Lorem ipsum dolorLorem ipsum dolorLorem ipsum dolorLorem ipsum dolor

Figur 4.3: Effekten av betoning och kursiv text.

4.1.5 Kommentarer och anteckningar

I koden förekom olika typer av kommentarer och anteckningar författareskrivit för att komma ihåg att göra saker senare. LATEX har stöd för kom-mentarer, allt mellan procenttecken och radbrytning ignoreras av kompi-latorn. Detta har används för kommentarer och anteckningar på sammasätt som kommentarer i programkod skriven i andra språk. En annan me-tod som använts är anteckningar skrivna direkt i löptexten, med någonform av separator, oftast **, för att de ska sticka ut. Dessa anteckningarhar varit problematiska, då de kommer med i det kompilerade resultatet.** TODO: Lägg till exempel på detta.** Ytterligare har paketet todonotesanvänts. Detta paket tillåter att man placerar egna anteckningar i margi-nalen på dokumentet med kommandot \todo{Exempel}. Dessa kan sedanstängas av med en enkel flagga i preamble.

4.2 Typografi

De typografiska inkonsistenser som identifierats och behandlats presen-teras nedan. Även om exempelvis formatering av siffror i löptext och av-stavning av referenser kan tyckas vara små detaljer anses de ändå varaintressanta.

4.2.1 Hur formaterar man definitionslistor?

Ett vanligt problem var formatering av definitionslistor och begreppslis-tor. Dessa har i koden typsatts med miljön description, fetstilt text i kom-bination med framtvingade radbrytningar, rubriknivån \paragraph{} ochett egenspecificerat kommando vid namn \definition{}. Figur 4.4 inne-håller exempel på några av de metoder som förekommit i koden.

4.2.2 Siffror i löptext

Flera sorters formatering av siffror har använts, även om skillnaden mel-lan dessa är ganska liten. I vissa fall har kommatecken använts som deci-maltecken och i andra fall punkter. Dessutom användes matematikmiljöeri vissa sammanhang även i löptext.

54

\paragraph{Paragrafer} används av vissa ?\\\textbf{Fetstilt text} används av andra?\begin{description}\item[Miljön description] kanske är bra?

\end{description}

Paragrafer används av vissa?Fetstilt text används av andra?Miljön description kanske är bra?

Figur 4.4: Några exempel på hur listor på beskrivningar typsatts i kodba-sen. Notera skillnaden i radavstånd och mellanrummens bredd.

Skillnaden mellan 1234, 567 och 1234,567 är märkbar beroende på typ-snitt. Den tidigare är typsatt enligt $1234,567$ och den senare med en-bart 1234,567. Den tidigare modellen, typsatt i en matematikmiljö, böranvändas för bland annat matematik och numeriska resultat, medan densenare bör användas då siffrorna är en del av texten, såsom årtal.

4.2.3 Obrytbara mellanrum

Vid referensanvändning bör obrytbara mellanrum användas mellan re-ferensen och ordet före referensen för att referensen inte ska avstavas. Ikodbasen användes referenser tillsammans med både brytbara och ickebrytbara mellanrum. Ett obrytbara mellanrum skrivs i LATEX med ett til-de (~) och referenser bör följaktligen användas enligt~\ref{fig:refs}.

4.2.4 Tabeller

Tabeller har under projektets gång typsatts olika. Figur 4.5 visar någraexempel av tabelltypsättning som förekommit. Det bör påpekas att ingetav dessa exempel är felaktiga, de är enbart olika.

Lorem ipsum dolor

sit amet sitelit malis aeternoan nam reque

Lorem ipsum dolorsit amet sitelit malis aeternoan nam reque

Lorem ipsum dolorsit amet sitelit malis aeternoan nam reque

Figur 4.5: Exempel på olika typsättning av tabeller.

5 Diskussion

Det är viktigt att notera att även om mycket av det material som resulta-tet bygger på är skrivet av nybörjare i LATEX så är det fortfarande skrivetav vana programmerare. Konstig syntax och “mystiska” kommandon äralltså antagligen inte ett lika stort problem som med mindre programme-ringsvana skribenter.

Många av problemen som identifierats är av en relativt enkel natur. Tillexempel är det nästan trivialt att använda korrekt syntax för citattecken

55

om man känner till den. Samma sak verkar gälla även för andra problem-områden. De är lätta att göra rätt om man känner till dem, det svåra är attkänna till dem. Under projektet fick medlemmarna i gruppen relativt liteutbildning, en snabbkurs i hur man kompilerar LATEX och ett exempeldo-kument tillsammans med en kort beskrivning. Avsaknaden av mer utför-lig utbildning kan förklara vissa av felen, till exempel citattecken.

5.1 Hur undviker man felen?

De fel som funnits i materialet är till största delen ganska enkla och böräven vara ganska enkla att avhjälpa. Problemet verkar snarare vara antaletolika detaljer författaren måste komma ihåg för att få ett korrekt resultat.Det finns flera sätt att minska bördan på författaren.

5.1.1 Abstraktion

Ett sätt att gömma undan problemområden är att abstrahera bort dem. Jufärre saker skribenten behöver bekymra sig om, ju färre fel kan denna gö-ra. Dan Langmyhrs makropaket StarTEX har till exempel valt att helt döljakommandon för “visual mark-up” och ytterligare gömma alla interna TEXkommandon. Ett exempel ur Langmyhrs paket är hantering av figurer.Exempelkod för typsättning av en figur i vanlig LATEX visas i figur 5.1.I fallet StarTEX används enbart ett kommando för att skapa hela figuren,med figurtext och filnamn som argument. Skribenten behöver till exempelinte bry sig om att centrera bilden. [16]

\begin{figure}\centering\includegraphics{flygplan.ps}\caption{Skiss av flygplan .}

\end{figure}

Figur 5.1: Exempel på hur en figur typsätts i LATEX.

Den stora nackdelen med abstraktion är densamma som dess fördel, mangömmer den underliggande komplexiteten. Skribenten blir låst till ab-straktionen och kan inte med samma enkelhet gå ner på detaljnivå, tillexempel för att skapa en figur som inte är centrerad. Detta kan tvingaskribenten till att försöka kringgå abstraktionen på något sätt, varvid ab-straktionen blir verkningslös.

5.1.2 Detektion

En möjlighet är att låta skribentens utvecklingsmiljö hjälpa till genom attdetektera vanliga fel utifrån källkoden. Detta kan göras med en så kallad

56

linter. En linter för LATEX är ChkTEX. Denna kan detektera många av defel som hittats i projektets kodbas, bland annat avsaknad av obrytbaramellanrum och felaktiga citattecken. [17]

Även om sådana verktyg existerar krävs att de aktivt används av skriben-ten. I fallet ChkTEX finns ett kommandoradsgränssnitt. Även om skriben-ten manuellt kan köra en linter över sin kod är det fördelaktigt om detsker automatiskt. Det finns LATEX-linters integrerade i textredigerare. [17]

Att ha en linter integrerad i en utvecklingsmiljö tillåter en betydligt snab-bare och enklare återkoppling för skribenten. Problem med en sådan mil-jö kan uppstå vid installation och konfiguration. Dessutom kommer enlinter enbart ge rekommendationer och informera skribenten. Skribentenkan helt ignorera detekterade felaktigheter. Det är även värt att notera attdet finns en viss risk för falsk detektion.

5.1.3 Utbildning

Under projektet fick projektmedlemmarna en begränsad introduktion tillLATEX. Introduktionen inkluderade inte några vanliga fel som bör undvi-kas. Att informera nya skribenter om vad som ofta går fel kan vara mycketfördelaktigt, då det troligtvis ökar medvetenheten kring hur koden ser ut.Vad är okej, vad är inte okej? Vad är bra, vad är dåligt?

5.1.4 Standardisering

Av de fel som uppmärksammats kan ett flertal lösas med standardisering.Standarder för indentering, kommentarer, formatering och namngivningfinns redan för många andra språk, till exempel den standard för python-kod som använts under projektet, PEP8 [12]. Författaren har inte tyvärrfunnit någon standardiserad stilguide för LATEX. Att i början av ett projektkomma överrens om projektspecifika standarder kan vara mycket fördel-aktigt.

5.2 Metod

Att göra en liknande studie på mindre programmeringsvana skribenterkommer troligen ge andra resultat. Programmerare är vana med att arbetamot en specifik syntax och struktur, varför karaktär på inkonsistenser ochfel troligtvis skulle förändras med andra skribenter.

6 Slutsatser

Även om de fel, brister och inkonsistenser som presenteras i denna rap-port inte är uttömmande sänker de kvaliteten på resultatet avsevärt. Att

57

undvika dessa på något sätt är av yttersta vikt för ett resultat av hög kva-litet, oavsett hur man undviker dem. Utbildning, standardisering och fel-detektion kompletterar varandra väl och bör tillämpas tillsammans. Ävenom abstraktion är ett kraftfullt verktyg kan det ställa till problem i merkomplicerade projekt, då skribenter antingen begränsas av abstraktions-lagren eller hittar sätt att kringgå dem.

Resultatet tyder på att det inte är komplexa problem som är jobbiga, ut-an väldigt enkla detaljer. Det är, särskilt för nya LATEX-skribenter, mångadetaljer att hålla ordning på. Det är mängd, snarare än komplexitet somutgör huvudproblemet.

58

Återanvändning av delsystem vidrekonstruktion

Niklas Hätty

I ett ombyggt system återanvändes en kommunikationslänk mellan två hårdvaru-enheter. I den här rapporten bestämdes vilka begränsningar som systemet fick tillföljd av detta val. Eventuella problem som systemet fick till följd av återanvänd-ningen identifierades även.

Det fastställdes genom en teoretisk analys att systemet fick en del mindre bety-dande begränsningar på hur fritt systemet kunde kontrolleras med inställningar.Samtidigt identifierades en del problem vilket gjorde att resultatet av en scanninginte blev helt skalenligt. Detta begränsade friheten av systemets styrning.

1 Inledning

En del av hårdvaran till det kompletta system för 3D-scanning som ut-vecklades i projektarbetet är en avståndskamera av modell SICK IVP Ru-ler E2111 och en linjärenhet av modell Origa systems plus med tillhörandeservo av märke Technosoft systems. Avståndskameran mäter avstånd frånkamera till objekt samtidigt som linjärenheten flyttar kameran i sidled.Dessa två delar var inför projektet redan valda och ihopkopplade. Dessatvå delar hade redan en fungerande kommunikationslänk där linjärenhe-ten styrde när avståndskameran skulle göra en mätning. För denna kom-munikationslänk hittades ingen dokumentation, vilket gav projektgrup-pen ett val att (i) bygga om kommunikationslänken, (ii) delvis bygga omkommunikationslänken, eller (iii) använda den existerande implementa-tion och få den att fungera med det nya systemet.

I projektets planeringsfas valde man att använda den tidigare implemen-tationen och integrera in den i det nya systemet. Detta gjordes med sär-skild hänsyn till projektgruppens bristande erfarenheter av liknande hård-vara. Den här individuella del av rapporten undersöker detta tillväga-gångssätt för att utvärdera hur lämpligt det var med avseende på eventu-ella begränsningar och resulterande problem.

59

1.1 Syfte

Denna individuella del av rapporten undersöker hur implementationenav en kommunikationslänk mellan två enheter i ett system hanteradesvid omkonstruktion. Syftet är att få en bättre förståelse för hur återan-vändning av delar vid omkonstruktion kan påverka slutresultatet, ochhur detta kan hanteras i liknande projekt.


I den här rapporten analyseras och utvärderas valet att återanvända enexisterande kommunikationslänk vid omkonstruktionen. Mer specifikt ärdet av intresse att bestämma eventuella begränsningar som systemet ficktill följd av att integrera den tidigare kommunikationslänken i ett nyttsystem. Vilka begränsningar fick systemet till följd av att använda en existerandekommunikationslänk?

I det fall då kommunikationslänken inte byggs om kan det uppkommaen del problem, som också undersöks. Vilka problem uppkom till följd avanvändandet av den existerande kommunikationslänken och hade de undvikitsom kommunikationslänken helt byggdes om?

1.3 Avgränsningar

I den här rapporten undersöks kommunikationslänken mellan avstånds-kameran och linjärenheten. Andra delar av systemet behandlas inte såvidade är direkt påverkade av den tidigare nämnda kommunikationslänken.

2 Teori

Den huvudsakliga teorin består av förståelse för hur systemet fungerar.Det är främst två enheter som är intressanta, avståndskameran och linjä-renheten, samt hur dessa ingår i systemet.

2.1 Avståndskameran SICK IVP RULER E2111

Avståndskameran mäter precisa avstånd och är utvecklad för att kunnaanvändas i ett system för 3D-scanning. När mjukvaran ber kameran attgöra en mätning gör den mätningar på en rak laserlinje. Mätdatan läggssedan i vad som kallas en profil. När linjärenheten rör sig i sidled byggsett punktmoln upp av alla profiler i en scanning. I detta projekt användes

60

Figur 2.1: Illustration av en halvfärdig scanning.

en inställning som innebar att en mätning skedde när den fick en utom-stående puls från linjärenheten. Avståndskameran styrs med ett API ochen inställningsfil som skapas med programvara från tillverkaren.

2.2 Linjärenheten

Linjärenheten är en enhet med hög mekanisk precision som flyttar ettobjekt i sidled. I detta fall flyttades avståndskameran i sidled för fylla i ettpunktmoln med mätdata. Den har en inställbar initial accelerationsperiodinnan den når en stadig hastighet.

2.3 Systemet

Figur 2.1 visar hur uppsättningen av de två ovanstående delarna ser ut ipraktiken. Det som är mest intressant för denna rapport är relationen mel-lan avståndskameran och linjärenheten. När linjärenheten flyttar kameranöver en initial punkt börjar den skicka en puls till avståndskameran sombörjar göra mätningar. Linjärenheten skickar sedan ut en puls med en förprojektet okänd frekvens för att tala om när avståndskameran ska göraen mätning och fylla en profil. Kommunikationen mellan avståndskame-ran och linjärenheten sker troligen seriellt via en kommunikationslänk.Denna kommunikationslänk är existerande från det äldre systemet ochimplementerades när systemet skapades för att låta linjärenheten kom-municera med avståndskameran. Rent hårdvarumässigt är det dock intemer än en seriellkabel mellan de båda enheterna. Information om hurkommunikationen gick till i det gamla systemet har tagits fram genomtester av systemet, eftersom det inte finns någon dokumentation mer änseparat för varje enhet. Således är informationen inte helt säkerhetsställd.

61

3 Metod

I den här rapporten fastställdes vilka begränsningar som systemet ficksom direkt följd av användandet av den existerande kommunikationenmellan avståndskameran och linjärenheten. Begränsningarna bestäms idenna rapport med avseende på två kriterier som definieras enligt föl-jande:

Modularitet Till vilken grad ett system eller program bestående av dis-kreta komponenter är konstruerat på ett sätt som gör att en för-ändring av en enskild komponent har minimal påverkan på andrakomponenter [2].

Utvecklingsmöjlighet Hur enkelt det är att vidareutveckla systemet.

För att göra detta var det främst systemet som analyserades teoretisktmed en variant av Ad Hoc testning [18] där systemet utforskades utandokumenterade testfall. Anledningen till detta är att de formella testersom utförts på systemet inte hade syftet att finna eventuella begränsningareller problem som är relevant för denna rapport.

3.1 Metod för att bestämma begränsningar

För systemets begränsningar undersöktes kriterier som modularitet ochutvecklingsmöjlighet. I Ad Hoc testerna undersöktes dokumentation förde två hårdvaruenheterna och båda hårdvaruabstraktioner för att se hurmycket arbete som krävdes för att byta ut en enhet samtidigt som kom-munikationslänken behölls.

För utvecklingsmöjligheterna undersöktes vilka delar av systemet som varberoende av kommunikationslänken, och hur detta påverkade systemetsom helhet.

3.2 Metod för att bestämma fördelar vid ombyggnation

De olika tillvägagångssätten som presenterats i rapporten har diverse för-och nackdelar. För att konkret fastställa vilka fördelar som systemet hadehaft om kommunikationslänken istället byggdes om helt identifieras pro-blem med att behålla kommunikationslänken, om det undersöks om dessaäven funnits om den byggts om. Dessa problem kunde identifieras genomatt produkten utvärderades vid demonstration av systemet för kunden iprojektet, och interna acceptanstester av produktens funktionalitet.

62

4 Resultat

I detta kapitel presenteras resultatet av den teoretiska analysen. Resultatetär uppdelat i två delar som systematiskt behandlar varsin av de presente-rade frågeställningarna.

4.1 Begränsningar

När systemet utvärderades för att se dess begränsningar noterades ingastörre begränsningar som påverkar systemet till följd av metodvalet. Kom-munikationen mellan linjärenheten och avståndskamera är i det utveck-lade systemet visserligen låst till att kommunicera med pulser, men dettafår anses vara en vanlig metod för avståndskameror. Ska en enhet bytas utkrävs det alltså att linjärenheten kan skicka ut pulser, och att avståndska-meran kan ta emot sådana och agera efter det. I dagsläget har alla typerinom produktfamiljen Ruler från SICK den typen av funktion [19]. Denfrämsta anledningen till detta är att varje hårdvarudel har ett eget hård-varugränsnitt som är den enda koden som hanterar hårdvaran.

Det finns en del begränsningar i hur systemet kan vidareutvecklas. Bå-de avståndskameran och linjärenheten har en stor uppsättning funktionerför olika tillämpningar och är således väldigt överdimensionerade för sinuppgift, och kommunikationslänken som används begränsar en del möj-ligheter för hur kameran och linjärenheten kan användas. Detta kan be-gränsa eventuella utvecklingsmöjligheter. Främst var det användandet avinställningsfilen till avståndskameran som påverkades, eftersom inställ-ningar som rör pulstriggning var känsliga för ändringar, och tenderadeatt få systemet att sluta fungera korrekt. Varför detta skedde finns det fle-ra anledningar till, men i huvudsak sker det för att systemet utveckladesmed en uppgift i tanke, och stödjer således inte alla möjliga inställningarsom avståndskameran har. Exempelvis är systemet låst till att starta frånursprungspunkten längst åt vänster eftersom en mätning annars kommeratt vara fylld med skräpdata som förstör punktmolnet, även om eventuellmätdata längst till vänster är irrelevant.

4.2 Hypotetisk analys av ombyggnad

Det identifierades en del problem med att behålla kommunikationslänkeni dess ursprungsskick. Då profiler endast skapades med tidsbaserade pul-ser från linjärenheten och den gamla kommunikationslänken gick det inteatt på ett pålitligt sätt placera ut punkter i ett punktmoln. I systemet somskapades placerades profilerna ut icke-skalenligt.

Effekterna kan ses i figur 4.1, där bilden till vänster är tydligt utdrageni sidled. Om systemet byggts om hade detta varit enklare att kontrollera.

63

Figur 4.1: Skillnad i resultat med olika hastigheter på linjärenhet. Till hö-ger syns en scanning med fyrdubblad hastighet. Bilderna är efterbehand-lade.

En påföljande effekt av ovanstående problem var att hastighet och accele-ration på linjärenheten påverkade resultatet markant. Eftersom pulsernavar tidsbaserade resulterade en snabbare hastighet i en mindre utdragenbild. Skillnaden kan ses i figur 4.1.

5 Diskussion

Kommunikationslänken som användes i det tidigare systemet är utformatför att fungera med den valda linjärenheten och avståndskameran. Det ärdärför inte särskilt förvånande att systemet får relativt få begränsningarom den inte byts ut. Detta stämmer särskilt eftersom systemets slutgilti-ga funktionalitet inte skulle ändras i projektarbetet, utan det enda somändrades var den bakomliggande arkitekturen.

Fortsättningsvis finns inte fullständig information om hur kommunika-tionslänken faktiskt fungerar. Dokumentationen är bristfällig, vilken kani värsta fall betyda att systemet slutar fungera om inställningar ändras påett sådant sätt som kräver att in- eller utdata till kommunikationslänkenagerar på ett annat sätt. Samtidigt har båda komponenterna, linjärenhe-ten och avståndskameran, en välskriven abstraktion för att förbättra sy-stemets modularitet. Enligt artikeln Software reuse [20] är abstraktion dengrundläggande funktionen för att återanvända mjukvara i ett system. Det-ta underlättar ett eventuellt byte av hårdvara, även om det möjligtvis kanvara svårt att byta ut en av enheterna mot väldigt annorlunda modellerutan att röra kommunikationslänken.

Ett resultat av scanning blev utdraget som direkt följd av att kommuni-kationslänken inte kunde kontrolleras helt. Det är alltså intressant att en

64

sådan liten del av systemet påverkade resultatet så markant. Ska scan-ningsresultat användas till något som kräver att bilden är korrekt skaladkrävs det att punktmolnet skalas i efterhand.

I framtida projekt kan det således vara vettigt att identifiera kritiska delarav projektet i planeringsfasen för att undvika liknande resultat genom enmer grundlig förstudie

6 Slutsatser

I den här rapporten bestämdes systemets begränsningar till följd av an-vändandet av den existerande kommunikationslänken teoretiskt. I överlagobserverades inga större begränsningar på systemets modularitet, främsteftersom att ett hårdvarugränssnitt skrevs till varje enhet. Det kan ävenkonstateras att systems utvecklingsbarhet begränsas något eftersom systemslåses till vissa inställningar som hade varit friare om kommunikationslän-ken byggdes om helt.

Fortsättningsvis undersöktes eventuella problem med att använda dengamla kommunikationslänken. Ett resultat från en scanning blev utdrageteftersom den tidigare kommunikationslänken skickade ut tidsbaseradepulser, och punktmolnen skapades ovetandes om pulsfrekvensen. Dettafick konsekvensen att linjärenhetens hastighet inte kunde bestämmas heltutan påverkan på resultatet av en scanning.

Det går alltså att konstatera att återanvändning av delsystem kan få kon-sekvenser som inte är önskvärda. I framtida projekt är det således rekom-menderat att tidigt undersöka om dessa begränsningar och problem på-verkar projektet tillräckligt mycket för att motivera en alternativ lösning.

65

En säkerhetsanalys av ett distribuerat systemJohan Jansson

Den här rapporten tar upp huruvida säkerheten hos ett system bör tänkas på bådeinnan och under utveckling, samt diskuterar hur säkerheten hos ett utvecklatsystem för 3D-scanning inte togs i beräkning och vad som skulle kunnat görasåt det. Det framkom genom en analys av de protokoll som systemet använde sigav att dessa var osäkra och hade säkerhetshål. Det tas även upp hur dessa kundeåtgärdas med olika strategier. Avslutningsvis kan det sägas att valet att användaPickle inte det bästa.

1 Inledning

När ett system utvecklas är säkerhet en viktigt sak att ha i åtanke. Ett sår-bart system kan leda till flera problem och oönskade konsekvenser i formav skadliga säkerhetshål. I detta projekt moderniserades ett system utandirekt arbete för att öka säkerheten . Den här rapporten tar upp huruvidadetta var något som borde ha gjorts, samt föreslår hur det kunnat göraspå ett bra sätt.

1.1 Syfte

Syftet med denna rapport är att få en insikt i hur man gör ett system säkertom detta är något som är av prioritet samt vilka sorters säkerhetsriskersom är specifika för systemet. Det är även av intresse att ta reda på omprojektgruppen hade kunnat göra något annorlunda vid utveckling avsystemet för att göra det säkrare.


Hur kan systemet göras säkrare, om säkerhetshål hittas?

Finns det något projektgruppen kunnat göra för att säkerställa säkerheten hossystemet?

67

1.3 Avgränsningar

Den här rapporten avser endast att ta reda på säkerhetsrisker och kommerinte utsätta systemet för skadlig kod för att testa dessa säkerhetsrisker. Detkommer inte heller att genomföras några penetrationstester på systemet.Den här rapporten är en efterhandsanalys av det byggda systemet, så ingautav de funna säkerhetsriskerna (om några) hade kunnat åtgärdats underprojektets gång.

2 Teori

Denna del tar upp olika aspekter som behövs för att förstå metoden somanvändes samt hur detta gav resultatet. Hela systemet byggs upp av föl-jande komponenter: en avståndskamera, en linjärenhet och ett rotations-bord som kommunicerar på följande vis. Kameran kommunicerar via nät-verk till en dator med Windows XP, rotationsbordet kommunicerar via se-riellport med datorn som kör Windows XP och linjärenheten kommunice-rar med en Linux-dator över seriellport. Mellan Linux-datorn och datornmed Windows XP så skickas data över nätverk då Linux-datorn agerarsom både master och ROS-nod.

Ett abuse case är väldigt likt ett use case, men tanken med ett abuse case ärgå över de fall som skulle kunna skada systemet. Ett abuse case definierasenligt följande “A complete abuse case defines an interaction between anactor and the system that results in harm to resource associated with oneof the actors, one of the stakeholders or the system itself” [21].

3 Metod

För att få fram information om säkerhetsrisker så har ett antal olika böckeroch publikationer lästs [22, 23]. Detta gav en stadig grund för att påbörjaarbetet kring analys av möjliga sårbarheter. Metoden som användes varatt analysera systemets olika protokoll utifrån den grund som informa-tionsinsamlingen gav. Detta tillsammans med en diskussion kring olikasäkerhetsrisker som finns i den mjukvara som systemet bestod av gavresultatet samt diskussionen i denna rapport.

4 Resultat

Vid undersökning av de protokoll och bibliotek som användes i projek-tet kom det fram att pythonbiblioteket pickle användes [24]. Pickle är ettserialiseringsbibliotek som alltså skapar seriella objekt utav data. Picklekan serialisera godtyckligt pythonobjekt eftersom det konverterar allt tillbytes, vilket betyder att en individ som känner till detta kan skriva en

68

funktion med godtycklig funktionalitet och pickla den. När paketet inne-hållande denna funktion sedan unpicklas kan den alltså vara skriven såatt den exekverar direkt, funktionen skulle kunna innehålla skadlig kodför att få information ifrån datorn som den unpicklades på eller få kontrollöver denna dator.

När det kommer till ROS [1] finns det även här säkerhetshål, när roscorestartar så kommer den öppna upp en port som klienter kan koppla uppsig emot. Så när en klient har kontakt med roscore kan den fråga roscoreom vad som helst som roscore har kontroll över. Det finns alltså ingaautentiseringsmekanismer mellan klient och roscore.

5 Diskussion

I det här kapitlet kommer resultaten från analysen att tas upp och disku-teras. Det kommer även att diskuteras alternativa lösningar och slutligenhålls en allmän diskussion.

5.1 Resultat

Som nämnts tidigare i de resultat som kom fram vid analys av systemet såskulle en godtycklig funktion kunna skickas över från den ena datorn tillen andra i systemet om man har tillgång till den datorn som ska skicka.Detta kräver antingen fysisk tillgång till någon utav datorerna eller ellerfjärråtkomst till datorn med Linux då det är denna som är uppkoppladmot eventuella nätverk. Ett exempel på kod som skulle kunna skickas är:

data = """ cossystem(S’gedit ’tR."""

pickle.loads(data)

Detta är ett harmlöst exempel som endast startar texteditorn gedit1. Påsamma sätt skulle skadlig kod kunna skickas. Då denna dator kör enLinuxdistribution som är gjord för långtidsstöd, vilket innebär att den kören “gammal” version av Linux. Detta skulle i sin tur kunna leda till atten attackerare skulle kunna få tillgång till datorn om ett nytt säkerhetshålhittas i Linux, och på så sätt få kontroll över hela systemet. Men att denhar långtidsstöd innebär även att den kommer få uppdateringar längre änen vanlig distribution, så om ett säkerhetshål hittas betyder det antagligenockså att detta kommer att fixas.

Som även beskrevs i resultatet är att det inte finns några som helst autentiserings-steg mellan en roscore och en klient, denna klient kan vara vad som helst

1https://wiki.gnome.org/Apps/Gedit

69

så länge den finns på samma nätverk som roscore, vilket skulle kunnavara ett ej publikt nätverk eller internet.

5.2 Projektplan och kund

En projektplan skrevs i början av projektet och då fanns det inte hellernågra datasäkerhetsrisker i åtanke, kanske för att de flesta inte visste vadsom behövde göras för att skydda systemet eller för att gruppen kansketrodde att sätta en Linux dator som master till systemet räckte. En annanorsak skulle även kunnat vara att kunden inte ställde några krav på sä-kerhet kring systemet. Då det var ett arkitekturbeslut att använda picklekanske det borde ha tänkts på att det kommer finnas en dator som sak-nade uppdaterad mjukvara samt att denna dator inte heller kommer fånågra fler mjukvaruuppdateringar i framtiden. Så att på något sätt väljaett annat protokoll för dataöverföring eller välja någon sorts säkerhet påannat sätt.

Tidigare nämndes det att kunden inte heller ställde några säkerhetskravpå systemet, vilket skulle kunna bero på att de hoppades på att det skullegå att modernisera systemet tillräckligt till den grad att man inte skullebehöva den datorn som använde sig av Windows XP. Det hade varit avintresse att ta fram abuse cases samtidigt som man tog fram use cases medkunden eller ta reda på om säkerheten var något kunden inte tänkt på.

5.3 Public-key verification

Ett alternativ för ökad säkerhet hade varit att ha public-key verification förde olika noderna data skickas mellan. Vilket innebär att den som ska skic-ka signerar data med sin privata nyckel, data skickas sedan till mottagarensom kan verifiera detta genom att använda sändarens publika nyckel föratt kolla att signaturen är genuin [25]. Detta säger alltså att data är okej attöppna och på så sätt skulle man kunna laga det säkerhetshål som picklehar. Problemet här vore om attackeraren fick reda på den privata nyckelndå detta skulle leda till att denne kan skicka data ändå.

5.4 JSON

En annan åtgärd skulle kunna vara att använda JSON istället för picklenär data behöver skickas, då JSON kräver ett visst format på den data manska skicka och på så sätt går det inte att exekvera godtycklig kod [26]. Detenda som behöver göras är att konvertera den data man vill skicka till ettJSON-objekt.

70

5.5 Allmänt

Alla dessa spekulationer kräver också att attackeraren antingen har fysisktillgång till någon utav de datorer som systemet är uppbyggt med eller attde lyckas ta sig in på det nätverk som systemet är uppkopplat mot.

Det skulle kunna vara så att just det system som byggdes i detta projektinte krävde några speciella säkerhetsåtgärder då systemet kanske inte ärspeciellt hotat eftersom att det är menat att användas i utbildningssyfte.Men det är en bra sak att ha i åtanke redan vid inledande samtal medkund om krav. samt vid utformning av arkitektur för systemet som skallbyggas.

6 Slutsatser

Det går alltså att konstatera att när man skapar ett system är en av de förs-ta sakerna man bör fråga sig själv samt kund hur säkert systemet behövervara mot attacker som berör till exempel känslig data inom systemet. Sä-kerheten hos systemet bör såklart hållas som tanke i bakhuvudet trotsdetta, även när inga krav ställs från kund och speciellt när man har delarmed utdaterad mjukvara i systemet till exempelvis Windows XP.

När man har med bibliotek att göra som till exempel pickle som är sårbaraoch inte säkra, så behövs det göras säkert och som diskuterades tidigareär public-key verification ett utav många sätt att göra detta. Alternativt attman hittar ett annat serialiserings bibliotek som till exempel JSON. Vilketär något som skulle kunnat göras i systemet för detta projekt. Men dåsystemet kanske inte är direkt utsatt och det är heller inte ens säkert attdet kommer kopplas upp mot ett publikt nätverk.

Så när det kommer till att göra ett system säkert om ett säkerhetshål hittasär det viktigt att ta reda på vilken sorts säkerhetshål det är samt identifieravad som kan göras åt det. Som nämndes i diskussionen så kan ett systemenkelt göras säkrare genom att till exempelvis ha någon sorts autentise-ring om känslig data behöver skickas. En annan åtgärd är att ta reda påom det finns någon alternativ teknik som kan användas istället för denvalda teknik för att göra systemet säkrare.

Så ur en säkerhetssynpunkt var valet att använda Pickle inte det bästa.

71

Svårigheter vid TidsplaneringFabian Petersen

Tidsplanering är en vital del för lönsamheten hos företag. Tyvärr så är det oftasvårt att göra träffsäkra uppskattningar på tidsåtgång hur lång tid det kommerta att uppfylla kraven, något som direkt påverkar företagens lönsamhet.

I ett försök att hitta den optimala tidsplaneringsmetoden så gjordes en littera-turstudie samt några praktiska tillämpningar av de teoretiska metoderna. Dettavisade att det inte finns någon metod som alltid passar för ett projekt, utan för-delarna och nackdelarna med varje metod måste jämföras med omständigheternaför projektet som ska tidsplaneras.

1 Inledning

Det har alltid varit svårt att göra tidsuppskattningar, främst när gruppenär nybildad och oerfaren inom ett område. Denna rapport kommer ge för-slag på vad man kan göra för att underlätta processen. Är det fördelaktigtatt enbart låta de mer erfarna medlemmarna i gruppen göra uppskatt-ningen, eller får man bättre resultat när alla deltar?

Rapporten kommer även behandla olika metoder för hur tidsplaneringkan utföras och hur de erhållna resultaten påverkas av erfarenheten hosgruppen samt dess gruppdynamik.

1.1 Syfte

Resultatet från rapporten ämnar göra det lättare för företag att göra mertillförlitliga tidsuppskattningar för projekt. Förmågan att bättre tidsupp-skatta projekt är otroligt viktig då det kan vara skillnaden mellan att gåmed vinst och förlora pengar på ett projekt, något som direkt påverkarföretagets lönsamhet.


Vilka för- och nackdelar finns vid tillämpningen av pokerplanning ochtop-down tidsplanering?

73

1.3 Avgränsningar

Rapporten täcker inte hur man identifierar vilket stadie en grupp är i,eller hur gruppen når ett visst stadie som beskrivs i 2.2.1. Den täcker inteheller hur man förändrar dynamiken i gruppen.

Rapporten kommer bara behandla de tidsplaneringsmetoder som använtsi projektet som beskrivs i avsnitt 3.1.

2 Teori

Detta avsnitt innehåller en kort beskrivning av syftet med tidsplaneringoch en av de mest vedertagna teorierna om gruppdynamik, eftersom des-sa områden är viktiga för resten av rapporten.

2.1 Planering

Tidsplanering är processen där det uppskattas hur lång tid det tar för engrupp att uppfylla vissa krav. Denna tidsplanering är grunden till mångaandra beslut som tas inom projektet, exempelvis storleken på budgeten,val av deadline, och antalet anställda som ska arbeta på projektet. [27]

2.2 Gruppdynamik

Gruppdynamik är ett samlingsbegrepp för hur individer interagerar medvarandra i en grupp. Exempel på vanliga interaktioner är när en gruppska lösa ett problem eller fatta ett beslut. [28]

Med en god gruppdynamik lyfts alla gruppmedlemmars kunskaper ocherfarenheter fram, man låter även enskilda gruppmedlemmar tänka ochhandla självständigt. Ansvaret för uppgifter sprids på flera gruppmed-lemmar och man förlitar sig inte helt på enskilda personer. [28]

Kommunikationen inom gruppen är en viktig del av gruppdynamiken, påen grundläggande nivå måste medlemmarna förstå varandra och kunnauttrycka sig.

2.2.1 FIRO

Fundamental Interpersonal Relations Orientation (FIRO) är en teori om grupp-dynamik skapad av William Schutz [29]. Teorin kan sammanfattas med atten grupps beteende delas in i tre faser [29]:

• I tillhörandefasen är gruppmedlemmarna artiga och deras främstafokus är att bli accepterad av resten av gruppen.

74

• Kontrollfasen är fylld av konflikter när gruppmedlemmarna är merkonfrontativa för att bestämma både sin egen och andras ställning igruppen.

• I öppenhetsfasen är gruppmedlemmarna öppna mot varandra ochdelar med sig av känslor och tankar. Gruppen är som mest effektivi denna fas.

2.3 Tidsplaneringsmetoder

Tidsplanering kan göra på flera olika sätt, det här är beskrivningar av hurpokerplanning och top-down metoderna utförs.

2.3.1 Pokerplanning

Pokerplanning utförs genom att deltagare vid planeringstillfället får indivi-duella ”spelkort” med olika tidsangivelser på. Därefter beskriver en del-tagare ett krav för gruppen, deltagarna väljer sedan det kort som kommernärmast deras individuella uppskattning av den tid det tar att slutförauppgiften. [30]

När alla deltagare valt det kort som de tycker bäst överensstämmer medtiden det tar att uppfylla kravet så diskuteras tidsuppskattningarna avvi-ker mest från gruppens median. Efter diskussionen så upprepas processentills gruppen enats om ett resultat.

Tanken med metoden är att gruppens samlade förmåga att uppskatta ti-der blir bättre tack vare individernas spridda kunskaper. Därför är detvanligt att alla medlemmar i en utvecklingsgrupp deltar, exempelvis ut-vecklare, designers och testare. [27]

Den stora spridningen i kunskap tenderar att ge en stor spridning i resul-taten, vilket ger mer underlag för diskussionen. Processen kan fortsätta iflera iterationer där gruppen förhoppningsvis blir allt mer enig för varjeiteration. Man går vidare till nästa krav först när gruppen anser att den ärtillräckligt enad om resultatet, vilket inte nödvändigtvis betyder att allahar lagt exakt samma valör på kortet. [31, 30]

2.3.2 Top-Down

Top-down sättet att planera involverar oftast bara projektledaren och an-vänds ofta för att lägga upp en tidig budget. Problemet med projekten iett tidigt skede är att många detaljer inte är fastställda. Man måste där-för göra en stor mängd antaganden som potentiellt innehåller felaktighe-ter. [32]

75

Eftersom enbart projektledaren arbetar vid top-down sättet så behövs inteen lika rigorös metod för hur detta utförs. Det primära är att projektle-daren har tidigare erfaranheter av likande projekt i samma miljö och kananvända den kunskapen för att dra generella slutsatser för hur lång tidvarje del kommer ta.

3 Metod

Undersökningen är baserad på en litteraturstudie och några mindre ex-periment. Teorin som erhållits genom litteraturstudien verifieras genomexperimenten.

3.1 Projekt

Metoderna som utvärderades användes i ett projekt i kursen TDDD96 påLinköpings Universitet. På projektet arbetade en grupp bestående av niostudenter under vårterminen 2016.

3.2 Tidsplanering

Utöver informationen som inhämtas genom litteraturstudien så har detäven hållits flera tidsplaneringstillfällen, där gruppen befunnit sig i oli-ka stadier och där man utnyttjat olika tidsplaneringmetoder. Metodernasframgång för gruppen sett ur utvecklingsledarens(författarens) subjektivaperspektiv bidrog till resultatet.

3.2.1 Pokerplanning

Under förstudien och iteration ett bokade utvecklingsledaren två mötenmed resten av gruppen för att med hjälp av pokerplanning tidsuppskat-ta kraven. Under det första mötet(under förstudien) användes inte någrafaktiska kort, utan gruppmedlemmarna berättade tiden de uppskattadeatt kravet skulle ta att realisera och varför de uppskattade just den tiden.Bristen på kort korrigerades till andra tidsplaneringsmötet genom att ut-vecklingsledaren delade ut spelkort med tider på.

3.2.2 Top-down

Under andra och tredje iterationen övergavs pokerplanning för top-downsättet att planera. Planeringen utfördes enskilt av utvecklingsledaren somanvände tidigare erfarenheter från andra projekt. Gruppens generella kun-skaper och förmåga bedömdes och bidrog till de slutgiltiga tiderna.

76

De tidigare uppskattningarna från avklarade krav jämfördes med tidendet faktiskt tog att realisera dem användes för att ge en så bra uppskatt-ning som möjligt för just denna utvecklingsgrupp.

4 Resultat

Det finns en rad olika metoder som kan användas för att genomföratidsuppskattningar. Här beskrivs några av dem i korthet.

4.1 Pokerplanning

Det var främst den här metoden som användes vid gruppens tidsplane-ring, för att försöka utnyttja den spridda kunskapen i gruppen. Tyvärrfungerade den här metoden relativt dåligt då det under förstudien ochiteration 1 var otydligt vad som behövde göras och hur kravens skullerealiseras. Detta resulterade i att samtliga tidsuppskattningar av kravenbehövde korrigeras senare i både samma iteration och följande iteratio-ner.

Bristen på spelkort under första tidsplaneringstillfället gjorde antagligenatt vissa gruppmedlemmar justerade sina tider för att inte stå ut allt förmycket ur gruppen. Detta observerades dock inte under tillfället då sprid-ningen på uppskattningarna var förhållandevis stor. Detta kan bero på attgruppen tidigt avancerade från tillhörandefasen.

Några fördelar med pokerplanning är [27, 30]:

• Deltagarna bestämmer sig själva för vad som är en rimlig tidupp-skattning under tystnad, vilket minskar risken att deltagare påver-kar varandra.

• Samtliga gruppmedlemmar är delaktiga i tidsuppskattningen, denspridda kunskapen leder till bättre uppskattningar.

• Deltagare erhåller kunskap genom att få en insikt i hur andra grupp-medlemmar identifierar svårigheter med att uppnå ett krav.

• Metoden kan upprepas tills konsensus nås.

Nackdelarna med pokerplanning är [27, 31]:

• Metoden är svår att tillämpa om gruppen är geografiskt spridd.

• Det finns en risk att gruppen når konsensus utan att erhålla all nöd-vändig information för att göra en korrekt bedömning.

77

4.2 Top-down

Denna metod lämpade sig bra för de senare iterationerna(2-3) av projekteteftersom utvecklingsledaren redan kunnat bedömma gruppens effektivi-tet och gruppdynamik. Det fanns även flera liknande krav som redan varuppfyllda, tiden det tog att uppfylla dessa kunde därför användas för res-ten av uppskattningarna. Över lag gav denna metod betydligt mycket mertillförlitliga resultat jämfört med pokerplanning.

Fördelarna med ett top-down tillvägagångsätt är [32]:

• Kostnaden för att utföra planeringen är väldigt låg, eftersom baraprojektledaren lägger tid på att planera.

• Eftersom planeringen antar att man inte vet mycket så är man med-veten om att den antagligen innehåller felaktigheter och kan därförtidigt kompensera för dessa.

• Kan ge en snabb indikation inför prisuppskattningar.

Nackdelarna med ett top-down tillvägagångsätt är [32]:

• Projektledaren kan ha bristande kunskap inom tekniska områden,vilket kan resultera i omfattande feluppskattningar i både kostnadoch schema.

• Tiden det tog att uppfylla krav i tidigare projekt är inte nödvändigt-vis en bra indikator på hur lång tid det kommer ta att göra sammasak i det aktuella projektet.

• Arbetsgruppen som blir tilldelad projektet kan känna sig uteslutnaur beslutsprocessen.

5 Diskussion

Gruppdynamiken kan i sig påverka resultaten av tidsplaneringen [28].Om alla i gruppen ser upp till en medlem finns det högre sannolikhet attvissa strävar efter att hamna i närheten av den personens resultat. Det härkan varit en av de största problemen som gjorde att det första tidsplane-ringsmötet gav så dåliga uppskattningar, eftersom bristen på kort gjordeatt framstående medlemmar i gruppen tidigt gav sin åsikt. Stävan efter attpassa in kan leda till en falsk konsensus, det är därför viktigt att begränsadiskussionerna till det faktiska mötet samt att ingen under mötet i förtidsäger vad de kommer välja för kort.

Ett sätt att tackla det här problemet är att låta en mindre expertgrupp görabesluten, eftersom det vid vanlig pokerplanning kan finnas medlemmar

78

som inte erhåller tillräckligt med kunskap och därför har lättare att barafölja efter en mer erfaren gruppmedlem.

En av de största fördelarna med pokerplanning, att gruppens spriddakunskaper leder till bättre diskussioner och därmed bättre resultat. Kanlika gärna leda till att mindre erfarna medlemmar tror att de vet mer ochger skeva uppskattningar som de starkt argumenterar för.

Gruppdynamiken har inte samma betydelse i top-down tillvägangångsät-tet eftersom det främst är projektledaren som bedömer hur lång tid sakerkommer att ta. Om gruppdynamiken därför är dålig så kan det vara för-delaktigt att använda den här sortens metod istället för någon av de andrasom är mer beroende på gruppdynamik.

Det är även svårt att stoppa gruppmedlemmarna från att diskutera poten-tiella svårigheter innan mötet. När systemet designas så brukar det oftavara interna diskussioner om hur man borde göra den specifika uppgif-ten, dessa diskussioner kan göra att framstående medlemmar i gruppenredan enats om ungefär hur lång tid kravet kommer ta att uppfylla.

Uppfattningarna som skapas här kan skapa en majoritet som har en vissåsikt, och som möjligtvis inte är benägna att ta in ny information frånresten av gruppen, då de anser sig vara bättre inom området.

Samtliga tidsuppskattningar som gjordes med pokerplanning korrigera-des i ett senare skede. Om det berodde på att kunskapen i gruppen ökade,att gruppdynamiken blev bättre eller att kraven för hur systemet skullefungera specificerades ytterligare, är svårt att säga. Oavsett så är det san-nolikt att alla dessa faktorer bidrog till framgången för top-down metodensom användes under de senare iterationerna.

För att fastställa de egentliga orsakerna så kunde en analys av vilket stadiegruppen befinner sig i utförts. Analysen hade sedan kunnat användas föratt bedöma hur gruppdynamiken kan ha påverkat tidsuppskattningarnaoch hur det påverkat effektiviteten hos de olika tidsplaneringsmetoderna.

6 Slutsatser

Ingen av metoderna är helt överlägsen resten, inom vissa projekt kommernackdelarna av en viss metod utväga fördelarna. Det är därför svårt attbestämma vilken metoder som lämpar sig bäst för samtliga projekt.

Vissa metoder som pokerplanning är bra för att få exakta uppskattningar,men är även dyr och tidskrävande och lämpar sig därför främst till projektsom företag redan har. Samtidigt lämpar top-down sättet sig bäst för attgöra en snabb bedömning av hur lång tid det tar att utföra projektet ochdärigenom ge en snabb prisuppskattning till en potentiell kund med lågkostnad för det egna företaget.

79

Automatisering av systemtestningDavid Pop

Varje mjukvaruprojekt har en uppsättning krav som produkten måste uppfylla föratt projektet ska anses som avklarat. Det är intressant att undersöka huruvida detgår att automatisera processen för att testa ifall produkten uppfyller de uppställdakraven. En analys för att besvara detta gjordes under projektets gång och presen-teras i den här rapporten. Analysen visade att det går att skriva automatiseradetester för sådana krav som är mätbara, tydligt specificerade och som går att mätagenom produktens användargränssnitt. Det visades även att i detta fall hade detinte lönat sig att utveckla ett sådant testsystem för automatiserade tester, men attdet hade hjälpt att försöka ta fram testscenarier för de olika kraven eftersom dettakan lyfta fram olika problem med kravspecifikationen.

1 Inledning

För att ett projekt ska anses vara avklarat måste slutprodukten uppfyllavissa krav som sattes upp tillsammans med kunden. Testerna som behövsför att verifiera att produkten uppfyller dessa krav är ofta omständiga ochtidskrävande. Detta innebär att det skulle vara fördelaktigt att undersökahuruvida dessa tester kan automatiseras samt vilket sätt man kan göradet på. Denna individuella del i kandidatrapporten presenterar ett försöksom gjordes under projektets gång att analysera hur man kan verifiera attprodukten uppfyller dessa krav genom automatiserad mjukvarutestning.

1.1 Syfte

Syftet med denna rapport är att teoretiskt undersöka huruvida det gåratt säkerställa att det utvecklade systemet uppfyller de uppställda kravengenom automatiserad systemtestning. I rapporten analyseras även vilkaegenskaper som kraven behöver ha för att kunna verifieras automatiskt.


Under projektets gång testades produkten manuellt genom att komman-don och instruktioner matades in till programmet av en testperson för att

81

se om programmet uppförde sig som hade specificerats i kravspecifikatio-nen. Det är av intresse att undersöka ifall denna process kan underlättasoch göras snabbare genom automatisering. På vilket sätt och i hur stor ut-sträckning kan kraven för systemet testas autormatiskt?

1.3 Avgränsningar

Det här avsnittet behandlar inte andra typer av mjukvarutestning, som in-te är väsentliga för målet med analysen, såsom enhetstestning eller integ-rationstestning. Analysen genomfördes på det systemet som tagits framunder projektets gång även om slutsatser kan dras för mer allmäna mjuk-varuprojekt.

2 Teori

Efter att de olika delarna i ett program har testats, genom enhetstestning,och efter att de integrerats och integrationstestats, kan man utföra system-testning på hela programmet. Spillner skriver om systemtestning i Softwa-re testing foundations a study guide for the certified tester exam[33]. Den härtypen av testning avser att testa produkten i sin helhet och verifiera attprodukten uppfyller de uppställda kraven. Av denna anledning grundassystemtesterna på sådan dokumentation som beskriver hur programmetär tänkt att fungera och användas, till exempel kravspecifikationen ochanvändarmanualen. Med hjälp av testerna ska man kunna upptäcka kravsom inte uppfylls och utöver det även problem i dokumentationen såsominkonsekvenser i kravspecifikationen.

Utöver de andra typerna av testning behövs systemtestning för att testaden framtagna produkten utifrån kundens och användarnas perspektiv.Den behövs också för att många problem inte upptäcks förrän det helaintegrerade systemet används samt för att vissa funktioner som behövertestas inte finns tillgängliga förrän alla delar har satts ihop. Vanligtvistäcker den här typen av testning även dokumentation, prestanda samtdatabaser.

Till skillnad från acceptanstestning utförs systemtestning av utvecklarnasjälva, inte i samarbete med kunden eller användarna. En rådande prax-is vad som gäller systemtestning jämfört med acceptanstestning är attsystemtesterna utförs i en testmiljö och inte i den miljön som produktenkommer att användas av kunden. Anledningen till detta är att inte skapaandra problem för användarna genom installation, testning och körningav programmet i kundens miljö.

I projektet utfördes dessa systemtester vanligen manuellt genom att allakommandon och funktioner anropades av en testperson på samma sätt

82

som det var tänkt att systemet skulle användas av slutanvändaren. Resul-tatet jämfördes sedan med det förväntade för att se om systemet uppför-de sig som det skulle. Denna process hade kunnat underlätttas och görassnabbare med hjälp av automatiserade tester. Med automatiserade testermenas här en kombination av skript och program som automatiskt utförsamma steg som en testare skulle göra manuellt.

Taipale m. fl. menar att en viktig fördel med automatisering av tester äratt de kan köras mycket snabbare och oftare [34]. Det kostar mycket attutveckla ett automatiserat testsystem jämfört med tester som utförs manu-ellt. Att automatisera testerna brukar ändå tjänas på i slutändan eftersomresurser sparas på att hitta och fixa fel samt på att utföra testerna. Det-ta ökar även kvaliteten på produkten, eftersom den kan testas oftare ochsnabbare och på så sätt problem kan upptäckas lättare.

3 Metod

Frågeställningarna har besvarats först genom att en analys av kravspe-cifikationen har gjorts. Sedan togs fram en metod för hur kraven skullekunna testas automatiskt.

3.1 Krav

Ett av syftena med rapporten var att undersöka vilka av produktens kravsom går att verifiera genom automatiserade systemtester, samt att reda utvilka egenskaper kraven måste ha för att kunna verifieras på ett sådantsätt.

Detta gjordes genom att gå igenom kraven för produkten som framtogsunder projektets gång. För varje krav gjordes ett försök att föreslå ett test-scenario som beskriver hur kravet skulle testas automatiskt. Om ett sådantscenario inte kunde tas fram för ett visst krav, ansågs det kravet som otest-bart och anledningen till detta analyserades.

Med ett testscenario i det här fallet menas en specifikation av hur ett kravkan testas. Detta innefattar indata till systemet, exekvering av systemetsamt förväntat utdata som resultatet jämförs med. För att testa systemetutifrån användarens perspektiv grundades dessa scenarier i kravspecifi-kationen och användarmanualen som beskriver hur produkten är tänktatt användas.

3.2 Systemtester

För att besvara frågan om huruvida det går att automatisera systemtest-ningen och på vilket sätt detta kan göras, gjordes ett försök att ta fram en

83

metod för hur den framtagna produkten skulle kunna systemtestas auto-matiskt. Avsikten var inte att ta fram en testplan som täcker så många fallsom möjligt, för att hitta fel i programmet, utan det var att exemplifierahur sådant testning kan gå till. En metod för hur automatiskt testning avkrav kan gå till föreslogs och grundades i de testscenarier som tagits framför de testbara kraven. Denna metod skulle främst vara lämplig under deförhållanden som rådde för den utvecklade produkten.

4 Resultat

Resultatet består av ett förslag på en metod för automatiserade tester somär lämplig för projektet samt en sammanfattning av vilka systemkrav somgår att testa automatiskt.

4.1 Testsystem

Produkten har utvecklats så att den erbjuder användaren ett komman-doradsgränssnitt. Det betyder att systemet styrs av användaren genominmatning av kommandon i terminalen. Resultatet skrivs antingen ut di-rekt i terminalen eller sparas till en fil på klientdatorn. Med tanke pådetta är den mest lämpliga metoden och lättast att utveckla att skriva etttestsystem som anropar produkten såsom en användare skulle göra, ge-nom inmatning av kommando i kommandoradsgränssnittet. Sedan kantestprogrammen ta emot resultatet från systemet och jämföra det meddet förväntade resultatet såsom specificierat i testscenarierna för att slut-ligen skriva ut om testerna är avklarade eller inte. Ett sådant testsystemillustreras i 4.1. I det här fallet skulle detta lättast utvecklas med hjälpav bash-skript som anropar det utvecklade programmet först och sedanpython-program som analyserar om resultatet är rätt. Ett huvudskript kantas fram som anropar alla andra skript för de olika testfallen och som an-tingen skriver ut testresultaten i terminalen eller till en fil. För att köratesterna sedan behöver bara anropas huvudskriptet och vänta på att allatester har kört klart.

4.2 Krav

Ett krav anses som testbart om ett testscenario kan tas fram för kravet. Pro-dukten byggdes för att kunna styras av slutanvändaren genom ett kom-mandoradsgränssnitt. För att testa produkten ur användarens perspektivbegränsas även systemtesterna till att bara interagera med användargräns-snittet. Detta sätter även en gräns på vilka krav som kan testas. En genom-gång av systemets krav gav att testscenarier kan bara tas fram för följande

84

System

CLI

Testsystem Testresultat

Figur 4.1: Översikt över hur systemet kan testas.

systemkrav och är därför bara dessa som går att testa på det föreslagnasättet:

1. “Användargränssnittet ska låta användaren spara punktmolnet i fil-formatet PCD till användares dator”. Kan testas genom att först ut-föra en scanning. Enligt specifikationen ska systemet spara resultatetfrån scanningen i en fil på klientdatorn. Testen ska verifiera att en filmed resultatet har sparats samt att formatet på resultatet stämmeröverens med formatet för en PCD-fil.

2. “Användaren ska från användargränssnittet kunna ställa in rota-tionsvinkel på rotationsbordet”. Kan testas genom att försöka sät-ta en viss vinkel på bordet och verifiera att inställningen har lyc-kats sättas. Sedan kan värdet verifieras genom att hämta värdet församma inställning och jämföra det med det som matades in. Oli-ka gränsvärden kan testas för att se att systemet hanterar dem påförväntat sätt.

3. “Scanningsdata ifrån systemet ska innehålla x, y, z koordinater samtintensiteten”. Kravet kan testas genom att verifiera att resultatet frånen scanning stämmer överens med detta format.

4. “Användaren ska från användargränssnitten kunna ställa in lutnings-vinkeln på rotationsbordet”. På samma sätt som med rotaionsvin-keln kan lutningsvinkeln sättas och sedan verifieras att den har sattsrätt. Det är bra att testa olika gränsvärden här också.

5. “Scanning med de tidigare specificerade hårdvarukomponentern ini-tialiserade ska ta maximalt 40 sekunder att utföra på samma maski-ner som det tidigare systemet för att inte bli långsammare än detta”.Detta krav kan testas genom att mäta tiden som det tar att utföra

85

en scanning. Eftersom hur lång tid en scanning tar beror på vad deolika inställningarna har satts till, ska detta test utföras med stan-dardinställningar.

5 Diskussion

I detta avsnitt tas upp egenskaperna hos kraven som går att testa automa-tiskt samt anledningen till varför de andra inte går att testa på det sättet.Sedan diskuteras hur problem i kravspecifikationen kan upptäckas genomatt ta fram testscenarier för de olika kraven. Slutligen diskuteras huruvidaett automatiskt testsystem hade lämpat sig i det faktiska projektet och ettalternativt verktyg för automatiska tester presenteras.

5.1 Krav

De första fyra av de testbara kraven är funktionella krav medan det femteär ett icke-funktionellt prestandakrav. Det som är gemensamt för dessakrav är att alla är mätbara. Allt detta, tillsammans med att de går att mätagenom att bara använda kommandoradsgränssnittet gjorde att de kundetestas genom automatiserade systemtester.

Dessa krav är dock långt ifrån att vara alla krav för systemet men restengick inte att ta fram något scenario för hur de ska testas. Anledningentill att de andra inte gick att testa varierar. På grund av projektets typhandlade många sådana krav om systemets hårdvaruenheter. För dessakrav var det omöjligt att ta fram något testscenario på grund av att detvar omöjligt att mäta dem genom att bara använda kommandoradsgräns-snittet. Ett exempel på ett sådant krav är: “Systemet ska använda sig avexisterande rotationsbord med två rotationsaxlar”. Ett sådant krav måstetestas på något annat sätt, som till exempel genom att manuellt verifieraatt kravet uppfylls.

Andra krav hade en otydlig formulering eller behandlade någonting somanvändaren inte har någon större kontroll över genom användargräns-snittet. Exempel på sådana krav är: “Scanningen måste utföras med minst1000 profiler ifrån avståndskameran för att inte få lägre precision än det ti-digare systemet” eller “Systemet själv ska kunna agera klient och användadess användargränssnitt”.

Andra krav var helt enkelt inte mätbara genom automatiserade tester. Ex-empel på sådana krav kan vara krav på systemets egenskaper, såsom mo-dularitet och portabilitet: “Mjukvara ska kunna installeras på ny dator avsamma plattform utan modifikationer” och “Systemets hårdvarukompo-nenter ska vara utbytbara utan mjukvaruändringar för övriga komponen-ter”. Samma gäller för krav som handlar om dokumentation, som t ex:

86

“Det ska finnas dokumentation av systemets mjukvaruarkitektur. Dettadokument är projektets arkitekturbeskrivning.”

Genom undersökningen upptäcktes brister i kravspecifikationen såsomomätbara krav och krav med otydliga formuleringar. En fördel med attförsöka utveckla automatiserade tester eller åtminstone ta fram scenarierför att testa kraven är att sådana brister upptäcks. Anledningen till dettaär att kraven analyseras då ur ett testningsperspektiv. Detta ger en annaninblick i kravens formuleringar och egenskaper än om dem bara läses.Testscenarier för de olika kraven kan tas fram redan i början av utveck-lingen för att hitta sådana problem i kravspecifikationen tidigt.

5.2 Automatiserade tester

Resultatet innefattar ett teoretiskt förslag till hur man kan utveckla au-tomatiserade tester för produkten med syftet att exemplifiera hur dettakan göras och inte att ta fram en fullständig testplan för produkten. Eninstressant fråga som uppstår då är ifall det hade lönat sig att lägga tidpå att utveckla ett sådant testsystem för produkten. Att köra automatiskatester tar mycket mindre tid än manuellt utförda tester och med tanke påhur få krav som går att testa automatiskt skulle det ta relativt kort tid attutveckla. Givet systemets uppbyggnad var det ett väldigt litet andel avalla krav som kan testas på detta viset och manuella tester skulle behövautföras i alla fall för resten av kraven. Det kunde ha varit fördelaktigt attutveckla ett automatiskt testsystem trots det lilla antalet testbara krav omdetta hade förkortat och underlättat testarbetet. Under projektets gång vi-sade det sig dock att formella systemtester har bara behövts utföras engång vilket tog mycket mindre tid än det hade tagit att utveckla de auto-matiska testerna. Det betyder att i det här projektet det hade inte lönat sigatt lägga resurser och tid på att utveckla ett sådant testsystem.

På grund av produktens beroende av en unik uppsättning av hårdvaru-enheter skulle det vara omöjligt att testa den utvecklade mjukvaran i enannan miljö än den som produkten kommer användas i. Detta strider ty-värr mot rådande praxis inom systemtestning då i vissa fall kan det händaatt nya problem introduceras i miljön på grund av installation och exekve-ring av produkten och testsystemet.

För ett större projekt som skulle behöva att fler tester utvecklas kan andraspeciella verktyg för automatiserade tester utnyttjas för att underlätta ochförkorta testarbetet. Ett sådant verktyg som skulle passa för just det härprojektet är så kallade komparatorer [33]. Dessa fungerar precis som denföreslagna metoden i och med att de exekverar systemet som ska testasoch jämför resultatet med förväntat data. Skillnaden med dessa är att desparar data om förväntat resultat i databaser eller filer. Utöver detta er-bjuder de också funktionalitet för filtrering och jämförelse av data för attunderlätta kontrollen av utdata från det testade systemet. Användning av

87

ett sådant verktyg skulle medföra att mindre tid skulle behöva läggas påatt skriva programmen som analyserar utdata från den utvecklade pro-dukten.

6 Slutsatser

Bara ett fåtal av systemets krav ansågs som testbara genom automati-serade tester. Testbara krav är sådana för vilka ett testscenario kan tasfram. I detta fall behövde kraven vara mätbara, tydliga och kunna mä-tas genom användargränssnittet. Det föreslagna testmetoden består av enkombination av skript och program som kör systemet och jämför resul-tatet med det förväntade resultatet såsom specificerat i testscenarierna. Idet här projektet hade det inte lönat sig att lägga resurser på att utvecklaett sådant testsystem men det hade varit fördelaktigt att försöka ta framtestscenarier för kraven tidigt i projektet för att upptäcka problem i krav-specifikationen. Slutsatsen är att vissa systemskrav går att testa genomautomatiserade tester och att kraven måste huvudsakligen vara mätbara,tydliga och kunna mätas genom systemets användargränssnitt.

88

En metod för att modernisera gamla,utdaterade system

Viktor Ringdahl

Gamla system når ibland den punkt då underhåll av systemet inte längre kan gö-ras effektivt och en modernisering krävs för att realistiskt kunna fortsätta utnyttjaoch vidareutveckla systemet. När detta görs är det ofta fördelaktigt att säkerställaatt vidareutveckling av systemet kan fortsätta utan att behöva göra en ny to-tal uppgradering några år senare. I denna artikel presenteras en metod som kanutnyttjas i små till medelstora projekt där mjukvara-hårdvara relationer ligger ifokus. Metoden ämnar göra det möjligt att snabbt kunna utveckla en ny modulärversion av ett gammalt system.

1 Inledning

Äldre system når ibland den punkt då de fungerar dåligt, eller inte alls,med nya enheter och teknologier som vill utnyttja funktionalitet i syste-met. Detta kan till exempel uppstå när en teknologi inte längre stöds avdess ursprungliga utvecklare. När detta inträffar behöver systemet upp-graderas och moderniseras för att säkerställa att det i fortsättningen kananvändas och vidareutvecklas. Denna rapport presenterar och utvärderaren metod som använts för att modernisera och framtidssäkra ett gammalt,utdaterat system.

1.1 Syfte

Att kunna utnyttja så mycket som möjligt av ett system under så långtid som möjligt är av stort värde för intressenter (stakeholders) då upp-graderingar ofta är kostsamma. Detta innebär att när ett gammalt systemtill slut når den punkten då en uppgradering krävs ligger det i linje medintressenternas bästa att lägga ned mer resurser på ett ordentligt systemsom sedan kan utnyttjas under lång tid, för att i det långa loppet sparain pengar, både genom att göra fortsatt utveckling enklare och genom attgöra komponenter i systemet möjliga att byta ut utan att skriva om reste-rande komponenter. En total omskrivning kan till och med vara mer eko-nomiskt rimligt än att försöka rädda spillrorna, något som Weide, Heym

89

och Hollingsworth framhäver i “Reverse Engineering of Legacy Code Ex-posed” [35].

Det finns många äldre system som behöver uppgraderas men inte bygg-des med uppgraderbarhet i åtanken. Detta medför att stora delar av sy-stemet måste skrivas om för att modernisera kodbasen till en nivå därfortsatt utveckling och användning av systemet kan göras effektiv igen.Detta är ett problem som blir ännu tydligare när systemet utnyttjar hård-vara (eller mjukvara) från tredje parter som i framtiden kan komma attbytas ut.

Denna situation rådde när ett styrsystem för en 3D-scanner skulle upp-graderas, och det är den metod som utnyttjats för detta ändamål somutvärderas i denna rapport.


Denna rapport ämnar att utvärdera den metod som tillämpats för att mo-dernisera ett utdaterat system genom att göra det modulärt. Vilka typer avprojekt lämpar sig metoden för? Vilka fördelar och nackdelar medför metoden?

1.3 Avgränsningar

Rapporten behandlar inte styrelserelaterade beslut och analyser, så somkostnadsuppskattningar eller riskanalys, utan förutsätter att behovet avett uppgraderat system finns. Som fokus i rapport ligger system där gam-mal hårdvara utnyttjas, regelrätta hårdvarulösningar betraktas inte ochkompletta mjukvarulösningar endast mindre ingående.

Metoden utvärderas endast baserat på de erfarenheter som erhållits underen användning av metoden då det inte funnits resurser nog att användaden i ett annat projekt.

2 Teori

Metoden som här ska presenteras uppkom när ett utdaterat system för3D-scanning skulle uppdateras. Det fanns mycket liten kunskap om detgamla systemet tillgänglig, dels på grund av systemets ålder och att ingaav de ordinarie utvecklarna eller efterföljande underhållare fanns tillgäng-liga att införskaffa information ifrån. Systemet hade tidigare mest använtsoch inte vidareutvecklats. Detta i kombination med mycket bristande do-kumentation i många av systemets delar medförde att det under en långtid var ovisst exakt vad som behövde göras.

90

Vidare var utvecklingstiden tillgänglig begränsad och således var det intemed säkerhet realistisk att i fullo sätta sig in i det tidigare systemet in-nan utveckling påbörjats. En arkitektur behövdes redan innan en djupareförståelse av systemet erhållits för att inte riskera att missa deadline.

Kunden önskade också att det nya systemet skulle utnyttja ROS, RobotOperating System [1]. Detta kunde inte utföras på en dator som kör-de Windows utan att använda experimentella och ofullständiga bibliotek(endast Ubuntu stöds officiellt) - något som helt strider emot önskan omatt få ett ordentligt och stabilt system. För hårdvaruenheterna rådde denmotsatta situationen - två av dem utnyttjar drivrutiner som endast finnstillgängliga för Windows.

Ett annat av kundens önskemål var ett uppgraderbart system då det an-sågs troligt att i framtiden uppgradera hårdvaran systemet byggts av. Stortfokus lades på att lösa detta - och således på att få ett så löst kopplat,modulärt, system som möjligt. Detta skulle underlätta vidareutvecklingeftersom modifieringar som görs endast kräver ändringar på ett eller fåtal(logiska) ställen.

Det resulterande systemet som denna rapport grundas på blev således ettdistribuerat system, där olika program på två olika datorer ansvarar förhelt olika områden. Dessa program har sedan som kommunikationsmeka-nism ett generellt nätverkslager som sköter kommunikationen i form avvanliga TCP meddelanden. All kommunikation går igenom detta lager,även om programmen behöver kommunicera med program på sammadator, för att hålla det hela så konsekvent som möjligt.

Ett distribuerat system är av natur alltid i någon mening modulärt, mendetta togs ett steg extra för att säkerställa att det endast är den styrandemodulen som har kännedom om hur systemet i helhet fungerar.

Värdet av att få ett system så okopplat (det vill säga modulärt) som möjligtframgår i arbetet som Visaggio gjort där en rad problem med åldrandesystem beskrivs. Hårt kopplade system medför att en ändring blir mycketresurskrävande att utföra. En biverkning blir också att regressionstester ärsvåra att utföra när många olika delar av ett system måste kollas. [36]

3 Metod

Denna rapport ämnar att undersöka hur ett utdaterat system kan uppda-teras till ett modernt system som sedan kan vidareutvecklas. Detta görsgenom att utvärdera den metod som utnyttjats för att utveckla treeD, enuppdaterad version av ett styrsystem för en 3D-scanner.

Undersökningen görs genom att först specificera den metod som faktisktuttnyttjats, för att sedan utvärdera metodens tillämplighet på andra pro-jekt baserat på de erfarenheter som införskaffats när metoden utnyttjades.De speciella förhållanden som rådde i projektet tas i beaktning när ett

91

teoretiskt resonemang förs för att undersöka till vilken grad metoden ärtillämpbar på andra projekt. Dessa förhållanden beskrivs mer ingående iavsnitt 2.

4 Resultat

Detta avsnitt presenterar de resultat som erhållits genom att först beskrivadet tillvägagångssätt som utnyttjats för att modernisera ett styrsystem fören 3D-scanner. Från tillvägagångssättet extraheras sedan en mer generellmetod som den resterande delen av rapporten behandlar.

4.1 Tillvägagångssättet

Kunskap om det äldre systemet innan moderniseringsarbetet påbörjatsvar mycket begränsad, och tiden tillgänglig var redan i förväg given. Där-emot fanns det klara krav definierade gällande funktionalitet, övergripan-de beteende och val av teknologier. Dessa förhållanden medförde att enkomplett arkitektur inte realistiskt kunde definieras innan utvecklingsar-betet påbörjats. Samtidigt var resursen i form av mantimmar tillgängligredan från projektets början, en resurs som behövde utnyttjas - projekt-medlemmar kunde inte rulla tummarna fram tills dess att en komplettförståelse av systemet erhållits. Ett annat problem som medförde att pro-jektet behövde komma igång så snabbt som möjligt var den begränsadetillgången till hårdvara, påbörjades inte arbetet direkt fanns det risk att enflaskhals skulle uppstå senare i projektet.

För att komma runt problemen behövde en metod som kompenserar fördem användas. Detta gjordes genom att defininera en arkitektur beståen-de av de delar som var väl specificerade och styrda av de krav kundenställt. Med andra ord var det hur kommunikationen mellan de ovissa de-larna och de nya funktionerna som önskades i systemet skulle ske somdefinierades. Samtidigt med detta undersöktes det gamla systemet för attpå så sätt få en förståelse om det. Detta gjordes genom att studera sy-stemets kod och den (lilla) dokumentation som fanns tillgänglig, för attsedan när en grundläggande förståelse erhållits skriva testprogram. Medandra ord försökte det äldre systemet förstås genom att utnyttja trial anderror metoden. Arbetssättet medförde att den resurs som fanns i form avarbetstimmar parallellt utnyttjades på att både få en förståelse av det gam-la systemet och utveckla det nya.

I takt med att mer kunskap om systemet erhållits skiftade fokus istället tillatt utveckla den funktionalitet som visat sig krävas från det äldre syste-met. Arbete på dessa delar påbörjades så fort arkitekturen var färdigdefi-nierad. I och med ovisshet i exakt vilken funktionalitet som krävdes hade

92

en mer allmän arkitektur än vad som krävts definierats. En positiv kon-sekvens detta medförde var att ingen större omskrivning av arkitekturensenare krävdes.

4.2 Metoden

Från tillvägagångssättet kan en mer generell metod extraheras;

1. Erhåll en grov översikt av systemet

2. Definiera kommunikations-/interaktionsmekanismer

3. Undersök, utforska och utveckla (görs parallellt)

a) Läs och förstå gammal kod

b) Skriv testfunktioner, trial and error

c) Utveckla kommunikations-/interaktionsmekanismerna

4. Förfina (görs parallellt)

a) Skriv gränssnitt som blottlägger och utför funktionalitet

b) Vid behov uppdatera kommunikations-/interaktionsmekanismerna

5. Koppla ihop

I första steget skaffas en överblick av vad det nuvarande systemet gör,vilka delar som kommunicerar med vilka och till vilken grad. När dettagjorts kan mekanismer som ska utnyttjas mellan hårdvarukomponenternadefinieras. Med fördel kan mekanismerna återanvändas mellan så mångadelar som möjligt i systemet för att dra ned utvecklingstiden. Exempel påmekanismer är läsning och skrivning till fil, databas eller nätverksbaseradkommunikation. När styrsystemet för en 3D-scanner skulle uppdaterasgjordes detta nätverksbaserat.

När mekanismerna är färdigdefinierade är förstudiefasen över och utveck-ling av dem påbörjas. Djupare informations-inhämtande ifrån det äldresystemets kod och dokumentation görs tillsammans med tester mot syste-met och eventuella hårdvarukomponenter för att skaffa en bild av vilkenfunktionalitet ifrån det äldre systemet som behövs implementeras i detnya.

När sedan en tillräckligt god bild av det äldre systemet är erhållen färdig-ställs ett gränssnitt som sedan kan utnyttjas av mekanismerna. Behöverdessa uppdateras sker detta efter behov.

Sista steget är sedan att koppla ihop mekanismerna med de underliggan-de funktionerna, och dessa mekanismer med varandra. I det projekt som

93

utförts innebar detta att koppla ihop hårdvarans gränssnitt med ett nät-verkslager, för att sedan koppla ihop dessa med en koordinatör för helasystemet.

5 Diskussion

I detta avsnitt analyseras och diskuteras för och nackdelar med den metodsom utnyttjats när ett styrsystem för en 3D-scanner moderniserats.

Då metoden från början utgår från en ofullständig bild av hur det slutgilti-ga systemet kommer att bli medför det att de kommunikationmekanismersom designas blir mer generella än vad som egentligen krävs. Detta på-tvingar en typ av moduläritet i och med att systemet från början designasför att fungera med flera olika delsystem. Denna moduläritet kan sedanutnyttjas om systemet i framtiden behöver uppdatera ett delsystem. Dettabetyder å andra sidan att mer tid än vad som egentligen krävts läggs föratt få funktionalitet som inte behövs för nuvarande version.

I och med att utveckling av kommunikationsmekanismer och lärande omdet gamla systemet sker parallellt med varandra kan arbetet i de fallendär endast ett begränsat antal hårdvarukomponenter finns tillgängliga skeutan att arbetet blir för begränsat av bristande resurser. Detta medför attmer kan göras, även om allt som blir gjort inte med säkerhet kommer tillnytta i slutändan.

Nackdelar är således att mer jobb än det som behövs med största sanno-likhet kommer att göras, dock med fördelen att det mesta av det överflödi-ga jobbet i framtiden kan komma att underlätta. Samtidigt blir resultatettroligtvis inte lika väl designat som om en full förståelse för det gamla sy-stemet från början erhållits, men detta medför istället att tiden som måsteläggas på förstudier blir längre. Om denna extra tid på förstudier innebären kortare utvecklingstid är en fråga som är svår att svara på generellt,detta tror rapportförfattaren vara väldigt projekt-specifikt.

Även storleken på projektet kommer inverka om metoden är lämplig. Ärdet ett allt för stort projekt går det givetvis inte att bara sätta sig ner ochskriva utan att först ha en ordentlig bild av hur allt ska fungera. I och medantalet personer som krävs och den tid som behövs läggas ned inte kaninvesteras utan att först ha en klar bild att det hela ens är rimligt, vilketdet ofta inte är [35].

6 Slutsatser

Metoden tros vara väl lämplig för hårdvarunära projekt, och endast imindre utsträckning för andra projekt i och med att vissa omständigheterkompenseras för. Nackdelen med metoden är att mer resurser i form avtotalt antal timmar som krävs för att realisera projektet behövs i och med

94

att tiden som läggs ned inte enbart läggs på saker som i slutändan visarsig vara relevanta. Fördelen blir dock att en annars väldigt tidskrävandeförstudiefas kan kortas ned och mer tid kan läggas på själva utvecklingen.

Har projektet begränsad tillgång på projektspecifika resurser så som hård-vara och/eller dokumentation, kort deadline men många utvecklare och/el-ler i behov av att inom rimlig framtid uppgradera komponenter i systemetkan metoden mycket väl lämpa sig att utnyttja. Om det är lönsamt att ut-nyttja metoden beror alltså mycket på de förhållanden som råder.

95

Grupprums påverkan på utvecklingsarbetet ien projektgrupp

Sara Svensson

Många företag erbjuder idag sina anställda att arbeta på distans. Under ett pro-jektarbete vid Linköpings universitet arbetade studenter i grupper om cirka niopersoner. Vissa av dessa grupper saknade egen arbetslokal och fick därför söka sigtill andra utrymmen för att arbeta. Det undersöktes huruvida deras förhållandenkunde jämföras med distansarbete på företag.

En intervjustudie genomfördes. Det visade sig att arbetsmetodiken underlättadesav grupprum, medan gruppdynamiken däremot tar skada. De för- och nackdelarsom upptäcktes med att inte ha ett eget grupprum och distansarbete skiljde sig åtpå många områden. Dessa kunde därför inte liknas med varandra.

1 Inledning

Detta projekt utfördes i samband med kursen TDDD96, Kandidatprojekt iprogramvaruutveckling, vid Linköpings universitet, där kursens syfte varatt efterlikna projektgrupper i arbetslivet som arbetar mot kund. Totaltgjorde tio grupper sitt kandidatarbete i anslutning till denna kurs, därtre av tio grupper kunde genomföra sitt arbete i ett tilldelat grupprum. Idenna rapport analyseras hur ett gemensamt rum kan ha påverkat arbetetför kursens projektgrupper, samt om dess påverkan har haft liknande för-och nackdelar som distansarbete.

1.1 Syfte

Syftet med denna rapport är att få en klarhet i hur en grupp har arbetat,planerat och kommunicerat med varandra beroende på om de har haft ettgrupprum att tillgå eller ej. Förhoppningen är även att få en uppfattningom det har funnits specifika likheter och skillnader med ett gemensamtrum för en grupp som arbetar med programutveckling och om dessa kanliknas med de för- och nackdelar som finns hos de företag som erbjuderdistansarbete.

97


På en del företag kan en anställd välja att arbeta på distans, till exempelpå ett satellitkontor eller hemifrån [37]. I denna kurs har en del grup-per blivit tilldelade egna arbetsrum, medan andra grupper inte har haftsamma möjlighet. Då denna kurs har haft som syfte att ge sina studentererfarenhet av det kommande arbetslivet, är det av intresse att ta reda påhur grupprum kan ha påverkat projektgruppers arbetsmetodik, gemen-skap och effektivitet. Det är även av intresse att jämföra gruppernas för-och nackdelar inom dessa områden med de problem som företag har meddistansarbete, vilket har gett upphov till följande frågeställningar:

Hur har gruppernas arbetsmetodik, gemenskap och effektivitet skiljt sig åt bero-ende på om de har haft tillgång till ett gemensamt rum eller ej?

Har det funnits specifika för- och nackdelar med ett gemensamt grupprum ochfinns det likheter med de för- och nackdelar företag stöter på med distansarbete?

1.3 Avgränsningar

Denna rapport avser inte att ta hänsyn till gruppernas projekt, även omdet skulle kunna finnas risk till att ha haft betydelse för resultatet. Omså är fallet kommer det dock att nämnas kortfattat utan djupare analys.I denna rapport tas det heller inte hänsyn till varken gruppstorlek ellermedlemmars tidigare erfarenheter, utan anses vara lika för samtliga grup-per även om så inte är fallet. Med grupprum menas ett eget arbetsrumpå campus valla i Linköping dit samtliga medlemmar har kunnat vistasoch arbetat i samtidigt. En grupp togs bort ur undersökningen då derasvillkor med att boka grupprum ej var densamma som för resten av degrupper som saknade egen arbetsyta.

2 Teori

De fakta som presenteras i detta avsnitt är hämtad från Telework: The Ad-vantages and Challanges of Working Here, There, Anywhere, and Anytime [37].

Distansarbete är ett samlingsord för all typ av arbete som inte sker på fö-retags fasta kontor. Det finns många olika varianter av distansarbete därnågra av de vanligaste är att arbeta ifrån satellitkontor och hemarbete.Dessa varianter är inte entydiga utan går att blanda, vilket gör distansar-bete till ett brett och aningen diffust ord.

98

2.1 Hemarbete

Hemarbete innebär, som namnet antyder, att personal med sådan anställ-ning jobbar hemifrån några gånger i månaden. Den enda kontakt som denhemarbetande har är då via telefon, internet, fax eller liknande. Det finnsingen fast gräns på hur många gånger i månaden en anställd måste jobbahemifrån för att det ska få klassas som hemarbete, dock bör det vara re-lativt frekvent för att de för- och nackdelar som finns med hemarbete skavara relevanta.

2.1.1 Fördelar med hemarbete

Hemarbete ger den anställde möjlighet att själv bestämma när och var detpassar att jobba, vilket kan öka personens produktivitet. Hemarbete kandessutom vara bra för att få personer som har långt till kontoret att intebyta jobb på grund av pendlingstiden. Det finns dessutom rapporter somvisar att personer som regelbundet jobbar hemifrån är mer nöjda medjobbet, presterar bättre och har mindre frånvaro.

2.1.2 Nackdelar med hemarbete

En stor nackdel med hemarbete är att ledare får sämre uppsikt över sinaanställda. Det kan leda till att de har sämre koll på sina anställdas styrkoroch svagheter, samtidigt som det kan bli svårare att organisera arbetet.Det kan också vara svårt för dem att skapa en bra grupp-synergi om intealla är på kontoret samtidigt. De dagar som de anställda jobbar hemifrånförlorar de dessutom kunskapsutbyten med kollegorna. Det finns dess-utom en stor risk att de personer som jobbar hemma blir distraherade avandra saker, till exempel hussysslor. Om en projektgrupp består av bådeanställda som får arbeta hemifrån och anställda som alltid ska befinna sigpå kontoret, kan det bli svårt att få samarbetet mellan kollegorna att fun-gera. De kanske inte vågar kontakta någon som jobbar hemma då de ärrädda för att störa personen, eller så är personen i fråga svår att få kontaktmed. De som jobbar hemifrån kan dessutom känna sig socialt avskärmadefrån sin projektgrupp om det är få som distansarbetar i gruppen.

2.2 Satellitkontor

Satellitkontor kallas de kontor som företag äger eller hyr och som inte är ianslutning till företagets huvudkontor. Syftet med satellitkontor är att fun-gera som en alternativ arbetsplats för de anställda. Personal med sådananställning kan därmed välja mellan att jobba på huvudkontoret eller detexterna kontoret. Satellitkontor kom till som ett alternativ till hemarbete

99

för att kunna erbjuda personal färre pendlingstimmar till huvudkontoretoch samtidigt undvika många av dem nackdelar som hemarbete innebär,exempelvis hussysslor, kunskapsutbyten, sociala förhållanden och kom-munikation.

2.2.1 Fördelar med satellitkontor

Fördelarna som finns med satellitkontor är ganska lika de fördelar somfinns för hemarbete. Även anställda som istället erbjuds satellitkontor fårkortare pendlingstid, vilket minskar risken för att de söker sig till andrajobb närmare hemmet. Till skillnad från hemarbete kan kunskapsutbytenlättare ske mellan kollegor samtidigt som distraktioner i hemmet undviks.

2.2.2 Nackdelar med satellitkontor

Precis som med fördelarna delar satellitkontor även många nackdelar medhemarbete. Även om personen troligtvis inte kommer att känna sig socialtavskärmad från sina kollegor, kan det ändå bli svårt med kommunikatio-nen till de personer som jobbar i samma projekt.

3 Metod

För att få svar på de frågor som togs upp i avsnitt 1.2 intervjuades enperson ifrån var projektgrupp i slutet av iteration fyra i kursen. De tiopersonerna valdes slumpmässigt ut och en träff bestämdes för intervju.Samtliga deltagare ställdes i grunden samma frågor som vid behov dis-kuterades vidare med följdfrågor. Frågorna formulerades så att de täck-te de områden som togs upp i frågeställningen, nämligen arbetsmetodik,gruppdynamik och effektivitet. De frågor som var förutbestämda ändradesdock inte mellan intervjuerna. Följande frågor som ställdes kan läsas iappendix C.

Intervjun förbereddes enligt Qualitative Interview Design: A Practical Guidefor Novice Investigators där de för- och nackdelar som Telework: The Advan-tages and Challenges of Working Here, There, Anywhere, and Anytime tog uppmed att arbeta hemifrån låg som grund för frågornas formuleringar [5,37]. Frågornas lämplighet diskuterades med en som själv utfört intervjuerefter Qualitative Interview Design: A Practical Guide for Novice Investigators.En pilotintervju genomfördes dessutom med denna person, vars svar intehar tagits med i resultatet.

Det som sades på intervjuerna antecknades. Renskrivna anteckningar frånintervjuerna som resultatet bygge på finns att läsa i appendix C. För attsammanställa all data från intervjuerna jämfördes svaren fråga för fråga

100

mellan de personer vars grupp hade ett eget rum att tillgå respektive desom inte hade det. Dessa sammanställdes och presenteras i avsnitt 4.

4 Resultat

I detta avsnitt presenteras resultatet av de intervjuer som ställdes i under-sökningen. Resultatet delas upp i arbetsmetodik, gruppdynamik och effektivi-tet och under varje rubrik är resultatet uppdelat i projektgrupper utan egetrum och projektgrupper med eget rum.

4.1 Arbetsmetodik

Detta avsnitt behandlar gruppernas arbetsmetodik. För tydlig struktur de-las området in i mindre paragrafer, nämligen arbetsplatser, arbetsplaneringoch fördelning, förbättring på arbetsmetodik och kommunikation.

4.1.1 Projektgrupper utan eget rum

Arbetsplatser För möten och samarbeten har salar på universitet fåttbokas. Alternativa lösningar har varit att sitta tillsammans på platser ikorridoren, eller att jobba hemifrån.

Arbetsplanering och fördelning Vanligast var att använda verktygetTrello1. Trello användes dock mycket olika. Största skillnaden var när upp-gifter lades upp på Trello, samt hur uppgifterna fördelades mellan grupp-medlemmarna.

Förbättring på arbetsmetodik Nästan alla grupper var nöjda med att dehade suttit mycket tillsammans och jobbat. Det som hade fungerat sämrevar strukturen på hur uppgifter hade fördelats. Hur detta hade gjortsskiljde sig mellan grupperna, men de flesta hade tyckt att det var rörigtemellanåt.

Kommunikation Slack2 har använts av samtliga grupper då muntligkommunikation inte har varit möjlig. En del diskussioner och längre dia-loger har förekommit i Slack. De flesta av grupperna tyckte att det hadefungerat bra att kommunicera via Slack, men för en del hade det emel-lanåt varit svårt att nå varandra.

1Ett verktyg för virtuella Kanban-tavlor, se trello.com2Ett kommunikationsverktyg riktat mot projektgruppe, se slack.com

101

4.1.2 Projektgrupper med eget rum

Arbetsplatser För de grupper som har haft grupprum påstår sig samt-liga ha jobbat över 90 % i grupprummet. Har de suttit hemma har de fördet mesta jobbat med dokument.

Arbetsplanering och fördelning Grupperna har planerat arbetet på mö-ten, men även kontinuerligt i arbetsrummet. Fördelning av arbetet harskett genom en fysisk Kanban-tavla i en grupp och genom Trello i enannan. En grupp satsade på att se till så att var medlem i första handplockade det som var relaterat för sin roll.

Förbättring på arbetsmetodik Någon grupp tyckte att det skulle ha an-vänts Trello istället för en fysisk Kanban-tavla, medan en annan tyckteatt deras Trello glömdes bort i slutet av projektet. I övrigt var samtligagrupper nöjda med sitt arbetsupplägg. Alla grupperna lyfte fram olikaaspekter som de tyckte hade varit specifikt bra, däribland att man valt attdela upp arbetet i mindre moduler för att få en bättre översikt av arbetet.

Kommunikation Samtliga grupper använde Slack då de inte var i grupp-rummet. Det som har tagits upp i kommunikationsverktyget har varit sa-ker som “var är du?” och “när ses vi imorgon?”. Responsen nämner enintervjudeltagare har varit mindre bra stundvis. Största delen av kommu-nikationen har skett i grupprummen och det är även där som diskussionerhar ägt rum.

4.2 Gruppdynamik

Detta avsnitt behandlar gruppernas gruppdynamik. För tydlig strukturdelas området in i mindre paragrafer, nämligen gruppdynamik och relationoch kunskapsförmedling och problemlösning.


Gruppdynamik och relation Gruppdynamiken beskrivs i de flesta fallsom väldigt bra, men i något fall var gruppen en aning splittrad eftersomnågra medlemmar föredrog att jobba själva hemma. Alla personer somintervjuades hade inte känt majoriteten av sina gruppmedlemmar innankursens start, men ansåg sig nu känna sina kollegor bra.

102

Kunskapsförmedling och problemlösning Alla förutom två stycken grup-per hade anordnat utbildningar i början av kursen. De andra två grupper-na hade istället lagt upp referenser i Slack. Endast en person var nöjdmed sin grupps kunskapsutbyten. Stötte medlemmarna på problem sva-rade nästan alla att de frågade sina gruppmedlemmar om hjälp.


Gruppdynamik och relation Gruppdynamiken beskrevs som väldigtbra av samtliga personer. Alla påpekade att medlemmarna kom bra över-ens och jobbar bra ihop, dock sa även en av dem att det ibland kunde blien negativ klang under deras diskussioner.

Kunskapsförmedling och problemlösning Det har inte förekommit nå-gon planerad kunskapsförmedling så som utbildningar. En person påstoddessutom att dess grupp hade varit dålig på detta område. Vid problemdiskuterade två av grupperna med sin programmeringspartner och vidfortsatta problem frågades andra gruppmedlemmar. En grupp sökte påinternet till problemet var löst.

4.3 Effektivitet

Detta avsnitt delas in i mindre paragrafer, nämligen effektivitet och arbetsin-sats och lediga dagar.


Effektivitet Många av dem som intervjuades tyckte sig vara mer kon-centrerade i skolan. Någon tyckte att det kunde vara svårt att koncentrerasig när gruppen satt tillsammans. Någon påstod att gruppen var som mesteffektiv när de satt tillsammans, medan en annan inte tyckte att det varnågon märkbar skillnad.

Arbetsinsats och lediga dagar De flesta av dem som intervjuades tyckteatt sin arbetsinsats kunde ha varit bättre. Hälften hade dessutom haft enkortare ledighet. Samtliga tyckte att det hade varit väldigt roligt att jobbamed projektet och de flesta tyckte även att det hade varit lärorikt. Några avgrupperna var väldigt nöjda med sin produkt och några sa att produktenhade blivit bra i förhållande till de förutsättningar de hade.

103


Effektivitet Alla grupper tyckte sig ha haft det enkelt att jobba i grupp-rummen och att effektiviteten har varit som bäst där. En tyckte även, bort-sett från kommunikationsbristen, att effektiviteten var bra hemma.

Arbetsinsats och lediga dagar Två av grupperna tyckte att deras ar-betsinsats hade varit bra, men även att de hade gjort bättre ifrån sig omde hade haft ett bredare perspektiv på projektet. En var helt nöjd medsin arbetsinsats. Samtliga tyckte att projektet hade varit roligt och lärorikt.Alla var nöjda med sin produkt.

5 Diskussion

I den här delen kommer de resultat som presenterades i avsnitt 4 att dis-kuteras. Diskussionen kommer att ha samma rubrikföljd som resultatde-len där gruppernas svar kommer att jämföras med varandra, samt medde för- och nackdelar som finns med distansarbete. Till sist kommer re-sultatets trovärdighet att utvärderas.

5.1 Arbetsmetodik

Arbetsplatser En stor nackdel med hemarbete, är att tillgänglighetenoch kommunikationen begränsas med den kollega som jobbar hemifrån.Även företagskulturen och gruppsynergin påverkas negativt [37]. Resulta-tet tyder på att vissa grupper i kusen hade upplevt dessa problem, fram-för allt de grupper utan eget arbetsrum. Samma grupper påstod också attarbetet flöt på som bäst när åtminstone de flesta av gruppen satt tillsam-mans och frågan är då om detta skulle kunna liknas vid satellitkontor.

Arbetsplanering och fördelning Arbetsplanering och fördelning mellangrupper utan eget rum verkar ha skiljt sig mer än mellan de med grupp-rum. Detta eftersom dessa personer förklarade hur de hade lagt upp arbe-tet mer utförligt än övriga intervjudeltagare. Att de med eget gruppruminte hade lika mycket att berätta om sin arbetsmetodik kan bero på denspontana diskussionsmöjlighet som de hade. Det är därför möjligt att entydligt definierad planerings- och fördelningsstrategi ej har varit nödvän-dig för att få struktur i arbetet för dessa grupper, vilket troligen har varitavgörande för de andra. Det kan också tolkas som att spontana diskussio-ner är en stor faktor till bra planering och fördelning.

104

Förbättring på arbetsmetodik Det är tydligt att de grupper som harhaft tillgång till ett eget arbetsrum generellt sett var mer nöjd med sinarbetsmetodik. Då arbetsmetodiken skiljde sig mycket mellan de grupperutan grupprum var det svårt att få fram en specifik orsak till detta. Dockanses det vara rimligt att anta att ledares sämre uppsikt kan vara en avanledningarna till en mer bristande arbetsmetodik bland dessa grupper,även om detta bara är spekulationer. I sådana fall är det en nackdel medbåde hemarbete och satellitkontor [37].

Kommunikation Samtliga grupper använde kommunikationsverktygetSlack, men användandet skiljde sig mellan de med grupprum och utan.Inte så förvånande hade de grupper som saknade eget arbetsutrymme ge-nerellt fler diskussioner i Slack. Även här går det att se att de grupper utangrupprum verkar ha haft ett större behov av att strukturera upp arbetetän vad andra tros ha haft. Detta på grund av deras tydliga kategoriseringav kommunikationsverktyget. En negativ aspekt med hemarbete kan varaatt personer inte vågar kontakta gruppmedlemmar som sitter hemma ochjobbar, eller att gruppmedlemmarna är svåra att kontakta [37]. Gruppernai denna kurs vekar dock inte ha stött på såanna problem, vilket kan tänkasbero på att studenter många gånger studerar utanför schemalagd tid.

5.2 Gruppdynamik och effektivitet

Gruppdynamik och relation Vad gäller gruppdynamiken verkar det in-te, bortsett från något undantag, vara stora skillnader mellan de olikagrupperna. I samtliga intervjuer påstods medlemmarna jobba bra tillsam-mans, även om någon grupp av dem utan grupprum hade varit en aningsplittrad. Med hemarbete finns nackdelen att stämningen mellan arbets-kamrater kan påverkas negativt om en eller flera inte alltid finns på kon-toret [37]. Detta vekar inte ha varit fallet för denna kurs projektgrupper.

Kunskapsförmedling och problemlösning När en eller flera anställdajobbar hemifrån förlorar de mycket kunskapsutbyten mellan sig och sinakollegor. Detta gäller främst spontana utbyten som sker på rasterna elleri korridoren [37]. I denna kurs verkar det dock ha varit tvärtom. Kun-skapsutbytet har fungerat bättre för de grupper utan arbetsrum än fördem med. På frågan om hur problem har hanterats var det mer vanligtatt de i första hand svarade att de skulle fråga någon, än vad det var förde andra. En deltagare tyckte dessutom att kunskapsförmedling var nå-got som hade varit bristande i sin grupp. Denna grupp hade eget rum atttillgå, vilket var lite av en överraskning då det innan studien troddes varatvärtom.

105

Effektivitet Samtliga grupper anser att det var mer effektivt att jobba isitt egna eller bokade grupprum i jämförelse med att jobba hemma. Detfanns dock ett fåtal undantag där man inte tyckte att det spelade någonroll. En fördel med att jobba hemma är att man inte blir störd av sina kol-legor, vilket gör det enklare att koncentrera sig [37]. De personer som kompå intervju var av annan åsikt, dock hade några haft kollegor som hadevalt att jobba hemifrån. Varför dessa personer valde att stanna hemma gådäremot inte att svara på.

Arbetsinsats och lediga dagar Av dem som intervjuades var de somhade haft ett grupprum mer nöjda över sin egen insats än de personersom inte hade haft grupprum. Dessa personer hade dessutom varit bortafler dagar från projektet. Alla tyckte överlag att det hade varit roligt attjobba med projektet och att deras produkt hade blivit bra.

5.3 Undersökningens trovärdighet

Det finns en del faktorer som kan vara bra att nämna om undersökningenstrovärdighet. För det första intervjuades endast en person ifrån var gruppsom fick föra alla medlemmars talan. Detta medförde att få personer somgillar att jobba hemifrån intervjuades, vilket gjorde det svårt att jämföragrupperna med de fördelar som finns med distansarbete. Detta har i sintur medfört att enbart negativa aspekter tagits upp i diskussionen. Det börockså nämnas att enbart tre av de nio grupperna hade ett eget arbetsrum.Innan undersökningen förväntades antalet vara något högre.

I denna undersökning har ingen referens använts på hur intervjuer skasammanställas, vilket har bidragit till att författaren själv har fått hitta påen lämplig metod. Detta, i kombination med att författaren aldrig tidigarehar gjort liknande intervjuer, kan vara bra att ha i åtanke.

6 Slutsatser

I detta avsnitt presenteras de slutsatser som går att dra från undersök-ningen. Dessa delas upp efter de frågeställningar som rapporten har be-handlat.

Hur har gruppernas arbetsmetodik, gemenskap och effektivitet skiljtsig åt beroende på om de har haft tillgång till ett gemensamt rum ellerej? Arbetsmetodiken har skiljt sig mellan grupper med och utan egetarbetsrum. Grupperna med arbetsrum har förlitat sig mindre på kommu-nikationsverktyg, i detta fall Slack, och låtit arbetet flyta på mer spontanti jämförelse med övriga. Det finns ingen tydlig likhet med hur de grupper

106

utan grupprum har valt att lägga upp arbetet, men Trello är i de flesta fallen gemensam nämnare. Detta verktyg har däremot använts väldigt olikamellan grupperna.

Gruppdynamiken mellan grupper med och utan eget arbetsrum har inteskiljt sig mycket, men har ändå varit aningen bättre bland de grupper somsaknar egen arbetsyta. Överlag har alla grupper haft en god stämning ochjobbat bra ihop med alla sina medlemmar, trots att de flesta inte kändevarandra sedan innan.

Effektiviteten har varit väldigt personlig. Vissa har ansett att det har varitnödvändigt att hela eller stora delar av gruppen ska ha suttit tillsam-mans för att produktutvecklingen ska vara som mest effektiv. Andra harpåstått att det har varit lätt att bli störd av varandra i grupprum. Det kun-de utifrån denna studie inte dras någon slutsats om det hade med egnagrupprum att göra eller ej.

Har det funnits specifika för- och nackdelar med ett gemensamt grupp-rum och finns det likheter med de för- och nackdelar företag stöter påmed distansarbete? Det har funnits fördelar med att ha ett gemensamtgrupprum i kursen. Bland annat har arbetsmetodiken fått ett lyft. De per-soner som hade eget arbetsrum var överlag mer nöjda med produkten ochsitt eget arbete än vad övriga deltagare i undersökningen var. Vad gällerde för- och nackdelar som finns med distansarbete skiljer sig dessa frånflera av de för- och nackdelar som upptäcktes med att vara utan grupp-rum i denna kurs. Dessa anses därför inte vara jämförbara, varken medhemarbete eller satellitkontor.

107

Litteratur

[1] Open Source Robotics Foundation. About ROS. 2016. url: http ://web.archive.org/web/20160414020800/http://www.ros.org/about-ros/ (hämtad 2016-04-14).

[2] “IEEE Standard Glossary of Software Engineering Terminology”. I:IEEE Std 610.12-1990(R2002) (1990). doi: 10.1109/IEEESTD.1990.101064.

[3] trello.com. Trello. Febr. 2016. url: https://trello.com (hämtad2016-05-27).

[4] leankit.com. Kanban. Febr. 2016. url: https://leankit.com/learn/kanban/kanban-board/ (hämtad 2016-05-27).

[5] Daniel W Turner III. “Qualitative interview design: A practical gui-de for novice investigators”. I: The qualitative report 15.3 (2010), s. 754.issn: 1052-0147.

[6] Click. http://click.pocoo.org/5/. Hämtad: 2016-05-27.

[7] Free Software Foundation. Standards for Command Line Interfaces.2016. url: https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html (hämtad 2016-05-27).

[8] Puppet. Puppet - The shortest path to better software. 2016. url: https://git-scm.com/ (hämtad 2016-05-23).

[9] Git. Git. 2016. url: https://git-scm.com/ (hämtad 2016-05-23).

[10] Tomas Svensson och Christian Krysander. Projektmodellen LiPS. Stu-dentlitteratur, 2011. isbn: 9789144075259.

[11] Slack. Slack: Be less busy. 2016. url: https://slack.com/ (hämtad2016-05-23).

[12] Guido van Rossum, Barry Warsaw och Nick Coghlan. PEP 0008 –Style Guide for Python Code. 2016. url: https://www.python.org/dev/peps/pep-0008/ (hämtad 2016-05-23).

[13] J. H. Andrews m. fl. “Random Test Run Length and Effectiveness”.I: Proceedings of the 2008 23rd IEEE/ACM International Conference onAutomated Software Engineering. ASE ’08. Washington, DC, USA: IE-EE Computer Society, 2008, s. 19–28. isbn: 9781424421879. doi: 10.1109/ASE.2008.12.

[14] Frank Mittelbach m. fl. The LaTeX Companion (Tools and Techniquesfor Computer Typesetting). Addison-Wesley Professional, 2004. isbn:0201362996.

[15] Richard J Miara m. fl. “Program indentation and comprehensibili-ty”. I: Communications of the ACM 26.11 (1983), s. 861–867.

[16] Dag Langmyhr. “An alternative to LaTeX for beginners”. I: 6 (2001).issn: 1108-4170.

109

[17] Jens T. Berger Thielemann. “ChkTEX v1.7.5”. I: (2006). url: http://www.nongnu.org/chktex/ChkTeX.pdf (hämtad 2016-05-27).

[18] Chris Agruss och Bob Johnson. “Ad Hoc Software Testing: A per-spective on exploration and improvisation”. I: Florida Institute of Te-chnology. 2000, s. 68–69.

[19] SICK IVP AB. https://www.sick.com/se/sv/. Hämtat: 2016-05-08.

[20] Charles W. Krueger. “Software Reuse”. I: ACM Comput. Surv. 24.2(juni 1992), s. 131–183. issn: 0360-0300. doi: 10 . 1145 / 130844 .130856. url: http://doi.acm.org/10.1145/130844.130856.

[21] John McDermott och Chris Fox. “Using abuse case models for secu-rity requirements analysis”. I: Computer Security Applications Confe-rence, 1999.(ACSAC’99) Proceedings. 15th Annual. IEEE. 1999, s. 55–64.

[22] J. Biskup. Security in computing systems : Challenges, Approaches andSolutions. Berlin : Springer, c2009., 2009. isbn: 9783540784425.

[23] G. McGraw. “Software security”. I: IEEE Security Privacy 2.2 (mars2004), s. 80–83. issn: 1540-7993. doi: 10.1109/MSECP.2004.1281254.

[24] Python. Pickle — Python object serialization. April 2016. url: https://docs.python.org/3.4/library/pickle.html (hämtad 2016-05-27).

[25] William Stallings. Cryptography and Network Security: Principles andPractice. 5th. Prentice Hall Press, 2010. isbn: 9780136097044.

[26] JSON. Javascript Object Notation. Maj 2016. url: http://www.json.org/ (hämtad 2016-05-27).

[27] Mike Cohn. Agile estimating and planning. Pearson Education, 2005.isbn: 9780131479418.

[28] Sture Sjödin. “Problemlösning i grupp: betydelsen av gruppstorlek,gruppsammansättning, gruppnorm och problemtyp för gruppro-dukt och individuell kunskapsbehållning”. I: (1991).

[29] W. Schutz. FIRO: A Three-dimensional Theory of Interpersonal Beha-viour. Rinehart books in the assessment of personality. Holt, Rine-hart och Winston, 1958. url: https://books.google.se/books?id=iWsrAAAAIAAJ.

[30] N. C. Haugen. “An empirical study of using planning poker for userstory estimation”. I: AGILE (2006). doi: 10.1109/AGILE.2006.16.url: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1667560&tag=1.

[31] V. Mahnic. “A Case Study on Agile Estimating and Planning usingScrum”. I: Elektronika Ir Elektrotechnika 111.5 (2011), s. 123–128. doi:10.5755/j01.eee.111.5.372. url: http://www.vpa.ktu.lt/index.php/elt/article/viewArticle/372.

110

[32] Greg L Stewart, Kirstin A Manges och Marcia M Ward. “Empo-wering sustained patient safety: the benefits of combining top-downand bottom-up approaches”. I: Journal of nursing care quality 30.3(2015). issn: 1057-3631. doi: 10.1097/NCQ.0000000000000103.

[33] Andreas Spillner. Software testing foundations a study guide for thecertified tester exam. Santa Barbara, CA: Rocky Nook, 2014. isbn:9781937538422.

[34] Ossi Taipale m. fl. “Trade-off between automated and manual soft-ware testing”. I: International Journal of System Assurance Enginee-ring and Management 2.2 (2011), s. 114–125. issn: 0976-4348. doi:10.1007/s13198- 011- 0065- 6. url: http://dx.doi.org/10.1007/s13198-011-0065-6.

[35] Bruce W. Weide, Wayne D. Heym och Joseph E. Hollingsworth. “Re-verse Engineering of Legacy Code Exposed”. I: Proceedings of the17th International Conference on Software Engineering. ICSE ’95. Seatt-le, Washington, USA: ACM, 1995, s. 327–331. isbn: 0897917081. doi:10.1145/225014.225045. url: http://doi.acm.org/10.1145/225014.225045.

[36] Giuseppe Visaggio. “Ageing of a data-intensive legacy system: symptomsand remedies”. I: Journal of Software Maintenance and Evolution: Re-search and Practice 13.5 (2001), s. 281–308. issn: 1532-0618. doi: 10.1002/smr.234. url: http://dx.doi.org/10.1002/smr.234.

[37] Nancy B. Kurkland och Diane E. Bailey. “The advantages and chal-lenges of working here, there anywhere, and anytime”. I: Organi-zational Dynamics 28.2 (1999), s. 53–68. issn: 0090-2616. doi: http://dx.doi.org/10.1016/S0090-2616(00)80016-9.

111

A Intervjufrågor - Erfarenheter och arbetsmetodik

De frågor som ställdes under intervjuerna tillhörde två teman, medlem-marnas tidigare erfarenheter i projektarbeten och projektets arbetsmeto-dik.

A.1 Tidigare erfarenheter

• Tog du med dig erfarenheter ifrån tidigare projekt, och i så fall vilka?

• Har de haft någon inverkan på ditt arbete och i så fall hur?

• Har de haft någon inverkan på gruppens arbete som helhet, och i såfall hur?

• Har du märkt att andra i gruppen använt sina tidigare erfarenheter,och i så fall hur?

• Hur skulle du säga att gruppens kommunikation har fungerat jäm-fört med tidigare projekt.

• Har du fått några nya erfarenheter ifrån detta projekt? I så fall, vilka?

A.2 Arbetsmetodik

• Vilka arbetsmetodiker tycker du att du vet om hur fungerar?

• Hur skulle du beskriva den använda arbetsmetodiken?

• Vad har fungerat bra?

• Vad har fungerat dåligt?

• Hur skulle du vilja ändra den?

• Hur har du använt de dokument som vi har producerat?

• Hur effektiv anser du att du har varit i jämförelse med tidigare pro-jekt?

• Hur effektiv anser du att gruppen har varit som helhet i jämförelsemed tidigare projekt?

• Vilken inverkan anser du att Semat-Alpha-korten har haft för pro-jektet?

113

B Intervjufrågor – testning

B.1 Som testare

• Hur upplever du att testningens noggrannhet?

• Hur skulle du göra den noggrannare?

• Hur upplevde du den informationen du fick av utvecklaren?

• Önskade du dig mer och i så fall vad?

• Hur skulle du vilja ändra den?

• Hur använde du testplanen?

B.2 Som utvecklare

• Hur upplever du att testningens noggrannhet?

• Känner du att om du varit testare för din egen kod att du hade hittatfler buggar än testpersonen?

• Känner du att testningen hittade fler buggar än vad du själv hadehittat?

• Missade testaren någon bugg som du känner till?

• Hur använde du testplanen?

B.3 Generellt

• Vad tycker du om testning?

• Vad kan ha fallit igenom och i så fall varför?

• Hur tror du att testerna påverkat produktens kvalitet?

• Övrigt?

114

C Intervjufrågor - Grupprums påverkan påutvecklingsarbetet i en projektgrupp

Nedan listas de frågor som ställdes till samtliga deltagare under intervjun.Mellan var fråga listas även de svar som antecknades under intervjuernaoch som har sammanställts i avsnitt 4. Svaren är uppdelade mellan degrupper med eget grupprum och de utan. Anteckningarna renskrevs in-nan publicering.

• Har din projektgrupp haft ett gemensamt rum att arbeta i under hela projektet där alla medlemmar har kunnatvistas samtidigt?

– Ja– Ja– Nej– Nej– Ja– Nej– Nej– Nej– Nej

• På vilken/vilka platser har du valt att jobba med projektet och varför?– Bara grupprummet, trevligt att sitta tillsammans och det är lättare at kontakta varandra.– Jobbat 95 % i grupprum. Resten lite hemma och då mest med kandidatarbete och egna delen.– Främst i skolan tillsammans med gruppen. Vi har haft möten och det har varit bra att sitta tillsammans.

Ibland har man suttit hemma om man om man varit seg. Dock bäst att sitta tillsammans. Vi sitter tillsam-mans varje dag nu, och så fort ingen har saker schemalagt.

– Hemma och i rum som de har bokat. Har orienterat runt i de salar som har varit lediga. Om salar ej harvarit lediga så har vi suttit i korridor eller gått hem.

– Mestadels i grupprummet. 10 % hemifrån och då mest med dokumentation och design.– I grupprum hela gruppen tillsammans för att samla gruppen. Även hemma enskilt eftersom det är smi-

digt. Gruppmöten har vi bokat grupprum till på skolan.– Vid stora inlämningar har jag jobbat i skolan för att kunna ta på mig nya arbetsuppgifter snabbt. Om jag

har arbetsuppgifter som jag behöver bli klar med så jobbar jag hemma då inget stör mig.– Jobbat tillsammans i korridor och grupprum. Grupprum bäst så att vi kan prata utan att bli störda. Har

jobbar hemma också, enklast.– Beror på uppgift. Kodande har gjorts i par. Detta har gjorts vid sofforna vid java eftersom de inte behövde

bokas.• Tycker du att effektivitet påvekats av de platser du valde att jobba på och i så fall hur?

– Vet inte om det ändrats till bättre eller sämre. Ibland effektivt och ibland inte. Både ock.– Oh ja, grupprum funkar som en arbetsplats för mig. Kommer jag in dit så jobbar man. Hemma eller själv

där ingen har koll på mig så finns det mycket som distraherar.– När jag suttit hemma så har det inte varit effektivt. Där är det svårt att koncentrera sig. Kan gå iväg och

göra annat hemma. Lättare att sitta i skolan för då jobbar man.– Man kan se det som positivt att man behöver byta sal och ta paus. Men annars så har man ingen möjlighet

att ha permanenta saker på Whiteboard. Mycket fås tas via nätet, men det är inte säkert att alla kolla där.Vissa salar har varit kalla, vissa har varit varma. Som sämst när man ha fått boka en timme sal. Har letttill att många stannar hemma för att kunna stanna på ett och samma ställe.

– Ja, har varit lättare att arbeta i grupprummet, har alltid funnits någon att fråga där. Bättre effektivitet.Rätt bra hemma också, skriver man i slack får man inte lika klara svar som när man pratar med någon,dock.

– Inte märkvärt, ganska lika. Kanske lita bättre om man är tillsammans hela gruppen och kan fråga munt-ligt.

– Ja, till viss del. Om vi jobbar i grupp på saker man inte har koll på så får man snabbare respons och andrasynvinklar. Kan inte sitta i grupp hela tiden för folk kan inte koncentrera sig så har fått gå iväg.

– Ja, har inte varit effektiva när folk har jobbat hemma. Sitter vi inte tillsammans så blir det en delayätt frågasaker. Spelar ingen roll om de sitter i grupprum eller öppna ytor på skolor, bara vi sitter tillsammans.

– Sitter man i grupprum med individuella uppgifter bli det svårt att koncentrera sig.• Hur och när har identifierade uppgifter organiserats och fördelats inom gruppen?

– Första delen av projektet genom möten. Andra delen tillades en fysisk Kanban-tavla.– Oftast på möten har det delats upp vad som behövs göras. Har också skett kontinuerligt eftersom folk

jobbar så nära varandra i grupprummet. Lätt kommunikation.– Planerat dom en iteration innan. Under denna iterationen ska det här göras. Sen sätter vi upp issues i

gitlab, så börjar den jobba och upptäckter att det här måste göras och gör ny issue. Typ Kanban-tavla.– "Imorgon ha vi möte där vi ska fördela det vi ska göra"eller så har folk hittat saker och lagt upp det

online på github och skrivit i Slack att det finns.– Suttit tillsammans inför var iteration och identifierat alla aktiviteter och lagt upp i Trello. Har plockat de

saker som varit relaterade till vår roll i främsta hand.– Har haft Trello där alla uppgifter som behöver göras finns. Försöker få en jämn arbetsbelastning över hela

gruppen. Man väljer lite själv vad man vill göra. Har försökt ligga i fas med planering och grupprum harvarit till hjälp för att ha koll på alla. Annars upp till var och en.

– möten, Trello. Man delar ut uppgifterna på Trello och sätter man sitt namn på den uppgiften. Fungerarriktigt bra.

115

– Trello användes mycket under alla iterationer. En eller flera ansvarade för att lägga upp uppgifter. Manskrev sitt namn på den man höll på med. Fungerade ganska bra men lite rörigt system ibland, inte heltoptimalt.

– Uppdelat efter roll om det finns. Annars rätt öppet, ej använt sig av Trello, utan delat upp arbetet i Slack.Möten för det mesta i början av veckan och då fördelas arbetet där. Mitt i veckan tas det upp i chattenoch då tar någon tar på sig det frivilligt.

• Finns det något eller några saker med ert upplägg som du nu i efterhand tycke hade varit bra att ändra på? Omja, vad?

– ja, tror mer på digital Kanban. Kan vara bra att kolla hemma också så att man kan planera kommandedag. Kanske bäst med båda. Trello sparar allt gammalt. Vi skulle ha delat ut mindre uppgifter som mankan följa upp med enklare också.

– På slutet lite svårt att veta vad man skulle göra. Då kan det vara bra med små uppgifter på Trello ellerliknande som folk kan plocka. Inte så effektivt arbete i slutet. på upplägget. Nöjd med hur vi lagt uppsaker. Det har varit effektivt och fått till det mesta väldigt bra.

– Bestämma när möten är tidigare än dagen/kvällen innan. Bestämma nästa möte på vårt nuvarande mötehade varit bra eftersom folk inte alltid läser på Slack. Svarsfrekvensen på möte imorgonpå slack är låg.Aktiviteter som kommer upp på github läser inte alla. Visste inte om folk hade set det men skitit i deteller annat.

– Nej.– Nej inte direkt, fungerade bra som vi gjorde.– Från början svårt att ha koll på vad de andra gjorde. Trello användes inte bra. Svårt att veta vad man

skulle göra, lite kaos", men sen blev det riktigt bra. Parprogammering och kortare deadlines var det somändrades så att det blev bra.

– Vi kom igång sent med att sitta tillsammans vilket gjorde att vi lärde känna varandra och våra styr-kor/svagheter sent.

– Vi skulle använt oss av Trello eller liknande så att det blir tydligare vem som håller på med vad. Somdet gjordes var man tvungen att scrolla upp för att se vad folk gjorde. Försvinner lätt i flödet. I börjanav iteration 1 svårt att ta an uppgifter. Många ville jobba själv hemma vilket gjorde det rörigt. Om detkunde jobbas i par så skulle vi ha gjort det.

• Finns det något eller några saker med ert upplägg som du tycker har fungerat bra? Om ja, vad?– Ja, bra med grupprum. Bra gruppanda. Sitter tillsammans alltid (paus och jobb). Gruppen har blivit tight

och kan jobba enklare då.– Har delat upp arbetet i moduler. Det var nödvändigt. Då kan två, tre stycken jobba på varje modul istället

för att alla jobbar på allt. Då har man bättre koll än om alla jobbar på allt.– Inte på upplägget. Nöjd med hur vi lagt upp saker. Det har varit effektivt och fått till det mesta väldigt

bra. Då får man bort konstiga variabelnamn och dylikt. Jättesmidigt med kodgranskning.– Bra med människor som har engagerat sig med att boka salar så fort det går. När vi väl sågs i samma rum

så flöt det på bra. Arbetsmetoden i samma rum var bra. Gick att fråga varandra om hjälp och utvecklasamtidigt.

– Alla har fått jobba med det som de tycker är intressant eftersom man har fått välja aktiviteter.– Att vi jobbat tillsammans i grupprum så man kan samlas och jobba.– Gjorde enkäter efter var iteration för att utvärdera individuella prestationer för att se hur folk trivdes med

sina roller. På så vis såg man utvecklingen.– Lite rörigt system ibland, inte helt optimalt.– Regelbundna möten.

• Hur skulle du beskriva er gruppdynamik?– Väldigt bra. Alla kan jobba med alla så vitt jag vet.– Ovanligt bra. Väldigt lätt att få gruppen att jobba. Inte ofta folk slackar eller inte kommer på möten, det

händer dock. Mycket bättre än vad jag trodde. Alla kommer bra överens och har dragit sitt släp.– Har haft våra möten, på sistone två gånger i veckan. Bra grupp i allmänhet. Alla har varit duktiga

progammerare och organisiellt, Tagit saker seriöst när vi har snackat om det. Har tagit kodstandad ochdylikt seriöst. Skön känsla i guppen.

– Lite splittrad på sätt att vissa föredrar att jobba hemifrån. Då sätter de sig själva utanför teamet. Svårt attfå uppfattning om vad de arbetar med, om de jobbar, jämfört med de som är i skolan. Gruppdynamikbra efter team-building. Aktiviteter utanför skolan, D-pub och torsdagskrök. Även suttit hemma hos folkoch jobbat och det har inte känts konstigt.

– Bra gruppdynamik, vi får mycket gjort och vi har kul. Kan sitta i sex timmar i rummet utan att det blirtråkigt. Jobbar i grupper om två och två eller tre och tre. Försöka utveckla moduler parallellt.

– Väldigt bra. Jobba bra tillsammans och jobbar bra som gupp. Inga konflikter.– Väldigt tighta. Bra grupp alla kan snacka med alla. Hade grillkväll.– Väldigt positiv. Alla verkar känna sig hemma i guppen. Kan skoja med varandra och hittar på saker med

varandra.– Vi får saker gjorda men har inte 100 % kontroll. Lite lätt kaos.

• Hur har gruppen kommunicerat och hur tycker du att kommunikationen inom gruppen har varit?– I rummet och slack. Mest muntligt dock. Inte varit så mycket kommunikation över slack mer än "var är

duöch gör det här". Inte snackat om arbetssaker via slack, bara försökt få tag på folk.– Slack när vi inte är i grupprummet. Kommunikationen har varit lätt eftersom många jobbar i grupprum-

met. Behöver inte vänta tills nästa möte när problem uppstår eller lösa det via text. Ibland kan det varasvårt att få kontakt med någon via slack, men inte ofta.

– Slack. Inte mycket diskussioner i slack, mest smågrejer som inte ä viktiga. Kalendern var kopplad tillslack. Öppnar man mergerequest så säger slack till. Utöver det så har teamledaren frågat typ om fika.Lite git-problem har tagits upp. Funkar jättebra, inga problem.

– Slack och muntligt de som varit i salen. Kommunikationen i salen har varit bra. Slack sämre, låg svarsfre-kvens. Allt som allt helt ok. Olika kanaler i slack för olika delar av projektet. Vill man ha hjälp med någoti koden så finns det en kanal för et, en generell osv

– Främst kommunikation muntligt, men också mycket i Slack. När ses vi imorgon", "Är de någon som harkoll på dettaställdes i slack efter skoltid.

– Slack, har fungerat bra, inga problem. Där har det tagits upp hur man jobbar, var man jobbar, ev problem,

116

hur det ska se ut med opponering, frågor, information. Det har blivit en del diskussioner om arbete ochhur man ska lösa vissa grejer. Informationen har nåtts ut bra för folk är aktiva på slack.

– Bra kommunikation. Ska försöka vara så tillgängliga på slack fram till kl 8 på kvällen. Olika kanaler förkodning - dokument, kundmöten, random, generell med mera.

– Från början nästan enbart Slack. Skapade många kanaler med projektets olika delar. Senare kom vi igångmed att sitta tillsammans också och då blev det mer muntligt.

– Slack till nästan allt. Slack funkar jättebra, har i princip allt. Lite problem med allmänna frågor då antingenalla eller ingen svarar. Måste rikta frågorna mer för att få svar. På möten diskuteras det.

• Hur har du hanterat eventuella tekniska problem under projektet?– Frågat folk som är kunniga i gruppen, läst dokumentation och försökt förstå, testat.– Dem med ansvar för det har fått ta det. Vi har parprogrammerat så har ofta väntat och diskuterat med

min partner vid problem. Vid andra större tekniska problem som kräver designbeslut tas upp på möten.– Frågat folk vid programmeringsproblem. Bollade mkt med sin parprogrammerare.– Har slängt timmar på det själv om jag känt mig kapabel till att göra det. Andra har gått via slack eller

github om de behöver hjälp. Om de är i samma rum så frågade man varandra direkt– Google. I andra hand frågat om produktiviteten tagit skada. Hela guppen har suttit engagerade och

googlat vid stora problem.– För det mesta frågat en annan gruppmedlem. Sen söka på internet. Alltid fungerat bra folk är hjälpsamma.– Fastnade man med programmeringen så åkte man till skolan och frågade folk om hjälp.– Frågade mina gruppmedlemmar.– Frågar någon i gruppen om jag tror att de har kunskapen, annars tar jag upp det på handledamötet där

man brukar gå runt och fråga. Vi jobbar i par, vilket gör att man diskuterar med varandra.• Hur har kunskaper förmedlats mellan gruppmedlemmarna?

– Fysiskt, visa.– Oftast genom slack. Även möten och kontinuerligt i arbetsrummet.– Snackat. I början gjordes mycket lektioner för de andra medlemmarna där projektor användes. Vi har

utvärderat oss själva och pratat vad vi lärt oss om.– Kanal i slack där dokument lades upp om hur man skriver git-commit-medellanden, hur git fungera och

kodstandarder med mera.– Inte så väl. Alla har kört sitt race och lärt sig det de behöver kunna för att göra sitt.– Ganska bra. Har haft genomgångar av det som man har gjort vilket har ökat förståelsen för vissa delar

som man inte själva har jobbat på.– Kan inte sitta i grupp hela tiden för folk kan inte koncentrera sig så har man gått iväg. Grupputbildningar.– Utbildningar i början. Annas sådär, har en i gruppen som kan hela systemet väldigt bra men han ha

jobbat mycket hemma och ingen har förstått hans kod. Han har dessutom varit svår att få tag på.– Lagt ut “tänk på detta”-saker i Slack.

• Beskriv gruppmedlemmarnas relation.– Bra arbetskamrater. Inte många som hänger på fritiden men när vi är i skolan så är vi tillsammans.– Det har inte blivit någon utfrysning, alla delaktiga och alla får prata. Alla kommer överens. En del kan

ha en större röst än andra såhär ska vi göra". Kan bli negativ klang när man inte får diskutera med vadfolk tycker utan säger istället såhär är det". Ingen angst mellan folk.

– Kände ingen jättebra innan men nu gör jag det. Ingen hänger utanför skolan. Vissa engagerade i sektionenoch kanske träffas utanför. Annars på skolnivå och den är bra.

– Många har bra relation till varandra. Några få som kanske har placerats lite utanför. Kan bero på att deinte har dykt upp på planerade möten eller att de har föredragit att vara ensamma. Förövrigt bra.

– Vi har blivit kompisar. Har jobbat så nära inpå varandra att vi har lärt känna varandra. Inte nära vännermen ändå kompisar.

– Bra. Man har respekt för varandra. Jag kände bara två/tre stycken innan kursen, de andra hade jag barasett. Nu känner jag dom ganska bra efter att ha jobbat med dem ganska länge.

– Alla kan umgås med varandra. Vissa är kompisar sedan tidigare. Vissa kan man pata lättare med meningen som man inte kan prata med, riktigt bra.

– Positiv. Alla är avkopplade med varandra och vi ha roligt tillsammans. Många spelar samma spel såspelar tillsammans.

– Inga problem med någon i guppen, men inte kommit jättenära alla i guppen, bara några. Lite uppdelat.• Vad tycker du om din arbetsinsats?

– Den var ok. Det finns några saker som man borde ha gjort bättre och några som man gjorde bra. Jag kanen del av systemet väldigt bra, men borde ha satt mig in i fler delar.

– Har gjort någonting. Försökt hjälpa till där det behövs. Känner att man kunde gå in i andras kod mer änatt snöa in sig på sin egen. Tycker att jag har dragit mitt släp på dokumentation. Jag har gjort lagom, folkhar gjort mer, folk har gjort mindre.

– Den har varit bra.– Svängigt. Vissa perioder mycket att göra, välja att vraka. Andra perioder suttit och väntat, då har jag gjort

min individuella.– Har gjort min del och gjort vad jag har kunnat.– Jag är nöjd med mig insats och vad jag har åstadkommit.– Kom igång lite sent.– Första iterationen så var jag en av dem som tog tag i arbetet mest. Ansträngde mig mycket då för att

få igång arbetet. Rent kodmässigt ganska medelmässig insats. Andra medlemmar ha satsat på kodandetvilket har gjort att jag har fastnat med dokumenten, men har jag gjort mitt bästa.

– Lagt mkt tid på dokument, inte så stolt över det.• Har du varit frånvarande från projektet? (Följdfrågor: Hur mycket? Anledning?)

– Typ två dar, semester.– Nej.– Nej.– Någon enstaka dag då och då.– Nej.– Nej.– Ja, några gånger.

117

– En veckas semester.– Nej.

• Hur tycker du att det har varit att jobba med ditt projektet?– Kul, har lärt sig mycket. Mycket jobb samtidigt men man har ändå något som är vettigt. Har kommit

fram till något som är bra.– Väldigt kul. Speciellt programmeringen. Det känns som att det är ett jobb och att man gör något av

värde som inte slängs bort. Häftigt att se att man jobbar med så många duktiga och att man får något islutändan. Beror mycket på bra gruppdynamik och duktiga gruppmedlemmar.

– Jättekul och jättebra! Bra grupp och rolig uppgift.– Kul som en process. Projektets tema var inte helt rätt för min del men kul att programmera.– Mycket lärorikt rent faktamässigt. Har drivits till att lära sig saker, inte för att det står i en kursmanual,

utan för att det behövdes till kunden. Mer drivkraft.– Väldigt roligt. Lite annorlunda jämtemot vad man är van vid att jobba.– Kul, spännande. Man har lärt sig mycket. Bland annat hur man jobbar i projekt och hur man lägger upp

arbete under en längre tid. Mycket jag kan ta med mig från detta.– Roligt och givande.– Väldigt roligt, häftig produkt. Kul med ny teknik och testa nya saker även om det inte är den program-

mering som jag gillar bäst.• Hur nöjd eller missnöjd är du med den produkt som ni levererade till kunden?

– 7/10 nöjd. Tror man kan fortsätta jobba på det. Tror kunden få användning av det. Finns mycket att göraom man vill dock.

– Väldigt nöjd eftersom kunden visade att han va nöjd. Vi har gjort systemet men inte mer, men hanuttryckte att han var nöjd.

– Väldigt nöjd. Ska bli kul att se hur det blir sen.– Givet vår tidsinsats så är den över min förväntan även om produkten i sig inte är ngt jag har förtoende

för.– Väldigt nöjd. Kunden kommer att använda produkten, det känns kul.– Väldigt nöjd, motsvarar de förväntningar jag hade i början av projektet, tror kunden är nöjd med.– Mer än vad jag förväntade att vi skulle göra.– Varken missnöjd eller nöjd. Den är precis i mitten på skalen.– Kunden väldigt nöjd och det är jag nöjd över. Finns förbättringar dock.

118

Modernisering av ett 3D-scanningssystem - Simple...

Documents

Transcript of Modernisering av ett 3D-scanningssystem - Simple...