826965/fulltext01.pdf · detektor f or dricksvattenkvalitet 26 juni 2015 projektidentitet vt, 2015,...

Institutionen för datavetenskapDepartment of Computer and Information Science

Examensarbete

Implementation av mätsystem fördricksvattenkvalitet

av

Fredrik Larsson, Hannes Snögren, Sebastian Gustafsson,Magnus Qvigstad, Hugo Lindholm, Rasmus Eriksson

LIU-IDA/LITH-EX-G--15/023--SE

2015-05-27

Linköpings universitetSE-581 83 Linköping, Sweden

Linköpings universitet581 83 Linköping

Linköpings universitetInstitutionen för datavetenskap

Examensarbete

Implementation av mätsystem fördricksvattenkvalitet

av

Fredrik Larsson, Hannes Snögren, SebastianGustafsson, Magnus Qvigstad, Hugo Lindholm, Rasmus

Eriksson

LIU-IDA/LITH-EX-G--15/023--SE

2015-05-27

Handledare: Jonas Lindgren

Examinator: Kristian Sandahl

Detektor for dricksvattenkvalitet 26 juni 2015

PROJEKTIDENTITETVT, 2015, Grupp 4

Linkopings Tekniska Hogskola, IDA

GruppdeltagareNamn Ansvar E-post

Fredrik Larsson Gruppledare, Kvalitetssamordnare [email protected] Qvigstad Analysansvarig [email protected] Gustafsson Arkitekt [email protected] Eriksson Utvecklingsansvarig [email protected] Snogren Testledare [email protected] Lindholm Dokumentansvarig [email protected]

Kund: Hans SundgrenKontaktperson hos kund: Hans Sundgren

Kursansvarig: Kristian SandahlHandledare: Jonas Lindgren

TDDD77Kandidatrapport

iii Grupp 4Detektor for dricksvattenkvalitet


Sammanfattning

Foljande rapport behandlar konstruktionen av ett system som kontinuerligt ska analysera kvalite-ten pa vatten. Systemet ar uppdelat i matenheter som utfor sjalva matningen och en centraliseradserver som man kan koppla upp sig mot for att overvaka/justera sina matenheter.

Uppdragsgivaren till projektet var forskare fran IFM pa Linkopings universitet. De hade sedantidigare ett fungerande system for att analysera vatten kontinuerligt. Var uppgift var att ersattaderas system med ett nytt, som var baserat pa mindre och billigare hardvara. Vi har visat attsystemet gar att implementera pa den onskade hardvaran.

Rapporten skildrar aven hur projektgruppen tog designbeslut under utvecklingsfasen. Denna de-signbeslutsprocess och de konsekvenser den fick for slutprodukten analyseras.


iv Grupp 4Detektor for dricksvattenkvalitet

Innehall

1 Inledning 11.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Bakgrund till fragestallningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Fragestallning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Ordlista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Bakgrund 22.1 Befintligt system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Problematik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Teori 23.1 Matning av vattenkvalitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.2 Databaser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.3 Natverkskommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.4 Packet-Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.5 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.6 Websocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.7 D3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.8 BeagleBone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.8.1 BeagleBone Black . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.8.2 ARM Cortex-A8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Metod 54.1 Utveckling av system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1.1 Kravsattning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.1.2 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1.2.1 Projektgrupp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64.1.2.2 Handledare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.1.2.3 Kund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.1.2.4 Projektets faser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.1.2.5 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1.3 Arbetsatt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.1.3.1 Moten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1.3.2 Gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1.3.3 Redmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1.4 Uppsamling av erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1.5 Jamforelse med forgaende system . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2 Designbeslutsprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2.1 Identifiera problem med designbeslutsprocess . . . . . . . . . . . . . . . . . 104.2.2 Analys av designbeslutsprocess . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Resultat 105.1 Kravhamtning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.2 Overgripande losning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.3 Hardvara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.3.1 D/A- och A/D-omvandlare . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.3.2 Realtidsdator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.4 Matenhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.4.1 Programstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.4.2 Programvara PRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.4.3 Delat minne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

v


5.4.4 Granssnitt mot PRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.4.4.1 prussdrv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.4.4.2 mio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.4.4.3 libpru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.4.4.4 pru interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.4.4.5 PruHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4.5 Matklient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.4.5.1 Natverkshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.4.5.2 Matningshanteraren . . . . . . . . . . . . . . . . . . . . . . . . . . 165.4.5.3 Filsystemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.5 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.6 Serverarkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.6.1 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.6.2 Webb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.6.2.1 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.6.2.2 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.6.3 MongoDB vs MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.6.4 Databasmodeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.6.4.1 Unit collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.6.4.2 User collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.7 Webbgranssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.7.1 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.7.2 DataTables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.7.3 Interaktiv graf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.7.4 Jade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.8 Designbeslutsprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.8.1 Plotly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.8.2 TCP-protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.8.3 Measurehandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.8.4 Var designbelutsprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.9 Tidsforbrukning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.9.1 Medlem hoppar av . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.9.2 Forbrukad tid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.10 Gemensamma erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Diskussion 266.1 Nya systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.1.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.1.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2 Designbeslutsprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Slutsatser 277.1 Fragestallning 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.2 Fragestallning 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.3 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7.3.1 Etiska och samhalleliga aspekter . . . . . . . . . . . . . . . . . . . . . . . . 287.3.2 Miljoaspekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8 Fortsatt arbete 288.1 Analys i matlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288.2 Varningar i webbgranssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288.3 Systemet for konsumeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


vi Grupp 4Detektor for dricksvattenkvalitet


A. Hugo - Analys av utvecklingsmetodik 30

A.1 Inledning 30A.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30A.1.2 Fragestallning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30A.1.3 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A.2 Bakgrund 31

A.3 Metod 31A.3.1 Utvecklingsmetodiker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31A.3.2 Analys av projektarbetet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A.3.2.1 Enkat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31A.3.2.2 Projekt dokument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A.3.3 Vald utvecklingsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A.4 Resultat 31A.4.1 Utvecklingsmetodiker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

A.4.1.1 Vattenfallsmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32A.4.1.2 Unified Process (UP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32A.4.1.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.4.1.4 eXtreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . . . . . 33

A.4.2 Analys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.4.2.1 Enkater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.4.2.2 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.4.2.3 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.4.2.4 Analysens resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A.5 Diskussion 35A.5.1 Analys av projektet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

A.5.1.1 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36A.5.1.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36A.5.1.3 Kod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37A.5.1.4 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37A.5.1.5 Fallerande punkter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A.5.2 Vardematris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38A.5.3 Vald utvecklingsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.5.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.5.5 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A.6 Slutsatser 40

B. Rasmus - Node.js 41

B.1 Inledning 41B.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B.1.2 Fragestallning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B.1.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B.1.4 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

B.2 Teori 42B.2.0.1 Server-klient arkitetkur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42B.2.0.2 En trad/process per anslutning . . . . . . . . . . . . . . . . . . . . . . . . . 42B.2.0.3 Eventdrivna modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43


vii Grupp 4Detektor for dricksvattenkvalitet


B.2.0.4 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

B.3 Resultat 44B.3.0.5 Prestandatester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

B.3.0.5.1 Test mot populara alternativ . . . . . . . . . . . . . . . . . . . . . 44B.3.0.5.2 Test mot Apache och liknande eventsystemet EventMachine . . . 44

B.3.0.6 Kodstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44B.3.0.7 Pakethanterare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44B.3.0.8 Sakerhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45B.3.0.9 Larande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

B.4 Diskussion 45

B.5 Slutsatser 46

C. Fredrik - Kvalitetsplan 48

C.1 Inledning 48C.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48C.1.2 Fragestallning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48C.1.3 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

C.2 Bakgrund 48

C.3 Teori 49

C.4 Metod 50

C.5 Resultat 50C.5.1 Risker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50C.5.2 Team Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

C.6 Diskussion 51C.6.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

C.6.1.1 Riskhantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51C.6.1.2 Team Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

C.6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

C.7 Slutsatser 53

D. Hannes - Enhetstestning 54

D.1 Inledning 54D.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54D.1.2 Ordlista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54D.1.3 Fragestallning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54D.1.4 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

D.2 Bakgrund 55

D.3 Teori 55D.3.1 Agil arbetsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55D.3.2 Enhetstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55D.3.3 Modultest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55


viii Grupp 4Detektor for dricksvattenkvalitet


D.3.4 Integrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55D.3.5 Regressionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55D.3.6 Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

D.4 Metod 56

D.5 Resultat 56D.5.1 Arbetssatt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56D.5.2 Testplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56D.5.3 Enhetstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56D.5.4 Integrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57D.5.5 Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57D.5.6 Effektivitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

D.6 Diskussion 57D.6.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57D.6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

D.7 Slutsatser 59

E. Sebastian - Implementation av realtidsfunktionalitet 60

E.1 Inledning 60E.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60E.1.2 Fragestallning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60E.1.3 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

E.2 Bakgrund 60

E.3 Teori 60E.3.1 Tidskritisk kod under normalt operativsystem . . . . . . . . . . . . . . . . . . . . 60E.3.2 Realtidsoperativsystem - RTLinux . . . . . . . . . . . . . . . . . . . . . . . . . . 61E.3.3 Extra hardvara - FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61E.3.4 BeagleBone Black - PRUSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

E.4 Metod 61E.4.1 Implementation av sampling pa PRU . . . . . . . . . . . . . . . . . . . . . . . . . 62E.4.2 Jamforelse av PRUSS mot andra implementationer . . . . . . . . . . . . . . . . . 62

E.5 Resultat 62E.5.1 1 kHz sampling med PRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62E.5.2 Resultat av vald implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

E.6 Diskussion 62E.6.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

E.6.1.1 1 kHz sampling med PRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63E.6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

E.6.2.1 Val av PRUSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

E.7 Slutsatser 63

F. Magnus - Kravframstallning 64

F.1 Inledning 64


ix Grupp 4Detektor for dricksvattenkvalitet


F.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64F.1.2 Fragestallning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64F.1.3 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

F.2 Bakgrund 64

F.3 Teori 64

F.4 Metod 65

F.5 Resultat 65F.5.1 Analys av projektet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65F.5.2 Kraninhamtnings inverkan pa mjukvaruprojekt generellt . . . . . . . . . . . . . . 65

F.6 Diskussion 66F.6.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66F.6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

F.7 Slutsatser 67

Referenser 68

Bilaga A Bilagor 71F.1.1 Bilaga enkat kund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71F.1.2 Bilaga enkat grupp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76F.1.3 Bilaga enkat kund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85F.1.4 Bilaga enkat grupp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90F.1.5 Bilaga enkat risker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Bilaga B Fredriks enkat 98F.2.1 Bilaga enkat Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99


x Grupp 4Detektor for dricksvattenkvalitet


1 Inledning

Under varen 2015 utforde sju studenter vid Linkopings universitet sina kandidatarbeten i form avett gemensamt projekt i kursen TDDD77. Projektgruppen fick valja mellan ett antal olika upp-gifter, och valde projektet Dricksvattenkvalitet.

Den har rapporten dokumenterar detta gemensamma kandidatarbete och behandlar den processsom ersatte ett befintligt system med ett nytt. Utover det undersoks hur designbeslutsprocessenfungerade under utvecklingen av detta system.

1.1 Syfte

Syftet med rapporten ar att undersoka om det ar mojligt att ersatta ett befintligt system for attmata dricksvattenkvalitet med ett nytt. Vi kommer aven redovisa vara erfarenheter fran utveck-lingen av detta system. Vidare soker vi fa djupare forstaelse for hur designbeslut tas pa ett brasatt.

1.2 Bakgrund till fragestallningar

Kund som bestallde projektet var intresserad av att veta huruvida det ar mojligt att utveckla ettnytt system kring ny hardvara som kan ersatta det befintliga. Det befintliga systemet beskrivsnarmare i avsnitt 2.

I projekt dar man utvecklar ett system kravs det att man tar en mangd designbeslut. Dessadesignbeslut har stor inverkan pa slutprodukten. Darfor ar den process som leder fram till dessabeslut sarskilt intressant.

1.3 Fragestallning

• Ar det mojligt att ersatta det befintliga systemet med ett nytt system?

– Kan en matstation implementeras pa en Beaglebone Black?

– Kan systemet fardigstallas pa avsatt antal timmar?

• Hur kan vi forbattra var designbeslutsprocess?

1.4 Avgransningar

Projektet avgransas till att endast utveckla mjukvara. Det avgransas ocksa till att endast imple-mentera den funktionalitet som projektgruppen kommer overens med kund om.

Gallande den andra fragestallningen avgransas utredningen till att samla in och jamfora erfaren-heter fran detta projekt med andra beslutsmetoder.

Arbetet skall genomforas pa 300 timmar per projektmedlem, med en tolerans pa 10%.


1 Grupp 4Detektor for dricksvattenkvalitet


1.5 Ordlista

REST Representational State Transfer (REST) ar ett arkitekturbegrepp for att beskrivahur kommunikation mellan maskin till maskin struktureras.

API Applikationsprogrammeringsgranssnitt (API), specifierar hur program kananvanda och kommunicera med en specifik programvara.

ODM Object document modeling (ODM), ar oftast ett verktyg som hjalper till attoversatta kod till databasstrukturer.

SVG Vektorgrafik-format for tvadimensionella bilder som stodjer animationer och in-teraktivitet. Kan embeddas i webbsidor.

FPGA Field-Programmable Gate Array. En integrerad krets som kan programmeras.Prob Hardvara med fyra elektroder som anvands vid matning av vattenkvalitet.MsSQL Microsoft SQL-databas.IFM Institutionen for Fysik, Kemi och Biologi.IDA Institutionen for Datavetenskap.Token En unik identifierare som kan anvandas for exempelvis autentiseringCollection En databas innehaller flera ’collections’. Dessa collections innehaller sedan doku-

ment.JSON Ett oppet standardiserat format for att skicka data.PRU Enhet som anvands for realtids programmering.

2 Bakgrund

En grupp forskare pa IFM vid Linkopings universitet har tagit fram ett system for att utforamatningar som upptacker fororeningar i dricksvatten. Dessa matningar utfors genom att matastrommen i tre olika elektroder da man belastar en fjarde med en serie spanningar. Denna probhar drivits av omfattande hardvara, inkluderande bland annat FPGA-kort och realtidsdatorer.Dessa forskare ville undersoka mojligheten att byta ut den befintliga hardvaran mot nagot mindreoch betydligt billigare i form av en BeagleBone Black.

2.1 Befintligt system

Det befintliga systemet betar av ett chassi pa ca 70x70x20 cm. Kostnaden for hardvaran lag over20 000 kronor. Inuti finns ett antal hardvarukomponenter som analog-till-digital och digital-till-analog-omvandlare, realtidsdator, FPGA, natverkskort och 3G-koppling. Pa denna hardvara korsmjukvara som ser till att matningar utfors och skickas ivag. Det finns ocksa en central server somkor en MS SQL-databas dar matningar lagras.

2.2 Problematik

Det finns flera argument for att bygga ett nytt system. Hardvaran ar stor, dyr och overdimensioneradfor uppgiften. Matningar utfors och sparas lokalt, samtidigt skickas den till en central server. Miss-lyckas overforingen gors inte nagot nytt forsok. Detta leder till att de behover ga till matenhetenfor att hamta ut den forlorade matdatan.

3 Teori

Detta avsnitt beskriver bakgrundsteori kring vasentliga delar av systemet.

3.1 Matning av vattenkvalitet

Principen ar en enkel elektrokemisk metod med elektrisk stimulering av reaktiva komponenter ivattnet. Reaktionerna ger upphov till en elektrisk strom som registreras. Detektorn bestar i hu-




vudsak av en liten yta av en katalytisk adelmetall placerad i vattenflodet. De datamangder somde uppmatta reaktionsstrommarna genererar maste utvarderas for att avvikelser i vattenkvalitetska kunna upptackas.

3.2 Databaser

Nar man pratar om databaser sa finns det ett par olika typer som fungerar pa olika satt, i den-na del kommer tva olika typer tas upp. Den forsta ar en Structured Query Language-databas,som hadanefter kommer benamnas SQL. Denna typ ar relationsbaserad. Den andra typen ar endokument-orienterad databas som ocksa kallas for NoSQL-databas, denna ar inte relationsbaserad.

Det finns ett par skillnader mellan SQL och NoSQL-databaser. Den storsta skillnaden ar att SQL-databaser ar strukturerade med rader och kolumner och behover ett fordefinierat schema over hurdatan ska se ut innan den sparas. NoSQL-databaser anvander sig av collections. MongoDBs col-lections har ett format som liknar formatet JSON(JSON , u. a.). NoSQL kraver inte att schematska definieras i forvag och ar helt dynamisk, man kan till och med ha olika schema typer i sammacollection. Databaserna skalar dessutom pa olika satt. En NoSQL-databas skalas genom att laggatill en till databas nod. En SQL-databas skalas genom att uppgradera komponenterna, till exempelmed en snabbare CPU, mer RAM och fler harddiskar.

3.3 Natverkskommunikation

Kommunikation via natverk bygger olika sorter av sockets. TCP(TRANSMISSION CONTROLPROTOCOL, 1981) ar en typ av socket som ar anvandbar nar man behover en eller fler kvaliteternedan:

• Paket i sekvensiell ordning

• Garantera att paket kommer fram

• Point-to-point

• Synkroniserad anslutning

• Saker avslutning

3.4 Packet-Framing

TCP garanterar att paket kommer fram och i ratt ordning. Det kan dock vara intressant for densom ska behandla datan att veta nar en forvantad datamangd har kommit in innan denne borjarbearbeta datan. Ett satt att gora detta kallas Packet-Framing”. Packet-framing kan goras pa flerasatt, nedan beskrivs tva av dessa(David Andersen, u. a.).

Teckenavslut Denna metoden bygger pa att protokollet specifierar ett speciellt tecken somavsatts (eller en sekvens av tecken) for att avsluta en datasekvens. Detta betyder att tecknet intefar forekomma inuti sekvensen. Vid binar filoverforing blir det ofta problem da binara filer mycketval kan innehalla detta specialtecken.

Sekvenslangd Metoden bygger pa att du i borjan av varje sekvens skickar ett nummer sommotsvarar langden pa den inkommande sekvensen. Fler bytes for att representera nummer tillaterlangre sekvenser.




3.5 Node.js

Node.js beskrivs i avsnitt B.2.0.4.

3.6 Websocket

Webbsocket anvands for att skapa en full duplexlank mellan en klient och server over http proto-kollet. Webbsocket ar standardiserat av W3C(“w3c”, u. a.) och finns i de storre webblasarna somChrome, Firefox och Opera.

3.7 D3

Data-Driven Document, forkortat D3, ar ett ramverk som anvands for att designa interaktivakomponenter till webbsidor som representerar nagon form utav data. Man kan saga att D3 ger livtill din data genom att anvanda sig utav HTML, SVG och CSS. D3 grundar sig pa att man forstlaser in den data som man vill jobba med i ett sa kallat Document-Object-Model-element (oftaforkortat DOM). Nar datan ar bunden till DOM-elementet finns det ett stort utbud av transfor-mationer och animationer for att kunna designa figurer och grafer av olika typer.

3.8 BeagleBone

BeagleBone ar en lagenergi-enkortsdator anpassad for att utvecklare ska kunna bygga en rad olikaapplikationer. BeagleBone var fran borjan byggt som en pedagogisk utvecklingsmiljo i syfte attutbilda anvandare i bade hardvara och mjukvara.

3.8.1 BeagleBone Black

BeagleBone Black ar en vidareutveckling av BeagleBonen med mer RAM-minne och en snabbareprocessorklocka. BeagleBone Black innehaller bland annat foljande I/O anslutningar:

• USB-port

• Ethernet-port

• HDMI

• 46-pins-anslutningar

BeagleBone black innehaller aven en AD-omvandlare med en precision av 12 bitar med 125 nano-sekunders sampeltid(“BeagleBoard System”, u. a.).




Figur 1 – Bild over BeagleBone Black

3.8.2 ARM Cortex-A8

BeagleBone Black innehaller aven tva stycken realtidsprocessorer av typen ARM Cortex-A8, dessabenamns hadanefter som PRU. ARM Cortex-A8 ar en 32-bitars processor med en klockfrekvensmellan 600 MHz och 1 GHz(Cortex-A8 processors, u. a.).

4 Metod

I det har avsnittet beskriver vi hur vi har gatt till vaga for att samla in relevant data for attbesvara vara fragestallningar.

4.1 Utveckling av system

For att undersoka mojligheten att designa det nya systemet och for att se om det gick att genomforadet inom den givna tidsramen sa gjorde vi ett forsok att bygga det fran grunden. Hur vi gjordedetta beskrivs i det har avsnittet.

4.1.1 Kravsattning

Kraven som kommer stallas pa systemet har arbetats fram tillsammans med kunden. Eftersomdet redan fanns ett befintligt system sa visste kunden vilken funktionalitet som behovde finnas.Kunden hade darfor tagit fram en kravspecifikation redan innan projektet som vi utgick ifran.Efter lite korrigeringar kom vi fram till en kravspecifikation som bada parter var nojda med.

For att sakerstalla att vi byggde systemet enligt kundens onskemal och informera kunden om varstatus sa traffade vi var kund minst en gang i manaden. Vid dessa moten forevisade vi vad vi hadebyggt och kunden fick chansen att ge feedback tidigt och tycka till om det var nagot vi missadeeller dylikt.

4.1.2 Organisation

Nedan beskrivs hur vi organiserade projektarbetet. Figur 2 visar strukturen over de inblandadeparterna.




Figur 2 – Schema over organisationen.

4.1.2.1 Projektgrupp For att projektet ska lyckas har projektgruppen kommit overens omett antal ansvarsomraden. Dessa ansvarsomraden har fordelats pa olika roller, dar varje grupp-medlem har atagit sig ansvar for en specifik roll. Dessa roller ar listade i tabell 1.




Titel AnsvarsomradeGruppledare Leder arbetet.

Ansvarar for miljo, att processer foljs och maluppfyllnad.Har sista ordet och representerar gruppen utat.Leder, planerar och bokar lokal for moten.

Analysansvarig Ansvarar for kundens behov.Forhandlingspart och orakel in mot ovriga gruppen.Dokumenterar krav.Kommunikation med kund skall i forsta hand ske genom analysansvarig.Ansvarar for kravuppfyllnads-status, forhandling och uppfyllnad.

Arkitekt Ser till att en stabil arkitektur tas fram.Identifierar komponenter och granssnitt.Har sista ordet i teknikfragor efter gruppledare.Dokumenterar arkitektur.

Utvecklingsledare Ansvarar for detaljerad design.Leder utvecklingsarbetet och beslutar om utvecklingsmiljo.Organiserar utvecklarens tester.Beslutar om kodstandard och dokumentering.

Testledare Beslutar om systemets status.Skoter den dynamiska verifieringen och valideringen av systemet.Ser till att systemet testas och pa ratt satt.Skriver testplan och testrapport.

Kvalitetssamordnare Initierar och foljer upp kvaliteten for systemet.Planerar och budgeterar med gruppen for kvalitetsarbetet.Skriver kvalitetsplan.

Dokumentansvarig Ansvarar for fillagret och konfigurationshanteringen.Ansvarar for att det finns mallar och logotyp.Ansvarar for andringshantering och leveranser till deadlines.

Tabell 1 – Fordelning av ansvarsomraden.

4.1.2.2 Handledare Projektgruppen har haft tillgang till en handledare. Handledaren harfungerat som ett stod och en resurs som kan svara pa och diskutera fragor rorande projektarbetet,arbetssatt, tekniska losningar och kandidatrapporten. Handledaren har ocksa givit feedback paden dokumentation vi skrivit.

4.1.2.3 Kund I projektgruppen ar analysansvarige ansvarig for att halla kontakten med pro-jektets uppdragsgivare tillika kund och halla denne informerad om vart arbete. Analysansvarighar tillsammans med kund tagit fram kravspecifikationen och sakerstallt att alla krav uppfyllts.Vi hade moten med kund for att presentera och demonstrera det system vi hade byggt for attsakerstalla att det i sa hog grad som mojligt uppfyller kundens onskemal.

4.1.2.4 Projektets faser Projektet delades in i fyra faser, med olika mal for varje fas. Fasernasyftar till att tydliggora projektets status for examinator och kund. De syftar ocksa till att goradet enklare for projektgruppen att planera och organisera sitt arbete. En oversiktlig planering avde olika faserna ges i figur 3




Figur 3 – Ursprunglig tidsplan

Den forsta fasen, forstudien, hade som mal att identifiera kundens behov, ta fram en kravspe-cifikation i samarbete med kund, planera projektet och paborja den dokumentation som kravs.Forstudien var tre veckor lang.

Under iteration 1 fokuserade projektgruppen pa att ta fram enkla prototyper for att fa en tydligarebild av vad kunden verkligen ville ha. Denna prototyp utvecklades sedan vidare i iteration 2, daden storsta delen av systemets funktionalitet implementeras. I iteration 3 skulle slutproduktenkravvalideras infor leverans. I slutet av varje fas omvarderade vi dessa mal och satte nya fornastkommande fas.

4.1.2.5 Dokumentation Under projektet skrevs ett antal dokument. Syftet med dessa varatt dokumentera projektet. De dokument som skulle skrivas presenteras i tabell 2.

Dokument Innehall

Projektplan Dokumenterar hur projektet skall genomforas.

Kravspecifikation Dokumenterar de krav som stalls pa systemet. Tas fram i samarbete mellankund och projektgrupp.

Arkitekturplan Beskriver hur systemet ar designat.

Kvalitetsplan Hjalpmedel for att bedriva kvalitetsarbete pa systemet.

Testplan Beskriver hur systemet skall testas for att verifiera systemets funktionalitetoch kvalitet.

Testrapport Sammanstallning av de test som genomforts pa systemet och systemetsstatus.

Motesprotokoll Protokoll fran gruppmoten, handledarmoten och kundmoten under projek-tets gang.

Tabell 2 – De dokument som skrivs for att dokumentera systemet och projektet.

LATEX Vi valde att skriva all dokumentation i typsattningsspraket Latex eftersom det bade gersnyggare dokument och mojlighet att versionshantera alla dokument med git.

Vi har anvant en gemensam mall for samtliga dokument, vilket innebar att vara dokument harett enhetligt utseende.

4.1.3 Arbetsatt

Vi valde att arbeta efter en agil-liknande metod dar projektet delades in i flera faser som beskrivet i4.1.2.4. Detta innebar att det for varje fas sattes krav pa mal och funktionalitet som skulle utforas.




Under forstudien bestamdes systemets overgripande struktur. Vi gjorde olika gruppmedlemmaransvariga for olika delar av systemet. Detta har betytt att det alltid funnits nagon att fragagallande en specifik modul samtidigt som delegering av arbetsuppgifter fungerat relativt smidigt.

Dessa identifieras till:

• Frontend

• Backend

• BeagleBone

• PRU

Under forstudien bestamdes vilka gruppmedlemmar som skulle fokusera pa vilken modul och pasa satt ha det yttersta ansvaret for den modulen.

4.1.3.1 Moten Under projektets gang har projektgruppen kontinuerligt haft ett flertal olikamoten. Forutom interna moten med gruppen har vi ocksa haft ett mote varje vecka med varhandledare samt flera moten med kund. Dessa moten har haft olika syften, sa som att klargoraprojektets status och fa feedback pa det vi gjort. Vid moten agerade normalt dokumentansvarigesekreterare med uppgift att skriva protokoll over vad som sagts. Dessa protokoll lades sedan uppsa att alla i gruppen kunde komma at dem.Internmotena foljde en tydlig struktur dar foljande fragor ofta togs upp:

• Hur arbetet har gatt for varje medlem

• Vilka mal som ska sattas till nasta iteration

• Vilka mal som ska uppnas inom kommande tid

• Vilka mal som varje gruppmedlem siktar mot att na den kommande tiden

4.1.3.2 Gitlab Vi har versionshanterat var kodbas. Vi valde systemet Git eftersom att vi allahar tidigare erfarenheter av det, kan det och tycker att det fungerar bra. Vi anvande tjanstenGitlab som tillhandahalls av IDA vid Linkopings universitet. Vi anvande tva Git-repositories, ettfor dokumentation och ett innehallandes var kod.

4.1.3.3 Redmine Redmine ar en issue-tracker. Redmine ger tillgang till att skapa aktiviteter.Varje aktivitet kan vara av olika typer som funktionalitet, organisation eller bugg. Via aktiviteterkan man logga antalet timmar som laggs pa den aktiviteten, se vem som ar ansvarig for aktivitetenoch om aktiviteten ar gjord eller lost. Vi valde att anvanda Redmine for att skapa aktiviteter somska goras, buggar som ska losas och logga antalet timmar vi jobbar och pa vad vi jobbar.

4.1.4 Uppsamling av erfarenheter

I slutet av iteration 3 genomforde hade vi ett erfarenhetsmote. Under detta mote fick alla chansenatt ta upp och diskutera sina erfarenheter vilket sedan antecknades.

4.1.5 Jamforelse med forgaende system

Vi hade tyvarr inte tillgang till det foregaende systemet under utvecklingen. For att ta reda pahur vart system stod sig mot det foregaende fick vi istallet ga mestadels pa vad kund berattat omsystemet. Vi kunde ocksa se i hur hog grad vi uppfyllde kravspecifikationen, vilken till stora delarvar baserad pa det foregaende systemet. Uppfyller vi kravspecifikationen har vi all funktionalitetdet foregaende systemet hade och lite till.




4.2 Designbeslutsprocess

I det har avsnittet definieras den metod vi anvande for att forsoka forbattra var designbeslutspro-cess.

4.2.1 Identifiera problem med designbeslutsprocess

For att forbattra designbeslutsprocess har vi valt att identifiera problem med den designbesluts-process som anvants. Dessa problem har sedan analyserats for att utrona om det ar brister i vardesignbeslutsprocess som har orsakat dem.

4.2.2 Analys av designbeslutsprocess

For att forbattra processen analyserades problemen som vi stotte pa under projektets gang,samtidigt gjordes antaganden om vart i designbeslutsprocessen problemet uppstod. Var processjamfordes med andra beslutsmetoder. En slutsats drogs sedan om hur vi kunde forandra vardesignbeslutsprocess for att forhindra att liknande problem uppstar.

5 Resultat

I detta avsnitt redogor vi for de resultat vi uppnadde, hur vi uppnadde dem och vilka erfarenhetervi som grupp tar med oss fran det har arbetet.

5.1 Kravhamtning

De krav som vi arbetade efter finns dokumenterade i kravspecifikationen som vi tog fram tillsam-mans med kunden i projektets forstudiefas. Kravspecifikationen ar uppbyggd av ett antal binarakrav (dvs de kan endast uppfyllas helt eller inte alls). Eftersom systemet ar uppdelat i mindremoduler ar kraven relevanta for en specifik modul. Kraven har aven olika prioriteringsgrad dar delistade med en etta motsvarar krav som skall vara uppfyllda efter projektets slut. De med lagreprioritering (tva eller tre) ses over i man av tid.

5.2 Overgripande losning

Enligt kraven fanns det ett antal forutsattningar for systemet. Matstationer ska kunna placerasute i falt och med hjalp av en prob utfora matningar pa vatten. Matstationer ska vara implemen-terade pa en BeagleBone Black. Ett webbgranssnitt som kan koras i Google Chrome ska finnas foratt komma at data, se status for matklienter och andra matklienternas konfiguration.

Med denna information kandes det sjalvklart att en centraliserad server kravs. Den ska tillhan-dahalla webbgranssnittet och kommunicera med matklienterna. En overblick kan ses i figur 4.




Webbklient Server

Matenhet

Figur 4 – Oversikt av systemet

En centraliserad server ar basta losningen da matklienter och anvandare kan sitta bakom olikasorters brandvaggar som skulle omojliggora direktkommunikation. Det ar ocksa smidigt att samlaall data pa ett och samma stalle.

5.3 Hardvara

Ett krav fran kunden var att en matstation skall besta av en BeagleBone Black, se kapitel 3.8.BeagleBone Black skulle kopplas ihop med en prob och for att integrera den analoga proben medBeagleBone Black behovdes en D/A- och A/D-omvandlare.

Eftersom BeagleBone Black endast hade 12 bitars precision kunde denna inte anvandas for attomvandla den analoga signalen, da kunden kravde en upplosning pa 16 bitar. Istallet anvandes enextern D/A- och A/D-omvandlare beskriver i kapitlet nedan.

5.3.1 D/A- och A/D-omvandlare

For att stimulera och lasa av matproben sa fick vi ett analogt granssnitt ifran kunden bestaende aven Analog Shield ifran Digilent. Detta kort innehaller en D/A- och en A/D-omvandlare som kon-trolleras via en gemensam SPI-buss. Da SPI inte ar en strikt standard sa foljer inte D/A- och A/D-omvandlaren samma standarder for kommunikation, utan de vill ha olika polaritet for klockpulseroch data under overforingar. Pa matenheten sa ar det PRU:n som styr SPI-kommunikationen,eftersom PRU:n inte har nagon SPI-hardvara sa ar protokollet implementerat i mjukvara.

5.3.2 Realtidsdator

Da ett vanligt Linuxprogram inte uppfyller kraven pa stabil sampling i 1 kHz sa behovde vinagot att lagga denna tidskritiska funktionalitet pa. Da BeagleBone Black innehaller ett sa kallat”Programmable Realtime Unit SubSystem” med tva PRU-karnor specifikt designade for att kunnaavlasta sadan tidskritisk funktionalitet sa var de lampliga att implementera samplingen pa. Merom denna losning beskrivs i kapitel E. Sebastian - Implementation av realtidsfunktionalitet.

5.4 Matenhet

I detta avsnitt beskriver vi hur vi valt att konstruera matenheten.

5.4.1 Programstruktur

Vi valde att anvanda programmeringsspraket Python pa matenheten dels da det var ett onskemalifran kunden, dels da det fungerar bra bade for att kommunicera med servern och for att kommuni-cera med PRU:n via en C-wrapper. Python fungerar aven bra i den Linux-miljo vi var begransade




till och det ar ett sprak vi hade tidigare erfarenhet av och kande oss bekvama med.

Figur 5 ger en snabb overblick av hur vi valde att strukturera programvaran pa matenheten. PRU:nhanterar det analoga granssnittet och utfor sjalva matningarna, PruHandler hanterar PRU:n,hamtar matningar fran denna och presenterar for Main som kommunicerar med servern fran vilkenden hamtar parametrar och skickar matningar.

Main

PRU interface

PRU

Figur 5 – Oversikt av Matenhetens struktur

5.4.2 Programvara PRU

PRU:ns program bestar av en mainloop som med hjalp av en hardvarutimer kors med en periodtidpa 0,1 ms. I varje iteration av loopen sa kontrolleras forst vilket tillstand som ar satt. Det finnstva olika tillstand, run och idle. I idle sa gors ingenting forutom att satta utsignalen pa D/A-omvandlaren till 0 V och i run sa okas tre tidsraknare med periodtiden. Raknarna styr om en nymatsampel ska tas och laggas i den delade bufferten, om en ny puls i pulstaget ska skickas ut, ellerom det ar dags att paborja ett nytt pulstag och en ny sampling. I slutet av varje iteration, oavsettlage, sa lases temperatursensorn av och temperaturen skrivs till det delade minnet.

5.4.3 Delat minne

For att overfora matdata fran PRU:n till Linux-sidan hade vi tva alternativ. Antingen kunde vilagga in matdata direkt i RAM fran PRU:n eller sa kunde vi anvanda ett sarskilt minne som delasmellan de bada PRU:erna och ARM-processorn. PRU:n kan lasa och skriva till det delade minnetpa en klockcykel. Det ar dock bara 12 kB stort.

En typisk matning, dvs alla sampel, ar i storleksordningen 80 kB. Fordelen med att skriva till RAMskulle vara att vi kan spara hela matningar utan att dela upp dem. Nackdelen med att anvandaRAM ar att det tar mycket langre tid for PRU:n att skriva till detta och implementationen hadevarit krangligare da vi maste allokera en mangd RAM som PRU:n far skriva till och kommunice-ra dessa minnesadresser till PRU:n. Med det delade minnet ar det precis tvartom. Nackdelen aratt vi maste dela upp en matning i flera delar eftersom hela matningen inte far plats i minnet.Fordelarna ar att det gar snabbt for PRU:n att lasa och skriva till minnet och implementationenblir enklare da adressen till det delade minnet ar alltid tillganglig.

Vi gjorde bedomningen att eftersom en matning sker over flera sekunder sa kan programmet paLinuxsidan lasa data snabbare an PRU:n hinner skriva. Vi har darfor bra mojligheter att skickamatningar i delar. Vi valde att anvanda det delade minnet och implementera en cirkularbuffer idetta for att fora over data till Linuxsidan.




Eftersom mangden parametrar som ska skickas till PRU:n ar begransade, 5 parametrar och upp till100 olika step levels, valde vi att helt enkelt dedikera minnesplatser till varje parameter i det delademinnet. Alternativet hade varit att ha en buffer ocksa till PRU:n, alternativt implementera buffer-ten som en tvavagsbuffer, och ha kontinuerlig tvavagskommunikation. Fordelarna med detta hadevarit att vi kan anvanda hela det delade minnet som buffer och om det i framtiden finns behov avatt utoka funktionaliteten hos PRU:n sa finns ett generellt protokoll for kommunikation till denna.

De fem parametrarna ar implementerade som 32-bitars heltal och varje step level ar ett 32-bitarsflyttal, det blir sammanlagt 420 byte. Vi gjorde bedomningen att dessa bytes inte skulle begransaprestandan i systemet namnvart. Om inte de resterande 11,5 kB racker har vi storre problemnagon annanstans. Dessutom kunde vi specificera de dedikerade minnesadresserna i en header-fil,vilket skulle gora implementationen av nya parametrar trivial vad galler plats i det delade minnet.

Adress Innehall Skrivs av0x0000 STEP TIME PruHandler0x0004 NUMBER OF STEPS PruHandler0x0008 STEP LEVELS PruHandler... Step levels PruHandler0x0194 Slut Step levels PruHandler0x0198 SAMPLE RATE PruHandler0x019C REPEAT RATE PruHandler0x0200 MODE PruHandler0x0204 TEMP PRU...0x0300 LOST DATA PRU0x0304 BUF HEAD PRU0x0308 BUF TAIL PruHandler0x030C BUF START PruHandler0x0310 BUF END PruHandler...BUF START Bufferns borjan PRU... Bufferdata PRUBUF END Bufferns slut PRU

Tabell 3 – Vad det delade minnet innehaller, och vem som skriver vad.

Tabell 3 visar innehallet i det delade minnet enligt tidigare namnda header-fil. Denna delas mellanpru_interface och PRU:ns programvara for att undvika situationer dar olika delar av systemetletar pa olika stallen efter samma sak samt for att gora det trivialt att andra fordelningen avinnehallet i detta minne. Notera dessutom att BUF START och BUF END ar dynamiska ochstyrs fran PruHandler och skulle kunna andras under korning (befintlig data i bufferten gar dockforlorad).

Buffern fungerar i ovrigt som sa att PRU skriver och Linux laser. BUF HEAD pekar pa det se-naste varde PRU:n skrev, och BUF TAIL pa nasta varde programmet pa Linux-sidan ska lasa.Normalt skriver PRU:n fyra varden till bufferten per sampel. Forst kommer ett 32 bitars hel-tal med sampleid, vilket talar om for oss vilket sampel i matningen vi ar pa. Detta anvands iPruHandler for att kontrollera att hamtad data inte ar korrupt (att datapunkter tappats). Sedanskrivs tre 32 bitars flyttal med uppmatt probdata. Skulle bufferten vara full, okar PRU:n storlekenpa LOST DATA med ett. Detta varde anvands dock for narvarande inte till nagot annat an atttesta och debugga systemet.




5.4.4 Granssnitt mot PRU

Figur 6 visar hur vi valt att strukturera det interface genom vilket vi anvander PRU:n.

PruHandler

pru interface

libpru

prussdrv mio

Delat minnePRU

Figur 6 – Oversikt av interfacet mot PRU

5.4.4.1 prussdrv Da PRU:n ar integrerad i BeagleBone kretsen behovde vi ett interface foratt hantera denna. Texas Instruments som tillverkar processorn tillhandahaller ett bibliotek foratt hantera PRU:en, prussdrv, vilket innehaller funktionalitet for att initiera, ladda in och startaprogram pa PRU:n.

5.4.4.2 mio Vi skrev sjalva koden vi anvander for att lasa och skriva till det delade minnet,mio, det inspirerades av kod fran biblioteket pru_sdk. Vi anvande ursprungligen pru_sdk men detuppfyllde inte riktigt vara onskemal. Detta ledde till att vi skrev ett nytt interface. Vi anvanderprussdrv som ar skrivet i spraket C. Vi valde da att fortsatta anvanda C aven for interfacet motdet delade minnet eftersom det ar naturligare att arbeta med minnespekare i C an i Python.

5.4.4.3 libpru Vi valde att skriva ett gemensamt C-interface for dessa tva moduler, libpru.I interfacet implementerade vi funktioner for att hantera den delade bufferten och setters for allaparametrar med undantag for step_levels, da dessa var enklare att implementera i Python.Det var smidigt att implementera denna funktionalitet i C delvis pa grund av den header-fil meddedikerade minnesadresser som delas med PRU:n. Hade vi implementerat det i Python hade vibehovt ha en kopia pa dessa konstanter i ett format som Python kan forsta.

5.4.4.4 pru interface Vi valde att badda in C-koden med Python-biblioteket Ctypes. Viansag att det vi skulle gora varken var sa omfattande att vi hade tjanat pa att anvanda ettautogenererat interface som SWIG eller sa prestandakritiskt att vi hade tjanat pa att anvandaCython. Ctypes ar enkelt att anvanda, man pekar pa en kompilerad objektfil och specificerar vad




inparametrar och returvarden har for datatyper. Cython skoter sedan konverteringen mellan Pyt-hons datatyper och motsvarande datatyper i C.

Vi implementerade den funktionalitet som saknades i pru_interface, som setters for step_levelsoch skapade ett paket, pru_interface, for att halla arbetsmappen ren.

5.4.4.5 PruHandler Det storsta problemet med att anvanda en buffer i det delade minnet aratt den har en begransad storlek vilket innebar att vi maste lasa den data PRU:n skriver konti-nuerligt. Vi maste dessutom lasa minst lika fort som den skriver for att inte forlora matdata. Foratt vi inte ska hamna i en situation dar vi endast tommer bufferten i slutet av en lang mainloopoch darfor maste anpassa mainklienten efter denna tidskritiska del av systemet sa valde vi att im-plementera en helt separat trad, PruHandler, vars uppgift det blir att hela tiden tomma buffertenoch presentera hela matningar mot matklienten. For att vi inte ska hamna ur synk med oss sjalvasa hanteras all kommunikation med PRU genom denna trad.

PruHandler ar uppdelad i tva delar, PruHandlerThread som ar den trad som hanterar PRU:n,och PruHandlerInterface som ger oss verktyg att hantera traden. PruHandlerThread styrsav tva dictionaries, ett innehallandes flaggor som talar om for traden vilket tillstand den be-finner sig i och ett som innehaller de parametrar som ska koras pa PRU:n. De resulterandematningarna laggs i en ko fran vilken PruHandlerInterface kan hamta dem. Dessa tre objektskapas i PruHandlerInterface och delas sedan med PruHandlerThread. I PruHandlerInterfaceaterfinns sedan funktioner for att andra flaggor, parametrar och returnera matningar. Dessa ab-straktionslager, visualiserade i figur 7 resulterar i att matklienten ar helt skild fran driften avPRU:n. Vi skulle kunna byta ut PRU:n mot nagot annat utan att behova andra nagot annat anPruHandler.

PruHandlerInterface

PruHandlerThread

flagsparameters

measurement queue

Main

matpunkttemperatur

set parameters(parameters)get queue size()set mode(mode)get measurement()get temp()

Figur 7 – Kommunikationsvagar i PruHandler

Da matenheten ar i RUN, tommer PruHandlerThread bufferten med jamna mellanrum. Da matenhetensparametrar eller tillstand forandras, vilket alltid ska ske i da enheten ar i IDLE, skriver traden dessatill det delade minnet dar PRU:n kan anvanda dem. PruHandlerThread gor ocksa en enkel kon-troll av inlasta varden genom att kontrollera sampleid och se till att det inte tog for lang tid attlasa in matningen. Om nagot fel upptacks, markeras matningen som korrupt och sedan forsokertraden ratta till problemet genom att kassera resten av matningen och forsoka hitta starten panasta matning. Ser matningen korrekt ut, filtrerar vi bort sampleid och lagger matningen i kon.




5.4.5 Matklient

Matklienten har tva uppgifter den ska klara av for att uppfylla kraven. Varje del av dessa tvakan hanteras individuellt och det ar sa koden ar uppbyggd. De kan hanteras individuellt pa grundav att natverksdelen ar en funktionalitet i sig sjalv och att hantera matningar ar en annan. Attnatverket gar ner far inte paverka matningsdelen sa det ar naturligt att dela upp dem. Dessa tvauppgifter ar allt matklienten behover gora, sa den ligger i en oandlig loop och utfor dem. Varjeuppgift bestar av underuppgifter. Bild 8 illustrerar dess underuppgifter.

Figur 8 – Illustration av matenhetens loop.

5.4.5.1 Natverkshantering Natverkshanteraren har som uppgift att koppla upp sig motservern och skota kommunikationen mellan dem. Detta innebar att den ska se till att kopp-la upp sig nar det ar mojligt och skicka lokalt sparade matningar som servern annu inte fatt.For att utfora sin uppgift anvands ett antal klasser som SocketHandler, PacketBuilder ochMeasurehandler. Sockethandler skoter den interna datastrukturen for sockets och ger funktio-nalitet for att skicka paket enligt protokollet. PacketBuilder anvands for att skapa paketen somskickas och Measurehandler har som uppgift att se till att halla reda pa matningar. Logiken arstrukturerad pa foljande satt:

• Om ej uppkopplad → koppla upp

• Om uppkopplad och ej autentiserad → autentisera

• Om uppkopplad och bor skicka status → skicka status

• Om uppkopplad och kan skicka matning → skicka matning

• Om uppkopplad → hantera lasning fran servern

• Om natverksfel → koppla ned

5.4.5.2 Matningshanteraren Matningshanteraren har som uppgift att se till att ta matningaroch spara dem. Detta gor det med hjalp av PruHandler. PruHandlerInterface ger tillgang tillnya matningar. Matningshanteraren kontrollerar om det finns nagon ny matning och sparar denlokalt i filsystemet.




5.4.5.3 Filsystemet For filsystemet diskuterades ett antal losningar. De som diskuterades varen lokal databas, samtliga matningar i en fil eller varje matning i varsin fil. Att anvanda en databasuteslots snabbt da den skulle krava onodigt mycket prestanda. Vi valde att spara varje matningi varsin fil da det var enklare att implementera. Vid stromavbrott ar det bara den matning somskrivs vid stromavbrottstillfallet som har risken att bli korrupt.

Nar det var beslutat att varje fil skulle sparas individuellt ville vi anda strukturera det sa varjematsession holl ihop och slutimplementationen blev enligt nedan.

En fil innehaller en JSON-lista over matsessioner som inte ar skickade. Sedan sparas alla matsessioneri egna mappar. Dessa mappar har sessionid:t som namn. I varje mapp finns en fil som innehaller enJSON-dictionary med nycklar till sessionid, antalet matningar och skickade matningar. Matningarsparas pa fil med matningsnummret som namn i matsessionsmappen. Bild 9 illustrerar filsystemet.

Figur 9 – Oversikt av matenhetens filstruktur




I filsystemet kan fem saker intraffa. Nedan beskrivs hur dessa paverkar systemet.

• En ny matsession startas.

– Matsessionid:t laggs till i JSON-listan over matsessioner.

– Matsessionsmappen skapas.

– Filen med JSON-dictionaryn over matningar skapas i matsessionsmappen.

• En matning sparas.

– En fil innehallande matningen sparas i matsessionsmappen med matningens id somnamn.

– JSON-dictionaryn uppdateras med nya antalet matningar for sessionen.

• En matning skickas.

– Filen innehallande matningen lases men filsystemet forblir oforandrat.

• En matning har skickats.

– JSON-dictionaryn uppdateras med antalet skickade matningar for den sessionen.

• En matsession har skickats.

– Matsessionid:t tas bort ur JSON-listan med matsessioner.

Ingen av dessa handelser jobbar pa manga filer samtidigt och vid stromavbrott ar det bara filersom skrivs som kan bli korrupta. Eftersom de viktiga filerna ar sma, och skrivs valdigt sallanminimerar vi risken for detta. Och det ar oftast bara en matning eller en matsession som kan blikorrupt. Det ar bara nar JSON-listan med alla matsessioner skrivs vi kan forlora all lokal data.

5.5 Server

Vid valet av serverutvecklingsverktyg fanns det en uppsjo av alternativ: PHP, Node.js, Python-Web, Java och .Net. Det finns for- och nackdelar med alla utvecklingssprak, beroende pa vilkauppgifter som ska losas. Eftersom enheterna laddar upp data till servern kontinuerligt sa kravsdet en server som kan hantera IO-operationer i stor skala. Detta var en av anledningarna till attvi valde Node.js som ar ett eventdrivet ramverktyg som bygger pa Chrome V8 javascript-motor.

En undersokning (Kai Lei, Yining Ma & Zhi Tan3, 2014) visar att Node.js presterar battre anmanga av sina konkurrenter vid tunga IO-operationer och aven nar antalet anslutna klienter okarblir responstiden nastintill densamma. De flesta gruppmedlemmar har aven erfarenhet av Java-script vilket gor utvecklandet och forstaelsen av serverkod enklare. Node.js har stod for MongoDBoch med hjalp av modulen mongoose blir det enkelt att bygga ODM-modeller.

5.6 Serverarkitektur

Servern ar uppdelade i tva storre komponenter:

• En TCP-del som hanterar anslutningar och IO-operationer mot matenheter

• En webbdel som hanterar anslutningar mot webben




5.6.1 TCP

Vi valde att kommunicera med matenheterna over TCP da det garanterar att paketen kommerfram sa lange en anslutning mellan parterna ar tillganglig. TCP segmenterar paketen vilket in-nebar att det inte ar garanterat att hela meddelandet inkommer direkt.

Enligt 3.4 beskrivs tva losningar for att paketera data. Vi valde att anvanda oss av sekvenslangdsmetoden,dar de fyra forsta byten beskriver langden pa meddelandet. Problemet med att anvanda sig av tec-kenavslut ar att identifieraren maste vara unik, vilket blir ett problem da vi sander icke overvakadbinardata. I varsta fall leder detta till att symbolen finns i binardatan och kommunikationslogikenblir ur synk.Kommunikationslanken mellan matenheten och server var strikt specifierat i ett protokoll, darvarje meddelande inleddes med en tag som identifierade vilket typ av meddelande som var pavag:

Length Tag Payload4 bytes 2 bytes Data

5.6.2 Webb

Webbservern ar uppdelad i tre delar:

• Statisk filserver som levererar CSS-, Javascript- och HTML-filer

• Datadriven server som levererar ett REST-API mot en godtycklig klient som kan hanteraHTTP-protkollet

• En oppen WebSocket som i realtid sander information till webbklienten

Nar en anvandare anslutar mot servern genom en webblasare sker kommunikation mellan serveroch klient enligt figur 10.

Figur 10 – Sekvensdiagram over kommunikation mellan server och webbklient

5.6.2.1 API Vi valde att anvanda oss av ett REST-API for att bygga en godtycklig data-driven server. Anledningen ar att det blir enkelt att utveckla godtyckliga grafiska granssnitt motexempelvis en applikation i Android eller Iphone.

API:t ar byggt med hjalp av express som ar ett ramverktyg till Node.js, gjort for webbapplika-tioner. Den generella strukturen for konstruktionen av API:erna foljde ofta samma metodik:

• Verification - Verifiera att det ar en inloggad klient som utfor API-anropet




• CheckInput - Verifiera att det ar korrekta parameterar som skickas in, det vill saga filtrerabort parametrar som kan anvandas for att komma at kanslig data

• ValidateInput - Verifiera att parametrarna ar i korrekt format

• BuildQuery - Bygg en sokstrang for att exempelvis lagga till eller hitta i databasen

• ReturnMessage - Skicka tillbaka ett svar till anvandaren i form av en JSON-strang

5.6.2.2 WebSocket Fran kundens sida fanns det krav pa att information om temperatur,minne och diskutrymme skulle visas pa webbsidan i realtid. Det finns tva vanliga losningar till pro-blemet, dar klienten kontinuerligt ska vara uppdaterad om vad som sker pa de olika matenheterna.Antingen fragar klienten om ny information har kommit in, i form av polling. Detta innebar attmycket utav kommunikationen mellan server och klienten blir onodig, vilket var nagonting vi villeundvika.

Genom att oppna upp en WebSocket-lank for klienterna mot servern kunde kommunikation ifull-duplex uppratthallas och klienten slipper polla om ny information.

5.6.3 MongoDB vs MySQL

I detta projekt har vi en matenhet som skickar en stor mangd data till servern som sedan spararundan all data. En anvandare kan sedan hamta data genom att ga in pa hemsidan och ladda nerden. En viktig poang ar att databasen kommer anvandas for att skriva valdigt mycket mer an vadden kommer anvandas for att lasa och skicka ivag data till anvandaren.

Eftersom vi inte har haft tid att testa tva olika databaser sjalva sa har vi utgatt fran andra personersom har genomfort samma typer av tester som vi skulle ha skapat. I ett test mellan MongoDB,MySQL och Cassandra (som ar en annan databas) for att se vilken databas som ar bast for ettloggsystem vann MongoDB overlagset. Vid insattning av 375 000 element var MongoDB mer antio ganger sa snabbt som MySQL, aven svarstiden var mindre for MongoDB. Figur 11 och figur12 visar hur overlagset MongoDB ar nar det kommer till logsystem. Det enda testet dar MySQLvar battre an MongoDB pa var vid matning av CPU-anvandningen. (Marcus Olsson, 2014)

Figur 11 – Diskskrivning till loggsystem.




Figur 12 – Tidsatgang for loggsystem.

I slutandan beslutade vi att anvanda ett filsystem for att spara matdatan istallet for att sparaden i databasen. Detta har gjort att valet av databas inte blev lika viktigt, da det sannolikt inteblir nagon namnvard skillnad nar det bara ar valdigt lite data som behover hamtas. Hade vi integjort detta och sparat all matdata i databasen hade MongoDB varit ett battre val.

5.6.4 Databasmodeller

For att matningar skall kunnas sparas korrekt till servern kravs det databasmodeller som specifi-erar serverns funktionalitet mot webbklienter och matenheter.

Databasmodellerna kan delas upp i tva storre delmodeller:

• Unit collection

• User collection

5.6.4.1 Unit collection Unit collection innehaller foljande ODM-modeller:

• Unit

• MeasureSession

• Measure

Unit innehaller information om matenheten samt attribut for att autentisera en matenhet, senedan.

Attribut namn Datatyp Syftemac addr Strang Spara datorn unika mac address

last ip Strang Spara datorn senaste anvanda ipname Strang Datorn unika namn

session token Strang En unik token som anvands av matenheten for att autentisera sigfile desc Strang Var i filsystemet den har sin unika mapp

status running Boolean Vilket tillstand enheten ar ilatest sent Datum Nar det senaste paketet skickades

latest measure session Strang Refererar till senaste matparametrarna

MeasureSession innehaller information om hur de olika matparametrarna lagras for, se nedan.




Attribut namn Datatyp Syfteunit Strang Refererar till vilken enhet den ar kopplade till

createdBy Strang Refererar till vilken anvandare som skapade matparametrarnafile desc Strang Var i filsystemet alla matningarna kopplade till dessa

step time Heltal Definierar hur lang tid i millisekunder ett sample ska tasnr of steps Lista Definierar hur manga pulser det finns i pulstagetstep lvls Lista Beskriver vilken spanning [mV] varje puls i pulstaget har

sample rate Heltal Definierar hur lang tid i millisekunder det ar mellan varje pulsrepeat rate Heltal Definierar hur ofta man gor en matning

Repeat rate ar hur ofta man gor en matning. Measure innehaller information om hur de olikamatningarna lagras, se nedan.

Attribut namn Datatyp Syftemeasure session Strang Refererar till den kopplade matparametern

file desc Strang Var i filsystem denna matning artemperature Heltal Temperaturen for matningentimestamp Heltal Nar matningen gjorde i matenheten, matt i NTP-standardtid sedan UNIX epoc.

5.6.4.2 User collection User innehaller information om hur anvandaren lagras.

Attribut namn Datatyp Syfteusername Strang Anvandarnamn for inloggningpassword Strang Losenord for inloggning, detta ar hashat och saltat med ett unikt salt

email Strang Anvandarens emailsalt Strang Unikt salt for varje anvandare

admin Boolean Om anvandaren ar admin eller inte

5.7 Webbgranssnitt

Manga av de kraven var kund hade pa vart system kretsade kring hur webbgranssnittet skulle seut och vad det skulle innehalla. Det befintliga systemet som vi skulle ersatta hade enligt kundenett trakigt utseende och “icke-responsivt” beteende. Kunden var tydlig med att var version skullevara mer anvandarvanlig, vilket paverkade flertalet designbeslut vi tog.

5.7.1 Bootstrap

Bootstrap ar ett ramverk som ar populart nar man ska bygga responsiva hemsidor. Bootstrapinnehaller HTML- och CSS-baserade modeller for typsnitt, indataformular, knappar och dylikt.Det positiva med Bootstrap ar att alla dessa komponenter blir responsiva. Ett exempel kan varaatt om man har musmarkoren over en knapp andrar knappen farg.

Det finns aven ett Javascript-bibliotek som mojliggor att man ger komponenter liv. Vi anvandeross till exempel av “dropdown-menyer”, vilket ar en meny som dyker upp under en knapp nar denklickas pa.

5.7.2 DataTables

DataTables ar ett plugin som anvands for att gora vanliga HTML-tabeller mer interaktiva och gedem utokad funktionalitet. Man far till exempel mojligheten att sortera pa samtliga attribut frantabellelementen. Man kan aven soka efter nagot i tabellen via en sokruta. Tabellerna far aven ensnygg design.




5.7.3 Interaktiv graf

Vi behovde representera matdatan fran den senaste matningen grafiskt. Efter en tid av letandebestamde sig en medlem sig for att anvanda ett plugin vid namn Plotly. Plotly skapade en valdigtsnygg och behandig graf, som visas i figur 13.

Figur 13 – Graf genererad av Plotly

Fordelarna med Plotly, forutom att den ar snygg, ar att det gar att zooma in genom att markeraen ruta i grafen. Dessutom var det valdigt enkelt att implementera grafen pa hemsidan.

Plotly har ett flertal nackdelar. Enbart en anvandare kan anvanda grafen i taget. Om Plotly skullevara otillgangligt skulle vi heller inte kunna visa nagra grafer. Vara matningar genererar storadatamangder som maste skickas till Plotlys servrar. Har man da en taskig natverksansluting al-ternativt om Plotlys servrar skulle strula nagon gang sa skulle det bli problem att ladda grafen.Dessutom hade en av gruppmedlemmarna problem med att ladda in grafen pa sin dator. Ett annatproblem var att Plotly inte ar helt gratis. Det ar gratis till viss del, man kunde ha tio styckengrafer men ville man ha fler sa behovde man betala. Det storsta problemet var daremot att Plotlyinte renderas lokalt.

Detta ledde till att vi beslutade att byta ut Plotly. Nackdelarna var fler an fordelarna. Da vidomt ut Plotly behovde vi hitta ett nytt satt att implementera var graf. Valet foll pa D3 eftersomdet ar ett kraftfullt ramverk som liksom Plotly hade stod for diverse zoom-funktioner. Nackdelengentemot Plotly (som for ovrigt delvis ar byggt pa D3) ar att det blir betydligt mer kodande. Enillustration over hur grafen ser ut kan skadas i figur 14.




Figur 14 – Graf kodad i D3

Vart system anvander D3 for att mala upp en interaktiv diskret graf som representerar den senastegjorda matningen dar de tre probernas uppmatta strom visas. Eftersom det ar ett mycket stortantal punkter som maste finnas i grafen kravdes det att man kunde implementera ”zoom anddragfunktionalitet. D3 blev valet eftersom det finns goda mojligheter for det.

5.7.4 Jade

Nar man skall designa hemsidor kravs det att man har HTML-dokument eftersom det ar dessasom webblasarna kan tyda. I Node.js finns det dock stod for andra typer av marksprak som Node.jssedan konverterar till HTML-kod. Ett av dessa sprak ar Jade som vi valde att anvanda. Fordelarmed Jade ar att det finns stod for sa kallat template inheritance vilket mojliggor att man intebehover inkludera Javascript och stylesheets i varje fil (som skulle vara fallet om man kodadei HTML). Det ar aven snabbare och trevligare att programmera i Jade gentemot HTML ansagprojektgruppen.


Under projektets gang identifierade vi tre problem som uppstod pa grund av brister i designbe-slutsprocessen. Nedan beskrivs dessa i mer detalj.

5.8.1 Plotly

Som beskrivet i avsnitt 5.7.3 implementerade vi till en borjan den interaktiva grafen i Plotly.Problemet var att det tog 40 arbetstimmar innan beslutet att byta till D3 togs.

5.8.2 TCP-protokoll

Tidigt i projektet beslutades det att ett TCP-protokoll skulle skapas. De tva gruppmedlemmarnavars moduler detta berorde beslutade att den ena gruppmedlemmen skulle implementera det.Gruppmedlemmen vars ansvar det var att implementera protokollet bestamde sig for att skapaprotokollet fran grunden. Innan denne hade hunnit implementera protokollet hade den andreredan gjort det med ett externt bibliotek. Eftersom biblioteket fungerade bra avbrots arbetet padet egengjorda protokollet.




5.8.3 Measurehandler

Under projektet skulle en klass i Python implementeras for att spara matningar pa matklienten.Gruppmedlemmen som ansvarade for matklienten gjorde ett felaktigt antagande om hur systemetskulle fungera. Detta ledde till ett onodigt komplext system. Det ledde ocksa till att aven testningblev svarare an nodvandigt.

5.8.4 Var designbelutsprocess

I slutet av projektet gick vi igenom hur varje gruppmedlem fattat designbeslut. Vi kunde enkeltkomma fram till en process vi alla anvant, eftersom att valdigt fa saker skilde sig mellan de olikagruppmedlemmarnas processer.

Samtliga hamtade information om olika mojliga losningar. Vi vagde for- mot nackdelar med olikalosningar. Hur andra moduler och utvecklare paverkas av din losning vagdes in i for- och nackde-lar. Hansyn har tagits till om beslutet paverkar nagon annan modul. Hansyn har ocksa tagits tillkund i de fall kunden paverkas direkt. Om nagon annan modul eller utvecklare paverkas mycketav beslutet har detta diskuterats denne.

Protokoll har diskuterats dar det har varit nodvandigt. Vissa gruppmedlemmar har fragat tredje-part i sarskilda fragor (framforallt om Node.js och hur tidskritiskt Linux ar). Darefter tas design-beslut.

I allmanhet har inga designbeslut diskuterats med gruppen. Undantag ar storre beslut som varintressanta redan i det forsta planeringsstadiet (t.ex PRU, Node.js, overgripande struktur medserver). Nastan inga beslut som har tagits i projektet har heller presenterats for gruppen, varkeni forhand eller i efterhand.

5.9 Tidsforbrukning

I kursen TDDD77 skulle 300 timmar spenderas per gruppmedlem. I dessa 300 timmar skulleprojektet genomforas, kandidatrapport skrivas och ett antal seminarier genomforas.

5.9.1 Medlem hoppar av

Efter cirka halva projekttiden meddelande en gruppmedlem att denne skulle hoppa av. Dettainnebar en forlust pa ungefar 200 arbetstimmar. Att medlemmen hoppade av medforde aven vissomorganisation, sarskilt eftersom avhopparen var gruppledare. Detta gjorde att en ny gruppledarebehovde valjas och behovde laras upp i arbetsuppgifterna gruppledaren ansvarar for. FredrikLarsson valdes till ny gruppledare. Detta ledde att vi tappade tid.

5.9.2 Forbrukad tid

Systemet konstruerades pa utsatt antal timmar. Forlusten av en gruppmedlem innebar att vissfunktionalitet vi planerat att implementera utover den kravsatta fick bortprioriteras. Av de kravsom satts pa systemet var det ett som inte uppfylldes. Gruppen diskuterade det ej uppfylldakravet med kund och kom fram till att den funktionalitet som saknades var onskvard snarare annodvandig.

5.10 Gemensamma erfarenheter

Ingen i gruppen har tidigare arbetat med ett projekt i samma omfattning. Det har gett oss nyaerfarenheter och insikter i vad som kan vara viktigt for att fa arbetet att fortskrida.




En av de viktigaste erfarenheter vi tar med oss, ar vikten av att komma overens tidigt om hur manska arbeta och kommunicera pa ett strukturerat satt. Vi har haft problem med kommunikation in-om gruppen vilket har markts da vi periodvis inte informerade och pratade med varandra sarskiltmycket. Under projektets gang bytte vi fran SMSgrupp och mail till Skype till Facebook. Ett bragemensamt kommunikationsmedel fran borjan, dar man kan vara saker pa att alla andra laser detman skriver hade varit bra. Tydligare struktur pa moten, med en tydlig dagordning och en planfor vad som ska astadkommas, hade kunnat gora saker mer strukturerade. Ett symptom av varbristande kommunikation ar till exempel att manga av de dokument vi skrivit inte har anvantssom stod for oss sjalva. Istallet har de skrivits mycket for att de ska skrivas utan att resten avgruppen ar inforstadd i dess innehall.

Gruppen har ocksa haft problem med att det inte funnits nagot uttalat arbetssatt. Vi hade nagraideer och planer i borjan, men i slutandan lyckades inte gruppen bestamma. Istallet blev gruppenuppdelad i mindre grupper dar varje grupp fick losa sina egna problem bast de ville. Detta leddetill att det har varit svart att fa en overblick av hur vi ligger till, hur langt vi kommit i projektetoch hur andra har lost problem. Vi upplever att vart arbetssatt har hindrat oss och att battreorganisation och mer struktur pa vart arbete hade hjalpt oss att astadkomma ett battre resultat.

Vi har markt att det ar bra, nyttigt och viktigt att testa den mjukvara vi skriver pa ett struktureratsatt och att borja gora det sa tidigt som mojligt. Vi har ocksa fatt erfara hur mycket tid som kanga forlorad om inte designbeslut tas pa ett bra satt. Somliga har fatt erfara att nagot man laggermycket tid pa att konstruera inte nodvandigtvis kommer med i slutprodukten. Vi har markt attdet kan vara till hjalp att arbeta mot tydligt uppsatta mal. Om vi hade haft battre mal for varjeiteration kanske vi hade kunnat fordela arbetsmangden battre over hela projekttiden. Slutligentar vi med oss viss insikt i vad det innebar att arbeta pa en vetenskaplig rapport.

6 Diskussion

6.1 Nya systemet

Har diskuteras fragestallningen om vi lyckades byta ut systemet och uppfylla de krav som kundenhade.

6.1.1 Resultat

Resultatet visar att det befinitliga systemet som anvandes innan kan bytas ut mot ett enklare,billigare och mer modulart system. Genom att byta ut realtidsdatorn som anvandes for matningarmed en BeagleBone Black och dess realtidsproccessor sparas hardvara och utrymme utan attmatningar forsamras.

Kundens krav om ett mindre bokigt webbgranssnitt uppfylldes, dar en nytt granssnitt utveckladesfor att passa till weblasaren i mobilen och datorn. Eftersom kunden var involverad under utveck-lingens gang ledde detta till ett granssnitt som alla parter blev nojda med, vilket inte var fallet idet gamla systemet.

6.1.2 Metod

Om vi inte hade lyckats konstruera det nya systemet, hade det kravts att vi hade kunnat bevisaatt det inte gar att konstruera systemet pa en BeagleBone Black for att besvara fragan huruvidadet gar eller inte. Vi har inte haft nagon metodik for att forsoka bevisa att det inte gar.

Pa motsvarande satt galler tidsaspekten. For att visa att det gar att konstruera systemet pa giventid behover vi konstruera det pa given tid, men for att visa att det inte gar maste vi pa nagot




satt bevisa att det inte gar. Vi samlade inte tillrackligt detaljerad data om hur mycket tid somspenderades pa vad for att kunna gora rimliga antaganden i det fall att vi hade misslyckats.


6.2.1 Resultat

Tva av de problem vi presenterade i avsnitt 5.8 resulterade i att arbetstimmar, som kunde lagtspa annat, slosades bort. Det tredje problemet orsakade mjukvara som tog hansyn till faktorer somi verkligheten inte finns, och darfor bade fungerar samre an det kunde och tog langre tid att testaan det borde ha tagit.

I det forsta fallet, gallande Plotly, sa var problemet att den gruppmedlem som tog beslutet intediskuterade det med nagon annan forran Plotly var implementerat och 40 timmar forbrukats.Hade detta beslut pa nagot satt redovisats for resten av gruppen ar det hogst troligt att vi hadebytt graf mycket tidigare.

I det andra fallet, gallande TCP-protokoll, var problemet tudelat. Till att borja med var det intesolklart fran borjan vad detta protokoll skulle hantera, om det skulle hantera specifikt JSON-objekt eller kunna skicka vad som helst, vilket innebar att den som utvecklade protokollet fickborja om tva ganger. Sedan var det ocksa ett problem att beslutet inte omvarderades nar detmarktes att det skulle ta lang tid att implementera. I slutandan valde den andra utvecklaren attanvanda ett fardigt paket, vilket innebar att det arbete som lagts pa att utveckla ett eget protokollgjorts forgaves. Hade det varit klart fran borjan vad protokollet skulle klara av hade mycket arbetesparas. Om utvecklarna hade varit medvetna fran borjan om risken att forutsattningarna skullekomma att forandras, hade man kanske kunnat valja ett fardigt paket och sedan bygga ett egetnar man var sakra pa vad man ville ha. Da det marktes att det skulle ta mer tid an tankt attkonstruera ett eget protokoll an planerat, hade det varit mojligt att omvardera det designbeslutetoch pa sa satt spara tid.

I det tredje fallet, gallade measurehandler, var problemet att en utvecklare antog att systemetbehovde kunna lagra data fran flera matsessioner parallellt. I verkligheten kommer detta aldrigatt ske. Den modul utvecklaren arbetade pa blev darfor mer komplex an den behovde vara. Det-ta forsamrade prestandan marginellt, i vissa fall specialfall kasseras matvarden i onodan, menframforallt tog det onodigt mycket tid att implementera, testa och felsoka.

Hade vi anvant en mer strukturerad designbeslutsprocess hade dessa problem troligtvis inte upp-statt. Tanken med att ha en riktig process att folja ar just att upptacka problem med olikaalternativ. I de flesta kanda designbeslutsprocesser ingar det en fas dar man diskuterar beslutetmed hela gruppen och eftersom nagon sannolikt hade tagit upp till exempel att Plotly inte riktigtvar det vi letade efter sa hade en annan losning undersokts istallet.

Det ar inte enbart denna diskussionsfas som ar nodvandig for att forbattra processen. Bara idenmed att faktiskt folja en given process gor att beslutet sannolikt kommer vara battre.

6.2.2 Metod

Vi baserar vara resultat framforallt pa erfarenheter uppsamlade i efterhand. Vi hade kunnat haforbattrat designbeslutsprocessen under projektets gang for att utvardera vara slutsatser.

7 Slutsatser

I detta avsnitt sammanfattar vi vara resultat och analyserar dessa i ett vidare perspektiv.




7.1 Fragestallning 1

Vi kom fram till att det ar mojligt att ersatta kundens befintliga system med ett nytt, mindreoch billigare system. Mycket pa grund av att datorn Beaglebone Black har integrerade realtids-processorer som kan anvandas for att utfora matningar med hog upplosning och hog precisiontidsmassigt. Detta system utvecklades och implementerades med framgang under projektets gang.

7.2 Fragestallning 2

Det ar tydligt enligt oss att det gar att forbattra var designbeslutsprocess. Detta skulle vara mojligtgenom att folja en gedigen process vid varje beslut som ska tas. Det ar hogst sannolikt att mangaav vara problem som vi stott pa under projektet skulle kunna ha undvikits om vi hade en brametod for att ta beslut.

7.3 Arbetet i ett vidare sammanhang

Nedan analyseras arbetet i ett vidare sammanhang.

7.3.1 Etiska och samhalleliga aspekter

Vi har inte funnit nagra varken etiska eller samhalleliga problem med det vi har utvecklat. Vi arovertygade om att det vi har kommit fram till bidrar till ett battre samhalle.

Ett hogst otroligt extremfall, skulle vara om vart system anvands for att overvaka manniskor. Mankan undersoka fororeningar i vatten i manniskors narhet och koppla amnen i vattnet till specifikalivsstilar eller beteenden.

7.3.2 Miljoaspekter

Vi bidrar till att fler datorer kan placeras i naturen och eftersom de ar billigare okar risken for attman glommer eller forsummar dem till den grad att de blir liggande i nagot vattendrag nagonstans.

A andra sidan kan det paverka miljon mycket positivt. Det blir enklare och billigare att upptackavattenfororeningar, vilket kan bidra till en renare miljo. Potentiellt kan det hjalpa till att kartlaggaforeringar av andra slag och gora det enklare att sanera dessa.

8 Fortsatt arbete

Att fortsatta arbeta pa produkten skulle inte vara nagot problem. Kunden ville redan fran borjanha ett storre system an vi kande vi skulle hinna med pa projekttiden, darfor finns det sedanpaborjad funktionalitet som skulle kunna vidareutvecklas.

8.1 Analys i matlab

Att utvardera matningar ar nagot kund eftertraktar. Detta gors for narvarande manuellt i mat-lab. Det finns en mojlighet att automatisera utvarderingsprocessen direkt i matenheten. Ommatklienten skulle kunna utvardera matningar medfor detta att extra funktionalitet for syste-met skulle kunna utvecklas.

8.2 Varningar i webbgranssnitt

Ett exempel pa extra funktionalitet ar ett varningssystem i webbgranssnittet. Detta varningssy-stem skulle kunna varna eller notifiera anvandare om uppkomna problem. Detta system skulleinte bara vara intressant for kund utan skulle i ett affarsperspektiv vara intressant for statliga




verk. Det skulle kunna anvandas for dricksvattensystem men ocksa i sjoar och aar for att se varfororeningar finns.

8.3 Systemet for konsumeter

Detta system skulle varit intressant for privatpersoner som har egen brunn. I en artikel publiceradi (Flera magsjuka av eget brunnsvatten, u. a.) kan vi lasa om privatpersoner som blivit sjuka pagrund av fororeningar i deras dricksvatten. Med detta system kunde detta undvikits.




A. Hugo - Analys av utvecklingsmetodik

A.1 Inledning

Utvecklingsmetoder ar intressanta eftersom det inte finns en bast bevisad utvecklingsmetod. Pro-jekt har anvant samma metod som gett olika resultat, men andra projekt har anvant olika metodersom gett samma resultat. Darfor kommer det tills en metod har bevisat sig vara bast, att varaintressant att fortsatta analysera projekt och dess utvecklingsmetod.

A.1.1 Syfte

Syftet ar att lara sig mer om olika utvecklingsmetodiker och vad de varderar. Att lara sig om vadsom skulle kunna gjorts battre med projektet Dricksvattenkvalitet. Att fa en djupare forstaelse avhur en kand utvecklingsmetodik skulle kunnat forandra projektet.

A.1.2 Fragestallning

• Vilka utvecklingsmetodiker finns det?

• Finns det delar i projektet som inte fungerat p.g.a att ingen formaliserad utvecklingsmetodikhar anvants?

• Skulle en annan utvecklingmetodik kunnat prestera battre i projektet?

A.1.3 Avgransningar

For att inte ga for djupt bland alla utvecklingsmetodiker, kommer jag att belysa fyra stycken.Delar i projektet som inte ska ha fungerat, ska vara punkter som finns i lista Falleringspunkter.Om en av dessa punkter inte uppfylls ar inte den delen av projektet uppfylld.

Falleringspunkter

• Krav

– Forstod alla gruppmedlemmar kraven?

– Upptog kraven hela projektet?

– Var kund och projektgrupp overrens om kraven?

– Omfattade kraven alla kundens mal?

• Kommunikation

– Fungerade kommunikationen gentemot kund?

– Fungerade kommunikationen i projektgruppen?

– Fungerade kommunikationen gentemot handledare?

– Fungerade moten?

• Kod

– Var koden forstaelig?

– Var koden strukturerad?

– Fanns det tillrackligt med dokumentation for att forsta koden?

• Process

– Har processen givit projektgruppen en chans att jobba obehindrat?

– Har processen gjort sa gruppmedlemmar vetat vad de ska gora?

– Har processen tillatit gruppmedlemmar att egna designbeslut?




A.2 Bakgrund

Projektgruppen specifierade aldrig en utvecklingsmetodik att anvanda under projektet. Istalletdelades gruppen in i mindre grupper dar varje grupp blev ansvarig for en modul i projektet. Hurvarje grupp arbetade pa sin modul lamnades till dem. Detta medforde att utvecklingsmetodikenblev en typ av iterativ pabyggnadsprocess for varje modul. Vi hade ocksa tre bestamda storreiterationspunkter fran kursen, under dessa utvarderade vi projektet enligt Semat Alpha(AlphaState Cards, u. a.).

A.3 Metod

Eftersom fragestallningarna ligger nara varandra i natur och kan ses som pabyggande, valde jagatt borja med att samla in olika utvecklingmetodiker. Dar efter analyserade jag projektet for atthitta punkter som inte uppfyllde falleringspunkterna. Nar detta var gjort jamnforde jag utveck-lingmetodikerna mot projektet, for att se om nagon skulle kunnat uppfylla falleringspunkternabattre.

A.3.1 Utvecklingsmetodiker

Jag sokte information via bloggar, bocker och vetenskapliga artiklar for att hitta olika utvecklings-metodiker. Jag tog fram information pa vad utvecklingsprocessen innebar och vad den vardesatte.

A.3.2 Analys av projektarbetet

For att ta reda pa vilka delar av projektet som inte fungerade, valde jag att gora en analys avprojektet. For att samla in data till analysen gjorde jag pa tva satt. Det forsta sattet var attskicka ut enkater, det andra var att samla data utifran olika dokument. Fran denna data drog jagslutsatser om punkterna ansags uppfyllda eller inte.

A.3.2.1 Enkat

Jag skickade ut tva enkater som kan hittas som bilaga F.1.1 och bilaga F.1.2. Den forsta enkatenskickades till kund for att se hur de tycker att krav och kommunikation har fungerat. Den andraenkaten var utforligare och riktad till projektgruppen, och tog upp fler fragor som t.ex processer,moten och kod.

A.3.2.2 Projekt dokument

Dokumenten jag har granskat har kommit fran det arbete gruppen har gjort under projektetsgang, daribland kravspecifikationen och motesprotokoll.

A.3.3 Vald utvecklingsmetodik

Det jag gjorde sist var att se pa de falleringspunkter projektet inte uppfyllt tillsammans medpunkter som uppgetts under enkaterna ’kunde varit battre’. Dessa punkter tillsammans utgjordegrunden for en vardematris dar de valda utvecklingsmetodikerna vardesattes. Om utvecklingsme-todiken hade som vardesattning att uppfylla den punkten fick punkten +1, om inte fick den 0.Den utvecklingsmetodik som hade hogst varde valdes som utvecklingsmetodik for projektet.

A.4 Resultat

I detta avsnitt beskrivs de valda utvecklingsmetodikerna och om den data som samlats in for attanalysera projektet.




A.4.1 Utvecklingsmetodiker

De fyra utvecklingsmetodiker som jag valt beskrivs kortfattat med en punktlista pa slutet, darbenamner jag saker de satter extra varde pa.

A.4.1.1 Vattenfallsmodellen

Vattenfallsmodellen ar en av de enklaste modellerna. Det bygger pa att steg for steg ga igenomett bestamt antal aktiviteter(Awad, 2005). Varje steg gors en gang och du gar som ett ’vattenfall’nedat i stegen. Stegen varierar fran kalla till kalla oftast kan stegen defineras som ’Vad? Hur?Implementation, testning och Leverans/dokumentation’. Figur 15 illustrerar dessa steg. Att vat-tenfallsmodellen inte tillater ”tillbaka vandring” gor det kostsamt att ga tillbaka i stegen. Atttestningen ligger sist kan ocksa gora att det inte ar helt ovanligt att man maste ga tillbaka iprocessen(Valueatwork - Vattenfallsmetodiken en kostsam myt , 2013).Varde for vattenfallsmodellen ar

• Allt gors en gang under projektet

• Planera hela projektet i borjan av projektet

• Samlar in alla krav i borjan av projektet

• Lagger mycket fokus pa dokumentation i borjan av projektet

Figur 15 – Illustration over vattenfallsmodel-lens steg.

Figur 16 – Illustration over hur pri-oriteringar for tid kan vara underett UP projekt. Bilden ar tagen franhttp://guide.agilealliance.org/guide/daily.html

A.4.1.2 Unified Process (UP)

UP ar en ’iterativ and incremental’ metodik som bygger pa att du itererar over ett antal stegvarje iteration. For varje iteration bygger du pa det du redan gjort (eller andrar) for att till slutgora en fardig produkt. Att du gor samma steg varje iteration betyder dock inte att iterationer-na ser likadana ut. Utan oftast lagger du olika mycket tid pa de olika stegen beroende pa vari projektet du ar(Awad, 2005). Det ar har ifran de fyra faserna for UP kommer ifran (’Incep-tion’,’Elaboration’,’Construktion’,’Transition’). Dessa fyra faser och hur antagandet om tid skalaggas kan ses i bild 16.Att varje projektmedlem far en specifik roll som den forvantas utfora gor att modellen inte ar saflexibel och att den kraver en viss kompetens(John Hunt, 2003). Att det finns ett antal steg attchecka av gor ocksa att den kan bli onodigt komplex och lampar sig darefter till storre, langvarigaprojekt.Varde for UP ar

• De fyra P:en (People, Project, Product, Process) (Slideshare - Unified Process, 2009)

• Use-case for funktionalitet(Best Practices of RUP , u. a.)

• Ateranvandning av moduler




• Verifiera testning och kvalitet

• UML-visualisering

• Kontrollerade andringar

A.4.1.3 Scrum

Scrum ar en agil, iterativ och uppbyggnadsmetodik. Scrum bygger pa iterationer kallade ’Sprints’som ar generellt 30 dagar. Varje sprint ska skapa eller bygga pa ett fungerande system, i slutetska ett nytt fungerande system vara producerat(Awad, 2005). For att halla reda pa vad som skagoras for systemet finns en ’scrum-backlog’ (Scrum alliance, u. a.) dar alla aktiviteter som skagoras over projektet finns. Nar en aktivitet blir vald att goras under en sprint flyttas den till’sprint backlog’ dar aktiviteter som ska goras under sprinten finns. Varje dag har man ett ’scrummeeting’ (aven Daily scrum)(Agilealliance - Daily meeting , u. a.) dar man gar igenom vad alla gjortsedan forra motet, vad alla planerat att gora tills nasta uppfoljning och om nagot har forhindratplaneringen.(Kim H. Pries and Jon M. Quigley, 2011).Varde for scrum ar

• Agila manifestet (Agila manifestet , u. a.)

• Oppenhet - En av de viktigaste sakerna ar att vara oppen om projektets status.

• Fokus - Jobba bara pa fa saker at gangen, darfor levererars vardeful funktionalitet tidigare.

• ’Dagliga moten’

• ’Sprint backlog’

• ’Scrum backlog’

A.4.1.4 eXtreme Programming (XP)

XP bygger pa att ta sina karnkvaliteter till det extrema (darav namnet)(Awad, 2005). XP byggerpa korta iterationer, oftast nagra veckor och som mest 5-6 veckor (Ahmed, 2012). For att planeraen iteration gors ett sa kallad ’planning-game’ dar en metaphor (en overrenskommen metaphormellan kund och utvecklare som beskriver en funktionalitet) oftast ar i centrum for funktionalitetensom ska implementeras. Test-driven programmering star i fokus nar man utvecklar, och ofta skriverman testfallen innan koden. Varje iteration avslutas med att produkten visas for kund. Om kundenhar invandningar rattas dessa till innan nasta iteration borjar.Varde for XP ar

• Daily stand-up(Agilealliance - Daily meeting , u. a.)

• Agila manifestet (Agila manifestet , u. a.)

• Pair-programming

• Collective ownership

• Test-driven programmering

• Enklaste designen ar den ratta designen

• Planering med kund

A.4.2 Analys

Har gar jag igenom insamlad data som anvands i analysen.




A.4.2.1 Enkater

Pa den enkat som skickades till vara tre kunder fick jag tva svar och pa enkaten till grupp vardet fyra av fem gruppmedlemmar som svarade. Svaren kommer sammanfattas under kapitel A.5.1och kan hittas som bilaga F.1.3 och bilaga F.1.4.

A.4.2.2 Krav

Jag gick igenom kraven som finns i kravspecifikationen for att se hur manga och hur spriddakraven var over projektet, denna data anvands sen i analysen om punkterna ”krav” i fallerinslistan. Diagram 17 visar resultatet over hur manga, och till vilken del de olika kraven tillhorde.

Figur 17 – Diagram over kravspecifikaitonen

A.4.2.3 Kommunikation

Data pa de olika kommunikationsmedierna som anvants under projektets gang samlade jag ocksain. Denna data kommer ocksa anvandas analysen. Vi har under projektets loptid haft fyra styckenkommunikationsmedel.

• Mail (Hela projektet loptid)

• SMS-grupp (20 jan 2015 - 10 maj 2015)

• Skype (11 mars 2015 - 10 maj 2015)

• Facebook grupp (25 april 2015 - 10 maj 2015)

Mail har inte anvands internt inom gruppen utan mest gentemot handledare och kund. Da jaginte har haft tillgang till alla mail, har jag valt att utesluta dessa ur statistiken nedan.All kommunikation inom mediet ar registrerat ifran det datum mediet borjade anvandas inomgruppen till den 10 maj. Diagram 18 visar antalet kommunikationer i mediet, antal dagar, samtkommunikationer per dag for varje medium.




Figur 18 – Till vanster diagram over antalet kommunikationer och till hoger antalet dagar ochkommunikation per dag.

Totalt ger detta 1738 kommunikationer mellan gruppen. Raknar man med fem dagars veckorperioden 2:e februari - 10:e maj blir det 70 dagar, vilket ger ca 25 kommunikationer per dag.Nedan i diagram 19 visas tva diagram pa antalet officiella motesprotokoll dokumenterade inomprojektet mellan 1:a feb och 10:e maj.

Figur 19 – Diagram over moten och antalet moten i varje manad.

Det har varit ca sex stycken moten per manad, utover detta har det ocksa varit inofficiella moten.Dessa moten ar dock inte dokumenterade och darfor inte medtagen i statistiken.

A.4.2.4 Analysens resultat

Eftersom analysen inte gar att gora helt objektiv har jag valt att ta upp den som en diskuterandedel (avsnitt A.5.1). Resultatet blev att projektet inte uppfyllt kommunikation, kod och processpunkterna.Extreme programming visade sig enligt vardematris i kapitel A.5.2 lamplig for att uppfylla falle-ringspunkterna.

A.5 Diskussion

Har diskuterar jag de metoder jag har anvant och de resultat jag kommit fram till.




A.5.1 Analys av projektet

For att bestamma fragan om hurvida projektet uppfyllt alla punkter, behovdes en subjektivbedomning pa enkater och annan data goras. Darfor har jag valt att ta upp deras sammafattaderesultat har. Vissa fragor besvarades inte av alla deltagare och procenten avser den del som svarat.

A.5.1.1 Krav

• Kund

– Kunderna tyckte att onskningar och krav upptogs under kravhamtning.

– Kunderna tyckte de fick vara med och prioritera kraven.

– Kunderna upptackte nya krav under processens gang och kande att de nya kraven lagtstill vid behov.

– Kunderna kande att alla vitala krav blev tillagda.

• Grupp

– Gruppen forstod alla krav som upptogs.

– Gruppen tyckte kraven speglade kundens bild.

– 75% av gruppen kande att alla krav fanns med.

– Gruppen kande inte att nagot krav fran kund missades.

– Gruppen tyckte kravinhamtningsprocessen gick bra, och att alla krav upphamtades itid.

Sammanfattning fran grupp och kund var att punkterna har uppfyllts, tillsammans med de 48kraven fran datan insamlad om krav (avsnitt A.4.2.2) finner jag att punkterna blev uppfyllda.Detta da kraven var spridda over hela projektet och svaren pa enkaterna sammanfattades somuppfyllt.

A.5.1.2 Kommunikation

• Kund

– Kunderna tyckte att kommunikationen fungerade.

– 50% tyckte att de haft lagom mycket kommunikation, 50% hade velat ha ytterligarekommunkation.

– 50% tyckte att de haft lagom inblandning i projektet och 50% hade velat ha lite merinblandning.

• Grupp

– Gruppen tyckte kommunikationen mot organisation fungerade.

– 50% tyckte att kommunikationen fungerade mot kund, 50% var osakra.

– 25% ville inte jobba narmare kund, 75% hade ingen asikt.

– 25% tycker att kommunikationen i gruppen fungerade, 50% tyckte det inte och 25%hade ingen asikt.

– 75% tyckte att moten fungerade, 25% tyckte det inte.

– 50% tyckte att gruppensmedlemmar oftast kom till motena och oftast var engagerade.

– 50% tyckte att gruppmedlemmar ibland kom till motena och ibland engagerade sig.

– 25% tyckte att en tydlig struktur fanns pa motena, 75% tyckte det inte.

– 75% sag det som ett problem att det inte fanns struktur pa motena.




Som svar pa varfor kommunikationen inte fungerade fick jag foljande sammanfattning:

• Beslut om kommunikationsmedium var inte tillrackligt tydlig och mediumet anvandes inte itillracklig utstrackning.

• Gruppmedlemmar uppgav inte orsak och meddelade inte nar de uteblev fran bestamdamoten.

• Kommunikationsmediumet var inte det anda problemet, utan att starta en diskussion ombeslut aven pa motena, fungerade ej.

Insamlad data pa kommunikation utvarderades ocksa (avsnitt A.4.2.3).Enligt ovanstaende upptacker man att det varit problem, med en otydliga utvecklingsprocess kanman anta att mer an ca ett mote i veckan hade behovts. Eftersom det inte var mer an drygt ettmote medfor detta att ca 25 kommunikationer per dag inte ar tillrackligt da det finns studier somhar snittat ca 25 kommunikationer per utvecklare(Perry, Staudenmayer & Lawrence G. Votta,1994). Detta ser vi ocksa i svaren fran enkaten for grupp. Kommunikation mot kund och handle-dare har varit battre, men kunde varit mer.Jag tycker inte detta uppfyller falleringskraven for kommunikation. Punkten moten och kommu-nikation inom grupp fallerar darfor och uppfylls ej.

A.5.1.3 Kod

Enkat for gruppen detta resultat:

• Gruppen tyckte att koden var forstaelig.

• 50% tyckte koden var strukturerad, 50% tyckte det inte.

• 25% uppfattade att det varit problem med ostrukturerad kod.

• 75% tyckte att tillracklig dokumentation skrevs, 25% tyckte det inte.

Det finns gruppmedlemmar som tyckte att en hardare struktur hade behovts och sag detta somett problem. Gruppmedlemmar har ocksa tyckt att mer dokumentation hade behovts for att forsakoden. Med dessa tva punkter ej uppfyllda, fallerar punkten kod.

A.5.1.4 Process

Enkat for grupp gav detta resultat:

• 75% tyckte processen fungerade, 25% tyckte det inte.

• 50% tyckte processen var tydlig och strukturerad, 50% tyckte det inte.

• 50% tyckte att det var ett problem att processen inte var tydlig nog och tillrackligt struktu-rerad, 50% tyckte det inte.

• 75% tyckte att de visste vad de skulle gora, 25% tyckte det inte.

• 33% tyckte det paverkade dem positivt att de inte visste vad de skulle gora, 67% tyckte detvar negativt.

• 75% kande att de visste vad andra gjorde, 25% kande det inte.

• 50% tyckte att det paverkade dem negativt att de inte visste vad andra gjorde, 50% tyckteinte att det spelat nagon roll.

• 75% tyckte designbeslut togs och fungerade. 25% valde att inte svara.

Det fanns gruppmedlemmar som inte visste vad de skulle gora. Detta paverkade negativt genomatt gruppmedlemmar inte kunde jobba obehindrat. Eftersom punkter inte ar uppfyllda blir intepunkten ”process” i analysen uppfylld.




A.5.1.5 Fallerande punkter

Projektet har fallerat pa tre stallen. De tre fallerande stallena ar kommunikation, kod och process.Det hade behovts mer kommunikation, och battre kommunikation inom gruppen. Koden skullevarit mer strukturerad med utforligare dokumentation. Processen skulle gjort det tydligare vadfolk skulle gora, och vad andra arbetade med.

A.5.2 Vardematris

De tre fallerade kategorierna kan sammanfattas till ett antal punkter, uppfylls dessa punkteruppfylls ’falleringslistan’.

• Kommunikation i gruppen

• Struktur over vad gruppen gor

• Struktur over vad gruppen ska gora

• Struktur i koden

• Ytterligare dokumentation

Enkaterna tog ocksa upp ett antal punkter som inte handlade om falleringspunkterna. Dessa kanocksa vara intressanta att titta pa.

• Motes struktur (grupp enkat)

• Motes narvaro (grupp enkat)

• Lata kunden arbeta narmare gruppen (kund enkat)

• Mer tid till testning (grupp enkat)

• Mer tid till kvalitet pa kod (grupp enkat)

• Mer oppenhet over statusen (kund enkat)

Jag gjorde en vardematris over dessa punkter, for att se vilken utvecklingsmetodik som fick hogstvarde i sina varderingar.

Vattenfalls. UP Scrum XPMer kommunikation 0 0 1 1Struktur att gora 1 1 1 1Struktur andra gor 0 0 1 1Strukturerad kod 0 1 0 1Dokumentation kod 1 1 0 0Motesstruktur 0 0 1 1Narmare kundkontakt 0 1 1 1Fokus testning 0 1 0 1Fokus kvalitet 0 1 0 0Oppenhet 0 0 1 1Summa 2 6 6 8

Tabell 4 – Vardematris.

Tabell 4 ar resultatet av vardematrisen. Punktlistan nedan forklarar valet for varje punkt.

• Mer kommunikation - Scrum och XP vardesatter ”dagliga moten”.




• Struktur att gora - Alla definerar tydligt vad som ska goras, aven om detta kan ske vid olikatillfallen.

• Struktur vad andra gor - Scrum och XP vardesatter ”dagliga moten” dar gruppmedlemmarrapportrar vad de gor och planerar att gora.

• Strukturerad kod - UP satter vikt pa kvalitet och XP ser ’refactoring’ som viktigt.

• Dokumentkod - I ’heavyweight’-metodiker ar dokumentationen en stor del i den tidiga pro-cessen.

• Motesstruktur - Scrum och XP vardesatter ’dagliga moten’ med en bestamd struktur.

• Narmare kundkontakt - UP och agila metoder vardesatter kund under hela projektet ochlater kund vara med och bestamma.

• Fokus testing - UP och XP vill tidigt verifiera testning.

• Fokus kvalitet - UP har som varde att verifera kvalitet och testning.

• Oppenhet - ’Agila manifestet’ uppmanar transparens mellan kund och arbetsgrupp.

Med denna vardematris satts XP som den med mest troliga att uppfylla dessa vardesattningar.

A.5.3 Vald utvecklingsmetod

Extreme programming var den utvecklingsmetod som hade storst overlapp av vardesattningar ochforbattringsbara punkter. XP blir darfor mitt val for den utvecklingsmetodik som skulle gett ettbattre arbetssatt for projektet.

A.5.4 Resultat

Av de utvecklingsmetoder jag tar upp, ar tva Heavy-weight och tva stycken agila(Awad, 2005).Detta gor att de inte ar helt lika i varderingar, dock tror jag att man skulle kunna fa en annubattre spridning. Det finns sa manga utvecklingsmetoder och olika varianter av dessa, att jag trordet viktigaste inte ar vilken du valjer utan varfor du valjer den. Detta innebar att varderingarnafor utvecklingsmetoderna ar det viktigaste, och jag anser man ska valja efter de som ar viktigastfor projektet.

Jag anser punkter som fallerade ar val motiverade med bade data ifran projektet och gruppmed-lemmar. Detta ar givetvis min subjektiva bedomning den kan vara extra paverkad av att jag sjalvvar med i projektet . Det gar inte heller att aterskapa resultatet, eftersom hur manniskor uppfattarsaker inte gar att gora om.

Varderingsmatrisen ar det resultat som ar mest subjektivt. Jag tror alla fyra utvecklingsmetoderhade presterat bra for projektet, och med nastan samma resultat. Att XP fick sa hogt varde trorjag beror pa att kund sattes i ett stort fokus med att vara mer involverad. Om involveringen forkommentarer och webbgranssnitt hade lagts under krav uppsamlingen hade t.ex. vattenfallsmo-dellen fungerat lika bra.

A.5.5 Metod

For att hitta utvecklingsmetoder kravde jag flera olika kallor. Det fanns dock ingen bestamdspridning eller pa vad som skulle presenteras ifran varje utvecklingsmetod. Detta gav mig mycketspelrum och kan leda till ett felaktigt resultat.




Vad projektet fallerat pa ar punkter som jag fann viktiga, och punkter som manga utvecklingsme-toder efterstravar att losa. Detta betyder dock inte att alla punkter fanns med. Det betyder inteheller att de paverkar projekt lika mycket.

Vardematrisen ar ocksa en vardesattning pa saker som projektmedlemmar och kund inte tycktefungerade eller kunde varit battre. Har kan en riktigt skev bild av verkligheten inverka. Om enutvecklingsmetod fokuserar pa punkter som redan fungerade eller inte var med pa denna lista, farden ett valdigt lagt varde nar den sakert hade fungerat bra i praktiken.

A.6 Slutsatser

Syftet var att fa en djupare forstaelse for utvecklingsmetoder. Fyra stycken utvecklingsmetoder harlyfts fram, Vattenfallsmodellen, Unified process, Scrum och eXtreme Programming. Forstaelsen fordessa har kanske inte blivit battre, men de fyra svarar pa fragestallningen om vilka som finns. Attutvecklingsmetoder vardesatter olika saker for att uppna vissa mal blir ocksa tydligt. Projektethar ocksa brutits ned for att svara pa vilka punkter som gatt snett, en klar bild har malatsupp av vilka problem som uppstatt. Kommunikation, kod, moten och diverse processer har inteuppfyllt standarden som satts. Detta ar svaret pa fragestallningen och det sager ocksa vad somskulle kunnat vara battre med projektet. Om en av de ovannamnda utvecklingsmetoderna skullepresterat battre kan jag inte utlasa. Jag har dar emot antagit att eftersom XP gav ett bra varde ivardematrisen, att den antagligen skulle kunna gora det. Dessa analyser och diskussioner hoppasjag kan hjalpa andra inom bade programvaru- och annan utveckling som gors i projekt. Att lasaom vilka punkter varat projekt inte klarade av att uppfylla, och vilken utvecklingsmetod somskulle kunna hjalpa till med detta.




B. Rasmus - Node.js

B.1 Inledning

Webbapplikationer blir allt mer avancerade och far flera anvandare fran olika plattformer. Detracker inte langre att leverera en statiska sida utan applikationer ska vara datadrivna och datanska skickas ofta och fort. Det stalls hoga krav pa servrar och valet av utvecklingsplattform for attskapa en produkt for nutiden och framtidens behov.(Paulson, 2005)

Parallellt med serverutvecklingen vaxer den eventdrivna modellen fram som ett alternativ till denklassiska ”en trad/process per anslutning”, dar utvecklingverktyg sasom Node.js, Python och Ru-by on Rails blir ett allt mer populart val.

Denna rapport behandlar Node.js dar praktiska erfarenheter och kunskaper hamtas fran blandannat projektet Dricksvatten som genomfordes under varen 2015. I projeketet anvandes utveck-lingsverktyget Node.js for serverutveckling. Node.js ar ett verktyg som det senaste aren vaxt(Node.js is taking over the Enterprise – whether you like it or not , u. a.) och etablerade foretagsasom Micrsoft, Uber och Ebay anvander Node.js for diverse projekt. (Companies using Node.js,u. a.)

B.1.1 Syfte

Syftet med rapporten ar att undersoka Node.js samt forklara varfor det har blivit ett populartalternativ samt vilka for-/nackdelar det finns med att anvanda Node.js.

B.1.2 Fragestallning

• Varfor har Node.js blivit populart inom severprogrammering?

• Vilka for-/nackdelar finns det med att anvanda Node.js?

B.1.3 Metod

Att besvara fragestallningen kraver att ett antal faktorer analyseras och vags mot varandra for attna en slutsats. Genom litteraturstudier och vetenskapliga rapporter utreds tekniska aspekter avfragestallningen. Med enkater mot anvandare som anvant sig av Node.js besvaras fragestallningenutifran faktorer sasom kodlaslighet, svarighetgrad och larningskurva.

Enkaten ar uppdelade i ett antal fragor som skickades via email till varje deltagare for att de skaha gott om tid att formulera sina svar. Praktiska kunskaper och erfarenheter hamtades aven franprojetktet Dricksvatten som genomfordes parallellt med skrivandet av denna rapport. Las mer omenkaten (http://goo.gl/forms/LxSN5Q1Piy).

B.1.4 Avgransningar

Rapporten beskriver fragestallningen med fokus kring webbservrar, aven om Node.js kan anvandasfor att implementera godtycklig funktionalitet (FTP, SMTP och sa vidare).

Att undersoka fragestallnigarna kraver att ett flertal faktorer analyseras for en fullstandig analyskan utforas. Pa grund av rapportens omfattning finns inte tid att analysera alla faktorer ochistallet fokuserar rapporten pa ett fixt antal faktorer som paverkar fragestallningen (se mer omdetta i resultatkapitlet).




B.2 Teori

Den 6 augusti 1991 publiserade Berners-Lee - en anstalld pa CERN – en kort summering overprojekt World Wide Web till nyhetsgruppen alt.hypertext.(About Berners Lee, u. a.) Detta kallasofta for webbens startskott och antalet anvandare har sedan dess vaxt exponentiellt till flerahundratals miljoner anvandare. Under 2012 hade Microsofts webbtjanster over 300 miljoner traffaroch 4.1 miljoner unika anvandare under en dag. (“Microsoft market share”, u. a.) Att hantera denvaxande efterfragan staller hoga krav pa servrar. Serverar ska levera data till manga anvandare ochdetta ska ske: ofta, utan langa fordrojningar och mojligheten att hantera tusentals anslutningarsamtidigt. For att mojligora detta, kravs det en bra korrelation mellan hardvara och tekniskalosningar.

B.2.0.1 Server-klient arkitetkur

Webbservrar anvander en server-klient struktur dar klienter ar exempelvis mobilapplikationer elleren webblasare medan servern bidrar med en service sasom email, fildelsningssytem eller en http-server. Server-klient arktitekturen delas in i tre olika lager; presentation, logik och data. Dessalager struktureras ofta upp pa tre olika satt: (Client server architecture, u. a.)

• Forsta nivans arkitkektur - 1-Tier Architecture - alla tre lager placeras pa samma maskin.(1-tier architecture, u. a.)

• Andra nivans arkitektur - 2-Tier Architecture - Presentation och logik ar en del av klienten,medan datalogiken tillhor servern.(2-tier architecture, u. a.)

• Tredje nivans arkitektur - 3-tier Architecture - presentation ar en del av klienten. Logiksamt kommunikation med en databasserver tillhor servern. Alla tre lagren ar frankoppladevarandra och kan potentiellt placeras i olika maskiner.(N-tier architecture, u. a.)

Vid webbutveckling anvands ofta tredje nivans arkitektur som har fordelar vid exempelvis skal-barhet, snabb exekveringstid och sakerhet. For denna rapport ar logiken den intressanta delen.Logiklagret hanterar bland annat berakningar, dirigering samt anvandarkontroller. Implementa-tion av logiklagret foljer ofta ett utav tva huvudkoncept (eventuellt en mix av bada). Dessa ar ”entrad/process per anslutning”eller den ”eventdrivna modellen”.

B.2.0.2 En trad/process per anslutning

Ar 1996 utvecklades den forsta http servern – CERN http - som levererade statiska sidor tillanslutna klienter. Huvudkoncept ar att varje inkommande anslutning kopplas till en dedikeradprocess. Detta skapar en naturlig logik for programmeraren och I/O operationer implementerasofta blockerande, dar det underliggande operativsysstemet hanterar context switching mellan pro-cesserna. Nar nya och forbattrade tradbibliotek dok upp, kunde varje anslutning kopplas med entrad istallet. Detta gav ett antal fordelar gentemot processer, sasom: snabbare context switch,mindre minnesanvandning och delat minne mellan tradarna for caching. (Jiantao Zhao & LiujieQin, 2014)

Apache Multi-Processing Modules (Apache MPM , u. a.) ar ett exempel pa en servermodell somanvander sig av en pool av tradar som ar kopplade till en specifikt process. Nar en inkommandeanslutning skapas, tas den emot av en acceptor thread som hanterar den initiala kommunikationfor att sen tilldela anslutningen en egen trad.




Figur 20 – Tradad servermodelll

B.2.0.3 Eventdrivna modellen

I den eventdrivna modellen finns det en trad som hanterar I/O operationer fran de inkommandeanslutningar. De nya I/O operationerna placeras i en eventko som hanterar handelserna eller vantarpa att nya handelser ska anlanda. Funktionaliteten av en eventtrad efterliknas en schemalaggare,som istallet hanterar tradar samt procceser och tillforser dem med systemresurser.

Figur 21 – Eventdriven modell

Nar en anslutning registerar exempelvis en fillasning, placeras denna som beskrivet ovan i eneventko. Nar handelsen sedan hanteras maste den returnerade datan fran fillasningen bearbetas.Antingen skapas en eventhanterare for specifika event eller sa definieras en callback. Callback aren funktion som definieras i forvag for den asynkrona metoden, som sedan anropas efterat. Inomprojektet Dricksvatten anvandes callbacks for att processera informationen fran eventtraden, dessakan se ut som figuren nedan: (Jiantao Zhao & Liujie Qin, 2014)

Figur 22 – Callbacks i Node.js

B.2.0.4 Node.js

Node.js ar ett eventdrivet ramverk for att bygga skalbara natvarksapplikationer. Node.js anvandersig av skriptspraket Javascript som mestadels anvands for att utveckla webbsidor. Specifikt anvandsV8 som ar en opensource motor utvecklad av Google till webblasaren Chrome. Node.js ar en en-kelkarnig process som hanterar alla klienter och I/O operationer i en eventloop. (About Node.js,




u. a.)

Till Node.js finns en pakethanterar vid namnet npm for att hantera tredjeparts bibliotek. Istalletfor att behova hantera tredjepartsfiler lokalt och ladda hem dessa, sa kan biblioteken direkt laddashem genom att specifiera: npm install module namnet. Vilka bibliotek man valjer att inkluderasparas i en json-fil, detta innebar att endast json-filen behovs for att dela med sig av projektet.Genom att sedan skriva npm install installerar npm alla de biblioteken specifierade i json-filen.Det finns i nulaget over 15000 bibliotek i npms databaser (About npm, u. a.).

B.3 Resultat

Nedan beskrivs resultat av olika faktorer som paverkar fragestallningarna.

B.3.0.5 Prestandatester

Nedan beskrivs resultatet av tva prestandatester.

B.3.0.5.1 Test mot populara alternativ I Performance Comparison and Evaluation of WebDevelopment Technologies in PHP, Python and Node.js utfordes prestandatester dar eventdrivnaspraket Node.js jamfors med tva populara serversprak, PHP och Python-Web. Testet utfors mel-lan tva datorer, dar ena datorn agerade server och den andra klient/er. Testet utfors med 10 till1000 uppkopplade klienter.

Testerna visar att Node.js overtraffar bade PHP och Python-Web vad galler prestandatesting ochscenariotesting. Specifikt vid responstester visas att Node.js ar upp till 2 ganger snabbare an PHPoch 6 ganger snabbare an Python-Web. Aven nar antalet anslutna klienter okas sa behaller Node.jsen stabil responstid som varierar minimalt.

Testerna visar att tunga berakningar okar responstiden, vilket enligt rapporten tyder pa att Node.jsinte ar byggt for att anpassa sig efter berakningstunga applikationer. Istallet beskriver rapportenatt de laga och nastintill oforandrade responstiderna vid responstester och I/O operationer tyderpa att Node.js ar mer gjord for dessa typer av operationer.(Kai Lei m. fl., 2014)

B.3.0.5.2 Test mot Apache och liknande eventsystemet EventMachine I Node.js Pa-radigms and Benchmarks genomfordes tester med Node.js mot Apache och EventMachine. Undertestets gang varierade antalet sammakopplade klienter mellan 1000 ochl 1000000. Testest visar attNode.js utpresterade sina konkurrenter nar antalet vid lagdataoverforing med manga uppkoppla-de klienter. Testet visar aven att vid ett farre antal klienter presterade systemen likadant, menda antalet anvandare okades markant var det endast Node.js som visade respons.(Robert RyanMcCune, 2011)

B.3.0.6 Kodstruktur

Node.js anvander sig av asynkrona callbacks som beskrivet i figur 3. Majoriteten av deltagarna ienkatundersokningen tyckte att hanteringen av asynkroniska metoder var annorlundare gentemotdet sekvensiella tanket, vilket gjorde att inlarningskurvan blev langre.

B.3.0.7 Pakethanterare

Enkatundersokningen visar att majoriteten tyckte att pakethanteraren npm hanterade tredjepartsbibliotek pa ett bra satt. Det uppskattades att npm hanterar nedladdning, sparandet och filstruk-turen.




B.3.0.8 Sakerhet

I Assessing the Security of Node.js Platform undersoks Node.js plattformen ur ett sakerhetsperspektivdar ett antal sakerhetshal undersoks. Eftersom Node.js kors pa en singeltradad event loop, kantraden blockeras med processering av stora datamangder eller logiska server fel. Dessa fel kan ivarsta fall avstanna servern helt da exempelvis ett funktionsanrop fastnar i en oandlig loop, vilketi sin tur betyder att server slutar vara responsiv for de andra anslutna klienterna.

Javascript ar ett skriptsprak som lange anvants for webbutveckling dar det inte handlat om attkora langa processer utan att varje skript lankas till en specifik webbsida. Om det uppstar pro-blem i skriptet kan anvandaren ladda om sidan for att kora koden igen. Denna funktionalitet arinte onskvard vid utveckling av servrar utan istallet ska processer koras lange och idealt aldrigbehova laddas om. Att ladda om servern skulle innebara att hela systemet blir icke funktionelltoch anslutna klienter behover vanta pa att servern startat om.

Felhantering i Node.js ar lamnade at anvandaren och ar ofta en valfri parameter att definiera i sinacallbacks. Detta medgor att utvecklaren maste alltid hantera och definiera felen for att undvikamojliga krasher.(Andres Ojamaa & Karl Duuna, 2012)

B.3.0.9 Larande

Enkatundersokningen visar att majoriteten tyckte att det fanns mycket material kring Node.js,men att den korrekta information inte alltid var enkel att hitta.

Enkaten visade att Javascript gjorde inlarningen gick snabbare och upplevdes som nagontingpositivt. Samtidigt uppfattades Javascript av vissa som ett problem med bland annat asynkronacallbacks och daligt stod for objekt och klasser.

B.4 Diskussion

Node.js har vaxt och blivit mer populart beroende pa ett fletal faktorer dar bland annat prestan-datester visar att den utpresterar vanliga alternativ sasom PHP och Python-Web vid smaskaligaanvandartester. Aven i tester gentemot liknande eventbaserade system visar det sig att Node.jsutpresterar, speciellt nar server belastas med ett storre antal samman kopplade klienter. Forutomprestandatester har populariteten vaxt pa grund av att Node.js innehaller en bra fungerande pa-kethanterar for att hantera tredjeparts bibliotek. Aven anvandandet av Javascript, vilket ar ettfamiljart skriptsprak gor utvecklandet enklare att komma igang med.

Det finns aven nackdelar med Node.js som visas i enkaten dar manga anser att asynkrona funk-tionsanrop (se figur 3) inte alltid kanns naturligt. Det kan bli komplicerat att folja en kodstrukturdar ett antal asynkrona funktionsanrop gors tillsammans. Koden kan latt bli nastlad och kodmo-dulariteten forsamras, som visas i figuren nedan.

Figur 23 – Nastlade funktionsanrop




Det finns hjalpmoduler som kan installeras i npm som loser dessa problem, exempelvis kan bibli-oteket async anvandas for att undvika nastlade funktioner.

Figur 24 – Nastlade funktionsanrop

Det ar inte alltid sjalvklart vilka bibliotek som ska anvandas, om biblioteken ar stabila eller ombiblioteken uppnar den sakerhetsstandard som applikation har. Detta ar ett problem i sig, darJavascriptmotorn var fran grunden tankt att skapa dynamiskt innehall for webbsidor och ar inteanpassade for serversidan.(Questions with Creator Ryan Dahl , u. a.)

Vid besvarandet av fragestallningen anvandes litteraturstudier av vetenskapliga artiklar, nyhe-ter och intervjuartiklar for att forma en asikt och bakgrund kring Node.js. Dessa kallor kannstrovardiga och faktamassigt ratt, samt att de dubbelkollades mot andra kallor.

Nar prestandatester utfors som i kapitel 3.0.5 blir det alltid svart att utfora rattvisa tester daralla delar av ett serverssprak visas upp. Det viktigaste ar att testet visar hur Node.js presterargentemot andra populara altenativ nar det galler exempelvis tunga I/O-operationer och selectoperationer i databaser. Da I/O-operationer och select operationer ar fundamentala och mycketvanliga transaktion mellan klient och server, speciellt nar webbutveckling skiftar allt mer mot endatadriven arkitektur.(Kai Lei m. fl., 2014) Det tva testerna som utfordes i Node.js Paradigms andBenchmarks samt Performance Comparison and Evaluation of Web Development Technologies inPHP, Python and Node.js visade hog insikt av testmiljoerna och valet av tester var val motiveradefor det som skulle testas.

Enkatundersokningen fyller fuktionalitet i att bilda en asikt over faktorer som inte ar lika tekniskasasom kodstruktur och inlarning. Majoriteten av deltagarna i enkaten var studenter som har hafterfarenhet i att programmera i Node.js, detta innebar att enkaten inte tacker in alla omraden,aven om svaren ofta holl sig till normen av vad som tycktes var bra och samre med Node.js.

B.5 Slutsatser

For att besvara fragestallningen om varfor Node.js har blivit populart sa maste ett flertal faktoreranalyseras. I resultatdelen visar prestandatesterna att Node.js utpresterar serveralternativen PHPoch Python-Web. Att Node.js presterar bra i tester ar en viktig faktorer till att populariteten vaxt.




Enkatundersokningen visar att mycket information och kodexempel paverkade inlarningen posi-tivt. Aven att Javascript anvandes som sprak gjorde att inlarningen blev mer familjar och att detvar enklare att komma igang med kodande.

Resultat visade att callbacks funktionalitet kandes frammande, speciellt om man kommer fran ettprogrammeringstank dar ett sekvensiellt tank ar mer naturligt. Aven att Javascript inte har brastod for klasser och objekt gor det svarare att utfora specifika uppgifter.




C. Fredrik - Kvalitetsplan

C.1 Inledning

Jag borjade mitt arbete i detta projekt som kvalitetssamordnare, dock sa hoppade en medlem avi mitten av projektet och da forsvann aven var gruppledare, en roll som jag nu har tagit over.Jag har darfor valt att fordjupa mig i min roll som gruppledare och kvalitetssamordnare for attse om anvanda en Team Risk Management vore en bra metod att anvanda i detta kandidatprojekt.

Eftersom vi har stott pa ett par problem som skulle kunna hanterats pa ett battre satt tankte jagaven undersoka om det finns ett bra satt att hantera risker med en riktig riskhanteringmetod. Nagrafragor som jag soker svar pa. Hur forbereder man sig pa oplanerade risker? Det gar sannolikt attforebereda sig for alla mojliga risker, men ar det konstruktivt att gora det? Var drar man gransentill vad som faktiskt ar effektivt och konstruktivt?

C.1.1 Syfte

Syftet med denna rapport ar att ta reda pa om det gar att forebereda sig for outforsagbarahandelser, samt att kunna hantera dessa risker pa ett effektivt och smart satt. Jag hoppas avenfa en battre overblick hur man far en bra kommunikation i gruppen.

C.1.2 Fragestallning

• Hur forbereder man sig pa oplanerade risker pa basta satt?

• Hade Team Risk Management varit en bra riskhanteringsmetod i detta projekt?

C.1.3 Avgransningar

Jag kommer enbart att fokusera pa riskhantering och kommunikation som hor till projektgruppersom haller pa med mjukvaruproduktion.

C.2 Bakgrund

Jag blev tilldelad en projektgrupp under tiden jag var borta i Are. Nar jag kom tillbaka sa hademin grupp blivit tilldelade projektet Dricksvatten. I detta projekt har vi haft manga ovantadehandelser som skulle kunna hanterats pa ett mer effektivt satt. Under den forsta iterationen savar en medlem sjuk i tva veckor. Detta stallde inte till med nagra jatteproblem men det var enovantad risk som vi inte hade tankt pa speciellt mycket och som vi inte heller hanterade pa ettvettigt satt. Nagra veckor senare valde denna medlem dessutom att hoppa av kursen, detta varnagot vi inte var forbereda pa. Aven om overgangen gick battre an forvantat sa skulle det varaonskvart att ha skrivit en riskplanering som ocksa kunde ha anvants for att hantera handelsenannu battre.

I borjan av projektet startade vi en SMS-grupp for att ha ett satt att fora kommunikationen pa,den har dock inte blivit anvand sa mycket som jag hade hoppats och var egentligen enbart entemporar losning. Vi forsokte under en tid att hitta andra alternativa losningar, till exempel satittade vi om det fanns ett plugin till Redmine eller om vi skulle anvanda Trello. Ett plugin tillRedmine verkade inte existera som skulle tillfredsstalla vara mal. Trello tyckte gruppen kandesonodigt nar vi redan bestamt att vi skulle anvanda Redmine. En IRC kanal var ocksa uppe padiskussion men intresset for detta var ocksa valdigt lagt. Jag tog ett eget beslut att anvanda Skypeoch har sedan dess forsokt att fa alla att installera Skype, ett program som tillater en att ha badeha textkonversationer och rostsamtal. Mer an halvvags in i projektet hade fortfarande inte alla




programmet pa sin dator och till slut hittades en annan losning i form av en Facebook grupp.Kommunikation har varit ett genomgaende problem i projektet.

C.3 Teori

Den definition av risk jag anvander ar definierad av Software Engineering Institute (SEI) somar en del av Carnegie Mellon University i Pittsburgh, Pennsylvania. De har definierat risk somchansen att gora en forlust (Higuera, Dorofee, Walker & Williams, 1994). Denna forlust kan varai form av fordrojd tid, samre kvalite pa produkten, okad kostnad eller totalt misslyckande.

Team Risk Management (TRM) eller gruppdriven riskhantering ar en metod for att hantera pro-jekt med fokus pa bra resultat genom att arbeta med riskhantering som en grupp. For att kunnaha en fungerande riskhantering kravs det att alla gruppmedlemmar kommunicerar med varandra.Det gar inte att en person skoter hela riskanalysen, hela gruppen maste jobba tillsammans for attta fram alla potentiella risker. Samma galler nar det kommer till att losa problemen som uppkom-mit, gruppdriven riskhantering kraver att man inte pekar finger. Alla sorter av kommunikation artillaten och uppmuntras (Higuera & Haimes, 1996).

Det finns det tre stycken faser i riskanalysen (Williams m. fl., 2006). Den forsta fasen ar till foratt identifiera de risker som finns. Det kan man gora genom att till exempel brainstorma, skrivaenkater och intervjua medlemmar i gruppen.

I den andra fasen skall man prioritera dessa risker. Sannolikheten och konsekvensen ifall riskenskulle intraffa ger en bra overblick pa hur man bor prioritera den. Ar det en risk som ar valdigtsannolik att intraffa och samtidigt ar valdigt allvarlig ar det uppenbart att den maste prioriterashogt. Ett bra satt att se hur hog prioritet en risk har ar att gora en sa kallad ’risk impact’ graf.Dessa ar konstruerade med sannolikheten for risken pa en axel och hur allvarlig konsekvensen arpa den andra. Denna typ av graf kan goras pa flera olika satt (Pritchard, 2014).

Figur 25 – Exempel hur en ’risk impact’ graf kan se ut.

Ett effektiv variant ar att gradera hur sannolik det ar att risken intraffar pa en skala fran 0 till100 % och bedomma konsekvensen ifall den intraffar pa en skal fran till exempel 0 till 1000 somvisas i figur 25. Att sedan placera in dessa i en graf sa far man en tydlig bild av vilka risker sombor prioriteras. Dessa typer av grafer kallas for ’risk impact’ eller ’probability charts’.

I den tredje och sista fasen skall man gemensamt ta fram en strategi for att hantera riskerna pa




ett effektivt satt.

Ska man implementera en riskhanteringsmetod som TRM i sitt projekt sa slutar inte de olika risk-hanteringsmomenten efter en riskanalys har skrivits. For att fa full kontroll ska man kontinuerligtuppdatera sin riskplanering och riskanalys. Enligt SEI tar det 18 till 24 manader att lara upppersonal samt implementera alla metoder som kravs efter ett beslut har tagits om att byta tillTRM. (Higuera m. fl., 1994; Higuera & Haimes, 1996). Figur 26 visar hur denna process ser ut.

Figur 26 – Kontinuerligt arbete kravs for Risk Management.

C.4 Metod

For att ta reda pa om TRM skulle vara en bra metod har jag skapat en enkat dar jag tar reda pade erfarenheter och asikter de andra gruppmedlemmarna har haft under detta projekt angaendevar riskhantering. Denna enkat, som kan ses i bilaga F.1.5, utgar jag fran nar jag diskuterar ochanalyserar. Jag har dessutom letat upp ett par olika vetenskapliga artiklar som beskriver TRMsamt hur man forebygger risker, bade innan de hander, under och efter.

C.5 Resultat

C.5.1 Risker

Ett basta satt for att hantera risker finns inte, men ett bra satt ar att folja en riskhanterings-metod fullt ut. Att gora en gedigen riskanalys och sedan fortsatta att kontinuerligt arbeta medriskhanteringen under projektets gang.

C.5.2 Team Risk Management

For att ta reda pa vad de andra gruppmedlemmarna hade for asikter angaende riskhantering ochkommunikationen sa lat jag alla gruppmedlemmar svara pa en enkat. Fragorna, som kan ses i bila-gan F.1.5, handlade om de ansag att vi spenderat tillrackligt med energi och tid pa riskhantering.Hur vi hanterade franvarande medlemmar och nar var gruppledare forsvann. Hur de tyckte attkommunikationen har varit i projektet och om vi skulle hanterat den pa ett annat satt.




Rent generellt verkade det vara liksinnande asikter, svaren skillde sig enbart pa nagra punkter.Till exempel om det skulle behovts en ytterligare riskanalys. Vissa tycker att det rackte med densom skrevs i starten om man istallet hade varit mer utforlig nar den skrevs. Andra tror att en tillriskanalys senare hade varit bra da andra risker som inte kunde identifieras i borjan blev tydligare.

Kommunikation ar nagot som alla tycker har varit ganska dalig under detta projekt, de flestahaller med om att den blivit battre i slutet av projektet. Ett problem de uttryckte var att detgruppen inte traffades varje vecka for att ha ett mote, och nar vi val hade ett mote var intresset foratt diskutera inte sa hogt som de hade onskat. Att gruppledaren slutade kursen tyckte daremotinte sa manga var speciellt farligt, eftersom arbetet var uppdelat sa blev det inte nagra storreforandringar i arbetsflodet. En medlem uttryckte dock att overgangen till den nya gruppledarenhade gatt snabbare om alla var narvarande pa motet. En annan ide var att vi skulle utsett en vicegruppledare som vi kunde ta over uppgifterna ifall gruppledaren forsvann.

Manga tycker att ett tydligare arbettssatt och en battre struktur pa projektet hade forbattratkommunikationen. En lista pa aktiviteter samt en tidsplan for dessa tros aven ha hjalpt. En medlemansag att Redmine skulle anvants mer, och att man aven skulle ha skrivit nar man forvantadesvara klar med sin uppgift.Med information fran enkaten och med de kraven som finns for att implementera TRM sa gar detatt konstatera att det inte hade varit ett bra val for oss. Kommunikationen var for dalig och vihade alldeles for lite tid for att implementera TRM fullt ut.

C.6 Diskussion

Under denna sektion gar det att lasa min analys om resultatet jag fatt och den metod jag anvant.

C.6.1 Resultat

Jag har delat upp denna del i tva delar, en for riskhantering generellt och en for TRM.

C.6.1.1 Riskhantering

Rent generellt satt sa har jag markt att det ar svart att hantera risker som man inte trodde skulleintraffa. Det man istallet borde ha gjort ar att skapa en gedigen riskanalys och fokuserat pa attha en genomtankt losningsgang ifall den skulle intraffa. I starten av detta projekt sa skrev vi enprojektplan for att gora just detta, i detta dokument fanns en riskanalys som skulle forbereda ossfor ovantade handelser. Det blev dock en valdigt kort analys dar enbart fyra olika risker togs upp.

Risk Grad LosningGruppmedlem sjuk eller borta Medel Bra kommunikation sa att andra kan hjalpa till med

dennes uppgift. Tillat sjalvstandigt arbete sa attgruppmedlemmar kan arbeta ikapp.

Gruppmedlem lamnar Hog Jobba strukturerat med bra dokumentation sa alla iprojektet har stor kannedom om alla delar. Gor endetaljerad tidsplan med tidsbuffer.

Missforstand av krav Hog Kommunicera med gruppen och kund vid osakerhetkring kraven. Gor prototyper.

Datakorruption/Dataforlust Liten Spara ofta, spara sakert. Anvand Git.

I efterhand sa ser jag att riskerna i vart projekt ar daligt analyserade. Graden av risken stammerbra, men losningarna ar valdigt vagt formulerade och de sager inte riktigt vad som faktiskt skagoras ifall en av riskerna intraffar. Utover det sa var det valdigt fa risker som har analyserats. Treav riskerna kraver dessutom att det finns en bra fungerande kommunikation vilket har varit ett




genomgaende problem i detta projekt.

Nagot som vi helt bortsag fran nar nagot utover det vanliga intraffade var just var riskanalys.Att vi ens skrev en riskanalys var egentligen helt onodigt eftersom den aldrig anvandes. Tva avriskerna som analyserades, mojligtvis daliga analyser, intraffade sa gjorde vi inte nagot for attforsoka losa dessa pa ett bra och effektivt satt. Vi tog det som det kom och struntade i att tittatillbaka pa vad vi hade sagt att vi skulle gora. Till exempel nar var gruppmedlem var sjuk undertva veckor sa gjorde vi inget speciellt for att minska konsekvenserna. Vi fortsatte att jobba somvanligt, vilket troligtvis enbart fungerade eftersom vi hade delat upp arbetet och kunde jobbasjalvstandigt. Samma sak gallde nar den forra gruppledaren hoppade av kursen, vi foljde intenagon riktig plan utan diskuterade lite snabbt vem som skulle bli den nya gruppledaren och sedanvar det klart. Enligt var riskanalys skulle vi ha en bra kommunikation och ett strukturerat sattatt arbeta, vilket ar nagot vi aldrig hade.

En bra riskanalys ar betydligt jobbigare att ta fram an den vi har haft i detta projekt. Det ardock omojligt att veta vilka mojliga risker som kommer intraffa, darmed kommer problemet medriskhantering. Var bor man lagga sina resurser ar svart att veta och det blir till slut en avvagningsom man maste gora.

Att det finns en stor skillnad mellan ett riktigt projekt och ett kandidat arbete ar uppenbart, iett storre projekt hade det sannolikt behovts en mycket mer avancerad riskanalys och den bordeocksa ha uppdaterats langre in i projektets gang.

C.6.1.2 Team Risk Management

En oppen och valfungerande kommunikation inom gruppen ar viktigt for att kunna implementeraTRM. Det ar nagot som vi saknat i detta projekt under vissa tider. Enligt enkaten jag skickatut for att ta reda pa vad de andra gruppmedlemmarna tyckte sa verkar de andra ocksa tycka attkommunikationen har varit lite samre an forvantat rent generellt. Kommunikationen mellan olikamedlemmar nar de diskuterat tekniska losningar har fungerat bra enligt manga, de uttrycker dockatt en battre struktur rent generellt hade varit bra. Ett tydligare arbettssatt tycker manga hadevarit bra, till exempel Redmine skulle ha anvants mer sa det lattare gar att se vad alla haller pamed.

C.6.2 Metod

Metoden som har anvants for denna studie av riskhantering ar inte helt konkret. Det finns samanga olika satt att hantera risker och att leta fram en som ar battre an en annan ar svart.Darfor blir det svart om inte omojligt att fa fram ett basta satt, det gar daremot att fa fram ettbra satt.

Metoden som anvandes for att se om TRM skulle vara en bra losning i detta projekt tycker jaghar varit ganska legitim. Att ta reda pa kraven som kravs for att implementera TRM och sedanjamfora med de erfarenheter och asikter vi har haft sa far man ett tydligt svar. Det skulle givetvisvarit battre att faktiskt implementera TRM i projektet eftersom da skulle det ga att avgora sjalvom det fungerade eller inte.

Kallorna jag har anvant verkar alla legitima. Kallorna som Higuera har medverkat i har citeratsmanga ganger, vilket tyder pa att det inte bara ar jag som tycker dessa ar bra. Att jag anvant tvakallor fran olika ar som ar skrivna av samma person ar daremot lite mindre bra. Det hade varitmer intressat om jag kunde fa flera kallor som visade pa samma sak. TRM verkar dock vara enmetod som forskarna pa SEI har kommit pa sjalva sa att hitta yterliggare kallor for den metodenblir svart.




C.7 Slutsatser

Att forbereda sig pa oplanerade risker kan vara svart, inte nodvandigtvis for att det ar sa svartatt identifiera riskerna och hitta en mojlig losning nar den val intraffar. Problemet ar att det blirhitta balansen mellan av hur mycket tid och energi du spenderar och hur mycket riskanalysenger. Spenderar du valdigt mycket tid pa att gora en riskanalys och kontinuerligt kollar sa att denfortfarande stammer kommer du spendera tid du skulle kunna ha anvant till nagot annat. Dennatid kanske du skulle spara in om du stoter pa en handelse som inte fanns med i din analys.Svaret pa fragan blir darmed nagot vagt. Det finns inte ett basta satt att hantera risker, sa attfa ett riktigt bra svar pa vilken metod skulle var bast ar omojligt. Det som gar saga ar att enbra riskhantering ar betydligt jobbigare att ta fram an den vi har haft i detta projekt. Det armycket mer tidskravande men i ett projekt som skulle forlora valdigt mycket pa medlemmar somforsvinner eller andra storre handelser sa skulle det sannolikt vara valdigt givande.

Hade jag genomfort ett liknande projekt i framtiden sa hade jag velat ha en mer valutveckladriskanalys, fler fall med tydligare handlingar ifall risken intraffar. Skulle en risk intraffa skulle jagga igenom riskanalysen ytterligare en gang och se om nagra nya risker uppstatt eller om det varnagon risk som pa vag att intraffa. Jag hade dessutom sett till fran borjan att det fanns motenvarje vecka sa gruppen hade en bra kommunikation.




D. Hannes - Enhetstestning

D.1 Inledning

Under varen 2015 genomfordes projektet Detektor for dricksvattenkvalitet vid Linkopings univer-sitet. I detta projekt var jag testledare och det var i det sammanhanget jag blev nyfiken pa hurbra var testmetodik egentligen var.

D.1.1 Syfte

Syftet med den har utredningen ar att undersoka hur val var egen testmetodik fungerade i projektetDetektor for dricksvattenkvalitet och hur vi hade kunnat forbattra den.

D.1.2 Ordlista

Term BetydelseModul En modul ar en storre del av hela systemet, som syftar till att utfora en

eller flera deluppgifter.

Stub En bit kod som simulerar en storre del av systemet i syfte att testa enmindre utan att behova kora systemet i sin helhet.

Driver En bit kod som stimulerar en specifik del av systemet att utfora sina upp-gifter i syfte att testa en mindre del av systemet utan att behova korasystemet i sin helhet.

PRU Integrerad realtidsprocessor i BeagleBone Black.

Statement En rad kod som utfor en operation.

BeagleBone Black Enkortsdator.

D.1.3 Fragestallning

• Hur anvander man enhetstestning pa ett effektivt satt i samband med en agil utvecklings-metodik?

– Finns det en risk att man missar for manga kritiska testfall?

– Bor man komplettera enhetstestning med ytterligare testmetodiker som regressionstestoch utforliga systemtest? Eller ar detta for dyrt i ett relativt litet projekt?

• Hur val fungerade den testmetodik vi valde?

– Hade var testning kunnat utforas pa ett battre satt?

D.1.4 Avgransningar

Jag har begransat utredningen till att undersoka metoderna enhetstestning, modultestning, integ-rationstestning, regressionstestning och systemtestning. Jag har ocksa begransat utredningen tillatt bara handla om test av funktionalitet. Kvalitetsvarden sa som prestanda och anvandbarhetkommer inte tas i beaktning.




D.2 Bakgrund

Att anvanda agila utvecklingsmetoder sa som Scrum eller Kanban har blivit populart. Samtidigthar sa kallad enhetstestning blivit vanligare, dar man i huvudsak testar varje liten del individuelltmed hjalp av stubs och drivers och sedan utgar fran att det fungerar nar man satter ihop det. Detar praktiskt att anvanda dessa i kombination, da det innebar att man tidigt far svar pa huruvidaden kodsnutt man skrivit fungerar och kan ga vidare till nasta arbetsuppgift.

D.3 Teori

I det har avsnittet redogors for hur de metoder som undersoks fungerar.

D.3.1 Agil arbetsmetodik

En agil arbetsmetodik bygger kring iden att ett projekt kan anpassas till nya mal och forutsattningarunder utforandet. En av de mest valkanda metoderna ar Scrum (What is Scrum? An Agile Fram-ework for Completing Complex Projects - Scrum Alliance, u. a.). Den karaktariseras bland annatav att det halls frekventa moten dar aktuella arbetsuppgifter fordelas pa arbetsgruppen.

D.3.2 Enhetstest

Under utvecklingen av ett system vill man som utvecklare kunna verifiera att man ar pa ratt sparoch att den kod man skriver gor det den ar tankt att gora. Dessutom vill man fixa simpla buggarpa en gang medans man ar insatt i koden. Utvecklaren skriver da enhetstest.

Dessa test ar sma, enkla och testar enskilda funktioner i den aktuella kodbasen. Enhetstest behoverinte testa alla mojliga testfall, aven om detta kan vara onskvart.

D.3.3 Modultest

Modultest testar samma funktioner som enhetstest, pa ungefar samma satt. De testar funktio-naliteten hos en enskild modul. Skillnaden mot enhetstest ar att modultest designas och utforsav en testare i syfte att verifiera att den kod utvecklaren har skrivit faktiskt fungerar som tankt.De ar med fordel nagot mer ingaende an enhetstest och utfors framst da modulen narmar sigfardigstallande.

D.3.4 Integrationstest

Integrationstest syftar till att verifiera att systemets moduler fungerar i samverkan. Framst bormalet med dessa test vara att testa granssnitten mellan moduler for att sakerstalla att de foljersamma protokoll.

D.3.5 Regressionstest

Under utvecklingen av ett system forandras ofta kodbasen over tid. For att upptacka och forebyggasituationer dar forandringar i en modul, som tidigare ansetts klar, skapar oforutsedda problem ien annan del av systemet utfors regressionstest. Regressionstest bor utforas kontinuerligt underprojektets gang pa de delar som anses fardiga for att tidigt hitta nya buggar som smugit sig in.

D.3.6 Systemtest

Systemtest utfors pa systemet i sin helhet. De anvands for att verifiera att systemet fungerarkorrekt och uppfyller satta krav.




D.4 Metod

For att undersoka effektiviteten av enhetstestning i ett agilt projekt har jag samlat in och ana-lyserat mina egna och andras erfarenheter av testning i det har projektet. Andras erfarenheterhar i huvudsak insamlats genom informella intervjuer under projektets gang. Jag har tittat pade testloggar som skrivits och jamfort med information fran andra skriftliga kallor, vetenskapligaartiklar och erfarenhetsdokument.

Jag vill jamfora enhetstest med mer formella och utforliga metoder sa som mer utforliga modultest.For att undersoka detta har jag genomfort mer ingaende test pa en utvald del av systemet. Jaghar sedan jamfort forbrukade resurser och mangden funna buggar med en annan del av systemetoch analyserat effektiviteten.

Till sist har jag analyserat mina nyvunna erfarenheter och kunskaper och jamfor med andratestmetoder fran skriftliga kallor for att forsoka dra en slutsats om vi hade kunnat utfora testandetpa ett battre och mer effektivt satt i projektet.

D.5 Resultat

I det har avsnittet redogor jag for den data som samlats in under projektets gang.

D.5.1 Arbetssatt

Under forstudien var planen att vi skulle anvanda en agil utvecklingsmetodik i projektet. Vihade dock problem med att komma igang med nagot organiserat arbetssatt. For det mesta var detsnarare fragan om att nagon hade insyn i en modul som denne sedan utvecklade vidare. Det innebarocksa att modultesten, som egentligen borde skrivits av nagon annan, skrevs av utvecklaren sjalv.Modultesten blev alltsa mer formella enhetstest.

D.5.2 Testplan

Under forstudien skrev jag en testplan som var baserad pa ett agilt arbetssatt dar vi hade valdigttat kommunikation inom gruppen. Den gick ut pa att utvecklaren sjalv var ansvarig for att en-hetstesta den kod denne skrev. Dessa enhetstest behovde inte dokumenteras, ty jag hoppades paatt vi skulle fa en bra bild av vad som fungerar genom att diskutera systemets status tillsammans.Nar val flera moduler borjade fardigstallas skulle dessa integrationstestas och systemtestas. Dessastorre test skulle dokumenteras.

I tredje och sista iterationen av projektet hade nastan ingenting testats ordentligt varfor jag skreven ny testplan dar alla moduler dessutom skulle genomga modultest som skulle dokumenteras.Detta gjordes i syfte att tvinga gruppen att dokumentera systemets nuvarande status pa ett tydligt,formellt satt. Samtliga gruppmedlemmar fick lista vad som fungerade, vad som inte fungerade, vadsom testats och inte testats. Detta gjorde att vi fick en tydlig bild av systemets status, nagot vihade behovt tidigare.

D.5.3 Enhetstest

Enhetstestning utfordes under projektet utan att dokumenteras. Informella intervjuer med grup-pens medlemmar gor dock klart att inte sarskilt mycket tid lades ner pa denna typ av test, deutfordes helt och hallet direkt i utvecklingsmiljon utan nagon automation.

Nar testplanen skrivits om under den tredje iterationen utfordes mer formella modultest pa samtli-ga moduler. Vissa moduler testades mycket mer utforligt an andra. De som testades extra intensivt




var PruHandler och pru_interface. Sarskild mjukvara designades for PRU:n dar testprogrammetkunde styra PRU:n att skicka olika matdata for att simulera alla mojliga testfall.

D.5.4 Integrationstest

Forst integrationstestades modulerna PRU och PruHandler tillsammans. Detta gjordes ganskautforligt, de flesta mojliga testfall testades. Sedan integrationstestades matklienten mot servern.Under detta test upptacktes att det protokoll som anvandes mellan dem varken var valdefinierateller dokumenterat nagonstans, det uppstod flera situationer dar de helt enkelt inte foljde sammaprotokoll.

Da de modultest vi utfort inte tackte alla mojliga testfall, uppstod ocksa ett antal buggar. Det vartydligt att de moduler som testats mer utforligt (PruHandler, pru_interface, PRU) produceradefarre buggar an de som inte testats sa utforligt (webbgranssnitt, server, matklient). Detta marktesgenom att integrationstest och debug av matklient↔ server tog oproportionerligt lang tid jamfortmed motsvarande test pa PRU-sidan.

D.5.5 Systemtest

Vi utforde inte nagra stora automatiserade systemtest dar alla funktionalitet systematiskt testats.De test som genomforts skedde informellt dar systemet sattes ihop i sin helhet med en eller fleramatenheter, bade riktiga BeagleBones med dummy-hardvara och simulerade BeagleBones medpahittad matdata. Vi gick sedan igenom systemets funktionalitet, framst funktionaliteten som artillganglig via webbgranssnittet, och kontrollerade den respons vi fick bade genom att titta paden data som syns i webbgranssnittet och genom att skriva ut debugmeddelanden pa server ochmatenheter.

D.5.6 Effektivitet

Till synes gjorde inte de odokumenterade enhetstesten sarskilt mycket for att garantera moduler-nas funktionalitet. De senare modultesten gav ett battre kvitto pa vad som fungerade, sarskilt dedelar pa vilka extra tid lades pa modul och integrationstest. Att designa automatiska mer utforligatest kostar dock tid. Trots att vi inte anvande nagot separat verktyg for modultest, utan skrevdem direkt i Python i form av drivers och stubs, sa spenderades 25 arbetstimmar pa att testaPruHandlern och dess kommunikation med PRUn. Av dessa 25 timmar ar dock 5 timmar integra-tionstest mot PRU. Jamfor med matklienten for vilken design och utforande av modultest endasttog 12 timmar, men integrationstest och tillkommande debug av kommunikation mot server togtva personer nastan 35 timmar sammanlagt.

D.6 Diskussion

I det har diskuterar jag min metod och mina resultat.

D.6.1 Resultat

Det ar for mig ganska uppenbart att var ursprungliga testplan inte fungerade val i vart projekt.Ett problem med var plan var att de forsta test som skulle dokumenteras var integrationstest,vilka ar svara att genomfora i ett tidigt stadie. Det tog alltsa lang tid innan test officiellt gjor-des och det var svart att fa en tydlig, konkret bild av vilka delar av systemet som faktiskt fungerar.

Hade vi haft ett mer strukturerat arbetssatt ar det mojligt att de ursprungliga enhetstesten hadegenomforts mer utforligt och bidragit mer till ett battre system. Erfarenheten fran det har pro-jektet ar att det i ett tidigt stadie kravs dokumenterade, formella test for att kartlagga systemets




status och sakerstalla att samtliga moduler fungerar som forvantat.

En ide skulle kunna vara att ha en mer test-driven utvecklingsmetod, dar automatiserade mo-dultest skrivs valdigt tidigt. Fordelarna med ett sadant arbetssatt ar manga, sarskilt i ett storreprojekt med manga utvecklare. Dessa automatiserade test kan utforas med jamna mellanrum ochagera regressionstest nar modulen anses fardig. Projekt- och utvecklingsledare kan fa en samman-fattning pa vilka testfall som ar godkanda och vilka som inte ar det och pa sa vis fa en tydlig bildav vilka delar av systemet som ar fardiga.

Under ett flerarigt projekt i USA tillampades en valdigt strikt testpolicy, dar systemets samtligastatements skulle testas i en egenbyggd testmiljo (Artho & Biere, u. a.). De fordelar de namnerinnefattar, forutom okat fortroende for systemets funktionalitet, aven saker som battre dokumen-tation av kod och minskat behov av detaljstyrning fran ledningen. Bada dessa saker kom av sigsjalv da utvecklarna bearbetade koden i samband med utvecklandet och utforandet av test. Jagdrar slutsatsen att test inte utfors bara for att forsakra sig om systemets kvalitet, utan aven kanverka positivt for projektets struktur i ett storre sammanhang. Detta stammer val overens medde erfarenheter jag haft i detta projekt och talar for att vi hade haft nytta av mer ingaende ochstrukturerad testning.

Problemet med utforliga, automatiska, formella test ar att det tar mycket tid att utveckla dem.Erfarenheter har till exempel visat att det kan ta mer tid an det ar vart att automatisera allaenhetstest (Collins & de Lucena Jr., 2012). I vart projekt med begransad tidsbudget var detaldrig aktuellt att anvanda en avancerad testmiljo och sikta pa fullstandig tackning. Vi gjordetillsammans bedomningen att vi hellre tar fram ett system med den funktionalitet kund vill haoch bara utfor tillrackligt mycket test for att kunna forsakra oss om att det fungerar val i devanligaste situationerna.

D.6.2 Metod

Vart bristfalliga arbetssatt har haft en negativ inverkan pa den har utredningen. Tanken var attutreda testning speciellt i ett projekt med ett agilt arbetssatt. Mangden data som kunnat samlasin ar alltsa begransad och den data som har samlats in ar inte nodvandigtvis representativ foragila projekt.

Det faktum att protokollet mellan server och matklient inte definierades och dokumenterades somdet borde, bidrar till att mitt resultat blir skevt da det tog oproportionellt mycket tid att testaoch debugga pa grund av de manga buggar det orsakade.

For att erhalla battre data att dra slutsatser fran, hade det hjalpt att ha en battre och tydligaretestplan fran borjan. Denna skulle garna ha forklarats och diskuterats mer ingaende med resten avprojektgruppen redan under forstudien sa att hela projektgruppen forstar syftet med dess innehall.Det hade ocksa varit fordelaktigt om samtliga test, aven enhetstest, dokumenterades ytterligare iform av hur mycket tid det tog att designa respektive utfora testen och hur manga buggar somupphittades och hur lang tid det tog att fixa dessa. I borjan av projektet gjordes bedomningenatt insamlandet av alla dessa data skulle haft en negativ inverkan pa utforandet av projektet, dautvecklarna hade behovt lagga icke forsumbara mangder tid pa administration och tidsredovising.Aven om det inte tar sarskilt lang tid att registrera tid sa paverkas arbetsflodet. Det ar en sakytterligare att halla koll pa och om du maste avbryta ditt arbete for att registrera tid sa ar detmer troligt att du glommer av vad det var du egentligen satt och arbetade med och hur du tanktelosa det aktuella problemet.




D.7 Slutsatser

Min utredning visar att ostrukturerade och odokumenterade enhetstest inte garanterar att en mo-dul ar buggfri. For att vara saker pa att systemet fungerar som det skall kravs nagot mer formellsom till exempel nagot mer utforliga modultest och integrationstest. Jag gjorde en jamforelse mel-lan tva delar av systemet, dar den ena modultestades mer utforligt an den andra. Utfallet blevatt integrationstestningen gick avsevart snabbare for den del som testats mer utforligt.

Jag har kommit fram till att en test-driven utvecklingsmetodik med automatiserade modultesthade kunnat vara fordelaktigt for vart projekt, med nackdelen att det potentiellt hade tagit formycket tid fran utvecklandet. Utifran tidigare namnda test gallande modul- och integrationstestdrar jag ocksa slutsatsen att mer formella, dokumenterade och utforliga modultest hade haft enpositiv inverkan pa det slutgiltiga systemet.




E. Sebastian - Implementation av realtidsfunktionalitet

E.1 Inledning

I det har projektet sa var ett huvudfokus att implementera avlasning av en sensor som skullekunna samplas i upp till 1 kHz, med sa stabil periodtid pa avlasningen som mojligt. I den hardelen undersoker jag hur man pa basta satt gor det med en BeagleBone Black (hadanefter benamndBBB).

E.1.1 Syfte

Syftet med denna utredning ar att undersoka hur man till lagst kostnad implementerar en matenhetpa BBB.

E.1.2 Fragestallning

• Kan BBB:s PRU-karnor anvandas for att implementera stabil sampling i 1 kHz?

• Vad finns det for eventuella fordelar och nackdelar med att anvanda PRU-karnorna framforatt anvanda t.ex. extra hardvara som en FPGA eller ett realtidsoperativsystem som RTLi-nux?

E.1.3 Avgransningar

Jag kommer inte analysera andra alternativ an de tidigare namnda PRU-karnorna, FPGA ellerRTLinux. De far ses som en generell representation av vardera typ av system de motsvarar.

Da jag inte har mojlighet att gora en full implementation av systemet pa varje alternativ sakommer jamforelsen mot FPGA och RTLinux endast basera sig pa efterforskningar och tidigareerfarenheter.

E.2 Bakgrund

Det befintliga datorsystemet som vi skulle ersatta med BBB anvander en FPGA och en relativtavancerad realtidsdator for att lasa av sensorn. Detta nuvarande system ar dyrt, stort och klumpigt,darfor vill var kund att vi ska ersatta det med enbart en BBB, om mojligt.

E.3 Teori

E.3.1 Tidskritisk kod under normalt operativsystem

En normal modern processor kor normalt i atskilliga GHz, aven en mindre processor som den iBBB kor pa atminstone 1 GHz. Med mojligheten da att utfora miljarder operationer i sekundensa kan det tyckas enkelt att astadkomma sampling i relativt laga 1 kHz, endast tusen ganger isekunden. Problemen kommer dock nar datorn kor ett vanligt hogniva-operativsystem, exempelvisLinux. Det ar inte ovanligt att hundratals processer kors samtidigt pa en dator, som alla mastedela pa processorns tid. Operativsystemet tillampar vanligtvis en teknik kallad ”time-slicing”, saatt varje process blir tilldelad en kort tidsperiod att koras pa processorn och sedan byts till nastaprocess som far kora. Under operativsystem som Linux och Windows ar det vanligt att processerkan bli tilldelade slices pa atskilliga millisekunder. Att da fa en samplande process att koras varjemillisekund (1 kHz), aven om varje sampling tar upp mycket kort tid, blir nastintill omojligt daoperativsystemet inte lamnar nagra garantier pa nar processen far koras nasta gang. (Silberschatz,Galvin & Gagne, 2014)




E.3.2 Realtidsoperativsystem - RTLinux

For att inte forlora alla fordelar som ett riktigt operativsystem for med sig sa finns projekt somRTLinux (RealTime-Linux) som forsokt implementera realtidsstyrning men fortfarande kor Li-nuxkarnan. I RTLinux kan man tilldela processer olika prioritet sa att hogre prioriterade proces-ser har ratt att ta over processorn ifran lagre prioriterade processer, en hogt prioriterad processkan da i princip kora nar den vill. RTLinux utlovar att en periodisk process far kora inom ca 25mikrosekunder fran sin utsatta periodtid. (Yodaiken, u. a.)

E.3.3 Extra hardvara - FPGA

Ett vanligt satt att implementera tidskritisk funktionalitet ar att gora det pa extra hardvara,exempelvis en FPGA. Detta gor att den tidskritiska samplingen kan utforas helt oberoende avhuvudprocessorn och paverkas inte av andra processer som belastar huvudprocessorn. En FPGAfungerar fundamentalt annorlunda an en vanlig processor, den ar uppbyggd av ”programmerbara”logikkretsar och kan utfora givna uppgifter mycket snabbt och helt parallellt, till skillnad fran enprocessorns sekventiella exekvering.

E.3.4 BeagleBone Black - PRUSS

BBB ar baserad pa processormodellen AM335x ifran Texas Instruments, denna innehaller forutomen vanlig ARM-karna pa 1 GHz aven vad de kallar PRUSS (Programmable Realtime Unit Sub-System) bestaende av tva PRU-karnor klockade i 200 MHz. PRU-karnorna ar 32-bitars RISC-processorer och kan programmeras till att exekvera kod oberoende av ARM-karnan. De har avendirekt tillgang till hardvarupinnar pa BBB och ett delat RAM-minne pa 12 kB som ARM-karnanoch bada PRU-karnorna kommer at och kan kommunicera genom. Systemet illustreras nedan ifigur 27. (Watkins & Betancourt, u. a.)

Figur 27 – Diagram over PRUSS

E.4 Metod

I detta avsnitt redovisas metoderna med vilka jag forsokt svara pa fragestallningarna.




E.4.1 Implementation av sampling pa PRU

For att undersoka om PRU-karnorna klarade uppgiften sa implementerade jag ett program somskulle utfora sampling i 1 kHz. Programmet skrevs i C och innefattar kommunikation med A/D-och D/A-omvandlare via SPI och publicering av datan till det delade RAM-minnet. SPI-kommunikationenmed A/D- och D/A-omvandlaren implementerades i mjukvara istallet for att anvanda AM335xSPI-hardvara, da programmet inte langre hade varit deterministisk annars, eftersom SPI-hardvaranfinns pa L3-bussen och ARM-karnans aktivitet skulle isafall interferera med PRU-karnans opera-tion. En hardvarutimer i PRUSS anvands for att halla periodtiden.

For att se sa att kravet pa stabil sampling uppfylldes sa anvandes en logikanalysator for attkolla pa SPI-bussen och ett oscilloskop for att kolla pa utsignalen ifran D/A-omvandlaren. Detsom kollades efter var stabil periodtid pa samplingen och hur lang tid avlasningen av vardera avde fyra kanalerna pa A/D-omvandlaren plus skrivningen till D/A-omvandlaren, alltsa fem SPI-transaktioner, tog i forhallande till periodtiden.

E.4.2 Jamforelse av PRUSS mot andra implementationer

Jamforelserna baseras till storsta del pa efterforskningar angaende de olika implementationsalter-nativen, men aven pa erfarenheter fran tidigare projekt med FPGA:er.

E.5 Resultat

I detta avsnitt redogors resultaten av mina undersokningar.

E.5.1 1 kHz sampling med PRU

Logikanalysatorn visade att de fem SPI-transaktionerna tar ca 70 µs, langt mindre an den kravdaperiodtiden pa 1 ms, alltsa klarar den gott och val 1 kHz. Inte heller nagon avvikelse ifran peri-odtiden pa 1 ms sags, samplingsperioden kunde alltsa anses vara stabil.

E.5.2 Resultat av vald implementation

Fordelar med PRUSS:

• PRUSSen med PRU-karnorna ar redan integrerade i BBB, sa ingen extra hardvara tillkom-mer som i fallet med en FPGA.

• PRU-karnorna kan programmeras i vanlig C, ett av varldens mest spridda sprak, vilket avenkan anvandas pa Linuxsidan. En FPGA kraver att programmeras i specialdesignade spraksom VHDL

• PRU-karnorna kan utfora stabil sampling helt oberoende av belastningen pa ARM-karnanoch ARM-karnans resurser frigors for att t.ex. utfora analys av datan. Under RTLinux saARM-karnans resurser delas av bade samplingen och ovriga uppgifter.

Nackdelar med PRUSS:

• Mojligheten att kora systemet pa annan hardvara an BBB begransas kraftigt, kostnaden attmigrera systemet till ny hardvara okar.

E.6 Diskussion

I foljande kapitel diskuteras resultaten av undersokningarna och valet av metod.




E.6.1 Resultat

E.6.1.1 1 kHz sampling med PRU

Da SPI-transaktionerna endast tog 70 µs sa skulle systemet alltsa i teorin klara en samplingsfre-kvens pa over 16 kHz. Det som sedan satter gransen for att ga annu snabbare ar inte PRU:n utanD/A- och A/D-omvandlaren, vilken inte klarar hogre hastighet pa SPI-linan an den som for nuva-rande anvands. PRU:ns SPI-drivrutin innehaller mycket vanteinstruktioner for att SPI-enheternaska hanga med i kommunikationen. Med battre D/A- och A/D-omvandlare sa skulle PRU:n alltsakunna klara annu hogre hastigheter an 16 kHz.

E.6.2 Metod

E.6.2.1 Val av PRUSS

Att anvanda PRUSS for att implementera realtidsfunktionaliteten valdes tidigt i projektet baseratpa att ingen extra hardvara skulle behovas och det da var det billigaste alternativet. PRU-karnornakandes aven som att de lag narmast de erfarenheter av sma mikrokontrollers som AVR som gruppenhade. Det fanns alltsa kompetens inom den typen av system, till skillnad ifran realtidsoperativsy-stem som RTLinux, vilket ingen hade erfarenhet av.Att konfigurera PRUSSen och lyckas exekvera kod pa PRU-karnorna visade sig dock inte sa trivi-alt som forst antaget. Att sedan designa ett kommunikationsgranssnitt mellan PRU-karnorna ochPythonprogrammet i Linux via det delade RAM-minnet var ocksa nagot som tog mycket tid.

Sahar i efterhand sa kanske RTLinux hade varit ett lika bra eller battre alternativ som PRUSSenanda. Ingen av dem har nagon extra hardvarukostnad, men det kan tankas att RTLinux kanskehade varit billigare i tidskostnad for att implementera systemet pa. Mer ingaende efterforskningari forstudien om hur mycket RTLinux egentligen skiljer sig ifran ett vanligt Debianbaserat Linux-system hade kunnat lett oss till att gora annorlunda val.

E.7 Slutsatser

BeagleBone Blacks PRUSS har visat sig utan problem klara av uppgiften att utfora sampling i 1kHz, utan ytterligare dyr hardvara. PRUSSen skulle tillochmed kunna anses overkvalificerad foren sadan enkel uppgift och arbetskostnaden for implementationen kanske inte var helt justifieradom fordelarna over ett realtidsoperativsystem inte anses tillrackligt stora.




F. Magnus - Kravframstallning

F.1 Inledning

Jag har, i egenskap av analysansvarig for detta projekt, valt att tillagna min individuella del ikandidatrapporten till att undersoka hur man pa basta satt kommer overens med kunden om vilkakrav som skall stallas pa projektet.

F.1.1 Syfte

Mitt syfte med denna rapport ar att bli battre pa att ta reda pa kundens egentliga krav i ettmjukvaruprojekt. Ofta kan kunden inte svart pa vitt saga exakt hur produkten skall se ut. Detkan bero pa att kunden saknar teknisk kunskap inom omradet eller kanske inte tankt pa vissfunktionalitet som egentligen gor produkten battre.

F.1.2 Fragestallning

• Vad ar viktigt att tanka pa nar man specificerar krav?

• Hur paverkade kravinhamtningsprocessen vart projekt?

F.1.3 Avgransningar

Rapporten behandlar endast ingenjorsprojekt inom mjukvarukonstruktion.

F.2 Bakgrund

Var projektgrupp har arbetat med ett projekt som heter dricksvattenkvalitet. Uppgiften var attersatta ett befintligt system som upplevdes som onodigt komplext och dyrt. Systemet ska konti-nuerligt utfora tester for att detektera abnorma substanser i ett vattenflode. Bestandsdelarna i sy-stemet ar matenheter som ska implementeras pa enkortsdatorer(Beaglebone) samt en centraliceradserver/databas som kommunicerar med samtliga enheter. Det ska aven finnas ett anvandargranssnittsom ska fungera som en kontrollpanel for matstationerna. De fundamentala delarna av syste-met(den kontinuerliga matningen) var kunden tydlig med hur den skulle se ut men resterande delarvar kunden inte lika saker pa och tyckte var mycket spannande att ha 6(7) dataingenjorsstudentersom fick tycka till om upplagget. Framfor allt ansag kunden att granssnittet till det tidigare syste-met var ”icke-responsivtoch trakigt och sag garna att vi var kreativa och kom med egna ideer narvi designade det. Efter ett flertal kundmoten kom vi fram till en kravspecification som alla partervar nojda med.

F.3 Teori

Med kravinhamtningsprocess inom mjukvara, menas de aktiviteter som foretag och mindre projekt-team maste utfora tillsammans med bestallare/kund, for att specifiera exakt vilken slutproduktsom skall utvecklas och vilken funkntionalitet som skall kravas av den. Sommerville, Ian har listatfoljande aktiviteter som han anser bor inga i kravinhamtningsprocessen. (Sommerville, 2010)

• “Requirement elicitation” Detta handlar om att samla in lampliga krav till systemet franslutanvandare, kunder och ovriga intressenter for projektet.

• “Requirement identification” Identifiera nya krav

• “Requirement analysis and negotiation” Ga igenom krav tillsammans med kund och bestallare.




• “Requirement specification” Framstall ett dokument som listar vilka krav som kommerstallas pa slutprodukten (kravspecifikation).

• “System modeling” Bestam overgripande modellering av systemet. Har ar det vanligt attman jobbar med generella objektorienterade sprak som UML (uml , u. a.)

• “Requirement validation” Verifiera att de dokumenterade kraven och modellerna ar rimligaoch tillmotesgar kund/bestallares behov.

• “Requirements management” Hantera forandringar i kraven under systemets utveckling.

F.4 Metod

Jag har, genom att genomfora detta projekt, erhallit erfarenheter som kommer att ligga tillgrundfor de slutsatser jag kommer dra i min rapport. Jag har aven diskuterat med kunden hur denneanser att kravinhamtningen gick for att fa feedback. For att bredda mina vyer ytterliggare har jaglast nagra vetenskapliga artiklar fran natet som behandlar detta amne.

F.5 Resultat

Nedan kommer jag att redovisa mina reslutat.

F.5.1 Analys av projektet

I vart projekt lade vi ett ganska stort fokus pa kravinhamtningsprocessen. Det tror jag har gynnatoss oerhort mycket. Kunden delade var uppfattning att en utforlig kravframstallning var nagonsom skulle prioriteras.Innan vi borjade koda och designa hade vi flera moten med kunden dar vi diskuterade hur denofficiella kravspecifikationen skulle utformas. Kunden hade tillsammans med sina kollegor pa IFMredan forberett en grov kravspecifikation som behovde modifieras och brytas ned till detaljniva.Till exempel sa byggde den kravspecifikationen pa att en extra hardvarukomponent (Labjack-T7)skulle inga i konstruktionen for att gora synkron pulsgenerering/pulsavlasningen mojlig. Vi visstedock att detta skulle kunna genomforas med hjalp av realtidsprocessorerna pa Beaglebonen. Vikande aven att flera av kraven i kundens kravspecifikation var for allmanna och ”icke-matbara”.Aven om vi forstod vad kunden efterfragade i de flesta fall sa kande vi oss mer komfortabla medmer konkreta krav. Detta medforde att vi spenderade mycket tid at Sommerville’s tredje aktivitet,att analysera kraven tillsammans med kund. Kravens innebord kanske inte alltid stammer overensmed hur projektgruppen ser pa dem. Det ar viktigt att man ser till att vara overens om allting.Kunden hade inte heller specifierat nagon overgripande design over systemet. Sa vi presenteradeen losning med en centraliserad server som kommunicerar med alla enheter. Denna server foreslogvi skulle kora en webserver. Att vi i ett tidigt skede bestamde dessa grova designval var viktigt.Om man i ett sent skede i projektet skulle bli oense med kunden om fundamentala designbeslutblir det mycket som maste goras om, vilket blir dyrt och fordrojer projektet.

F.5.2 Kraninhamtnings inverkan pa mjukvaruprojekt generellt

Hur kan da ett projekt paverkas av genomforandet av kravinhamtningen? Figur 28 ar hamtad fran“Concurrent Engineering”, av J R Hartley (Hartley, 1998)och visar hur kostnaden for att andranagot i implementationen varierar over projektets gang. Nar man studerar denna kurva inser manatt kostnaden blir hog om man maste gora andringar i systemet sent i projektet. Det ar darforviktigt att utvecklare och kund kommer overens om hur kraven ska se ut tidigt i projektet.




Figur 28 – Kostnad

F.6 Diskussion

Nedan kommer mina resultat och min metod att diskuteras.

F.6.1 Resultat

Aven om vi genomforde en ganska bra kravinhamtinng finns det givetvis saker vi kunde gjortbattre. Jag kanner, sahar i efterhand att det kanske var nagra krav som vi missade. Vi hadetill exempel inga krav gallande systemets robusthet, dvs att servern inte far krascha eller attmatenheter inte far do. En fundamental egenskap med den typen av system som vi utveckladear ju just att de ska fungera en langre tid, helst helt utan att behova teknisk modifikation. An-ledningen till att vi forbisag detta tror jag ar for att kunden, som var kallan for de krav somskulle finnas, tankte att sadanna kvalitetskrav inte var nodvandiga eftersom han inte var expertinom mjukvaruutveckling och da tanker man inte alltid pa vikten av felsaker kod. Vi som skallforestalla experter borde givetvis tankt pa detta och det blir nagot att ta med sig till nasta projekt.

Jag tycker aven att vi inte var tillrackligt noggranna med den sista aktiviteten i Sommerville’sbeskriving av kravinhamtningsprocessen, namligen att folja upp kraven under utvecklingsfasen.Det var flera krav som vi inte hann med att utveckla. Den huvudsakliga anledningen till det varatt vi under kravframstallningen planerade att projektlaget skulle besta av sju medlemmar. Vireducerades med en person i ett tidigt skede av projektet. Vilka krav som vi inte hann genomforablev ganska slumpartart. Vi borde istallet ha diskuterat detta med kunden mer noggrant, ochtillsammans valt ut vilka krav som var mindre viktiga att fardigstalla av de som var kvar. De kravsom inte genomfordes gjorde dock inte att systemet i stort ej gick att anvanda, utan det var kravsom att matenheterna skall ha en lysdiod som indikerar vilken mod enheten ar i eller hur enhetenskall agera om strommen forsvinner. Kunden har aven sagt att han generellt skulle vilja vara merinvolverad i vart projekt an vad som blev fallet. Vi sags valdigt sallan under forsta halvan avutvecklingsfasen vilket inte var optimalt. Gallande hur kravinhamtingen paverkar projektet ar detinte mycket mer att saga an att det straffar sig att ha dispyter med kunden angaende funktionali-tet under senare delar av projektet. I vart fall sa slapp vi att gora nagra storre forandringar under




utvecklingsfasen.

F.6.2 Metod

Mitt resultat ar i stora drag baserade pa erfarenheter som jag erhallit fran detta projekt. Jag trordock detta projekt kan anses vara ganska typiskt for hur mindre projekt inom detta falt ser ut.Det fanns en kund/bestallare som efterfragade en produkt/system och utvecklingslaget bestod av6-7 ingenjorer som skulle realisera produkten/systemet med begransade resurser.

F.7 Slutsatser

Viktiga saker man bor ha i atanke nar man specifierar krav ar att

• Allokera tillrackligt med tid at kravinhamtningsfasen.

• Sitt ner tillsammans med kunden och analysera samtliga krav som skall stallas pa systemet.

• Diskutera stora designbeslut tillsammans med kunden.

Att inte utfora en fullstandig kravinhamtningsprocess kommer att straffa sig under senare delarav projektet. Att implementera om saker nar mycket kod ar skriven tar mycket lang tid. Och idessa sammanhang ar tid pengar. I vart projekt missade vi att strukturera upp kvalitativa kravi hog grad vilket gjorde att systemets robusthet inte fick tillracklig prioritet. Vi kunde aven varitnoggrannare gallande att folja upp kraven over projektets gang (speciellt med tanke pa att vi fickett avhopp) sa att vi kunde prioritera de krav som var vardefullast for kunden pa ett optimaltsatt.




Referenser

1-tier architecture. (u. a.). Hamtad fran http://www.techopedia.com/definition/17374/one

-tier-architecture

2-tier architecture. (u. a.). Hamtad fran http://www.techopedia.com/definition/467/two

-tier-architecture

About Berners Lee. (u. a.). Hamtad fran http://www.w3.org/People/Berners-Lee/Longer

.html

About Node.js. (u. a.). Hamtad fran https://nodejs.org/about/

About npm. (u. a.). Hamtad fran https://www.npmjs.com/

Agila manifestet. (u. a.). Hamtad 2013-05-15, fran http://agilemanifesto.org/

Agilealliance - Daily meeting. (u. a.). Hamtad 2013-05-15, fran http://guide.agilealliance

.org/guide/daily.html

Ahmed, A. (2012). Software Project Management: A Process-Driven Approach. Auerbach Publi-cations.

Alpha State Cards. (u. a.). Hamtad 2015-06-12, fran http://www.ivarjacobson.com/

alphastatecards/

Andres Ojamaa & Karl Duuna. (2012). Assessing the Security of Node.js Platform. I The 7th inter-national conference for internet technology and secured transactions. Hamtad fran http://

ieeexplore.ieee.org.e.bibl.liu.se/stamp/stamp.jsp?tp=\&arnumber=6470829

Apache MPM. (u. a.). Hamtad fran http://httpd.apache.org/docs/2.2/mpm.html

Artho, C. & Biere, A. (u. a., maj). Advanced unit testing. I Proceedings of the 2006 internationalworkshop on automation of software test - ast ’06 (s. 92). New York, New York, USA: ACMPress. doi: 10.1145/1138929.1138947

Awad, M. (2005). A comparison between agile and traditional software development methodolo-gies. University of Western Australia, 10. Hamtad fran https://xa.yimg.com/kq/groups/

71601056/324265895/name/A\ comparision\ between\ Agile\ and\ Traditional\ SW\

development\ methodologies.pdf

BeagleBoard System. (u. a.). Hamtad fran http://makelinux.net/lib/ti/BeagleBoard\ SRM\

C4/

Best Practices of RUP. (u. a.). Hamtad 2013-05-15, fran http://www.my-project-management

-expert.com/the-advantages-and-disadvantages-of-rup-software-development

.html

Client server architecture. (u. a.). Hamtad fran http://searchnetworking.techtarget.com/

definition/client-server

Collins, E. F. & de Lucena Jr., V. F. (2012, juni). Software test automation practices in agiledevelopment environment: an industry experience report. I (s. 57–63). IEEE Press. Hamtad2015-05-03, fran http://dl.acm.org/citation.cfm?id=2663608.2663620

Companies using Node.js. (u. a.). Hamtad fran https://nodejs.org/industry/

Cortex-A8 processors (forskningsrapport). (u. a.). Hamtad fran http://infocenter.arm.com/

help/topic/com.arm.doc.subset.cortexa.a8/index.html\#cortexa8

David Andersen. (u. a.). Lecture 6 - Datalink-,Framing,Switching. Hamtad 2013-05-15, franhttp://www.cs.cmu.edu/~srini/15-441/F06/lectures/06-datalink.pdf

Flera magsjuka av eget brunnsvatten (forskningsrapport). (u. a.). Hamtad fran http://www.st

.nu/medelpad/sundsvall/flera-magsjuka-av-eget-brunnsvatten

Hartley, J. R. (1998). Concurrent engineering. Productivity Press. Hamtad franhttp://www.amazon.com/Concurrent-Engineering-Shortening-Raising-Lowering/

dp/1563271893

Higuera, R. P., Dorofee, A. J., Walker, J. A. & Williams, R. C. (1994, juli). Team Risk Ma-nagement: A New Model for Customer-Supplier Relationships. Carnegie Mellon Univer-sity. Hamtad fran http://oai.dtic.mil/oai/oai?verb=getRecord\&metadataPrefix=

html\&identifier=ADA283987

Higuera, R. P. & Haimes, Y. Y. (1996, juni). Software Risk Management. Carnegie Mellon Univer-




sity. Hamtad fran http://oai.dtic.mil/oai/oai?verb=getRecord\&metadataPrefix=

html\&identifier=ADA310913

Jiantao Zhao & Liujie Qin. (2014). Design and Implementation of Static Ser-ver Based on Event-driven. I Software engineering and service science (s. 679–682). Hamtad fran http://ieeexplore.ieee.org.e.bibl.liu.se/stamp/stamp.jsp?tp=

\&arnumber=6933659\&tag=1 doi: 10.1109/ICSESS.2014.6933659John Hunt. (2003). Guide to the Unified Process Featuring UML, Java and Design Patterns.

Springer. Hamtad fran http://library.books24x7.com.e.bibl.liu.se/assetviewer

.aspx?bkid=16238\&destid=1019\#1019

JSON. (u. a.). Hamtad 2015-05-13, fran http://www.json.org/

Kai Lei, Yining Ma & Zhi Tan3. (2014). Performance Comparison and Evaluation of Web Deve-lopment Technologies in PHP, Python and Node.js. I 17th international conference on com-putational science and engineering (s. 661–668). Hamtad fran http://ieeexplore.ieee

.org.e.bibl.liu.se/stamp/stamp.jsp?tp=\&arnumber=7023652

Kim H. Pries and Jon M. Quigley. (2011). Scrum Project Management. CRC Press.Marcus Olsson, S. H. (2014). Experimentell jamforelse av Cassandra, MongoDB och

MySQL (doktorsavhandling, Blekinge Institute of Technology). Hamtad franhttp://sea-mist.se/fou/cuppsats.nsf/all/d278348433255a3dc1257d060049cd01/

\$file/BTH2014Hevosmaa.pdf

Microsoft market share. (u. a.). Hamtad fran http://news.microsoft.com/bythenumbers/

index.HTML

Node.js is taking over the Enterprise – whether you like it or not. (u. a.).Hamtad fran https://www.centurylinkcloud.com/blog/post/node-js-is-taking-over

-the-enterprise-whether-you-like-it-or-not/

N-tier architecture. (u. a.). Hamtad fran https://msdn.microsoft.com/en-us/library/

bb384398.aspx

Paulson, L. D. (2005). Building Rich Web Applications with Ajax. IEEE Computer Soci-ety. Hamtad fran http://ieeexplore.ieee.org.e.bibl.liu.se/stamp/stamp.jsp?tp=

\&arnumber=1516047 doi: 10.1109/MC.2005.330Perry, D. E., Staudenmayer, N. A. & Lawrence G. Votta, J. (1994). Understan-

ding Software Development Processes, Organizations, and Technologies. IEEE softwa-re. Hamtad fran http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.322

.9866\&rep=rep1\&type=pdf

Pritchard, C. L. (2014). Risk Management: Concepts and Guidance (Fifth edit utgavan). CRCPress. Hamtad fran https://books.google.com/books?hl=sv\&lr=\&id=soyZBQAAQBAJ\

&pgis=1

Questions with Creator Ryan Dahl. (u. a.). Hamtad fran http://bostinno.streetwise.co/

2011/01/31/node-js-interview-4-questions-with-creator-ryan-dahl/

Robert Ryan McCune. (2011). Node.js Paradigms and Benchmarks. Univer-sity of Notre Dame. Hamtad fran http://netscale.cse.nd.edu/cms/pub/Edu/

GradOSF11FinalProjects/final.pdf

Scrum alliance. (u. a.). Hamtad 2013-05-15, fran https://www.scrumalliance.org/why-scrum/

core-scrum-values-roles

Silberschatz, A., Galvin, P. B. & Gagne, G. (2014). Operating System Concepts, Ninth Edition.John Wiley and Sons Inc. Hamtad fran http://codex.cs.yale.edu/avi/os-book/OS8/

os8c/

Slideshare - Unified Process. (2009). Hamtad 2013-05-15, fran http://www.slideshare.net/

guy\ davis/unified-process

Sommerville, I. (2010). Software engineering (9th ed.). Addison-Wesley. Hamtad fran http://

www.amazon.com/Software-Engineering-9th-Edition-Sommerville/dp/0137035152

TRANSMISSION CONTROL PROTOCOL. (1981). Information Sciences Institute at Universityof Southern California. Hamtad 2013-05-15, fran https://www.ietf.org/rfc/rfc793.txt

uml. (u. a.). Hamtad 2015-05-24, fran https://http://www.uml.org/




Valueatwork - Vattenfallsmetodiken en kostsam myt. (2013). Hamtad 2013-05-15, fran http://

valueatwork.se/vattenfallsmetodiken-en-kostsam-myt/

w3c. (u. a.). Hamtad fran http://www.w3.org/

Watkins, M. & Betancourt, C. (u. a.). Ensuring real-time predictability. Texas Instruments.Hamtad fran http://www.ti.com/lit/wp/spry264/spry264.pdf

What is Scrum? An Agile Framework for Completing Complex Projects - Scrum Alliance. (u. a.).Hamtad 2015-05-10, fran https://www.scrumalliance.org

Williams, R., Bertsch, B., Dale, B., van der Wiele, T., van Iwaarden, J., Smith, M. & Visser, R.(2006, januari). Quality and risk management: what are the key issues? The TQM Maga-zine, 18 (1), 67–86. Hamtad fran http://www.emeraldinsight.com/doi/full/10.1108/

09544780610637703 doi: 10.1108/09544780610637703Yodaiken, V. (u. a.). The RTLinux Manifesto. Department of Computer Science at New Mexico

Institute of Technology. Hamtad fran http://www.yodaiken.com/papers/rtlmanifesto

.pdf




Bilaga A Bilagor

F.1.1 Bilaga enkat kund



dddddddddddddddddddddddddddddddddddddddddddddddddd 5 555555 5 5 555555

?ddd?d?dddddddddd?dddddddddd?dddddddddd?d?ddddddd??d?ddddddddddddddd???ddddddd?

.......................

a

a a

k

5

s

55

?ddd?d??ddddd?dddddd?dd?ddddddddd?ddd?d?d?dd?ddddddddddddd?

.......................

a

j

da

5

?ddd?d???d?ddddd?ddddddddddddddddd?d??dddddddd?dd?

.......................

a

j

5

?ddd?d??d?ddd?d???d?ddddddd?d?d?dddddddd?dddddddddddddddddddddddd?dddd??d?ddddddddd?

.......................

s l

s l a

s l a

s

5

?ddd?d?dddddddd?d?dddddddd??ddddd?dddddddddddd??dddddd?d?dddddddddddd?ddd?ddddd?ddd?

.......................

a l

a l

a l

j

55

.................................................. ..................................................................

.....7 77.7.77....7..7.

?ddd?dtddddd

. j 5

55

????ddddddd?d?d?dddddd?dddddd?dd?ddd?d?ddddddd?dddddddd?ddddddddddd?d??ddddd?

.......................

t

5

t

55

????ddddddd?d?d?dddddd?ddddddd???ddddddd?dddd?ddddddddddd?d?d?d??dddddd??d?ddddddd?d?dddddddddddd?ddddd?

.......................

. g

.

.

. g

5

????ddddddd?d?dtddddd

. j 5

5

?ddddddddd?d?ddddddddd?d??dddddd?ddd?dd?dddddddddd?dd?

t l l .......................

a

j

da

5 5

.................................................. ..................................................................

7....7 77.7.77....7..7.

?ddddddddd?d?dddddd?dddddd?dd?ddddddddd?ddddddd?dddddddd?ddd??dd?d??ddddddddddddd??dddddddd???dddd?dd?d?dddddddd?dd?ddd?

555

?ddddddddd?d??ddddd?dddddd?d??dddddddddddddddddd??dddddddddddddd?dddd?d?dddddd?ddddddddd?d?d?d?

.......................

a

j

5 5

?ddddddddd?dtddddd

. j 5

5 5

?d?dddd?d??ddddd?dddddd?d?dddddddd??dd?ddddddddddddddddddddd?d??dddddddd?dd?

.......................

a

j

a

5 5

?d?dddd?d??ddddd?dddddd?dd?ddddddddd?d?ddddddddddddddddddddd?d??dddddddd?dd?

.......................

a

a l

j

555

.................................................. ..................................................................

.....7 77.7.77....7..7.

5 g g

?d?dddd?d??ddddd?dddddd?d?ddddddd??d?ddddddddd?

.......................

a l

a l

j

555

?d?dddd?d??ddddd?dddddd?d?dddddddd???dddddddddd??d?

.......................

a l

a l

j

555

?d?dddd?d??ddddd?dddddd?d?dddddddddddddd?ddddd?dddddddd??dddddddddddd??dddddd?ddddddddddd?

.......................

a l

a l

j

5 5

?d?dddd?d?dddd?d?dddddddd??d?ddd?dddddd?

.......................

j l a a

a

j l a

a

5 5

?d?dddd?dtddddd

. j 5

5

.................................................. ..................................................................

7....7 77.7.77....7..7.


F.1.2 Bilaga enkat grupp



---------------------------------------------

---mmm-m--m 5 555555 5 5 5555555

?---?-?----------m-----------mm??m------------?

.......................

a

k

5

55

?---?-??---?--m--------mm??m--m-------?-?----??--m---?----mm?

.......................

a

j

5

?---?-?m---?-?---?---m----m---??----??------m---------??---?-------?

5

?---?-??-m--m--------------m------m---?--m------m----m---?-----?

.......................

a

j

5

?---?-??-----m-------?-?-------------?

.......................

a

j

55

......................................................... ...............................................................

.....1 1...............

?---?-?-?--m-----m----?----------?-?-------------?

.......................

a

j

5

?---?-?------m--m-?-------??------??-?--m--------?-?-----m-----?---?-?---?m---m---m--?

.......................

a

j

55

??mm-------?-?-?------m---?mm-------?----m?--?--m--m----?---?-------?

.......................

a

j

5

??mm-------?-?-?------m---?mm-------?--m?-----m-?---?-------?

.......................

a

j

5

??mm-------?-?-?------m-----?---????---?-m------m?

.......................

a

j

555

??mm-------?-?-?------m---?mm-------?----?m----mm---?---?-------?

.......................

a

j

555

......................................................... ...............................................................

1....1 1...............

??mm-------?-?-?m---?-m?--?-?--?---?-??---------m--?m--?-?---------?--?-----

5 5

?--mm?-?------m-----mm---?----??-----------------??------------m-??-----?

.......................

a

j

5 5

?--mm?-??-----m---------mm---?----------------------?-------??------------m-??-----?

.......................

a

j

5 5

?--mm?-?---m---??-------m---?mm------?-?-----m-m----------?--------mmm-m--mm--?

.......................

a d

a d d

a d

j d

555

?--mm?-?---m-----m?------?

.......................

a d

a d

j

5 5

?--mm?-?m-?--?---?-?--------?--?------?-------------?-?------.

555

......................................................... ...............................................................

1....1 1...............

??--?-?---m?-----?-------?

.......................

a

j

5 5

??--?-?---m-m--m----?-------m?-m?----?

s s d .......................

a d

a d

a d d

j d

5 5

??--?-?---m-m--m-----------------m?-m?----?

.......................

a d

a d

a d d

j d

55

??--?-?--------m-------------?-------m?-m?----?

.......................

a

j

55

??--?-?m---?-?---?-?---m---------------m-??--m?

.......................

a d

a d d

j d

5

??--?-?m--?-?--?-?-------?-?--m?---?-?---m--??-----??-m---?----m??

.......................

a d

a d d

j d

5

......................................................... ...............................................................

.....1 1...............

?-?----?-?------m--m-?-------??----?-----?-------?

.......................

a

j

5

?-?----?-?------m--m-?-------?-----------m----?-?------------m?

.......................

a

j

55

?-?----?-?------m--m-----?-------------m-??--m--?m-??--?m--------------?

.......................

a

j

5

?-?----?-?------m--m-?-------?-------------m--m-----?

.......................

a d

a d

j d

j d

55

?-?----?-?------m--m------?------?---?-------?

.......................

a

j

5

?-?----?-?------m--m-?-------?------------------m-----?-mm--m------?-?-------?--?m??

.......................

a

j

5

?-?----?-?------m--m-----------m-------m-m-------?--?

.......................

a

j

55

......................................................... ...............................................................

.....1 1...............

?-?----?-?m---?-?---?-?---m-----m?------?

.......................

a d

a d

55

?-?----?-?------m--m-----------m-------m---m----?-?

.......................

a

j

5

?-?----?-?m---?-?---?-?---m-----m?------?

.......................

a d

a d

j

5

?-?m---?-?------m--m-?m-------mm?------------?

.......................

a

j

5

?-?m---?-?-?--m-----m--------m-?m-------mm?------------?

.......................

a

j

55

?-?m---?-?----m-?m-------?m-m---?---?

.......................

j d d

a

j d

5

-?--m------?-?-?------m--m?--m------?---------------?-----?

.......................

j d

a d

j d

55

......................................................... ...............................................................

1....1 1...............

-?--m------?-?-?------m------m--??---?-------m-------m-??-----?

.......................

a

j

5

-?--m------?-?-?m---??-?---m---------------m-??--m?

.......................

a

j

5

??m?-?----?m--------------------m?

.......................

a

j

55

??m?-?m---??-?---m---------------m-??--m?

.......................

a

j

55

??m?-?----?m---------??---?---?

.......................

a

j

5

??m?-?------m---?m---?---??-?--m-??--------------------?

.......................

a

j

5

?--m?--?-?----------m--?m---m------m-m?-m?--m------?-?

.......................

s

5

s

5

......................................................... ...............................................................

1....1 1...............

5 s s

?--m?--?-?----------m--?m---m------m-m?-?-----?-------?

.......................

s

5

s

55

?--m?--?-?----------m--?m---m------m-m?---------?

.......................

s

5

s

5

?--m?--?-?----------m--?m---m------m-m?-------?

.......................

s

5

s

55

?--m?--?-?m-m---?------------------------m--?m--?---?--m--m----------?--------??----?

.......................

a

l

n

5

?--m?--?-?m-m--?----?-m------------m-?------?---m--------m-------?

5

......................................................... ...............................................................

1....1 1...............


F.1.3 Bilaga enkat kund



[email protected] fotoHugo [email protected]–SekretessVisa profilHugo [email protected] (standardinställning)Alla dina sidor i Google+ ›Lägg till kontoLogga utRedigera detta formulär3 svarVisa alla svar Publicera analyser

SammanfattningKrav: Hur tycker Ni att era önskningar och krav upptogs under kravuthämtningen?

Bra 1 50 %Mindre bra 0 0 %Ok 1 50 %Dåligt 0 0 %Upptogs inte alls 0 0 %Bra 1 50 %Mindre bra 0 0 %Ok 1 50 %Dåligt 0 0 %Upptogs inte alls 0 0 %

Krav: Känner Ni att Ni fick vara med och prioritera kraven?

Ja 2 100 %Nej 0 0 %Ibland 0 0 %Ja 2 100 %Nej 0 0 %Ibland 0 0 %

Krav: Upptäckte Ni nya krav under projektets gång?

Ja 2 100 %Nej 0 0 %Ja 2 100 %Nej 0 0 %

Krav: Om ovan, Upptogs de då och kunde läggas till i kravlistan efter förhandlingar?

Upptogs, men fick ej lägga till 0 0 %Upptogs, vissa blev tillagda 1 50 %Upptogs, alla blev tillagda 1 50 %Upptogs aldrig 0 0 %Upptogs, men fick ej lägga till 0 0 %Upptogs, vissa blev tillagda 1 50 %Upptogs, alla blev tillagda 1 50 %Upptogs aldrig 0 0 %

Krav: Var det något krav som ni kände vitalt som inte hamnade i kravspecifikationen?

Ja, men fick ej lägga till 0 0 %Ja, men kunde ej läggas till pga resurs 0 0 %Ja, men upptogs aldrig 0 0 %

Dricksvattenkvalitet - analys av utveckling - kund - Google Formulär 2015-05-13

file:///C:/Users/Hugo/Desktop/kandidat%20referenser/Dricksvattenkvalitet%20-%20analys%20av%20utveckling%20-%20kund%20-%20Google%20Formul%C3%A4r.htm 1 / 5

Nej 2 100 %Övriga 0 0 %Ja, men fick ej lägga till 0 0 %Ja, men kunde ej läggas till pga resurs 0 0 %Ja, men upptogs aldrig 0 0 %Nej 2 100 %Övriga 0 0 %

Krav: Övrigt

Kommunikation: Tycker Ni att Ni har haft tillräcklig inblandning i projektet?

För mycket 0 0 %Lagom 1 50 %För lite 1 50 %För mycket 0 0 %Lagom 1 50 %För lite 1 50 %

Kommunikation: Tycker Ni att kommunikationen mellan kund och projektgrupp fungerat och varittillräcklig?

Har fungerat och varit tillräcklig 1 50 %Har fungerat men kunde varit mer 1 50 %Har fungerat men var ej tillräcklig 0 0 %Har ej fungerat och ej tillräcklig 0 0 %Har fungerat och varit tillräcklig 1 50 %Har fungerat men kunde varit mer 1 50 %Har fungerat men var ej tillräcklig 0 0 %Har ej fungerat och ej tillräcklig 0 0 %

Kommunikation: Övrigt

Vet ej något om kommunikationenVet ej något om kommunikationen

Utveckling: Tycker du projektet har prioriterats rätt?

Ja 0 0 %Nej 0 0 %Ibland 0 0 %Övriga 2 100 %Ja 0 0 %Nej 0 0 %Ibland 0 0 %Övriga 2 100 %

Utveckling: Tycker Ni att Ni fick tillräckligt med tillgång för projektresurser som statusrapporter,kod, designdokument?

För tidigt att säga.För tidigt att säga.

Utveckling: Känner Ni att projektet skulle gett bättre resultat med närmare inblandning från Er?

Ja 0 0 %Nej 2 100 %Övriga 0 0 %Ja 0 0 %Nej 2 100 %Övriga 0 0 %



Utveckling: Övrigt

Produkt: Känner Ni att produktens mål har varit klart under projektets gång?

Ja 1 100 %Nej 0 0 %Mot slutet 0 0 %Övriga 0 0 %Ja 1 100 %Nej 0 0 %Mot slutet 0 0 %Övriga 0 0 %

Produkt: Känner Ni att Ni har vetat produktens status under projektets gång?

Ja 0 0 %Ja, men inte tillräckligt 1 100 %Nej 0 0 %Ja 0 0 %Ja, men inte tillräckligt 1 100 %Nej 0 0 %

Produkt: Känner Ni att produkten följer kraven?

Ja, alla 1 100 %Ja, vissa 0 0 %Nej inga 0 0 %Ja, alla 1 100 %Ja, vissa 0 0 %Nej inga 0 0 %

Produkt: Känner Ni att produkten uppfyller era mål?

Ja, alla 1 100 %Ja, vissa 0 0 %Nej inga 0 0 %Ja, alla 1 100 %Ja, vissa 0 0 %Nej inga 0 0 %

Produkt: Känner Ni att produkten saknar funktionalitet för ett krav som inte blev tillagt?

Ja, flera funktioner 0 0 %Ja, några funktioner 0 0 %Nej 1 100 %Övriga 0 0 %Ja, flera funktioner 0 0 %Ja, några funktioner 0 0 %Nej 1 100 %Övriga 0 0 %

Produkt: Blev produkten som Ni tänkt er?

Nej, blev bättre 1 100 %Ja 0 0 %Nej, blev sämre 0 0 %Blev inte alls vad vi ville 0 0 %Nej, blev bättre 1 100 %Ja 0 0 %Nej, blev sämre 0 0 %Blev inte alls vad vi ville 0 0 %



Produkt: Övrigt

Eftersom projektet inte är slutredovisat går det inte att svara helt korrekt på alla frågor.Eftersom projektet inte är slutredovisat går det inte att svara helt korrekt på alla frågor.

Krav: Hur tycker Ni att era önskningar och krav upptogs under kravuthämtningen?

Krav: Känner Ni att Ni fick vara med och prioritera kraven?

Krav: Upptäckte Ni nya krav under projektets gång?

Krav: Om ovan, Upptogs de då och kunde läggas till i kravlistan efter förhandlingar?

Krav: Var det något krav som ni kände vitalt som inte hamnade i kravspecifikationen?

Krav: Övrigt

Kommunikation: Tycker Ni att Ni har haft tillräcklig inblandning i projektet?

Kommunikation: Tycker Ni att kommunikationen mellan kund och projektgrupp fungerat och varittillräcklig?

Kommunikation: Övrigt

Utveckling: Tycker du projektet har prioriterats rätt?

Utveckling: Tycker Ni att Ni fick tillräckligt med tillgång för projektresurser som statusrapporter,kod, designdokument?

Utveckling: Känner Ni att projektet skulle gett bättre resultat med närmare inblandning från Er?

Utveckling: Övrigt

Produkt: Känner Ni att produktens mål har varit klart under projektets gång?

Produkt: Känner Ni att Ni har vetat produktens status under projektets gång?

Produkt: Känner Ni att produkten följer kraven?

Produkt: Känner Ni att produkten uppfyller era mål?

Produkt: Känner Ni att produkten saknar funktionalitet för ett krav som inte blev tillagt?

Produkt: Blev produkten som Ni tänkt er?

Produkt: Övrigt

Antal dagliga svarDatum Räkna

6 maj 2015 3Datum Räkna

6 maj 2015 3

Antal dagliga svarVisa alla svar Publicera analyser

Sammanfattning




F.1.4 Bilaga enkat grupp



[email protected] fotoHugo [email protected]–SekretessVisa profilHugo [email protected] (standardinställning)Alla dina sidor i Google+ ›Lägg till kontoLogga utRedigera detta formulär4 svarVisa alla svar Publicera analyser

SammanfattningKrav: Hur tycker du att kravupphämtningen gick?

Bra 2 50 %Ok 1 25 %Dåligt 0 0 %Övriga 1 25 %Bra 2 50 %Ok 1 25 %Dåligt 0 0 %Övriga 1 25 %

Krav: Förstår du alla upphämtade krav och varför de togs upp?

Ja 4 100 %Nej 0 0 %Ja 4 100 %Nej 0 0 %

Krav: Om nej ovan, vad kunde gjorts för att du skulle förstå kraven?

Krav: Kände du att kraven speglar din bild av vad kunden önskar?


Krav: Känner du att något krav saknas?

Ja 1 25 %Nej 3 75 %Ja 1 25 %Nej 3 75 %

Krav: Tror du kunden känner att något krav saknas?

Ja 0 0 %Nej 4 100 %Ja 0 0 %Nej 4 100 %

Krav: Tycker du processen för att få fram kraven från kund var bra och inom tidsramen?

Dricksvattenkvalitet - analys av utveckling - gruppmedlem - Google Formulär 2015-05-13

file:///C:/Users/Hugo/Desktop/kandidat%20referenser/Dricksvattenkvalitet%20-%20analys%20av%20utveckling%20-%20gruppmedlem%20-%20Google%20Formul%C3%A4r.htm 1 / 9


Kommunikation: Tycker du kommunikationen mot handledare har fungerat?


Kommunikation: Tycker du kommunikation mot kund har fungerat?


Kommunikation: Skulle du viljat jobba närmar kund?


Kommunikation: Tycker du kommunikation inom gruppen har fungerat?


Kommunikation: Om nej på någon ovan, förklara vad som ej fungerat kortfattat

Skype/fb. Folk som inte säger när dom inte kommer på möten.Oavsett kommuikationsmedel har det inte alltid varit lätt att få svar på saker. Diskussioner gällande saker som arbetssätt ochordanisation (dokument, "formalia") har varit obefintliga.Skype/fb. Folk som inte säger när dom inte kommer på möten.Oavsett kommuikationsmedel har det inte alltid varit lätt att få svar på saker. Diskussioner gällande saker som arbetssätt ochordanisation (dokument, "formalia") har varit obefintliga.

Grupp: Tycker du gruppen har gjort sitt yttersta för att klara projektet?


Grupp: Känner du att gruppen har engagerat sig tillräckligt för att klara projektet?




Grupp: Har det hänt att du kommit i konflikt med en eller flera gruppmedlemmar?

Ja, alltid 1 25 %Ja, ibland 0 0 %Ja, sällan 0 0 %Nej, aldrig 3 75 %Ja, alltid 1 25 %Ja, ibland 0 0 %Ja, sällan 0 0 %Nej, aldrig 3 75 %

Grupp: Har detta påverkat?

Ja, positivt 1 25 %Ja, negativt 0 0 %Nej 3 75 %Ja, positivt 1 25 %Ja, negativt 0 0 %Nej 3 75 %

Grupp: Om ja ovan, beskriv kortfattat orsaken till konflikten.

Möte: Har mötena fungerat?

Ja 3 75 %Nej 1 25 %Ja 3 75 %Nej 1 25 %

Möte: Har medlemar närvarat på mötena?

Ja, alltid 0 0 %Ja, oftast 2 50 %Ja, ibland 2 50 %Nej, aldrig 0 0 %Övriga 0 0 %Ja, alltid 0 0 %Ja, oftast 2 50 %Ja, ibland 2 50 %Nej, aldrig 0 0 %Övriga 0 0 %

Möte: Har medlemar engagerat sig på mötena?

Ja, alltid 0 0 %Ja, oftast 2 50 %Ja, ibland 2 50 %Nej, aldrig 0 0 %Övriga 0 0 %Ja, alltid 0 0 %Ja, oftast 2 50 %Ja, ibland 2 50 %Nej, aldrig 0 0 %



Övriga 0 0 %

Möte: Har en tydlig struktur funnits på mötena?

Ja 1 25 %Nej 3 75 %Ja 1 25 %Nej 3 75 %

Möte: Om nej ovan, har detta varit ett problem?

Ja, alltid 0 0 %Ja, ibland 3 75 %Nej, aldrig 1 25 %Ja, alltid 0 0 %Ja, ibland 3 75 %Nej, aldrig 1 25 %

Möte: Om någon frånvarat från mötet, har de fått informationen då?

Ja, alltid 1 25 %Ja, ibland 1 25 %Nej, aldrig 0 0 %Övriga 2 50 %Ja, alltid 1 25 %Ja, ibland 1 25 %Nej, aldrig 0 0 %Övriga 2 50 %

Process: Tycker du processen för arbetet fungerat?

Ja 3 75 %Nej 1 25 %Ja 3 75 %Nej 1 25 %

Process: Tycker du processen har varit tydlig och strukturerad?

Ja 2 50 %Nej 2 50 %Ja 2 50 %Nej 2 50 %

Process: Tycker du detta har varit ett problem som försämrat resultatet?

Ja 2 50 %Nej 2 50 %Ja 2 50 %Nej 2 50 %

Process: Tycker du processen har klarat av deadlines?

Ja, alltid 1 25 %Ja, oftast 3 75 %Nej, sällan 0 0 %Nej, aldrig 0 0 %Ja, alltid 1 25 %Ja, oftast 3 75 %Nej, sällan 0 0 %Nej, aldrig 0 0 %



Process: Tycker du design beslut har fungerat?


Process: Tycker du processen har klarat av alla delar (implementation, tester, kod)?


Process: Tycker du det varit tydligt vad du ska göra?

Ja 3 75 %Nej 1 25 %Ja 3 75 %Nej 1 25 %

Process: Om nej ovan, har detta påverkat?

Ja, positivt 1 33.3 %Ja, negativt 2 66.7 %Ja, positivt 1 33.3 %Ja, negativt 2 66.7 %

Process: Tycker du det varit tydligt vad andra gör?

Ja 3 75 %Nej 1 25 %Ja 3 75 %Nej 1 25 %

Process: Om nej ovan, har detta påverkat?

Ja, positivt 0 0 %Ja, negativt 1 50 %Nej 1 50 %Ja, positivt 0 0 %Ja, negativt 1 50 %Nej 1 50 %

Produkt: Tycker du produkten uppfyller kraven?

Ja 4 100 %Nej 0 0 %Ja 4 100 %Nej 0 0 %

Produkt: Tror du kund tycker produkten uppfyller kraven?

Ja 4 100 %Nej 0 0 %Ja 4 100 %Nej 0 0 %



Produkt: Blev produkten som du tänkt?

Nej, bättre 0 0 %Ja 3 75 %Nej, sämre 1 25 %Nej, bättre 0 0 %Ja 3 75 %Nej, sämre 1 25 %

Dokumentation: Tycker du dokumentationen varit tillräcklig?

Nej, för mycket 0 0 %Ja, lagom 3 75 %Nej, för lite 1 25 %Nej, för mycket 0 0 %Ja, lagom 3 75 %Nej, för lite 1 25 %

Dokumentation: Tycker du att du förstår alla delar i projektet?

Ja 1 25 %Nej 3 75 %Ja 1 25 %Nej 3 75 %

Dokumentation: Om nej, har detta varit ett problem?

Ja 0 0 %Nej 4 100 %Ja 0 0 %Nej 4 100 %

Kod: Har koden varit strukturerad?

Ja 2 50 %Nej 2 50 %Ja 2 50 %Nej 2 50 %

Kod: Om nej, har detta varit ett problem?

Ja 1 25 %Nej 3 75 %Ja 1 25 %Nej 3 75 %

Kod: Har koden varit förstålig?

Ja 3 100 %Nej 0 0 %Ja 3 100 %Nej 0 0 %

Kod: Tycker du koden har följt projektets kvalitetskrav?

Ja 3 75 %Nej 1 25 %Ja 3 75 %Nej 1 25 %



Allmänt: Hur tycker du om tiden lagd på dokumentation?

För mycket 0 0 %Lagom 4 100 %Förlite 0 0 %För mycket 0 0 %Lagom 4 100 %Förlite 0 0 %

Allmänt: Hur tycker du om tiden lagd på funktionalitet?


Allmänt: Hur tycker du om tiden lagd på kvalitet?


Allmänt: Hur tycker du om tiden lagd på tester?


Allmänt: Om du känner till en utvecklingsmetodik, tror du den skulle fungerat bättre?

Ja 2 50 %Inte de jag känner till 1 25 %Känner inte till någon 1 25 %Ja 2 50 %Inte de jag känner till 1 25 %Känner inte till någon 1 25 %

Allmänt: Om du fick ändra en sak i processen, vad skulle det vara?

Mer kakorTydligt vad information om man ska göra/implementera. Hårda beslut, en som bestämmer.Bestämma och specificera arbetssätt osv i förstudien. Se till att komma igång med utvecklingen tidigare så att det inte finns någonrisk att projekt stannar av.Mer kakorTydligt vad information om man ska göra/implementera. Hårda beslut, en som bestämmer.Bestämma och specificera arbetssätt osv i förstudien. Se till att komma igång med utvecklingen tidigare så att det inte finns någonrisk att projekt stannar av.

Krav: Hur tycker du att kravupphämtningen gick?

Krav: Förstår du alla upphämtade krav och varför de togs upp?

Krav: Om nej ovan, vad kunde gjorts för att du skulle förstå kraven?

Krav: Kände du att kraven speglar din bild av vad kunden önskar?




F.1.5 Bilaga enkat risker

Bilaga B Fredriks enkat

• Tycker du att riskhanteringen i detta projekt har varit tillracklig?

• Om ja, varfor?

• Hur tycker du att gruppen hanterade gruppmedlemmen som var franvarande?

• Vad tycker du vi kunde ha gjort annorlunda?

• Hur tycker du gruppen hanterade nar gruppmedlemmen forsvann?

• Vad skulle vi gjort sa att overgangen gick battre till den nya gruppledaren?

• Hur anser du att var kommunikaten i var grupp har varit?

• Kanner du att beslutet att anvanda skype var oklart?

• Hur tycker du vi skulle hanterat den undermaliga kommunikationen vi har haft?

• Finns det nagot du tycker gruppen borde tagit hansyn till nar det kommer till risker?




F.2.1 Bilaga enkat Node.js



Sammanställning enkät

Antalet deltagare : 20 stycken

Hur mycket erfarenhet har du av programmering?

• Lite – 50%• Medel – 40%• Erfaren – 10%

Hur mycket erfarenhet har du av serverprogrammering?

• Lite – 40%• Lite mindre än medel – 20%• Medel – 40%• Lite mer än medel – 0%• Mycket – 0%

Hur mycket erfarenhet har du av Node.js?

• Lite – 40%• Lite minder än medel – 10%• Medel – 50%• Lite mer än medel – 0%• Mycket – 0%

Hur svårt var det att komma igång med Node.js?

• Enkelt – 40%• Medel – 60%• Svårt – 0%

Vad var svårare att sätta sig in I Node.js? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

• Asynkrona metoder• Mycket information men inte alltid rätt

Vad var enklare att sätta sig in I Node.js? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

• Javascript var familjärt• Javascript är enkelt• Npm var enkelt att använda

Hur är kodtydligheten I Node.js?

• Lätt – 0%• Lite mindre än medel – 20%• Medel – 60%• Lite mer än medel – 20%• Svårt – 0%

Vad var bättre gällande kodtydligheten? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

• Javascript som språk• Familjär och enkel syntax

Vad var sämre gällande kodtydligheten? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

• Asynkrona callbacks

Hur tycker du Node.js hanterar säkerhet?

• Har ingen åsikt – 80%• Dåligt – 10%• Medel – 10%• Bra – 0%

Vilka problem finns det med Node.js? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

• -

Hur tycker du Node.js hanterar tredje parts bibliotek?

• Dåligt – 0%• Ok – 80%• Bra - 20%

Vad hanterar NPM (Node.js pakethanterare) bra? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

• Configfil för hantering av alla bibliotek• Nedladdning och sparandet av bibliotek• Stor databas

Hur var tillgängligheten med hjälpmaterial för Node.js? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

• Låg – 0%• Lite mindre än medel – 0%• Medel – 80%• Lite mer än medel – 20%• Mycket – 0%

Vilka fördelar finns det med Node.js? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

• Familjärt språk• Enkelt kan bygga en server med mycket funktionalitet• Massor av plugins• Enkelt att komma igång

Vilka nackdelar finns det med Node.js? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

• Dåligt/inget stöd för klasser (objektorienterat)• Asynkrona callbacks• Mycket användning av externa bibliotek

Har du erfarenhet av andra serverspråk?

• Nej – 50%• Ja – 50%

Vilka serverspråk har du erfarenhet av? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

• PHP (med alla olika ramverk) – 12 st• Java – 6 st• C# - 2 st• .Net – 2 st• Python – 8 st

Vilka fördelar/nackdelar finns det med Node.js jämfört med andra språk? Denna lämnades blankt för vissa, nedan listas en sammaställning av svar.

Fördelar• Går snabbt att sätta sig in I• Mycket dokumentation • Många plugins för att göra olika uppgifter

Nackdelar• Asynkrona callbacks• Dåligt stöd för objektorienterat

Hur svårt var det att lära sig Node.js gentemot andra språk?

• Enklare – 10%• Lika – 80%• Svårare – 10%

På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en 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 det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden 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 seförlagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on 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 bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

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

© [Fredrik Larsson, Magnus Qvigstad, Hannes Snögren, Rasmus Eriksson, Magnus Gustafsson, Hugo Lindholm]

826965/fulltext01.pdf · detektor f or dricksvattenkvalitet 26 juni 2015 projektidentitet vt, 2015,...

Documents