Institutionen för datavetenskap825659/FULLTEXT01.pdf · 3 Teori Detta kapitel behandlar teori som...

Institutionen för datavetenskap Department of Computer and Information Science

Kandidatrapport

Utveckling av Fashion Web som en flexibel slut-användaradministrerad plattform

av

Johannes Klasson, Jakub Binieda, Sebastian Sundin, Daniel Sjövall, Jonas Tarassu, Harald Pettersson, Johan Lindberg och Tomas Doverfelt

LIU-IDA/LITH-EX-G--15/025—SE

2015-06-14

Linköpings universitet

SE-581 83 Linköping, Sweden Linköpings universitet

581 83 Linköping

Linköpings universitet Institutionen för datavetenskap

Kandidatrapport


av


LIU-IDA/LITH-EX-G--15/025—SE

2015-06-14

Handledare: Jonas Wallgren Examinator: Kristian Sandahl

Linköpings universitetInstitutionen för datavetenskap

PROJEKTIDENTITET2015/VT, Grupp 5

Tekniska högskolan vid Linköpings universitet, IDA

GruppdeltagareNamn Ansvar Telefon E-postJohannes Klasson Gruppledare 073-8209003 [email protected] Binieda Dokumentansvarig 076-5921283 [email protected] Sundin Analysansvarig 070-6197415 [email protected] Sjövall Arkitekt 070-2965847 [email protected] Tarassu Utvecklingsledare 070-5738583 [email protected] Pettersson Testledare 073-3288744 [email protected] Lindberg Kvalitetssamordnare 076-8225014 [email protected] Doverfelt Specialist 070-5749851 [email protected]

E-postlista för hela gruppen: [email protected]: Susan Szatmáry, 070-3315558

Teknisk kontakt hos kund: Erik Berglund, 070-3475060Kursansvarig: Kristian Sandahl, [email protected]

Handledare: Jonas Wallgren, [email protected]


Sammanfattning

Denna kandidatrapport redogör för arbetet med att utveckla en webbplats, med avsaknad avtidigare erfarenheter inom området. Arbetet var kopplat till en riktig kund med tanke att användaresultatet för försäljning av modeaccessoarer i verkligheten.

I dokumentet beskrivs även de metoder som använts, och vilka resultat som dessa har lett till.Det innefattar också vilka erfarenheter som har förvärvats under projektets gång, och hur dessakan utnyttjas i senare projekt.

Linköpings universitetInstitutionen för datavetenskap v

Innehåll

I Gemensamma erfarenheter och diskussion 1

1 Inledning 1

1.1 Motivering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Bakgrund 2

3 Teori 3

3.1 Systemutvecklingsmetoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1.2 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.2 Kommunikationsverktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.2.1 Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.3 Utvecklingsverktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.3.1 Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.3.2 Gulp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.3.3 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.3.4 Npm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.3.5 Pip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3.6 Bower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3.7 Flask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3.8 Sass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3.9 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3.10 React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Metod 8

4.1 Förstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.2.1 Arbetsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.3 Forskningsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

viLinköpings universitet

Institutionen för datavetenskap

5 Resultat 105.1 Förstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2.1 Iteration 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2.2 Iteration 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2.3 Iteration 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2.4 Feedback från kund . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.3 Gruppens gemensamma erfarenheter . . . . . . . . . . . . . . . . . . . . . . . 12

5.4 Översikt över de individuella utredningarna . . . . . . . . . . . . . . . . . . . 12

6 Diskussion 146.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.2.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.3 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . 15

6.3.1 Etiska och samhälleliga aspekter . . . . . . . . . . . . . . . . . . . . . 15

6.3.2 Miljöaspekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7 Slutsatser 167.1 Flexibel utvecklingsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7.2 För- och nackdelar med webbplattform från grunden . . . . . . . . . . . . . . 16

8 Fortsatt arbete 178.1 Marknad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

8.2 Konkurrens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

8.3 Ekonomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Linköpings universitetInstitutionen för datavetenskap vii

II Enskilda utredningar 18

A Projektplanering i ett programvaruprojekt 18A.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

A.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

A.1.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

A.1.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

A.1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

A.2 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

A.2.1 Aktivitetsstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

A.2.2 Tidsestimering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

A.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20


A.3.2 Tidsuppskattning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

A.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21


A.4.2 Tidsuppskattning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

A.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

A.5.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

A.5.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

A.6 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

B Dokumentskrivning i olika dokumenthanteringsmiljöer 24B.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

B.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

B.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

B.1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

B.1.4 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

B.2 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

B.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

B.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

B.4.1 Teoretisk del . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

B.4.2 Praktisk del . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

B.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

B.5.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

B.5.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

B.6 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

viiiLinköpings universitet


C Hur krav av hög kvalitet tas fram och varför de är viktiga 31C.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

C.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31C.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31C.1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

C.2 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31C.2.1 Svårigheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32C.2.2 Lösningsförslag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

C.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33C.3.1 Beskrivning av krav . . . . . . . . . . . . . . . . . . . . . . . . . . . 33C.3.2 Möten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

C.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34C.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

C.5.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34C.5.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

C.6 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

D React, the V in MVC 36D.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

D.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36D.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36D.1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36D.1.4 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

D.2 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37D.2.1 Model-View-Controller (MVC) . . . . . . . . . . . . . . . . . . . . . 37D.2.2 Document Object Model (DOM) . . . . . . . . . . . . . . . . . . . . . 38D.2.3 React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38D.2.4 AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

D.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38D.3.1 MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38D.3.2 React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

D.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39D.4.1 MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39D.4.2 React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

D.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39D.5.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39D.5.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

D.6 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Linköpings universitetInstitutionen för datavetenskap ix

E Npm som byggautomatiseringssystem 41E.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

E.1.1 Motivering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

E.1.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

E.1.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

E.1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

E.2 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

E.2.1 Byggautomatisering . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

E.2.2 Pre- och posthooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

E.2.3 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

E.2.4 Gulp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

E.2.5 Npm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

E.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

E.3.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

E.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

E.4.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

E.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

E.5.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

E.5.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

E.6 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

F Testning i ett medelstort projekt 46F.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

F.1.1 Motivering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

F.1.2 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

F.1.3 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

F.1.4 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

F.1.5 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

F.2 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

F.2.1 Mjukvarutestning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

F.2.2 unittest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

F.2.3 Selenium Webdriver . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

F.2.4 coverage.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

F.2.5 BrowserSync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

F.2.6 Google Chrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

F.2.7 Mozilla Firefox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

xLinköpings universitet


F.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

F.3.1 unittest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


F.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

F.4.1 unittest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50


F.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

F.5.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

F.5.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

F.6 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

G Kvalitet i ett programvaruutvecklingsprojekt 53G.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

G.1.1 Motivering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

G.1.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

G.1.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

G.1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

G.2 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

G.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

G.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

G.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

G.5.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

G.5.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

G.6 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

H Tillvägagångssätt vid webbutveckling för flera platformar 58H.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

H.1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

H.1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

H.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

H.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

H.3.1 Webbdesign från grunden . . . . . . . . . . . . . . . . . . . . . . . . 58

H.3.2 Webb på olika platformar . . . . . . . . . . . . . . . . . . . . . . . . . 59

H.3.3 Responsiv webbdesign . . . . . . . . . . . . . . . . . . . . . . . . . . 59

H.3.4 Olika hjälpmedel för responsiv design . . . . . . . . . . . . . . . . . . 60

H.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

H.4.1 Förstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Linköpings universitetInstitutionen för datavetenskap xi

H.4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

H.4.3 Jämförelser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

H.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

H.5.1 Förstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

H.5.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

H.5.3 Jämförelser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

H.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

H.6.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

H.6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

H.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

xiiLinköpings universitet


DokumenthistorikVersion Datum Utförda förändringar Utförda av Granskad0.1 2015-03-13 Första utkast. Grupp 50.2 2015-04-20 Uppdaterade individuella delar Grupp 5 Grupp 50.3 2015-05-13 Uppdaterade gemensamma och indivi-

duella delarGrupp 5 Grupp 5

0.4 2015-05-27 Lade till referenser och granskade text Grupp 5 Grupp 51.0 2015-06-14 Granskade dokumentet Grupp 5 Grupp 5

Linköpings universitetInstitutionen för datavetenskap 1

Del I

Gemensamma erfarenheter och diskussion

1 Inledning

Denna kandidatrapport sammanfattar gruppens arbete mot kund i syfte att utveckla en webbshopfrån grunden med begränsade förkunskaper inom området. Rapporten behandlar frågeställning-ar kring uppdraget och svarar på dessa genom insamling av teori som sedan sätts på prov genomimplementation. Avslutligen redogörs och diskuteras det uppnådda resultatet.

1.1 Motivering

I princip alla väletablerade företag idag har någon slags webbplats, varav många är till förförsäljning. Bara i Sverige såldes det varor för runt 42,9 miljarder kronor över nätet under 2014,vilket är en ökning med 16 % från tidigare år [1]. Denna ökning har varit nästan linjär i flera år,och ser ut att fortsätta vara det i framtiden. Denna rapport tar därför upp tillvägagångssätt ochproblem vid utveckling av en webbshop.

1.2 Syfte

Syftet med denna rapport är dels att lyfta fram svårigheter som kan uppstå i ett projekt då manarbetar i en medelstor grupp mot kund, dels att på ett objektivt sätt ge svar på frågeställningarnai avsnitt 1.3 genom att belysa moment i projektet som vållat särskilda problem.

1.3 Frågeställning

1. Vilken utvecklingsmetodik är lämplig att använda med fokus på flexibilitet?

2. Vilka för- och nackdelar finns det med att utveckla en webbplattform från grunden jämförtmed att använda en befintlig lösning?

1.4 Avgränsningar

Front-end ska vara implementerad i Twitter Bootstrap, JQuery och JavaScript. Back-end i sintur ska använda Flask som är ett Python-ramverk.

2Linköpings universitet


2 Bakgrund

Uppdraget från kund, Susan Szatmáry, var att bygga en webbplats med uppvisning och försälj-ning av modeaccessoarer från kundens egna märke.

Susan Szatmáry har i över 10 år jobbat som frilansande designer över hela världen för kändamodeföretag som Alexander MQueen (Gucci) och Celine. Hon vill nu börja utveckla sina egnaprodukter under sitt eget varumärke och sälja dessa via webben. Då Susan är designer läggerhon stor vikt vid utseendet av hemsidan då hon vill att hennes produkter ska vara i fokus vid ettbesök på webbplatsen.

Funktionellt är det viktigt att kunna uppdatera innehållet snabbt och enkelt från webben ochmobilen. Eftersom webbsidan efter projektet ska lämnas över till och kunna drivas av kundensjälv ställs stora krav på att det ska vara enkelt att förändra innehållet från någon typ av admi-nistrationsgränssnitt.


3 Teori

Detta kapitel behandlar teori som är relevant för projektets frågeställning.

3.1 Systemutvecklingsmetoder

Här beskrivs de systemutvecklingsmetoder som användes i projektet.

3.1.1 Scrum

Scrum är en agil metod för systemutveckling som presenterades för första gången på OOPSLA1995 [2]. Kännetecknande för Scrum är att man har små tvärfunktionella team där arbetet skeriterativt. Iterationerna kallas för sprinter. Dessa varar vanligtvis mellan en och fyra veckor. Tea-men är uppdelade i tre huvudsakliga roller. Överst finns en Produktägare vars uppgifter bestårav att ta emot, hantera och prioritera tillägg och ändringar för produkten man arbetar på. Tarman sedan ett steg ner finner man Scrum Master. Typiska uppgifter som hör till en Scrum Mas-ter är att coacha utvecklingsteamet som denne har under sig samt att se till att de kan fokuserapå det de är bäst på.

Till sin hjälp har ett scrumteam två olika backlogs. En backlog kan man tänka på som en or-derstock av saker som ska göras. Produktägaren har en produktbacklog som är en samlingsplatsför alla önskemål om förändringar på produkten. Dessa förändringar prioriteras av produktä-garen. Utvecklingsteamet och Scrum Mastern har en egen backlog som kallas sprintbacklog.Sprintbacklogen består av uppgifter eller funktioner som ska slutföras innan sprinten är slut ochmedlemmarna i utvecklingsteamet får under sprinten själva välja bland dessa. De är alltså inteprioriterade i samma mån som uppgifterna på produktbacklogen.

3.1.2 Kanban

Kanban är ett japanskt ord som betyder skylt eller visuellt kort. Kanban är en arbetsmetod somToyota först tog fram. Det är en agil metod där man arbetar enligt lean som är en filosofi omhur man hanterar resurser. Arbetar man enligt lean försöker man optimera utnyttjandet av deresurser man har till sitt förfogande. Kanban handlar i stort om att visualisera sitt arbetsflödeoch bryta ner arbetet i delar. Dessa delar sätter man sedan på en vägg som man delat upp ikolumner som man gett olika namn och där man har begränsat hur många kort som det får varai en kolumn samtidigt [3].

3.2 Kommunikationsverktyg

Här beskrivs de kommunikationsverktyg som användes under projekt.



3.2.1 Slack

Slack [4] är ett kommunikationshjälpmedel för grupper, skapat av Stewart Butterfield. Det bör-jade som ett internt kommunikationshjälpmedel inom hans företag, men lanserades för allmän-heten i augusti 2013. Slack finns tillgängligt som webbversion, men även som app för Mac, iOSoch Android. Det Slack gör är att minska antalet verktyg som används inom kommunikation, dådet i princip ersätter den funktionalitet man får ut av sms, Skype (eller liknande chat-program)och mail. Slack går även att integrera med andra program, såsom Google Docs, Dropbox ochGitHub, så att man till exempel kan få en notifikation om något ändras på någon branch.

3.3 Utvecklingsverktyg

Här beskrivs de utvecklingsverktyg som användes under detta projekt.

3.3.1 Trello

Trello är en nätbaserad tjänst som låter personer, grupper och organisationer organisera sinaprojekt. På Trello går det att skapa ett Trello board, vilket är en lista med kategorier, där varjekategori är en lista med aktiviteter. Då det är väldigt enkelt att koppla ihop personer med varjeaktivitet och flytta aktiviteter mellan olika kategorier så är det ett väldigt kraftfullt verktyg förplanering och organisering av projekt [5].

3.3.2 Gulp

Gulp är en task runner, ett program som tar källfiler och omvandlar dessa till vad användarenönskar med hjälp av diverse tillägg [6]. Det använder sig av så kallade pipes för att föra kodenfrån ett tillägg till ett annat. Gulp gör detta automatiskt när någon av de filer den övervakar änd-ras. Gulp har plugins som kan användas till att till exempel uppdatera innehållet på en webbsida,synkronisera innehållet mellan olika webbläsare, konkatenera kodfiler till en fil och minifierakoden.

3.3.3 Bootstrap

Bootstrap är ett open source framework för webbapplikationer [7]. Det består i huvudsak avmallar för HTML och CSS, men det finns även tillägg för JavaScript. Bootstrap underlättarutvecklandet av dynamiska och responsiva webbapplikationer genom att bistå med mallar somskalar om sig för olika skärmstorlekar.

3.3.4 Npm

Npm är en pakethanterare för JavaScript och är standard för Node.js [8]. Den gör det enklareför användare att dela och återanvända kod. Den underlättar också uppdatering av delad kod.


3.3.5 Pip

Pip är en pakethanterare som används för installation och hantering av paket som är skrivnai Python [9]. Namnet Pip är en rekursiv akronym för Pip installerar paket. Fördelen med attanvända Pip är att det är lätt att installera och avinstallera paket genom att använda bara ettkommando. Pip kan också hantera flera paket samtidig med hjälp av en textfil.

3.3.6 Bower

Bower är ett open source pakethanteringssystem som används inom webbprogrammering föratt utveckla front-end [10]. Det underlättar installation och uppdatering av olika bibliotek ochramverk. Ett av de olika paket som Bower tar hand om och som vi använder är Bootstrap (seavsnitt 3.3.3). Bower kräver Node.js och installeras därför med Npm (se avsnitt 3.3.4).

3.3.7 Flask

Flask [11] är ett ramverk för webbapplikationer, byggt för Python och baserat på Python-verktygen Werkzeug [12] och Jinja 2 [13]. Flask kallas även för ett mikroramverk, då det haren liten, enkel kärna som istället är väldigt påbyggbar. Det varken kräver eller gör några an-taganden gällande vilka verktyg och bibiliotek som ska användas. Istället får man till exempelsjälv välja vilken databas som ska användas. Men Flask stöder tillbyggnadspaket vilket gör detväldigt lätt att integrera bibliotek och gör så att man får intrycket att de ingår i Flask.

Den lilla kärnan gör att det är oerhört enkelt att få igång ett fungerande Flask-program, somsedan kan byggas ut med nödvändig funktionalitet. Här kommer ett urval av de externa paketsom Flask går att byggas ut med:

• Flask-Admin - ett paket för att skapa gränssnitt för administratörer.

• Flask-Login - tillhandahåller inloggningsfunktioner och användarsessioner.

• Flask-SQLAlchemy - sköter konfiguration för att smidigt integrera Python-verktygetSQLAlchemy [14], vilket används för databasen.

3.3.8 Sass

Sass (Syntactically Awesome Stylesheets) är ett språk för att skriva formatmallar inom webb-programmering [15]. Kod skriven i Sass kompileras och översätts till vanlig CSS (CascadingStyle Sheets). Det finns två olika syntaxer för att skriva Sass. Från början så ärvde Sass mycketav sin syntax från Haml (HTML Abstraction Markup Language), och använder därför indente-ringar för att separera kodblock och nya rader för att skilja på regler. Dessa filer har filändelsen.sass. Utvecklarna av Sass tyckte dock att koden kändes lite väl främmande för de som hållit påmed CSS tidigare och kände att det var en barriär för de som vill börja använda Sass. Den enklalösningen på detta problem var helt enkelt att införa en ny syntax. Denna är mycket snarlik densom används för vanlig CSS, och använder kolon, semikolon och klammerparanteser för att se-parera på kodblock och regler. Dessa filer har istället filändelsen .scss, och har snabbt blivit denpopuläraste varienten av Sass då den är så enkel att börja använda bara man hållit på med liteCSS tidigare.



Sass utökar CSS genom att förse användaren med funktionalitet som finns i mer traditionellaprogramspråk, speciellt objektorienterade språk, men som inte finns i CSS. Några exempel påfunktionalitet som ingår i Sass är variabler, nästling, mixins (i objektprogrammering en klasssom kan innehålla kombinationer av metoder från andra klasser) och arv. I figur 1 visas hurnästlad kod kan se ut i Sass och hur koden ser ut efter den har blivit kompilerad till CSS.

Figur 1: Exempel på Sass-kod kompilerad till CSS.

Denna funktionalitet gör det enkelt att göra saker som tidigare varit jobbigt och stökigt, och detär därför den används av många webbutvecklare idag.

3.3.9 Docker

Docker är en plattform för utvecklare som hjälper till att bygga, paketera och köra applikationer[16]. Fördelen Docker ger vid utveckling av applikationer är att man kan vara säker på attapplikationen fungerar på exakt samma sätt när man flyttar den till en annan maskin än denman utvecklar på. Detta eftersom en dockerifierad applikation fungerar som en container medalla beroenden och inställningar som körs som en enskild process på värdsystemet.

Frågan är då vad som skiljer en Docker-applikation från vanliga virtuella maskiner som mångaår har varit en lösning för samma problem.

Den stora skillnaden är att när man använder sig av virtuella maskiner, följer det förutom självaapplikationsdatan med otroligt mycket overhead-data i form av hela gästoperativsystemet sommånga gånger mångdubblar storleken av applikationen i sig. Det går också åt prestandaresurserdå värdmaskinen måste hålla igång alla virtuella maskiners bakgrundsprocesser och liknande.

Med Docker kör man istället varje applikation som en isolerad process på värdsystemet, menman delar kerneln med de andra applikationerna enligt figur 2. Man har därför en virtuell ma-skins fördel med isolerade resurser och allokeringsfördelar, men i ett mycket mer portabelt ocheffektivare format.


Figur 2: Virtuella maskiner jämfört med Docker.

3.3.10 React

React är ett open source JavaScript-framework som underhålls av Facebook och Instagram [17].React utvecklades specifikt för att tackla utmaningarna som uppstår i så kallade “En-sides-applikationer” (eng. single-page applications).

En single-page application, härefter SPA, är en applikation som får plats på en “sida” (eng.web page). Målet med denna typ av applikation är att låta användaren få en upplevelse sommer kan liknas med en “native”-applikation genom att låta sidan agera behållare för dynamisktinnehåll. Till skillnad från traditionella webbsidor där statiskt innehåll laddas om, så laddas enSPA endast in en gång. Antingen hämtas all nödvändig HTML, JavaScript och CSS direkt viddenna inladdning, eller så byts kod ut dynamiskt vid behov.

React delar in sidans innehåll i komponenter, där varje komponent specificeras av ett gränssnitt.Detta tankesätt liknar mer traditionell programmering där man skapar sina egna abstraktioner.Det blir även väldigt enkelt att återanvända innehåll. Rätt komponenter laddas in och uppdaterasutifrån användarens interagerande med sidan.

För att ha kontroll över vilka delar på sidan som ska uppdateras använder sig React av en vir-tuell representation av sidans dokumentobjektsmodell (eng. Document Object Model), härefterDOM. Vanligtis ritas sidan om när det sker en förändring hos dess DOM, vilket kan innebäraprestandaförluster. Detta löser React genom att hålla koll på vilka förändringar som sker i denvirtuella DOM:en och bara uppdatera det som är nödvändigt.



4 Metod

Detta avsnitt behandlar de metoder som har använts för att utföra projektets olika faser.

4.1 Förstudie

Projektet inleddes med en förstudie som gick ut på att säkerställa kundens verkliga behov. Dettagjordes genom att gruppledaren, arkitekten och analysansvarig träffade kunden där den ladefram ett förslag till tänkt design. Detta möte lade sedan grunden för arbetet med att försökaformulera kraven på designen i en kravspecifikation för att enkelt kunna kommunicera dessamellan gruppen och kunden. Utifrån dessa krav kunde gruppen därefter arbeta fram aktiviteteroch milstolpar som skulle vara avklarade för att alla krav skulle anses uppfyllda.

4.2 Implementation

Nedan beskrivs hur arbetet utfördes under själva implementationsfasen samt vilka verktyg somanvändes.

4.2.1 Arbetsmetod

Eftersom gruppen består av åtta personer och arbetet sker i iterationer där kunden kan kommamed nya krav valdes en agil arbetsmetod, en kombination av Scrum och Kanban som beskrivitsi avsnitt 3.1.1 respektive 3.1.2. Det Kanban bidragit med är synlighet och att inte arbeta medför mycket olika saker samtidigt. Från Scrum har vi tagit produktbacklogen och sprintbacklogenoch slagit ihop dessa till en backlog, som vi sedan haft på Trello (se avsnitt 3.3.1). Från börjanfanns på Trello endast de aktiviteter som tagits fram under förstudien, men vi har sedan medjämna mellanrum haft möten där vi reviderar backlogen. Utöver mötena där backlogen ses överträffas hela gruppen och handledaren varje vecka där alla får presentera vad de gjort sen förramötet följt av en diskussion av vad som ska göras härnäst.

All versionshantering för såväl dokumentation som kod sköts via ett privat GitHub-konto. Kom-munikationen i gruppen kändes till en början onödigt krånglig, då det användes flera olika kom-munikationsmedel beroende på vald arbetsplats, och man visste inte riktigt var man skulle kollaför att få den senaste informationen. För att på ett enkelt sätt kunna hantera allt informations-flöde mellan medlemmar och olika konton knöts allt samman med hjälp av Slack (se avsnitt3.2.1).

För att göra utvecklingen smidig används programvarorna Gulp, Bower, Npm och Pip (se av-snitt 3.3.2, 3.3.6, 3.3.4, 3.3.5) för att automatisera vissa tidskrävande moment som installation,kompilering och komprimering av filer. Bower används även för att automatisera installationenav program som krävs, och för att Gulp ska klara av att kompilera och komprimera filer krävsdet att man installerar tillägg för just detta. Npm och Pip är pakethanterare som tar hand ominstallation och hantering av respektive JavaScript- och Python-paket.

Det Gulp används för i detta projekt är att:

• Förminska HTML-filer.

• Förminska bilder.


• Göra om Sass-filer (se avsnitt 3.3.8) till CSS-filer.

• Söka efter ändrade filer och automatiskt visa upp dessa ändringar i webbläsaren.

För att sedan göra leveransen av programvaran enkel samt göra arbetet för att konfigurera ochsätta upp hemsidan på en server så snabbt som möjligt använder vi oss av Docker (se avsnitt3.3.9). Vi har då delat upp hela hemsidan i tre olika Docker-containrar. Först och främst encontainer för front-end som kör Nginx [18] som webb- och proxyserver. Denna är det endaen användare kommer kommunicera med då den levererar alla statiska filer samt sköter vi-darebefordring av förfrågningar till back-end-containern. Back-end-containern består av vårFlask-applikation som levereras till front-end med hjälp av Gunicorn [19]. Till detta finns ävenen databascontainer som endast kommunicerar med back-end. Denna består bara av en mysql-server.

Alla dessa byggs automatiskt via ett antal kompileringsscript och går sedan att använda förhosting på valfri webbserver.

4.3 Forskningsmetod

När vi under projektets gång har kommit till punkter där vi behöver ta ett beslut angåendeprogramspråk, verktyg, eller annan lösning på problem, hade vi fördel av att en person i gruppenhade goda erfarenheter av liknande projekt sen tidigare. Detta gjorde att vi sällan körde fast utanatt veta vilken väg vi skulle fortsätta på.

De gånger vi trots allt körde fast, bland annat med hur front-end-routingen skulle fungera, gjordevi simuleringar med små modeller gjorda av flera olika bibliotek, som vi sedan utvärderade föratt komma fram till vilket som passade oss och projektet i helhet bäst.



5 Resultat

I detta avsnitt presenteras de resultat och erfarenheter som gruppen samlat in genom metodernabeskrivna i föregående avsnitt.

5.1 Förstudie

Genom förstudien fick gruppen en översiktlig bild av vad kunden ville ha rent designmässigtgenom ett möte med kunden. Enligt projektbeskrivningen från kunden skulle gruppen tilldelatsen färdig design av webbsidan, men så blev inte fallet. Det gruppen fick ta del av var en presen-tation gjord i PowerPoint där enbart en desktopversion tagits i åtanke. En erfarenhet från dettaär att man inte ska lita på att allt blir som man tänkt sig. Gruppen fick även reda på vilka kravkundens tekniska representant hade på val av programspråk och ramverk.

Gruppens arkitekt tog under förstudien fram ett första utkast på en tänkt arkitektur som kan sesi figur 3, där fokus låg på att tillmötesgå kunden i form av teknikval samtidigt som den skullevara modulär nog för att gruppens medlemmar skulle kunna arbeta på olika delar oberoende avvarandra. Det faktum att arkitekturen togs fram av en enda person ledde till problem senare iprojektet i form av ojämn kunskapsfördelning.

Under förstudien arbetade gruppen fram ramar för hur det fortsatta utvecklingsarbetet skullebedrivas. Saker som versionshantering av kod, utvecklingsmiljöer och dokumenthantering sta-kades ut.

Figur 3: Arkitektur framtagen under förstudien.


5.2 Implementation

Nedan presenteras resultatet från de olika implementationsiterationerna.

5.2.1 Iteration 1

Under iteration 1 togs ett skelett fram för webbsidan med tillhörande back-end. På front-endhade de flesta moduler tillräcklig funktionalitet och design för att visas upp för kund som ettförsta utkast. Även en fungerande routing-funktion för navigering mellan sidorna fanns på platsi detta skede. På back-end fanns ett grovt API på plats för att ta hand om förfrågningar från front-end och vidarebefordra dessa till rätt ställe. Dock fanns det i detta skede ingen kommunikationmellan front-end och back-end. Databasmodeller för de flesta delar i back-end implementerades.Ett enkelt administrationsgränssnitt togs fram för att redigera produkter och inlägg i databasen.

Eftersom arkitekturen var så pass modulär gick arbetena på front-end och back-end att utföraparallellt vilket blev väldigt tydligt under denna iteration då front-end och back-end utveckladeshelt skilda från varandra.

5.2.2 Iteration 2

Under iteration 2 förfinades back-end och front-end vad gäller funktionalitet och design. Påfront-end färdigställdes de flesta moduler funktionsmässigt och kopplingen mellan front-endoch back-end implementerades för att möjliggöra hämtning av information från databasen somtillhör back-end. Administrationsgränssnittets funktionalitet utvidgades till att innehålla funk-tioner för att modifiera och lägga till bilder i databasen och redigera produkter och inlägg.

Under denna iteration hade gruppen mer frekventa möten med kunden för att kunna kommanärmare en slutgiltig design. Att kunden inte reflekterat över en mobilversion av sidans designhar fördröjt arbetet avsevärt.

5.2.3 Iteration 3

Under den sista och avslutande iterationen har sidan blivit helt dynamisk vad gäller innehållsånär som på en logotyp och en huvudmeny vars utseende är statiskt. Administrationsgräns-snittet är helt färdigställt och därigenom kan allt innehåll som kan vara intressant att ändra påhemsidan justeras efter kundens önskemål.

Allt innehåll på hemsidan hämtas nu dynamiskt från back-end via ett API. Administrations-gränssnittet är klart för användning, och användaren kan genom detta själv välja vilket innehållsom ska synas på hemsidan. Funktionaliteten som från början önskades från kund är färdigställdoch produkten är sånär som på några små designjusteringar klar för leverans.

5.2.4 Feedback från kund

Under tidigare iterationers gång hade vi möten med kund för att kunna få feedback på vad sombehövdes ändras och vad som var bra. Feedbacken kunde vara allt från hur upplägget på en sidaska vara till ändringar av textstorlekar. Kombinationen av feedback från kund och att arbeta iiterationer gjorde att man tydligt kunde se hur hemsidan utvecklades.



5.3 Gruppens gemensamma erfarenheter

Detta projekt har varit lärorikt för denna grupp. Majoriteten av gruppmedlemmarna hade aldrighållit på med webbprogrammering tidigare vilket medförde att man behövde utbilda sig inomdet. Förutom att alla fick utbilda sig, tilldelades alla en roll med tillhörande uppgifter, vilketockså var lärorikt.

Att jobba mot en riktig kund var även det en ny erfarenhet. Kunden ställde en del krav varavvissa var väldefinierade medan andra var lösare satta och kunde ändras. Detta passade bra dåvi jobbade agilt och arbetade i iterationer vilket även det var nytt för oss. Parprogrammeringvar något som pratades om tidigt i projektet. Tyvärr började vi dock använda det väldigt sent iprojektet. Det fungerade däremot väldigt bra under den tid som det användes och är något vi tarlärdom av och kan ta med till senare projekt.

Ett privat GitHub repository har varit ett bra versionshanteringsverktyg som har använts flitigt,för att dela med sig av sitt arbete. Detta repository hade vi kod och dokument i, dokumentenskrevs i LATEX som var nytt för oss. Uppdelningen av uppgifter borde ha gjorts tydligare. Vissauppgifter var för stora när man väl började arbeta med dem och man borde ha delat upp demytterligare för att jämna ut storleken av vissa uppgifter.

5.4 Översikt över de individuella utredningarna

Allt som ingår i Del II av den här rapporten tillhör de individuella utredningarna. De beskriverforskningsprojekt som varje gruppmedlem utförde enskild under projektets gång.

Avsnitt A är skrivet av Johannes Klasson. Det behandlar frågor kring hur projektplanering inomprojektgrupper kan skilja sig från varandra, men snuddar även vid hur teamledarens roll kan seut i jämförelse med projektledarens.

Avsnitt B är skrivet av Jakub Binieda. Det beskriver en utredning som handlar om att jämföraolika dokumenthanteringsmiljöer och hitta en som skulle vara bäst anpassad för dokumentskriv-ning.

Avsnitt C är skrivet av Sebastian Sundin. Det handlar om hur krav av hög kvalitet tas framoch varför de är viktiga.

Avsnitt D är skrivet av Daniel Sjövall. Det handlar om hur man kan använda React som ramverkvid utveckling av en ny webbplats.

Avsnitt E är skrivet av Jonas Tarassu. Det är en utredning om huruvida det är möjligt eller inteatt använda Npm istället för Gulp eller andra liknande byggautomatiseringsverktyg för bygg-automatisering. Rapporten trycker på för- och nackdelar med att använda Npm gentemot andramer uppgiftsspecifika program.

Avsnitt F är skrivet av Harald Pettersson. Det handlar om testning i ett medelstort projekt.

Avsnitt G är skrivet av Johan Lindberg. Det beskriver en utredning som handlar om kvalitetoch hur det kan uppnås i ett programvaruutvecklingsprojekt.


Avsnitt H är skrivet av Tomas Doverfelt. Det handlar om tillvägagångssätt vid webbutvecklingför flera platformar.



6 Diskussion

Detta kapitel diskuterar metoden och resultatet, men även arbetet i ett vidare sammanhang.

6.1 Resultat

En del av den funktionalitet som planerades in i förstudien av projektet utfördes aldrig, då kun-den kände att hon ville vänta med att lansera betalsystemet. Funktioner som ej utvecklades ärbland annat betallösningar och kundkorg. I övrigt är all tänkt funktionalitet antingen färdig, el-ler nästan klar.

Det fanns även en hel del funktionalitet med som kunden inte själv insåg att den behövdesfrån början, speciellt vad som gäller ändring av innehåll då projektet var över och innehåll påmobila enheter. Det förstnämnda försökte förklaras för kunden, men det som kändes uppenbartför oss var långt från uppenbart för en modedesigner, och det var inte innan admingränssnittetbörjade demonstreras som det på riktigt sjönk in. Detta orsakade dock inga problem för utveck-lingen, då projektgruppen var väl medveten om vad som behövdes och kunde utföra detta förkundens bästa.

6.2 Metod

En stor del av arbetet byggde på att vi trodde att vi skulle ha fått en ordentlig och tydlig designfrån kunden, och arbetet lades initialt upp utifrån detta. Vi hade uppfattningen att kunden skulleta in en webbdesigner, då det i beskrivningen av projektet stod “Designen kommer att definie-ras av en professionell webbdesigner från modevärlden...” [20]. Den design vi fick var dockundermålig och hade många brister, speciellt vad gäller dynamiskt innehåll och design på olikaplattformar. Detta gjorde att vi var tvungna att ha många möten med kunden för att klargörahur hon ville att hemsidan skulle se ut. Det hade varit bättre om vi redan från början hade insettdetta, och då tillsammans med henne tagit fram en design som hade kunnat ligga som grund tillhemsidans utseende. Med detta sagt är det bra att vi kunnat iterera resultat och feedback frånkunden.

6.2.1 Implementation

Under projektets gång har en kombination av Scrum (avsnitt 3.1.1) och Kanban (avsnitt 3.1.2)använts. Hade Scrum använts så strikt som möjligt med Scrummöten, produktägare, ScrumMaster, produktbacklog och sprintbacklog hade vi troligen fått ett bättre flöde i vårt arbete.Speciellt om vi hade delat upp våra stora iterationer i mindre på kanske en eller max två veckor.

Arkitekturen med React (avsnitt 3.3.10) och Flask (avsnitt 3.3.7) är kanske inte helt nödvändigdå React är betydligt mycket mer potent än vad vi använder det till i detta projekt. Hade vianvänt en arkitektur utan React hade mer fokus kunnat läggas på webbsidans design som ikundens ögon är det absolut viktigaste. Flask däremot har varit väldigt smidigt att jobba med dådet tillsammans med alla tillägg som finns tillgängliga kan skräddarsys precis efter behov.


6.3 Arbetet i ett vidare sammanhang

Här diskuteras arbetet ur andra aspekter än de tekniska, som resterande dokument behandlat.

6.3.1 Etiska och samhälleliga aspekter

Vårt arbete har i sig ingen etisk eller samhällelig påverkan. Men efter att vi är klara med arbetetså lämnas produkten helt och hållet över till kunden, och vad som händer då är bortom vårkontroll. Kunden har möjlighet att lägga upp vad hon vill på sidan, och det finns en risk att vissapersonen kan ta illa upp av innehållet. Detta problem finns dock för alla webbyråer och det gårinte att komma ifrån.

6.3.2 Miljöaspekter

Även om projektgruppen ej har planerat sitt arbete utifrån olika miljöaspekter så har projektethaft en minimal påverkan på miljön. All produktion har skett på varje gruppmedlems egnadator, och den enda miljöpåverkan dessa haft är den el de har använt. Efter överlämning tillkund kommer hemsidan behöva ligga på en server någonstans, och även denna kommer att drael. Utöver detta så kommer all den miljöpåverkan som projektgruppen har vara försumbar.



7 Slutsatser

I detta avsnitt besvaras de initiala frågeställningarna.

7.1 Flexibel utvecklingsmetod

I detta projekt har kunden haft åsikter och förslag på förändringar ända in i det sista, vilket harställt höga krav på flexibel kod och ett allmänt modulärt system. Genom att arbeta agilt medmetoder från både Kanban och Scrum har vi lyckats dela upp arbetet till aktiviteter som sedanfördelats inom teamet. Genom att ha möten där alla aktiviteter uppdateras och gås igenom harvi haft koll på att projektets framfart inte blir lidande.

7.2 För- och nackdelar med webbplattform från grunden

Vid användandet av en webbplattform som någon annan utvecklat så är man i regel mer låsttill dess funktionalitet. Utvecklar man istället sin egen lösning är det upp till en själv att läggatill den funktionalitet som behövs. Man kan även begränsa sig till att endast lägga till vad sombehövs och således hålla nere kostnader. Dessutom får man också kunskapen om exakt hursidan fungerar “bakom ridån”, det är inget magiskt som bara funkar utan man kan faktiskt litapå att det fungerar som man tror att det gör.

Den uppenbara nackdelen med att göra saker själv är att det tar tid. Om man endast värderar denfärdiga produkten och behöver komma igång fort så är det inte ekonomiskt gångbart att förstsätta sig in i utvecklingen och sedan arbeta på plattformen innan den kan användas.


8 Fortsatt arbete

Gruppen har nu fått en djupare förståelse i arbetet kring webbutveckling och är mer mogen attta det vidare till en annan nivå. Vår kunskap är tillräcklig för att göra ett högkvalitativt arbete påmycket kortare tid än tidigare. Mycket av den kod som redan är skriven går att återanvända dådet mest är design som skiljer sig från olika kunders önskemål. Denna återanvändning gör att vikan hålla en mycket kort produktionstid, till skillnad från de 300 timmar/person som redan harlagts ner på projektet.

Den produkt vi erbjuder är en enkel och dynamisk lösning. Kunden kan själv välja i principallt som ska ingå på sidan genom vårt lättanvända användargränssnitt. Vår första kund var enmodedesigner med mycket begränsat tekniskt kunnande, och hon kunde med enkelhet navigera ianvändargränssnittet för att hitta och välja det hon ville. Senare versioner av produkten kommerkunna finslipas ytterligare för att göra den ännu enklare att använda, och kommer på så sätt varaanpassad för alla, även om kunden själv saknar tekniskt kunnande.

8.1 Marknad

Det sker ständigt att enskilda personer eller små företag vill utvidga sin försäljning av produkterfrån bara en enskild fysisk butik till försäljning över hela landet, eller till och med till flera andraländer. För att göra detta används till stor fördel en webbshop. Då dessa personer oftast saknarden kunskap som behövs för att utveckla en egen webbplats behöver de anlita någon som kanutföra arbetet åt dem. Det finns även efterfrågan på andra sorters webbsidor, och utvecklingenav flera av dessa är relativt liknande.

8.2 Konkurrens

Det finns redan många webbyråer som erbjuder lösningar liknande det vi gjort, och konkurren-sen är ganska stor. För att kunna lyckas måste ens arbete vara av hög kvalitet och man måstehitta något sätt att sticka ut från andra webbyråer. I vårt fall görs detta genom att erbjuda enlösning som ger kunden mycket stor valmöjlighet, då nästan allting väljs dynamiskt, samtidigtsom den kommer vara väldigt enkel att använda.

8.3 Ekonomi

Då projektgruppen helt saknar startkapital kommer gruppmedlemmarna behöva göra en deluppoffringar den första tiden och arbeta helt gratis innan ett första avtal har skrivits på av kun-den. Det kan även vara svårt att direkt börja med alla åtta gruppmedlemmar inom företaget, dådetta leder till att vi antingen får väldigt låga löner under de första uppdragen, eller kräver attvi tidigt lyckas få tag på flera kunder. Det sistnämnda är dock ganska otroligt då marknadenär relativt hård. Lyckas väl projektgruppen etablera sig på marknaden så finns det dock godamöjligheter att utvidga sig och få tillräckligt med jobb för att hela projektgruppen skulle kunnaarbeta med det på heltid.



Del II

Enskilda utredningar

A Projektplanering i ett programvaruprojekt

Detta bidrag är skrivet av Johannes Klasson.

A.1 Inledning

En essentiell del av nästan alla större projekts början är en bra projektplanering, där man räknarin de resurser man har till förfogande för att sedan kunna fördela dem så att kundens behov ochönskemål uppfylls.

A.1.1 Motivation

Då jag själv haft rollen som teamledare så är det av intresse för mig att vidare undersöka team-ledarens roll i ett projekt och hur den kan variera från t.ex en projektledare, som har använtstidigare år i denna kurs. Teamledarens roll är dock väldigt bred, och för att specificera mig när-mare har jag valt att rikta in mig på projektplanering, då den i vårt fall skiljer sig en del från detman kan anse som normalt.

A.1.2 Syfte

Syftet med denna del är att ge läsaren en inblick i hur planering av olika projekt kan utföras,och visa hur planeringen varierar med de olika resurser och förutsättningar som projektgruppentillhandahåller.

A.1.3 Frågeställning

1. Hur skiljer sig projektplaneringen i vetenskaplig litteratur mot den som användes i dettaprojekt?

2. Vilka skillnader finns det i projektplaneringen för en teamledare och en projektledare?

A.1.4 Avgränsningar

Det finns många småvariationer i metoder att planera projekt på och alla dessa kommer ej attbehandlas i denna undersökning.

A.2 Teori

Detta kapitel behandlar hur teorin kring hur projektplanering ofta ser ut inom programvarupro-jekt, specifikt den planering som sker efter att en tidig kundkontakt redan är avklarad.


A.2.1 Aktivitetsstruktur

Det första nästan alla projektledningar gör efter införskaffad information om kundens behovoch önskemål är att översätta dessa till aktiviteter och milstolpar. Här är det viktigt att vetaskillnaden mellan en aktivitet och en milstolpe. En aktivitet är en del av projektet som vararöver en viss tid, medan en milstolpe är det tillfälle då en eller flera specifika aktiviteter har blivitavklarade. En aktivitet kan även vara beroende av att en eller flera andra aktiviteter redan harblivit avklarade. Dessa aktiviteter och milstolpar är sedan ett mycket bra hjälpmedel för bådekunden och medarbetarna för att följa framsteg i projektet.

I större projekt så blir det lätt ett väldigt stort antal aktiviteter att ha kontroll på, och för att fåen bättre överblick över dessa så behöver de struktureras upp på något sätt. Ett av de vanligastesätten att göra detta på är att använda en så kallad work breakdown structure (WBS). Den går utpå att man i en hierarkisk trädstruktur delar upp ett projekt i hanterbara arbetspaket. Exempelviskan man dela upp projektet i flera faser, där varje fas i sig kan innehålla flera steg, och varje stegkan innehålla flera aktiviteter. Ett exempel på detta illustreras i figur 4.

Figur 4: Exempel på en WBS struktur

A.2.2 Tidsestimering

Vill man utöka strukturen ytterligare så kan man utöver beroende av tidigare aktiviteter lägga tillytterligare två parametrar: tidsåtgång för att utföra aktiviteten och ett slutdatum då aktivitetenska vara klar. Med hjälp av dessa tre parametrar så kan man skapa en aktivitetsgraf, där mankan se i vilken ordning varje aktivitet kommer och vilka beroenden den har. Figur 5 visar ettexempel på detta. Man kan tydligt se att både aktivitet 2.1 och 3.1 är beroende av aktivitet 1.3,och man ser även att t. ex. aktivitet 2.2 och 3.2 är helt oberoende av varandra.

För att uppskatta tidsåtgång för hela projektet går det att använda critical path method (CPM).Denna metod går ut på att hitta den längsta vägen, s.k. kritiska linjen, från start till slut i enaktivitetsgraf. För att bättre förklara hur man hittar den kritiska linjen så kan vi återigen titta påfigur 5. Uppenbart är att aktivitet 1.1 till 1.3 är den kritiska linjen, då det inte finns någon annan



Figur 5: Exempel på en aktivitetsgraf

väg att gå. Därefter så delar dock vägen upp sig, och då får man börjar räkna ihop tiden för allaaktiviteter för varje gren i sig. Låt oss säga att aktivitet 2.1 och 2.2 tar 11 timmar tillsammans,och att aktivitet 3.1 och 3.2 tar 17 timmar tillsammans. Då går den kritiska linjen över aktivitet3.1 och 3.2, då denna väg är sex timmar längre än den andra. Eftersom aktivitet 4.1 beror påbåde 2.2 och 3.2 så måste båda dessa vara avklarade innan aktivitet 4.1 kan påbörjas. Dettamedför att den tillgängliga tiden för att klara av aktivitet 2.1 och 2.2 är 17 timmar, trots att debara tar 11 timmar. De sex timmar som skiljer sig mellan den tillgängliga tiden och den faktiskatiden kallas för “slacktid”. Vill man nu uppskatta tidsåtgången för hela projektet så följs heltenkelt den kritiska linjen hela vägen.

A.3 Metod

Vid projektstart möttes teamledaren direkt av uppgiften att strukturera upp projektgruppen ochdela upp ansvarsområden. Som hjälp på traven fanns dessa förbestämda ansvarsområden somlämpade sig bra till projektet:

• Analysansvarig

• Arkitekt

• Utvecklingsledare

• Testledare

• Kvalitetssamordnare

• Dokumentansvarig

• Specialist inom utvalt område


Vanligtvis skulle varje post först och främst ha valts utifrån den enskilde personens kunskapoch erfarenheter för att se till att varje uppgift sköts på det sätt den ska. I detta fallet fanns dockinte denna förutsättningen, då det endast fanns en gruppmedlem med tidigare erfarenheter inomområdet. För att maximalt utnyttja denne persons förkunskaper så valdes han in på den positionsom har mest inflytande på kodens struktur, vilket är som arkitekt. På detta sätt fanns ändå enbra grund att arbeta utifrån för medlemmar utan tidigare erfarenhet. Därefter skulle resterandemedlemmars ansvarsområde väljas, och det enda dessa val baserades på var önskningar frångruppmedlemmar så att alla fick en roll de kände sig bekväma med. Bekvämlighetskänslan kanspela stor roll i en individs arbete och en person är oftast mer produktiv om den är bekväm meddet arbete den utför [21].


Efter att gruppen fått reda på kundens behov så översattes dessa till aktiviteter och milstolpar.För att underlätta att se vem som arbetade med vad så lades alla aktiviteter in i Trello (se avsnitt3.3.1), och stora aktiviteter delades upp i delaktiviteter. Till skillnad från projektledaren så angerinte teamledaren vad varje person ska göra, utan här kunde varje person själv välja en aktivitetoch hela gruppen kunde enkelt se vem som höll på med vad. Alla aktiviteter ordnades även så attdet gick att se vilka tidigare aktiviteter de var beroende av, och genom att dela upp aktiviteternai respektive moduler, så som front-end och back-end, så gjordes en mindre WBS.

A.3.2 Tidsuppskattning

En riktig tiduppskattning för varje aktivitet gjordes dock ej då det kändes som slöseri med tiddå gruppen knappt ens visste hur en aktivitet skulle utföras och definitivt inte hur långt tiddet skulle ta, vilket skulle kunnat leda till att uppskattningarna blivit helt fel. Så även om entidsuppskattning skulle blivit gjord, så skulle den knappast blivit använd ändå. Kursuppläggetgjorde det dock möjligt att göra planeringen på ett sätt mer anpassad för vår projektgrupp, menmindre anpassad för ett projekt i arbetslivet. Det vi först och främst arbetade utifrån var hurmånga timmar vi hade till förfogande, och spred ut dem över de moduler som fanns i projektet.Efter det så gjordes det regelbundet ändringar, om t. ex. gruppen kände att front-end-modulenhalkar efter, så överfördes resurser från back-end för att se till att de låg i fas med varandra.Detta ledde till att om det vid projektets slut hade visat sig att vi ej hunnit med allt vi tänktkunde ändå en fungerande webbplats garanteras, då grunden hade funnits klar för varje modul.

A.4 Resultat

Som projektledare delar man ut arbetsuppgifter till alla gruppmedlemmar, vilket kräver att pro-jektledaren har bra kunskap om ämnet. I annat fall kan aktiviteter göras i fel ordning, en personblir tilldelad en uppgift som den saknar kunskap för att utföra, det kan finnas någon annan merlämpad för uppgiften m.m. På så sätt är en teamledare mer lämpad om kunskap saknas, för dåkan den falla tillbaka på gruppen för att göra dessa beslut. Detta kräver dock en bra samman-hållning i gruppen, och i detta projekt krävde det även ökat ansvar på den enskilde personen,då den själv fick välja sina aktiviteter och ta ansvar över att detta görs på ett korrekt sätt. För enteamledare utan kunskap inom området kan det även vara svårt att hjälpa till om någon kör fastpå sin del, utan kan då enbart hänvisa till gruppmedlemmen med kunskap, eller till någon somjobbar på liknande del.




Den metod som användes för att behandla aktiviteter och strukturera upp dessa får ses somganska standard då den är väldigt snarlik med den i avsnitt A.2.1, men även i tidigare kurserinom projektutvecklingsmetodik.

A.4.2 Tidsuppskattning

De förutsättningar som fanns i detta projekt skiljer sig markant från de som finns för riktigaprojekt, vilket har medfört att även den projektplanering som användes här skiljer sig. Den endaresurs projektgruppen hade till förfogande var 300 arbetstimmar/person, och det var detta somlade grunden till den projektplanering som användes. I riktiga projekt är det istället ekonominsom avgör hur mycket arbetskraft som går att anställa, och på sätt hur många timmar som finnstillgängliga. De har därför som utgångspunkt att minimera antalet timmar att få ett specifiktjobb avklarat på, medan vår grupp hade som utgångspunkt att maximera arbetet på ett specifiktantal timmar.

A.5 Diskussion

Detta kapitel diskuterar metoden och resultatet.

A.5.1 Resultat

Det man märker är hur stor roll personen med tidigare erfarenheter inom området spelade i vårgrupp, och vilken fördel vi hade att ha med honom. Dock så ser man även ett av projektets störstarisker där, vilket är om den personen på något sätt försvinner, vilket skulle lämnat gruppen heltutan tidigare kunskap och gjort att det tagit mycket längre för projektet att komma igång.Då det inte skedde någon riktig tidsuppskattning i projektet gick det inte heller att från aktivi-teterna göra en fullständig aktivitetsgraf. Det blir även svårare att hitta en kritisk linje, då dennästan helt och hållet bygger på tidsuppskattningar. Det finns dock särskilda fall då det går attfinna en kritisk linje utan tidsuppskattning, och det är om man har en väldigt rak aktivitetspla-nering, dvs varje aktivitet endast är beroende av en tidigare aktivitet, och alla aktiviteter på såsätt läggs på en rad i planeringen. Då finns det bara en väg att gå, och denna måste vara den kri-tiska linjen. Så var dock inte fallet i vårt projekt, då det fanns flera enskilda moduler som skullebyggas samman, och medlemmarna vid projektets start tog varsin aktivitet från olika moduleroch började arbeta. Detta går tydligt se i figur 6 där det visas hur varje medlem skapade en nybranch på Git då ett nytt större arbete påbörjades.

Även om det finns flera metoder för att uppskatta tidsåtgång inom ett projekt, så visades sigmånga av dem olämpliga för vårt projekt, och användes därför inte. Ett exempel på detta ärPERT (Program evaluation and review technique) [21]. Den använder sig av normalfördelningoch varians utifrån tidigare liknande arbeten för att uppskatta tidsåtgången. Denna var olämplig ivårt projekt då brist på kunskap inom projektgruppen gjorde att även om det skulle finnas någonnormalfördelning på hur lång tid vissa aktiviteter skulle ta, så skulle dessa ej vara relevanta föross. Ett annat exempel på en metod för att uppskatta tidsåtgång är the delphi technique [22].Den bygger på att flera experter sätter sig ner för att uppskatta tiden, vilket redan där gör denolämpliga i detta projekt då vi är långt från experter inom ämnet.


Figur 6: Graf från Git som visar en del av vårt branch-nätverk.

A.5.2 Metod

Mycket av den information som hämtats in i ämnet är hämtad från de erfarenheter som förvär-vats under min tid i projektet, men även från den forskning som skett parallellt med projektet.Till detta har det använts flera källor för insamling av fakta, där alla har hög trovärdighet då deinnehåller källhänvisningar till den information de skrivit, men är även citerade i flertalet andravetenskapliga artiklar. Det är dock en källa som använts till större del än de andra, Softwareengineering: theory and practice [21], då denna varit rik på information inom området.

A.6 Slutsatser

Den största skillnaden mellan en teamledare och projektledare inom projektplanering är attprojektledaren har mer ansvar och får mer av en ledande roll, vilket även ställer högre krav pådenne. Teamledaren känns lite mer som en vanlig gruppmedlem, och har inte riktigt sammahöga krav på sig som projektledaren.

Den struktur som användes vid aktivitetshantering i detta projekt följer ganska bra vad somkan ses som standard, i alla fall med tanke på projektets storlek. Aktiviteterna samlades in ochstrukturerades sedan upp på ett effektivt sätt. Den stora skillnaden mellan projektplanering idetta projekt och den i vetenskaplig litteratur är det sätt tidsuppskattningen sköttes på. Då dettaprojekt hade annorlunda förutsättningar än vanliga projekt i arbetslivet bestämdes det att envanlig tidsestimation ej skulle göras, utan att projektet istället skulle planeras med fokus på attmaximera det arbete som kunde utföras inom de tidsramar som fanns.



B Dokumentskrivning i olika dokumenthanteringsmiljöer

Detta bidrag är skrivet av Jakub Binieda.

B.1 Inledning

Som dokumentansvarig hade jag till uppgift att välja något ordbehandlingsprogram eller typ-sättningssystem för dokumentskrivning. De olika miljöer som jag fick välja mellan behandlas idet här avsnittet.

B.1.1 Syfte

Syftet med denna analys är att undersöka de olika dokumenthanteringsmiljöerna och jämföraderas fördelar och nackdelar.

B.1.2 Frågeställning

1. Vilka är fördelarna och nackdelarna med de olika miljöerna?

2. Vilka funktionella fördelar finns det beroende på vald miljö och hur kan man med hjälpav de funktionerna följa olika dokumentstandarder?

3. På vilket sätt kan man samarbeta med andra gruppmedlemmar beroende på vald miljö?

B.1.3 Avgränsningar

Inom den här undersökning ska jag begränsa mig till fyra utvalda miljöer, annars skulle under-sökningen bli för bred. De utvalda miljöerna är MS-Word, OpenOffice.org Writer, Google Docsoch en texteditor som använder sig av typsättningssystemet LATEX.

B.1.4 Definitioner

Texteditor [23] - Program som används för att redigera oformaterad text. Texteditorer har oftastbegränsad funktionalitet och ger inte möjlighet att till exempel ändra textstorlek eller typsnitt.Det finns heller ingen möjlighet att se hur dokumentet kommer att se ut efter utskrift. Textedi-torer används oftast för skrivning av programkod.

Ordbehandlare (ordbehandlingsprogram) [24] - Program som används för att skapa doku-ment och spara det på dator, samt skriva ut det på papper om det behövs. Förutom att man kanredigera text kan man också med hjälp av ordbehandlare formatera texten. En stor andel avmoderna ordbehandlingsprogram använder ett grafiskt gränssnitt som underlättar skrivning avdokument. Redigering sker i WYSIWYG-läge som betyder att man på skärmen kan se resultatav förändringar i dokumentets utseende och hur dokumentet kommer att se ut efter utskrift. Detär också en av skillnaderna mellan ordbehandlingsprogram och texteditorer som inte har denfunktionen. De flesta ordbehandlare ger möjlighet att välja mellan olika typsnitt, textfärg, text-storlekar. Många av dem har också andra funktioner som till exempel automatiskt skapande avinnehållsförteckning, ordlistor, referenslistor, sidnumrering. Oftast används ordbehandlare vid


skrivning av brev, rapporter, böcker och så vidare. Några av de mer kända ordbehandlingspro-grammen är MS-Word, OpenOffice.org Writer, Pages.

MS-Word (Microsoft Word) [25] - är ett ordbehandlingsprogram. Det skapades ursprungligenav Richard Brodie för PC-datorer med DOS 1983. Följande versioner uppkom för Macintosh,SCO UNIX och Windows. I början var det ett fristående program, men med tiden blev det en delav Microsoft Office-paketet. MS-Word är nuförtiden en av de mest populära ordbehandlarna.

OpenOffice.org Writer [26] - är en ordbehandlare som ingår i ett gratis kontorspaket somheter Apache OpenOffice. Första versionen kom år 2002. Programet är tillgängligt bl.a. förplattformarna Microsoft Windows, Solaris, Linux och Mac OS X.

Google Docs [27] - är en webbaserad ordbehandlare med möjlighet att dela och kollaborativtredigera dokument med andra personer. Google Docs utseende liknar MS-Word.

LATEX [28] - är ett typsättningssystem baserat på TeX [29]. Skapare av första versionen varLeslie Lamport. Denna version skapades i SRI Internationals forskningslaboratorium och denvar baserad på språket Scribe. LATEXanvänds oftast för skrivning av tekniska och vetenskapligadokument.

IEEE (Institute of Electrical and Electronics Engineers) [30] - är en organisation som bilda-des 1963. Denna organisation bestämmer standarder inom data- och elektroteknik. De bestäm-mer också dokumentationsstandarder som till exempel IEEE 830 som är standard för kravspe-cifikationer.

B.2 Teori

Det finns många verktyg nuförtiden som man kan använda för att skriva olika slags dokument.De mest populära är ordbehandlare som till exempel MS-Word eller OpenOffice Writer. Deär tillräcklig enkla att använda, man behöver inte ha stora datorkunskaper för att kunna skrivadokument med hjälp av dem. Men ordbehandlare är inte de enda verktygen som finns. EnligtAllin Cottrell och Michael Schlotter som har undersökt det ämnet lite grand så finns det bättrelösning. Ett av dem är typsättningssystemet LATEX. I sin artikel, Word processors: Stupid andinefficient [31], försöker Allin Cottrell bevisa fördelarna med att använda LATEX för att skrivadokument. Cottrell tycker att på grund av WYSIWYG blir textförfattare distraherade och foku-serar på typografiska val som de har inte kunskap om. I Development of course material in amulti-author environment [32], skriver Michael Schlotter att sådana ordbehandlare som till ex-empel MS-Word eller OpenOffice Writer är en dålig lösning på grund av att de inte på rätt sättstödjer det matematiska innehållet, de har ingen avancerad layoutfunktionalitet för till exempelbildplacering och de ändrar regelbundet filformat. Samtidigt så tycker de båda två att LATEX ären bra lösning på grund av att det är mer anpassat för dokumentskrivning.

B.3 Metod

Metoden som används för att göra undersökningen uppdelas i två delar. Den teoretiska delenhandlar om att samla information om hur en viss miljö används och sedan jämförs den med and-ra miljöer. I den teoretiska delen undersöks också på vilket sätt man kan samarbeta med andragruppmedlemmar under dokumentskrivande och om det finns möjlighet att utföra nedanståendepunkter:



1. Kunna fastställa dokumentets format

2. Ställa in sidmarginal för hela dokumentet

3. Sätta teckenstorlek för hela dokumentet

4. Ställa in radavstånd

5. Redigera sidhuvud

6. Redigera sidfot

7. Kunna lägga till och formatera sidnummer

8. Kunna skapa innehållsförteckning

9. Kunna skapa tabeller och tabellbeskrivningar

10. Kunna lägga till bilder med bildbeskrivningar

11. Kunna lägga till referenser

Om det visas i den teoretiska delen att det är möjligt att implementera de punkterna i de förut-valda dokumenthanteringsmiljöerna, så måste svårighetsgraden av detta testas i den praktiskadelen. Detta görs genom att skriva ett dokument som följer standarder med hjälp av de olikamiljöerna. För att underlätta jämförelse måste dokumentets utseende vara förutbestämt. Som enmall tas IEEE 830 och modifieras lite för att underlätta genomförandet av uppgiften och för attkunna göra testning av funktionaliteten hos de olika dokumenthanteringsmiljöerna. Nedan finnsen instruktion för hur dokumentet borde se ut.

1. Marginalen ska vara 25 mm på vänster och höger sida.

2. Radavstånd ska vara 1.15 mm.

3. På första sidan (Figur 7a):

• Ett sidhuvud med datum i övre högra hörnet.

• Dokumentnamn i mitten av sidan. Det ska vara centrerad med typsnitt Times NewRoman, fet stil och storlek 30 pt.

• Sidfot med kurskod men utan sidnummer.

4. På andra sidan (Figur 7b):

• Sidhuvud och sidfot som på första sidan.

• Innehållsförteckning


(a) Första sida (b) Andra sida

Figur 7: Bild på hur första och andra sida ser ut

5. På tredje sidan (Figur 8a):

• Sidhuvud som på första sidan. Sidfot ska innehålla sidnummer.

• Inledningsrubrik med rubriknummer. Den ska vara skriven med fet stil, typsnitt Ti-mes New Roman och fontstorlek 14 pt.

• Under rubriken ska finnas text med fontstorlek 12 pt och samma fonttyp som rubri-ken.

• Det ska också finnas en underrubrik med samma parametrar som rubriken.

• Det ska finnas text under den och referensmarkering.

6. På fjärde sidan (Figur 8b):

• Sidhuvud och sidfot som på föregående sidan.

• Referensrubrik utan nummer. Den ska inte ingå i innehållsförteckningen.

• En referens.



(a) Tredje sida (b) Fjärde sida

Figur 8: Bild på hur tredje och fjärde sida ser ut

B.4 Resultat

Nedan följer resultat från de två delarna av undersökningen.

B.4.1 Teoretisk del

Genom att läsa olika dokumentationer och manualer för de olika verktygen visade det sig att ialla dokumenthanteringsmiljöer går det att implementera de 11 punkterna. Google Docs är denenda miljö som inte innehåller inbyggda funktioner för detta och allt måste skrivas manuellt.Detta betyder att om man till exempel implementerar innehållsförteckning så måste man läggatill sidhänvisningar själv och de kommer inte att uppdateras om man ändrar någonting i doku-mentet. Samtidig är Google Docs det enda verktyget som innehåller samarbetetssystem som gördet möjlig att dela dokumentet med andra personer och ändra i den samtidigt i realtid från olikadatorer som är kopplade till Internet.

B.4.2 Praktisk del

Genom att skriva samma dokument i olika dokumenthanteringsmiljöer kunde jämförelse gö-ras. Resultatet blev att MS-Word visade sig vara lättare att använda än OpenOffice Writer ochmer funktionell än Google Docs, men inte lika bra anpassad för dokumentskrivning som LATEX.LATEX är, jämfört med ordbehandlare, svårare att använda i början, men på grund av dess funk-tionalitet är den en bättre lösning för dokumentskrivning än de andra verktygen.


Resultat av dokumentskrivning:

MS-Word: Dokumentet uppfyllde alla punkter från metoden, men det var svårt att implemente-ra referensmarkering i texten.

Google Docs: För att uppfylla alla punkter måste allt skrivas manuellt och det finns ingen möj-lighet att uppdatera sådana delar av dokumentet som innehållsförteckning eller figurnummer.

OpenOffice Writer: Liksom MS-Word uppfyllde den alla punkter men det var väldigt svårtatt implementera innehållsförteckning och referenser jämfört med de andra verktygen.

LATEX: Det gick att implementera alla punkter, men bara memoirklassen gav möjlighet att hafontstorleken större än 24 pt.

B.5 Diskussion

Nedan följer diskussion av resultat och metod.

B.5.1 Resultat

Resultatet från den här undersökningen verkar bekräfta teori att LATEX är en bättre lösning än deandra verktygen.

B.5.2 Metod

Resultatet av den teoretiska delen av undersökning baseras på guider från hemsidor som tillhörde olika företag som har skapat och tar hand om de olika dokumenthanteringsmiljöerna. På det-ta sätt kan man vara säkert att det är korrekt. Det är lite annorlunda när det gäller resultatet frånden praktiska delen som baseras på mina upplevelse och beror på mina kunskaper. På grund avatt jag har använt MS-Word under nästan hela mitt liv så är det enklare för mig att jobba meddet än med OpenOffice Writer som är en ny miljö för mig. Detta kan vara en faktor som harpåverkat mitt omdöme. På grund av att jag programmerar mycket så är det enklare för mig attanvända LATEX. Det är också en faktor som kan påverka resultatet. Även om min kunskap omandra verktyg blev större efter den teoretiska undersökningen så är den fortfarande inte tillräck-lig stor för att resultatet ska vara helt objektivt.

En sak som man skulle kunna göra för att förbättra den här undersökningen är att genomfö-ra den med ett större antal människor som har olika dator- och dokumentskrivningskunskaper.På detta sättet skulle resultatet bli mer allmänt och den mänskliga faktorn skulle komma attpåverka det mindre.

B.6 Slutsatser

Genom att undersöka de olika dokumenthanteringsmiljöerna kom jag fram till att MS-Word ochOpenOffice Writer är ganska lika varandra. De innehåller samma funktioner men OpenOfficeWriter kan kännas lite svårare att hantera. Många av dess funktioner är gömda och det tar lite tid



att hitta dem i början om man har bara använt MS-Word tidigare. Å andra sidan är OpenOfficeWriter ett kostnadsfritt program som alla kan ladda ner och installera. Med både MS-Word ochOpenOffice Writer kan man uppfylla alla punkterna i metodkapitlet. De två dokumenthante-ringsmiljöerna har några fördelar. De är ganska lätta att använda och man behöver inte ha storadatorkunskaper för att begripa hur de fungerar. Det går nästan att göra allt med de två miljöernaoch det underlättar dokumentskrivning. En av de nackdelar som finns är att ibland räcker detatt lägga till ett litet ord och man måste formatera om hela dokumentet för att det ska se bra utigen. Det finns inte någon inbyggd funktion som skulle kunna underlätta samarbete med andragruppmedlemmar.

Google Docs liknar också MS-Word och OpenOffice Writer, men det innehåller inte lika mångafunktioner och det är svårt att uppfylla alla punkter från metodkapitlet på rätt sätt. Till exempelså går det inte att implementera en figurbeskrivning som automatiskt skulle ändra figurnummerom det behövs. Ett annat problem kan vara en innehållsförteckning som efter implementeringinte innehåller sidhänvisning. På grund av detta är det svårt att skriva dokument som skulle upp-fylla olika dokumentstandarder. Det är enkelt att använda och ger möjlighet till ett samarbetemed andra gruppmedlemmar som andra dokumenthanteringsmiljöer inte gör. Det räcker baraatt de personerna som har skapat ett dokument delar det med andra gruppmedlemmar och allakan skriva i det samtidigt i realtid. På detta sättet kan man enkelt se hur alla ligger till och hurmycket är det kvar att göra. Detta orsakar heller inga merge- och versionproblem, som git ellermail skulle orsaka.

En texteditor med typsättningssystemet LATEX skiljer sig mest från de andra miljöerna. För enperson med kunskaper inom programmering borde det vara en enkel miljö att använda. För enutan det kan det skapa problem, men det är inte omöjligt att lära sig. Till skillnad från de andramiljöerna som jag tar upp i den här undersökningen är det inte grafiskt baserat och allt måstegöras genom att skriva och kompilera kod. Detta kan vara en nackdel i början för att man måsteåtminstone bläddra igenom LATEX guiden för att veta hur dess kod ser ut. Fördelen kan vara attall information som man behöver kan man hitta på internet. Liksom i MS-Word och OpenOfficeWriter finns det ingen inbyggd samarbetesfunktion. En av lösningarna som man kan användaär git repository. Problemet med det kan vara att om många personer ändrar i samma fil kan detleda till mergekonflikter. Även om det finns några nackdelar så finns det också ganska mångafördelar som kompenserar alla problem. För det första kan man uppfylla alla punkter som finnsi metodkapitlet. Med hjälp av LATEX kan man göra ungefär allt, det är bara viktigt att känna tilltillräcklig många kommandon. LATEX stödjer det matematiska innehållet och underlättar skriv-ning av olika matematiska formler. En annan fördel är att om man först förbereder formatet fördokumentet, så behöver man inte tänka mer på det för att LATEX kommer i stort sätt fixa allaformatproblem själv.

Slutligen så rekommenderar jag en blandning av två miljöer. Lösningen är att använda GoogleDocs för att skriva innehållet i dokumentet och sedan kopiera det och klistra in i en förberedLaTeXmall. På detta sätt undviker man formateringsproblem och man kan lösa problem medsamarbets- och funktionalitetsbrist. En annan lösning är att använda MS-Word eller OpenOfficeWriter tillsammans med Google Docs. Den lösningen är bäst för dem som tycker att LATEX ärett för komplicerat verktyg.


C Hur krav av hög kvalitet tas fram och varför de är viktiga

Detta bidrag är skrivet av Sebastian Sundin.

C.1 Inledning

För att kunna göra en produkt åt en kund behöver man inte bara veta vad kunden vill ha utanäven vad den behöver, även om den själv inte vet det än. Jag kommer gå igenom hur kravframställs och varför det är så viktigt att de är tydliga.

C.1.1 Syfte

Bland det viktigaste när man gör en produkt är att den gör det den ska. En produkt kan varaväldigt bra på det den gör men det betyder inte att det är en bra produkt. Det är därför viktigtatt veta vad den ska göra och veta detta i detalj. Detta avsnitt kommer att beskriva vad man skaoch inte ska göra, baserat på det jag och min grupp har lärt oss under detta projekt.

C.1.2 Frågeställning

1. Vad är ett bra krav?

2. Hur tar man fram ett bra krav?

3. Angående beskrivning och framtagning av krav i projektet:

(a) Vad har vi gjort bra?

(b) Vad kan vi ha gjort bättre?

(c) Vad ska undvikas i framtida projekt?

C.1.3 Avgränsningar

Medan dessa lärdomar även kan användas inom andra områden så kommer avsnittet vara foku-serat på mjukvaruutveckling.

C.2 Teori

Enligt Goldsmith kan man använda sig av en problempyramid för att ta reda på kundens sannakrav [33]. Den består av sex steg som ska följas i ordning:

1. Identifiera det sanna problemet, möjligheten eller utmaningen.

2. Identifiera de mått som visar att problemet finns.

3. Identifiera de mål som kan visa att problemet har lösts och värdet av att ha löst det.

4. Identifiera orsaken till problemet, eftersom det är det som ska göras något åt.



5. Definiera vad som ska levereras för att uppfylla målen.

6. Specificera hur kraven ska uppfyllas.

Steg 2 till 6 är relativt lätta jämfört med steg 1. Steg 1 är väldigt viktigt och väldigt svårt attuppfylla. Det har därför lagts ner mycket tid för att få fram ett bra system, eller riktlinjer, attfölja.

C.2.1 Svårigheter

Det finns ett antal svårigheter när det gäller att ta fram krav. Följande är några av de problemsom kan uppstå [34]:

1. Begränsningarna i systemet är dåligt definierade eller så ges onödiga tekniska detaljersom kan förvirra, istället för att förtydliga, systemets användningsområde.

2. Kunden vet inte riktigt vad som behövs, har en liten förståelse av vad deras system klararav, har inte full koll på vad problemet är, har svårt att leverera tydliga krav, utelämnarkrav som tros vara självklara, specificerar krav som är i konflikt med vad som egentligenbehövs eller specificerar krav som är otydliga eller otestbara.

3. Kraven ändras under projektets gång.

Alla dessa gör det svårt för projektgruppen att få en tydlig och korrekt bild av vad som ska göras- det är låg kvalitet på kraven.

C.2.2 Lösningsförslag

Det är viktigt att eliminera otydligheter eller sänka risken för att de kan inträffa - att höja kvali-teten på kraven. Detta kan göras på ett antal sätt:

1. Visualisera slutprodukten med till exempel penna och papper eller ett bildbehandlings-program. Huvudsaken är att få med alla funktioner och grundläggande utseende. Dethjälper till att se alla funktioner som behövs så att man inte missar det som vissa kananse är självklart. Detta gäller inte bara för grafiska gränssnitt. Om det är ett programsom gör mycket beräkningar och bara visar svaret så kan funktioner och hur systemet serut på insidan visualiseras. Det ger även projektgruppen något att sträva efter och någotsom de kan jämföra sitt program med.

2. Använd konsekvent språk och uttryck. Om beteckning för en viss del byts utan förklaringkan det uppstå förvirring. Använd gärna det som kunden är bekant med.

3. Dokumentera tydligt och konsekvent så att det är lätt att följa och det inte uppstår för-virring.

4. Om det uppstår förändringar i kraven så skall dessa dokumenteras och även gärna moti-veras. Detta ger en djupare förståelse om vad systemet kommer användas till och huranvändarna kommer att använda det.

Det som dessa löser har mycket med kommunikation att göra. Det ska vara tydligt och detal-jerat, och både kund och utvecklare ska vara överens om kraven. Den enklaste lösningen är attgruppen, eller delar av gruppen, kontinuerligt träffar både kund och användare.


C.3 Metod

Hur man mer i detalj kan applicera de lösningsförslag som anges ovan.

C.3.1 Beskrivning av krav

Kraven ska vara skrivna på ett språk som alla i gruppen kan förstå. Det är bra om gruppeni början av projektet kommer överens om termer som ska användas. Detta för att underlättadiskussioner och minska förvirringar som kan uppstå.

Kraven ska skrivas tydligt och på sådant sätt att det inte finns rum för diverse tolkningar. Om engruppmedlem är det minsta osäker på ett krav ska detta diskuteras och förtydligas.

Kraven ska ha någon sorts prioritetsnivå så det är lätt att se vad som ska fokuseras på. Dessanivåer ska vara baserade på vad kunden önskar och gärna komma från kunden själv.

C.3.1.1 Uppdatering av kravKraven kommer med stor sannolikhet att ändras under projektets gång. Då detta händer skaden officiella kravlistan uppdateras så att gruppmedlemmarna vet vad som gäller. Det ska varabeskrivet vad det nya kravet är, varför det ändrades och gärna även när det ändrades. Grupp-medlemmarna ska även meddelas om att en ändring har skett och vilken det var så de kangranska den och se till så att det inte finns rum för tolkning.

C.3.2 Möten

Att ha möten med kunden, och gärna även användaren, är ett bra sätt att förtydliga vad kundenvill ha.

Under det första mötet är det bra att ha med sig penna och papper. Detta för att kunna skissaupp vad kunden vill ha. Det ger både kunden och utvecklaren en visuell bild och ser till att de äröverrens. Det är även bra till anteckningar som både kund och utvecklare kan skriva ner. Vissakan föredra en dator eller en surfplatta men de är sällan lika smidiga som penna och papper. Detär däremot bra att ha någon med sig, en sekreterare, som kan anteckna det som sägs på en datorför att få lite mer struktur på vad som har sagts, även för att vissa personers handskrift inte alltidär lättläslig.

Till nästa möte ska projektgruppen gärna ha påbörjat de grundläggande delarna av systemet elleren lätt grafisk prototyp, beroende på om projektet följer en top-down- eller bottom-up-metod.Om gruppen ej har en grafisk prototyp så ska de ha utvecklat skissen från första mötet och gjortden lite mer verklighetstrogen. Ännu en gång är det bra att ta med sig penna och papper. Detunderlättar för kunden när hen ska berätta vad som inte stämmer. Efter detta möte ska gruppenha en klarare bild av vad som ska göras och kan därför påbörja produktion på riktigt.

De följande mötena ska helst inte ändra på krav utan vara mer som en uppdatering till kundenför att visa vad gruppen har gjort och få svar på eventuella frågor som gruppen har. Om kundenär nöjd vet gruppen att de kan fortsätta.

Mot slutet av projektet ska gruppen ha en fungerande prototyp som kund och användare fårtesta. Om det är något fel, grafiskt eller funktionellt, är det förhoppningsvis något litet som gårsnabbt att lösa.



De eventuella stora ändringarna av kraven sker, med hjälp av denna metod, i början av projektet.Detta ger projektgruppen god tid att ändra det som behövs.

C.3.2.1 Behandling av mötesdataNär de personer som varit på möte med kund kommer tillbaka till resten av gruppen ska allasätta sig ner och gå igenom vad som har sagts. Detta ska göra så snart som möjligt efter mötetdå allt är färskt i minnet. Hela gruppen blir uppdaterade och får en beskrivning på vad som skagöras. De gruppmedlemmar som inte var med på mötet kan här även be om förtydliganden somförhoppningsvis kan lösas med ett e-mail eller telefonsamtal till kunden.

C.4 Resultat

Med hjälp av de metoder som har angivits ovan kommer kraven att vara tydliga för alla inblan-dade, de kommer att följa kundens önskningar, och det finns inget rum för tolkningar. Dessakrav, om följda och avslutade, kommer att leda till en produkt som kunden är nöjd med.

C.5 Diskussion

Detta kapitel behandlar diskussion kring resultat och metod.

C.5.1 Resultat

Detta område är väldigt svårt med tanke på att det är människor inblandade, människor sominte är perfekta och skiljer sig väldigt mycket från den ena till den andra. Det är inte alltid dettaresultat kommer att inträffa.

Denna undersökning borde ha påbörjats redan i början av projektet för att kunna fokusera merpå de metoder som nämns. Det som är skrivet i denna del är taget från publicerade verk ocherfarenheter, inte på personliga undersökningar. Detta gör att de metoder som nämns inte haranvänts till fullo då det kräver mycket arbete i början av projektet. Det som kan göras i detta sta-dium är att jämföra vad vi gjort med det som undersökts i efterhand. Detta gör att en bedömningav metoderna inte kan utföras tillräckligt mycket för att diskutera resultatet.

C.5.2 Metod

Visualisering har varit väldigt viktigt för kunden i detta projekt. Det har därför varit viktigt attvisa vad som har hänt med produkten mellan mötena och även att låta kunden kunna testa den.Kommunikationen mellan gruppen och kunden har varit lite problematisk då den ena parten intealltid förstår vad den andra menar. Detta har lett till ett större behov av möten än tidigare tänkt.

På möten med kund så har större delen av gruppen varit närvarande. Detta för att få så mångaögon och öron som möjligt som kan uppfatta saker och på så sätt öka chansen att uppfattakorrekt. Då det är många närvarande får fler svar på sina frågor direkt utan att någon behövervidarebefordra frågor från gruppmedlem och svar från kund och kanske tappa något på vägen.Att ha många frågor leder även till tydligare krav från kund. Då kunden inte har varit säker påvissa delar uppskattas förslag och förklaringar, även detta underlättas med många närvarande.


Förslaget om att använda penna och papper för att skissa prototyper hade inte fungerat så bra idetta projekt då kunden var noga om att se slutprodukten, inte bara skisser. Det har dock hjälptvid beskrivning av problem, dels för att göra det tydligare vad som menas och för att kunna tamed sig de papper man har skrivit på och analysera dem efter mötet.

Det blev mer och mer frekventa möten i slutet av projektet. Detta skulle ha kunnat undvikas omkraven hade varit bättre framtagna i början.

C.6 Slutsatser

Ett bra krav är ett som alla inblandade förstår och håller med om. Detta går att ta fram genomatt ofta ha kontakt med kund och diskutera inom projektgruppen. De ovanstående arbetssättenska följas för att göra detta på bästa sätt.

I projektet har det funnits många osäkerheter vilket har lett till diffusa krav. Grunden som togsfram i början har bestått genom större delen av projektet men funktionalitet och utseende påhemsidan har ändrats då och då.

Att redan i början ha många möten med kunden, gärna en gång i veckan, hade hjälpt oss myck-et. Om denna rapport och undersökning hade börjats tidigare hade vi vetat detta. Nu vet vi iframtiden att för att få krav som vi kan lita på ska möten hållas i början av projektet.



D React, the V in MVC

Detta bidrag är skrivet av Daniel Sjövall.

D.1 Inledning

De första hemsidorna som kom till webben bestod av enkla textsidor, kanske med enstaka färger.Detta skiljer sig otroligt mycket från dagens enorma system och webbapplikationer där sidorska laddas dynamiskt, innehåll ska plockas ut från databaser, manipuleras och visas upp samtatt användaren ska kunna påverka vad som visas via olika användarinteraktioner. För att lösaallt detta använder man till stor del JavaScript, men för att slippa återuppfinna hjulet för varjeny hemsida går alltmer webbutveckling mot att bygga hemsidor på existerande ramverk. Dessakommer oftast som helhetslösningar, och brukar kräva att du följer hela designmönstret Model-View-Controller, hädanefter MVC. React, ett förhållandevis nytt JavaScript-ramverk utvecklatav Facebook, går mot strömmen genom att bara lösa view-delen och överlåter sedan valet åt dighur du vill bygga resterande delar [17].

D.1.1 Syfte

Syftet är att jämföra fördelar med nackdelar när det kommer till att använda React som ramverkistället för någon helhetslösning, vid utvecklingen av en ny webbplats.

D.1.2 Frågeställning

1. Vad finns det för fördelar/nackdelar med MVC?

2. Vad tjänar man på att använda React istället för en helhetslösning?

D.1.3 Avgränsningar

Rapporten syftar enbart till att besvara frågorna ur ett webbutvecklingsperspektiv för en webb-plats utvecklad av 6-8 personer under ett antal månader.

D.1.4 Bakgrund

Jag har sedan tidigare utvecklat flera hemsidor både enligt MVC-modellen och på annat sätt.Detta gör att jag redan har viss erfarenhet av hur utvecklingen av projekt, och i det här falletframför allt webbplatser, går till och hur man kan förvänta sig att projektet blir om man inteföljer någon speciell modell.

Jag har under mina tidigare projekt också testat på några helhetslösningar för utveckling avfront-end, till exempel AngularJS, som strängt förespråkar och faktiskt tvingar utvecklaren tillatt följa MVC-modellen vilket bidrar till att jag kan jämföra de nya resultaten med mina gamlaerfarenheter [35].


D.2 Teori

D.2.1 Model-View-Controller (MVC)

MVC är ett designmönster som går ut på att dela upp applikationen i flera lager:

Modellagret utgör en representation av de data som applikationen arbetar med. I detta lageringår bland annat databasstrukturen för applikationer med databas.

Viewlagret kan oftast ses som själva användargränssnittet, alltså det man ser när man går in påen hemsida.

Controller är lagret som reagerar på händelser som interaktioner från användaren. Det är ocksåcontrollern som gör förändringar i model och viewlagren.

Figur 9: Ett exempel på hur kommunikationen kan ske enligt MVC.

Man ser i Figur 9 att Controllern fungerar som länken mellan Model och View, beskrivet somheldragen linje. De streckade linjerna beskriver indirekta länkar, till exempel genom observers.

Nedan har vi ett exempel på hur filstrukturen kan se ut i ett projekt som följer MVC:

app /�� c o n t r o l l e r s /�� m a i n C o n t r o l l e r . j s�� o t h e r C o n t r o l l e r . j s�� d i r e c t i v e s /�� m a i n D i r e c t i v e . j s�� o t h e r D i r e c t i v e . j s�� s e r v i c e s /�� u s e r S e r v i c e . j s�� i t e m S e r v i c e . j s�� j s /�� b o o t s t r a p . j s�� j q u e r y . j s�� app . j s



v iews /�� mainView . h tml�� o the rView . h tml�� i n d e x . h tml

Fördelar man får genom att använda sig utav designmönstret MVC är att det delvis blir lättare attfelsöka applikationen, delvis lättare för en efterträdare eller annan utomstående att sätta sig in iden. Man kan också enklare förändra utseendet utan att ändra datastrukturen och logiken [36].

D.2.2 Document Object Model (DOM)

När man laddar en hemsida så skapar webbläsaren en DOM av all data den får från servern. Närinternet fortfarande var ungt så behövde man ladda om sidan eller bläddra till en annan sida föratt denna DOM skulle kunna ändras. Då detta lätt blev lite tråkigt började man använda sig avJavaScript för att modifiera denna DOM i efterhand.

D.2.3 React

JavaScript har vuxit så mycket under dessa år att bibliotek och ramverk har börjat bli enorma,men också kraven på vad en hemsida ska kunna göra. Detta ställer höga krav på prestanda ochhar rentav börjat bli ett problem då en DOM är ganska långsam att arbeta med.

React påstår sig ha hittat en lösning på detta. Vad som görs är att React bygger en virtuell DOMsom alla ändringar görs i. Denna är extremt snabbarbetad eftersom den inte behöver rita ut någotpå skärmen. Ett antal gånger per sekund jämförs sedan denna virtuella DOM med den riktiga,och React byter sedan ut de delar som skiljer sig åt.

Vad som också gör React unikt är att det bara fokuserar på att lösa view-delen, till skillnad frånde flesta andra ramverk som försöker lösa hela MVC-strukturen.

D.2.4 AngularJS

AngularJS är till skillnad från React en helhetslösning som står för både M, V och C-delen. Detär utvecklat av Google och försöker förenkla både utvecklingen och testningen av webbappli-kationer och följer strängt MVC modellen.

En stor skillnad mot React är att allt måste vara skrivet “The Angular way” vilket innebär atthela applikationen måste skrivas om ifall man vill implementera AngularJS i ett senare skede.

D.3 Metod

Här tar jag upp vilka metoder jag använt mig av för att komma fram till resultatet.

D.3.1 MVC

Genom att vi utvecklat detta projekt enligt MVC-modellen har jag kunnat undersöka vilka de-signval som gjorts annorlunda samt hur dessa har påverkat projektet i helhet och jämfört dessamed hur utvecklingen hade gått till om vi beslutat oss för att inte följa någon speciell utveck-lingsmodell.


D.3.2 React

Då vi utvecklat hela användargränssnittet i React har jag även kunnat se vilka fördelar ochnackdelar det har gett oss jämfört med tidigare projekt som jag gjort med helhetslösningenAngularJS.

D.4 Resultat

Här tas resultaten upp som jag kommit fram till utifrån de tidigare beskrivna metoderna.

D.4.1 MVC

Att följa MVC-modellen gav många fördelar som bra översikt genom att bryta ut logiken frångränsnittskoden och välstrukturerad kod då man redan från början vet exakt vart man ska placerafunktioner, och det gav få egentliga nackdelar.

D.4.2 React

Det är enkelt att komma igång med att skriva kod och det går fort att nå resultat i ett biblioteksom React. Det är också lätt att lära sig. Att dela upp gränssnittet i småkomponenter ger en braöverblick och gör det lättare att förstå vad som händer var.

D.5 Diskussion

Nedan följer diskussion av resultat och metod.

D.5.1 Resultat

Jag finner att MVC-modellen är ett designmönster som egentligen passar alla projekt och somgår att applicera på nästan all programutveckling som har med användargränssnitt att göra. Dockkan det i väldigt små projekt möjligtvis bli lite för uppdelat och på så vis framkalla en negativeffekt. Det känns också som ett allmänt sunt sätt att dela upp koden på.Jag fann också React vara ett välgenomtänkt ramverk som är väldigt enkelt att komma in i, dockfinns det också vissa faror med att använda sig av ett så öppet ramverk. Då det inte finns någonstandard eller rekommenderad väg att gå kan det lätt, för en oerfaren utvecklare, bli svårt attkoppla ihop ordentligt med resten av webbplatsen och få en ordentlig struktur på det hela. Därgör helhetslösningar som AngularJS en tjänst genom att det ofta automatiskt leder till att kodskrivs på rätt sätt.

D.5.2 Metod

Då jag inte gjort exakt samma projekt flera gånger med olika designmönster och olika ramverkkan jag inte rakt av jämföra resultaten från detta projektet med mina tidigare. Jag har helleraldrig utvecklat i en grupp av likvärdig storlek vilket också kan påverka.Jag kan tänka mig att i en grupp av denna storlek blir det desto viktigare med ett tydligt förbe-stämt designmönster.



D.6 Slutsatser

Det finns absolut fler fördelar än nackdelar med att följa MVC-modellen och jag ser egentligeningen anledning till att inte följa den om man inte gör ett väldigt litet projekt på bara ett fåtalpersoner. Den löser också filstruktur och kodstruktur redan från början så man har alltid koll påvad som ligger vart.

React ger också många fördelar men med det sagt, går det absolut inte att säga att det är denbästa vägen att gå. Det är smidigt att man i princip kan slänga in React lite när man vill ochbehöver inte anpassa hela projektet efter det, men det kan också vara bra att ha en helhetslösningsom faktiskt är beprövad och som leder till att koden skrivs på rätt sätt. Man behöver också haganska grundläggande tidigare erfarenhet för att kunna ta bra beslut angående de andra delarnaav projektet för att kunna utnyttja React fullt ut. Bara en sådan grundläggande sak som Routingär något som inte finns med i React från början och som kan bli problematiskt om man inte vethur det ska hanteras.


E Npm som byggautomatiseringssystem

Detta bidrag är skrivet av Jonas Tarassu.

E.1 Inledning

Denna del av rapporten är tänkt att ge en övergripande bild av innehållet i stort. En motiveringges följt av syftet. Efter detta presenteras frågeställningarna tillsammans med de olika avgräns-ningarna.

E.1.1 Motivering

Mjukvaruindustrin kräver idag att man går från idé till färdig produkt väldigt snabbt, det kantill och med innebära skillnaden mellan att lyckas eller misslyckas [37]. För att detta ska varamöjligt krävs det att man vid utveckling har system som sköter tidskrävande uppgifter. Till des-sa uppgifter hör bland annat kompilering, länkning och testning. Kan man automatisera dessauppgifter kan de som programmerar fokusera på det de är bäst på, nämligen programvaruut-veckling. Detta har gjort att utvecklingen av programvaror som automatiserar arbetet har skenatoch idag finns det en stor mängd olika varianter som alla är mer eller mindre olika varandra.Behövs alla dessa eller klara man sig gott med enklare varianter?

E.1.2 Syfte

Denna rapport syftar till att besvara huruvida Npm kan utföra samma uppgifter som mer upp-giftsspecifika program så som Gulp för att slippa ytterligare ett beroenden. Detta görs genomatt utifrån en förutbestämd uppgift konfigurera Npm så att den löser en uppgift som Gulp medsäkerhet kan lösa. I stort är det sex olika uppgifter som ska utföras, dessa är följande:

• Göra om filer i SCSS-format till CSS-format och komprimera dessa

• Ta bort tomrum och kommentarer från HTML-filer

• Minimera bilder

• Göra om React-filer till JavaScript

• Flytta resultatet av samtliga ovanstående samt övriga relevanta filer i källkodsmappen tillen mapp för statiska webbfiler

• Uppdatera filerna i mappen för statiska webbfiler vid förändring i källkodsmappen

E.1.3 Frågeställning

1. Kan man uppnå samma resultat med Npm som med mer uppgiftsspecifika program somGulp när det gäller att automatisera tidskrävande uppgifter?

2. Hur kan en sådan lösning se ut?

3. Vad kan det finnas för för- respektive nackdelar med att använda den ena eller andralösningen?



E.1.4 Avgränsningar

Rapporten syftar till att besvara frågeställningarna enbart gällande webbutveckling av front-endoch filer relevanta för densamma.

E.2 Teori

I detta kapitel kommer teori tas upp som krävs för att läsaren ska kunna tillgodose sig materi-alet i denna rapport. Kapitlet inleds med en liten snabb introduktion till vad byggautmatiseringär och hur den växt fram och varför. Efter detta presenteras olika verktyg och metoder somanvänds inom området innan kapitlet avslutas med ett mindre exempel på hur början till ettbyggautomatiseringssystem kan se ut.

E.2.1 Byggautomatisering

Byggautomatisering syftar till att automatisera tidskrävande uppgifter som mjukvaruutvecklareställs inför. Typiska uppgifter kan vara att kompilera och testa kod samt att sätt upp systemetså att förändringar som görs går att se på produktionssystemet. I början av datorns och pro-grammeringens historia använde utvecklare kommandoradskommandon eller små byggskriptför att länka och kompilera filer. Detta är en bra lösning så länge antalet filer och källor inteär för stort. Allt eftersom datorernas prestanda och komplexitet ökade gjorde även mjukvarandet vilket ledde till att utvecklingen av byggautomatiseringsverktyg tog fart. Utvecklare börjadesnart lägga uppgifter som skulle göras före och efter länkning och kompilering som testning ochversionshantering. Byggautomatisering har gått från länkning och kompilering till att innefattaett stort spann av uppgifter även före och efter dessa steg.

E.2.2 Pre- och posthooks

Man brukar benämna skript eller program som körs automatiskt innan eller efter det programman egentligen anropat för pre- och posthooks. Ofta får användaren själv styra över vad somska köras. Inte sällan kan man anropa en hook enbart genom att lägga till ett pre eller post ianropet till huvudprogrammet.

E.2.3 Node.js

Node.js är en open source runtime-miljö byggd i JavaScript som används på serversidan avwebbapplikationer och för olika nätverksapplikationer. En stor fördel med Node.js är att detmesta är asynkront och eventdrivet vilket leder till att Node.js är väldigt bra på att hanterainput-output-uppgifter. Anledningen till att Node.js är så bra på just detta är att strömmar avdata används tillsammans med eventhanterare. Dessa eventhanterare kan konfigureras så attspecifika uppgifter utförs när data är tillgänglig i en ström [38].

E.2.4 Gulp

Gulp är ett byggverktyg byggt ovanpå Node.js som används för att automatisera uppgifter vidprogramvaruutveckling. Gulp utnyttjar nodeströmmar vilket leder till att det inte skrivs och läses


massa onödiga filer till och från disk vilket är tidskrävande och ineffektivt om man ska processadata från ett skript direkt med ett annat vilket fallet ofta är. Detta gör att Gulp klarar av mångauppgifter på kort tid [6].

E.2.5 Npm

Npm är en förkortning för Node Package Manager som är två saker, dels ett digitalt arkiv därutvecklare kan publicera och förvara JavaScript-projekt, men även ett kommandoradsverktygsom används tillsammans med det digitala arkivet [8]. I roten av alla projekt man laddar nermed Npm finns en fil som heter package.json. Denna innehåller information om projektet, somnamn och version, men även om vilka beroenden projektet har, det vill säga alla övriga paketprojektet behöver för att fungera. Utöver detta kan den även innehålla skript som kan se ut enligtnedan:

" s c r i p t s " : {" c l e a n " : " rm � r f . / app "

}

Genom att öppna ett terminalfönster och navigera till mappen med package.json där ovanstå-ende kod ligger och skriva npm run clean kommer kommandot rm -rf ./app som tarbort mappen ./app att köras. Detta faktum tillsammans med att skriptfunktionen stödjer hoo-king gör att man kan bygga upp mer komplexa skript, ett exempel på detta syns nedan:

" s c r i p t s " : {" c l e a n " : " rm � r f . / app " ," p r e c l e a n " : " mkdir . / app " ," p o s t c l e a n " : " echo En mapp t o g s b o r t "

}

Genom att skriva npm run clean i terminalen kommer alla kommandon i skriptet att körasi ordningenmkdir ./app, rm -rf ./app, echo En mapp togs bort. Faktumet att Npm-

skript stödjer hooking kommer utnyttjas i kapitel E.3. Sanningen är att de plugin som görs tillGulp använder sig av skript som återfinns via Npm. Ofta använder man Npm tillsammans medGulp för att ladda ner de plugin som behövs till Gulp.

E.3 Metod

Eftersom det redan är känt att Gulp klarar av den typen av uppgifter som ska lösas har enbarten version baserad på Npm tagits fram. Lösningen är implementerad på OS X Yosemite version10.10.3 där Npm version 2.7.5 använts.

E.3.1 Implementation

I detta kapitel kommer jag att beskriva hur lösningen med Npm är uppbyggd. Alla sökvägarsom används i exempel under detta kapitel är direkt från projektmappen som användes underarbetet med Fashion Web.



Implementationen av byggsystemet baserat enbart på Npm är uppbyggt av åtta olika friståendepaket som alla är hämtade med npm, dessa är följande:

Browserify - Gör om React-filer till vanlig JavaScript samt flyttar dessa till ./app.

Imagemin - Komprimerar bilder och flyttar dessa till ./app/images.

Rimraf - Används istället för rm -rf för att lösningen ska blir plattformsoberoende. Rimrafanvänder sig av Node.js vilket göra det möjligt att använda kommandot på samtliga plattformardär det är möjligt att intallera Node.js.

HTML-minifier - Tar bort tomrum och kommentarer i HTML-filer och flyttar dessa till ./app.

Sass - Gör om SCSS- till CSS-filer och flyttar dessa till ./app.

Onchange - För att kunna upptäcka ändringar i källkodsmappen används ett paket som konti-nuerligt kollar en given mapp/fil och kör ett givet kommando vi förändring i denna mapp/fil.

Mkdirp - Används istället för mkdir för att lösningen ska blir plattformsoberoende. Mkdirpanvänder samma princip som Rimraf ovan.

Browser-sync - Används för att skapa en lokal server som använder filerna i ./app som ska-pats av de övriga paketen för att visa en hemsida med innehåll. Ser även till att synkroniserasidan med filerna så att de hela tiden är det mest aktuella som visas. Det är även möjlig attöppna flera olika webbläsare och gör man någon förflyttning i en webbläsare uppdateras ävende övriga.

Alla paket ligger som devDependencies i package.json för att möjliggöra hantering av upp-datering av dessa med ett kommando nämligen npm install. För samtliga paket så användesden senaste version vid datumet då rapporten skrevs.

Genom att använda pre- och posthooks går byggprocessen att starta med endast ett kommando.Det som görs innan build körs är att att ./app tas bort och mappstrukturen sätts upp pånytt med hjälp av mkdirp. När detta är gjort exekveras build vilket innebär att allt som skafrån källkodsmappen ./src till ./app behandlas och flyttas över dit. Så snart alla filer är påplats aktiveras kontrollen av källkodsmappen och browser-sync körs igång. I Appendix B finnspackage.json för implementationen av byggprocessen med Npm för Fashion Web.

E.4 Resultat

I detta kapitel kommer resultatet från implementationen av Npm som gjordes i kapitel E.3.1 attpresenteras.

E.4.1 Implementation

Genom att använda enbart Npm och paket som är tillgängliga därigenom har jag lyckats få tillen lösning som beter sig likvärdigt som en liknande lösning gjord med Gulp. En lösning kan sesi Appendix B. Detta uppnåddes genom att använda skript-funktionen som finns inbyggd i Npmsamt att jag drog nytta av möjligheten att använda pre- och posthooks. Anledningen till att pre-och posthooks används är för att kunna starta byggprocessen med enbart ett kommando. Genomatt använda paket som gör det möjligt att ta bort och lägga till mappar oavsett operativsystemfungerar lösningen oberoende av operativsystem så länge det är ett POSIX-operativsystem. Justatt det enbart fungerar på POSIX-operativsystem är så klart en nackdel som Gulp inte har. Förvarje ny funktion man vill införa i sitt skript i Npm så tillkommer det två rader, dels en för att


installera paketet dels en för att köra skriptet. Att installera och använda ett skript i Gulp kräverfler rader [39].

E.5 Diskussion

I detta kapitel kommer teorin, metoden och resultatet att diskuteras.

E.5.1 Resultat

Att lösningen inte fungerar på Windows beror på att terminalen inte stödjer &-kommandot sompå ett POSIX-operativsystem tillåter körning av parallella program i ett terminalfönster. Etttänkbart sätt att komma runt detta kan vara att installera Cyqwin som ger tillgång till storadelar av det POSIX-API som behövs för att få en känsla och funktionalitet likt Linux, fast påWindows.

E.5.2 Metod

Genom att faktiskt implementera en lösning och inte bara göra en undersökning och sedanresonera huruvida något är möjligt eller inte kan jag med hög säkerhet dra slutsatsen att Npmfaktiskt går att använda som ett supplement till Gulp. Implementationen är utvecklad på OS Xmen är även testad på Ubuntu 14.04 med framgångsrikt resultat.

E.6 Slutsatser

Det man kanske inte tänker på vid användandet av till exempel Gulp är att man får väldigt mångafler beroenden och plugin att hålla reda på vilket kan leda till stora problem när det släpps enny version av Gulp som väsentligen ändrar sättet Gulp fungerar på. Om så är fallet måste allaplugin som skrivits till den gamla versionen skrivas om vilket i värsta fall kan ta flera veckoreller månader. Visst kan detta ske även med Npm men det är inte alls lika troligt då dess primäramål är att vara en pakethanterare. Faktum är att Gulp ofta används tillsammans med Npm dåstörre delen av de plugin som finns till Gulp återfinns via Npm.

En stor fördel med Gulp jämfört med många andra byggsystem är att det använder sig av ström-mar. Dock är detta en sanning med modifikation eftersom alla plugin inte drar nytta av detta.Men faktum är att en liknande funktionalitet går att få till i bash med hjälp av |-kommandot somskapar en pipeline från stdout av en funktion till stdin på en annan.

Att använda Npm istället för Gulp begränsar antalet beroenden i ett projekt markant och det gåratt uppnå samma funktionalitet med färre rader kod. Att det man gör till Npm inte alla gångerfungerar på alla plattformar är såklart en nackdel. Dock är det kanske något man kan förbiseför att slippa hantera massa olika beroenden och allt underhåll samt komplikationer som kankomma med det.



F Testning i ett medelstort projekt

Detta bidrag är skrivet av Harald Pettersson.

F.1 Inledning

För att uppnå bra, pålitlig programvara krävs mycket testande. Detta kan vara tidskrävande dåvarje förändring ger upphov till att test återigen måste genomföras.Ett verktyg kommer att testas för att se huruvida det är värt att automatisera testning för ettgrafiskt användargränssnitt på en relativt liten hemsida.

F.1.1 Motivering

Testning är något som det pratas mycket om i programvaruutveckling i allmänhet och i syn-nerhet vid agila utvecklingsmetoder. Vid Internets start hade de första hemsidorna en väldigtenkelt struktur och var lätta att testa, kvaliteten låg snarare hos utvecklaren och dennes färdig-heter [40]. Men så är inte längre fallet, hemsidor idag kan vara väldigt avancerade. Men hur detgår till mer konkret är inte lika tydligt. Denna rapport syftar till att klargöra hur testning kan gåtill och att ge mer erfarenhet av testning till utföraren.

F.1.2 Definitioner

unittest - Ett ramverk för testning i Pythons standardbibliotek. Bygger i grunden på java-ramverket JUnit [41].

Selenium WebDriver - Hjälper till att automatisera webbläsare. Kan öppna och operera i devanligaste webbläsarna. [42]

coverage.py - Ett verktyg för att se hur stor del av en kod som har exekverats. Ger en rapportmed vilka rader som exekverats och vilka som inte har gjort det. Det går även att se branch-täckning, så att man kan se hur många olika sätt koden har testats på.

URL - Uniform Resource Locator - är en adress till en resurs på Internet.

F.1.3 Syfte

Att undersöka hur testning kan gå till. För att undersöka detta är två verktyg utvalda, unittestoch Selenium Webdriver. Ska även försöka visa hur enkelt det är att skapa enhetstester.

F.1.4 Frågeställning

1. Hur svårt är det att skapa enhetstester med Python-biblioteket unittest?

2. Hur kan man automatisera testningen för användargränssnitt vid ett relativt litet webbut-vecklingsprojekt, med hjälp av Selenium WebDriver och unittest?

3. Hur står sig detta mot manuell testning?


F.1.5 Avgränsningar

Endast testning för HTML/CSS/JavaScript front-end kommer att undersökas. Testning kommerske via Selenium WebDriver och unittest. Testning kommer ske i Google Chrome och MozillaFirefox.

F.2 Teori

Detta kapitel syftar till att ge underlag och en del förståelse för några koncept och verktyg somanvänds.

F.2.1 Mjukvarutestning

För att undersöka hur ett program fungerar utförs ofta mjukvarutestning av programmet. Vadtestningens mål egentligen är kan vara varierar. Vissa menar att testningens mål är att hitta felså att de kan rättas till [43]. Men testning kan utföras av fler anledningar, såsom att bestämmasystemets kvalitet, ge underlag för beslutsfattning och även för att förebygga fel [44]. Oavsettvilken avsikt man har av sin testning kan man bör man inse hur relevant testning är vid framta-gandet av högkvalitativa mjukvaruprogram.

F.2.2 unittest

Python har i standardbiblioteket ett ramverk för testning, unittest. Klassen och ramverket bidrarmed fyra delar för att göra testning lättare:

• Upplägg av testmiljö - genom att skriva över metoder kan man skapa sin egen testmiljö,med temporära filer och databaser, samt starta serverprocesser. Dessa kan sedan tas bortoch termineras efter att testerna är körda.

• Testfall - genom att ärva från klassen TestCase kan man skapa sina egna testfall. Det ärden klass som bidrar med de metoder som skrivs över för att upprätta testmiljön.

• Testsviter - för att lättare binda samman testfall kan man samla dem i testsviter.

• Test-exekverare - styr hur testen körs och producerar text som beskriver resultaten avtesterna.

F.2.3 Selenium Webdriver

Selenium Webdriver är en uppsättning verktyg för att automatisera webbläsare. Med hjälp avSelenium Webdriver kan man öppna webbläsare, gå till URL:er och interagera med hemsidorpå de flesta sätt en vanlig användare kan. Ett nyckelverktyg är förmågan att identifiera webbele-ment, detta kan göras på flera sätt, till exempel genom att identifiera element med vissa taggar.På detta sätt kan man söka efter och interagera med till exempel länkar eller inmatningsfält.Selenium Webdriver finns för flera olika programspråk och kan användas av flera olika testram-verk. För Python installeras Selenium Webdriver via kommandot pip install selenium.



F.2.4 coverage.py

För att se hur mycket av koden som exekverats via test, kan modulen coverage användas.Den mäter hur många av en kods rader som har körts. Genom att köra Pythonprogram viakommandot coverage run [fil], där [fil] är ett körbart Pythonprogram, och sedancoverage report får man en utskrift på hur mycket av filens kod som exekverats och vilkarader som ej har körts.

F.2.5 BrowserSync

BrowserSync är ett verktyg som synkroniserar filändringar och direkt visar dem på alla webblä-sare och enheter. Den synkroniserar även interaktioner med en av webbläsarna och utför dessaäven på de andra. [45]

F.2.6 Google Chrome

Den mest använda webbläsaren av W3Schools användare april 2015 [46].

F.2.7 Mozilla Firefox

Den näst mest använda webbläsaren av W3Schools användare april 2015 [46].

F.3 Metod

Mycket av metoderna syftar till att ge utföraren erfarenhet av testning, och hur det går till atttesta

Selenium kommer att testas för att se hur det löser olika situationer och hur lätt det är att skapatestfall. Mot detta kommer manuell testning ställas, där man som person sitter och testar genomatt klicka sig fram.

F.3.1 unittest

För att förstå och se hur svårt det är att lära sig unittest kommer test att skapas. Testobjektetför unittest kommer vara filen imagecomp.py, en liten fil med funktioner som skalar bilder. Iprojektet används den till att se till att bilder som läggs upp på hemsidan har rätt upplösning.För att testa funktionerna skapas ett testfall, som kontrollerar att:

1. funktionen scale_image, med olika bredder och höjder som argument, skapar bildermed rätt dimensioner.

2. funktionen default_image_scale skapar och sparar bilder med rätt dimensioneroch sparar dem på rätt sätt.

Detta kommer ge en förståelse för hur enhetstestning i allmänhet och unittest i synnerhet kan seut. För att se hur mycket av koden som testats startas coverage.py innan.



Det kan vara svårt att helt automatisera testning av en webbplats, då en stor del av det manvill testa är hur hemsidan ser ut och känns. Selenium ska dock användas dels till att försökaautomatisera så mycket som möjligt, till exempel ska olika nyckelord sökas efter i en hemsidaskällkod, dels göra den manuella testningen smidigare, genom att automatisera klickandet ochskrivandet. Detta kommer leda till att testaren förhoppningsvis kan koncentrera sig på att letafel istället för att tänka på hur den ska interagera med hemsidan. Det som ska undersökas ärom detta är en rimligt sätt att testa en webbplats, och vilka utmaningar man ställs emot med ettsådant verktyg.

För att testa hur bra Selenium Webdriver fungerar kommer en testmiljö sättas upp. Detta görsgenom att använda unittest som ramverk. Testobjektet kommer vara projektets hemsida. Test-miljön skapar och sätter upp en fördefinierad databas och en till databasen associerad mängdbilder på server-sidan. unittest bidrar med bra assert-funktioner som kan användas för att tillexempel testa att källkoden innehåller bilder med en viss klass. När fel uppstår ska Selenium taen skärmdump av webbläsaren, för att man senare ska kunna se vad som kan ha gått fel.Den fördefinierade databasen och dess associerade samling bilder ska innehålla:

• Två kollektioner, med sex bilder var.

• En webbshop med en front, som visar ett antal blandade produkter, och två produktkate-gorier med ett antal produkter i. Varje produkt ska ha minst fyra bilder.

• Två kategorier under Story Board, en som visar tidstämpel och en som inte gör det. Någrainlägg med bilder var i varje.

För att testa två vanliga webbläsare samtidigt används BrowserSync så att man kan se hurbåda webbläsarna reagerar på interaktionerna. Med Selenium Webdriver öppnas ett fönster förGoogle Chrome och ett fönster för Mozilla Firefox. Sedan testas att:

1. hemsidan kan hämtas, genom att se att den har rätt titel,

2. länken till kollektioerna, som hittas via dess länkadress, går att klicka på,

3. bilder funna på sidan har specifik klass,

4. bilderna förändras på rätt sätt när fönstret förminskas,

5. bilderna funna på den sidan går att förstora och förminska,

6. länken till shoppen går att följa,

7. den nya sidan innehåller rätt information,

8. länken till story board går att följa,

9. sidan som ska ha datum, har datum,

10. sidan som ej ska ha datum, ej har datum.

Notera att detta är sidspecifika test, som även kräver korrekt uppsatt testmiljö.



F.4 Resultat

Detta kapitel syftar till att på bästa sätt svara på frågeställningarna definierade i kapitel F.1.4.

F.4.1 unittest

Att sätta upp ett test med unittest har en enkel stomme:

import u n i t t e s t

c l a s s t e s t C l a s s ( u n i t t e s t . T e s t C a s e ) :def se tUp ( s e l f ) :

pass

def tearDown ( s e l f ) :pass

def t e s t _ s u m ( s e l f ) :pass

Om man sedan bygger ut detta med att lägga till en funktion:

def sum ( x , y ) :re turn x + y

och ändra testet:

def t e s t _ s u m ( s e l f ) :s e l f . a s s e r t E q u a l ( sum ( 4 , 6 ) , 10)

så får man utskriften som visas i figur 10. Om man sedan ändrar så att funktionen inte fungerarsom den ska:

def sum ( x , y ) :re turn x � y

så kommer testet att misslyckas, vilket ger utskriften i figur 11.

Figur 10: Utskrift från simpelt test skrivet i unittest.

I setUp(self) och tearDown(self) kan sedan läggas sådan kod som ska köras förerespektive efter varje test.


Figur 11: Utskrift från simpelt test skrivet i unittest.


Med hjälp av Selenium Webdriver och unittest kan man skapa ett simpelt test:

from s e l e n i u m import w e b d r i v e rfrom s e l e n i u m . w e b d r i v e r . common . keys import Keysimport u n i t t e s t

c l a s s t e s t C l a s s ( u n i t t e s t . T e s t C a s e ) :def se tUp ( s e l f ) :

s e l f . b rowse r = w e b d r i v e r . Chrome ( )

def tearDown ( s e l f ) :s e l f . b rowse r . c l o s e ( )

def t e s t _ g o o g l e ( s e l f ) :s e l f . b rowse r . g e t ( " h t t p s : / / www. g oo g l e . s e " )s e l f . a s s e r t I n ( " Google " , s e l f . b rowse r . t i t l e )s e a r c h _ f i e l d = s e l f . b rowse r . f i nd_e lemen t_by_name ( " q " )s e a r c h _ f i e l d . s end_keys ( " Se len ium Webdr iver " )s e a r c h _ f i e l d . s end_keys ( Keys .RETURN)s e l f . a s s e r t N o t I n ( " Your s e a r c h � Selen ium Webdr iver � d i d

n o t match any documents " , s e l f . b rowse r . p a g e _ s o u r c e )

Detta test söker efter “Selenium Webdriver” i google, och testar så att det finns sökresultat.

För att se kod som testar de test definierade i kapitel F.3.2 se Appendix A. Denna tar ävenskärmdumpar vid påkomna fel.

Att istället testa detta för hand skulle inte ta lång tid, men om detta ska göras flera gånger kandet vara ett tidskrävande och tradigt arbete. Men det upptäcktes att vid mer avancerade test vardet svårt att med Selenium Webdriver och unittest upptäcka fel. Det var även så att det iblandgick att upptäcka att något var fel, men att det var svårt att identifiera var det gick fel.



F.5 Diskussion

Detta kapitel behandlar diskussion kring resultat och metod.

F.5.1 Resultat

Att göra simpla test var väldigt enkelt, när man hade tydliga definitioner av vad som var korrektbeteende på en hemsida. Efter att ha testat runt med både unittest och Selenium Webdriver harjag dock insett att det är svårt att göra automatiska test för hemsidor. Dessa förändras mycketoch utseendet är väldigt viktigt. Det är svårt att via kod avgöra om sidan ser korrekt ut. Atttestprogrammet i Appendix A blev såpass stor, för ett relativt enkelt test talar också för att detär smidigare att använda manuell testning. Det som automatiserande verktyg, såsom SeleniumWebdriver, dock kan göra är att förenkla testandet. Det är svårt att reproducera fel när mantestar manuellt, eftersom det inte är så lätt att göra exakt samma sak varje gång. Det kan ävenbli mindre tröttsamt för testaren om den slipper tänka på att hur den ska klicka och interageramed sidan, och istället kan kolla efter defekter.

F.5.2 Metod

För att riktigt se hur bra testverktygen är skulle mer kunskap om testning överlag samt webb-programmering behövts. Detta är på grundnivå, där endast simpla strukturer testas. Ett robusttestsystem med ordentliga mock-objekt skulle ha behövts, samt tydliga test cases som klargörom ett system beter sig på korrekt sätt. Att automatisera testning när man inte vet vad man letarefter är oerhört svårt.

Några problem som uppstod berodde mycket på att en ordentlig miljö, med till exempel tillfäl-liga filer inte sattes upp ordentligt, samt att många av de funktioner som man ville testa sköttesi bakgrunden av externa paket. Databasen sattes upp manuellt och sparades, då det var enklareatt använda administratörsgränssnittet än att göra det via programkod. Detta borde ha gjorts au-tomatiskt, då en databasmodell kan ändras och då måste hela databasen skapas på nytt, vilket ärett tråkigt arbete.

F.6 Slutsatser

Enhetstestning med unittest är enkelt att komma igång med, detsamma gäller Selenium Web-driver. Problemet är inte verktygen i sig utan snarare testkunskapen, vad man ska anta.


G Kvalitet i ett programvaruutvecklingsprojekt

Detta bidrag är skrivet av Johan Lindberg.

G.1 Inledning

Denna undersökning kommer att handla om kvalitet i ett programvaruutvecklingsprojekt. Dettaär ett mindre projekt med åtta deltagare, där enbart en har genomfört ett liknande projekt förutoch det mesta i projektet görs från grunden. Detta medför att det kan uppkomma svårighetermed att uppnå kvalitet i projektet på grund av oerfarenhet och svårighet att överblicka. Detfinns flera olika sätt att uppnå kvalitet och ett av de sätten är att använda en kvalitetsstandard.

Befintliga kvalitetsstandarder är bra att tillämpa för att skapa en egen kvalitetsstandard då dettaär ett mindre projekt, där allt inte är relevant eller kan tillämpas.

G.1.1 Motivering

Kvalitet är något som är viktigt i alla projekt och det finns flera olika sätt att uppnå det. Det mankan också fundera på, är om kvalitetsstandarder är bra att följa rakt av eftersom de är avseddaatt passa till flera olika projekt vilket gör att de kanske innehåller mer än vad man behöver.

Utöver att kvalitet är en vital del i ett projekt, känns det även som ett intressant område attfördjupa sig inom.

G.1.2 Syfte

Syftet är undersöka hur kvalitet kan uppnås i ett programvaruutvecklingsprojekt.

G.1.3 Frågeställning

1. Hur kan kvalitet uppnås i ett programvaruutvecklingsprojekt?

2. Vilka är fördelarna och nackdelarna med att följa kvalitetsstandarder?

3. Vad är kvalitetssamordnarens uppgift i ett programvaruutvecklingsprojekt?

G.1.4 Avgränsningar

Avgränsningen kommer att vara vad som har tillämpats i detta projekt och vilken kvalitetsstan-dard vi har använt. Den kvalitetsstandard som har använts är IEEE 730.

G.2 Teori

IEEE står för Institute of Electrical and Electronics Engineers som har producerat ett flertalstandarder för projekt av olika slag som säger hur man kan standardisera vissa moment när manvill utveckla t.ex. mjukvara [30]. IEEE 730 är en av dessa standarder. IEEE 730 är kvalitetsstan-dard för krav på uppstart, planering, kontroll och utförande. Standarden anger alltså hur krav



och kvalitet ska uppnås i de olika faserna. Oftast behövs det mer än en IEEE-standard för ettprojekt då varje standard handlar om ett specifikt område.

Att man använder en agil utvecklingsmetod innebär att man arbetar nära tillsammans med kun-den under utvecklingsfasen och utvecklaren får kontinuerlig återkoppling från kunden. Kravsom ställs kan ändras även långt in i projektet [47]. Projektet utfördes i tre olika iterationer medbegränsad tid där man har ställt upp olika mål för varje iteration som säger hur långt man ska hahunnit på ett visst tidsspann. Kombinationen av kontinuerlig feedback och att arbeta i iterationergör att man tydligt kan se hur projektet går framåt.

Scrum (se avsnitt 3.1.1) är en agil utvecklingsmetod som innebär att arbetet sker i iterationerdär man sätter upp mål för funktionalitet i varje iteration. Det ska även ingå att man se över dettidigare arbetet för att se om det uppfyller kraven eller inte.

Kanban (se avsnitt 3.1.2) är en agil utvecklingsmetod. Projektet delas upp i olika funktionersom man sedan sätter in i olika faser, t.ex. ska göras, görs, testas och färdig för attvisa hur långt man har kommit i utvecklingen. Varje medlem i gruppen kan välja en uppgiftoch börja arbeta med den och flyttar den till görs, när den är färdig flyttas den till testasoch när den är färdigtestad flyttas den till färdig. Detta gör då att man kan få ett fint flöde iutvecklingen. Det kan dock finnas beroenden mellan de olika uppgifterna och man kan behövaprioritera vissa uppgifter före andra.

Kvalitet kan vara flera olika saker i ett projekt och det är ofta svårt att säga vad det är exakt [48].

Git är ett versionshanteringssystem [49] där all kod finns som alla i gruppen har tillgång till föratt lätt kunna komma åt och dela kod med varandra. Git stödjer att man har en branch eller flerabranches dvs. separata delar där man kan göra ändringar utan att påverkas av ändringar somgörs av andra gruppmedlemmar.

G.3 Metod

I detta avsnitt kommer genomgång att göras av metoden som har använts i projektet.

I projektet har vi arbetat med en agil utvecklingsmetod, som liknar Scrum och Kanban, vilkethar gjort att saker kan omarbetas i flera iterationer. Eftersom projektet utförs i iterationer kanman kontinuerligt läsa igenom, förbättra eller ändra kod allt eftersom projektet fortlöper.

Eftersom krav och funktionalitet lätt kunde ändras var en agil utvecklingsmetod bättre än vat-tenfallsmetoden som är striktare när det gäller krav. Det är svårt att jämföra den potentiellakvaliteten om man hade använt vattenfallsmetoden jämfört med den agila utvecklingsmetodsom användes i detta projekt, då den agila utvecklingsmetoden är bättre lämpad för detta pro-jekt [50].

Skriven kod kommer alltid att bli granskad av andra personer vilket gör att kvaliteten på kodenökar. Koden som man har skrivit ska vara väl kommenterad i de fall det finns behov av kom-mentarer. Dessa kommentarer är till för att den som läser igenom koden lätt ska kunna förståvad koden gör.

När man ska utöka funktionaliteten eller lägga till nya moduler ska man förgrena utifrån denbranch där det samlade systemet finns. Detta för att undvika missöden, som att man t.ex. förstörfungerande kod, men också för att flera ska kunna arbeta samtidigt med olika saker utan att manpåverkas av andras arbeten.


Varje gång man gör ändringar i kod och lägger upp den ska det finnas ett tydligt meddelandesom beskriver vad som har ändrats. Denna information kan användas vid felsökning om detskulle uppstå något fel när man sedan sätter ihop den nya koden med det befintliga systemet.

Varje medlem i projektet har valt en roll, där kvalitetssamordnare var en av rollerna. Kvalitets-samordnaren fick i uppgift att göra en kvalitetsplan som utgick ifrån IEEE 730. Det som ingåri kvalitetsplanen berör dokument och kod. Dokumenten som tillhör projektet nämns vid namn,de är till för att kunna ge inblick i projektet. Kvalitetsplanen säger även vilket språk som skaanvändas i dokumenten. Kod kommer att följa olika standarder beroende på vilket språk kodenär skriven i. Kodspråken i detta projekt var Python, version 3.4, och JavaScript. Standardernasom valdes är egentligen mycket större än vad som behövs för detta projekt och det som är an-vändbart från dessa är huvudsakligen hur man namnger variabler och funktioner. Istället för attvälja befintliga standarder kan man skapa egna, som bara tar ut särskilda delar som man anserär viktiga.

Utöver att kvalitetssamordnaren skrev en kvalitetsplan som ställer upp standarder och riktlinjer,ska den även se till att projektet håller god kvalitet, vilket innebär att kod och dokument följerde riktlinjer och standarder som har definierats. Om det finns brister i kvaliteten ska kvalitets-samordnaren delegera arbete för att åtgärda bristerna.

G.4 Resultat

Resultatet kommer att vara sett ifrån vad som har gjorts i detta projekt och är därmed projekter-farenheter.

Kvalitet i ett programvaruutvecklingsprojekt kan uppnås på flera olika sätt. Genom att sätta uppolika standarder och följa dem kan man få ett projekt som ser enhetligt ut och är lätt att ta del av.Vad man anser är kvalitet kan vara flera olika saker och det kan variera från person till person, idetta projekt valdes kod men även hur lång tid det tar att ladda en sida.

Fördelen med att använda befintliga kvalitetsstandarder är att det finns redan uppsatta standardersom säger vad som behövs och vad som är viktigt.

Nackdelen med att använda befintliga kvalitetsstandarder är att de är oftast mer generella ochkan användas på flera olika typer av projekt men att de inte är anpassade till det specifikaprojektet.

Kvalitetssamordnarens roll är att sätta upp riktlinjer och standarder som ska följas för att pro-jektet ska uppnå hög kvalitet. Är det bristande kvalitet ska kvalitetssamordnaren se till att detåtgärdas. Rollen som kvalitetssamordnare är viktig för att projektet ska uppnå hög kvalitet, mendetta projekt är ett mindre projekt där det inte fanns så många olika aspekter att kontrollera.

G.5 Diskussion

Detta avsnitt är till för att diskutera resultatet och metoden.

G.5.1 Resultat

Resultatet kan variera beroende på vilken typ av projekt det är, eftersom resultatet kommer frånjust detta projekt.



Det finns olika vägar som man kan välja för att uppnå hög kvalitet i ett programvaruutvecklings-projekt. Eftersom detta projekt består av kod och dokument måste man se till att dessa hållerhög kvalitet, genom att skapa en egen kvalitetsstandard av något slag, t.ex. en kvalitetsplan. Denställer då upp hur projektets olika delar ska struktureras för att uppnå hög kvalitet i projektet.

IEEE 730 täcker in mycket mer än vad som kommer kunna tillämpas på ett litet projekt av dettaslag. Därför måste man sovra och ta ut specifika delar som man anser är viktigare än andra.Detta projekt hade som det nämnts tidigare, dokument och kod men även funktionella krav somladdningstid av sidor, vilket gör att de delar ur IEEE 730 som valdes främst handlar specifiktom de delarna. Man får alltså ta ut det man anser är relevant för det projekt man arbetar med.

Fördelen med att följa en kvalitetsstandard är däremot att det finns tydliga riktlinjer för vadsom ska ingå och vad som innefattas. I denna undersökning där IEEE 730 har tillämpats så harIEEE 730 utvärderats i flera olika utgåvor vilket har gjort att vissa aspekter har förändrats tilldet bättre.

Kvalitetssamordnarens roll i ett programvaruutvecklingsprojekt är att ställa upp en kvalitetsplansom säger vad som är standard och hur den ska upprättas. Hade projektet varit mer omfattande,hade kvalitetssamordnaren haft en större roll i projektet. Det hade kanske varit fler moduler ochmer kod vilket hade gjort att det hade varit mer arbete.

G.5.2 Metod

Eftersom projektet utfördes med en agil utvecklingsmetod kunde kvaliteten kontinuerligt kon-trolleras och om kvaliteten var bristande, kunde den åtgärdas. Hade projektet utförts med vat-tenfallsmetoden hade det sett väldigt annorlunda ut. Krav som ställdes på projektet skulle intekunna ändras och vi skulle helt enkelt inte kunna gjort de ändringar som vi behövde göra. Vat-tenfallsmodellen är bra om man har fastställda krav som inte kan ändras. Eftersom detta projektutfördes i iterationer - krav kan ändras och saker omarbetades efter feedback från kund - hadevattenfallsmetoden inte varit någon lämplig metod att följa och därför är en agil utvecklingsme-tod bättre att använda.

Projektet var uppdelat i många små moduler och funktioner vilket gjorde att Kanban var ett braval då man enkelt kunde välja en uppgift och jobba med den enskilt eller i par. Detta sätt varväldigt bra att jobba på eftersom man kunde välja de saker man ville jobba med.

Scrum är en bra utvecklingsmetod att använda på ett projekt som detta, då allt görs i iterationeroch saker kan hela tiden omarbetas. Det man hade kunnat göra är att dela upp iterationerna iännu mindre iterationer för att ofta kontrollera det som gjorts tidigare och eventuellt fixa detsom behövs.

Något som hade kunnat göras annorlunda är att vi kunde haft mer parprogrammering. Frånbörjan tog varje medlem i gruppen den uppgift som den ville göra men p.g.a. bristande kunskapbehövde den utbilda sig inom det området, vilket tog tid. De flesta i gruppen hade inte gjortnågot liknande tidigare och kände att utbildning var väldigt viktigt i början vilket gjorde attarbetet stod stilla i början. Detta innebar också att man inte visste den bästa lösningen på detsom skulle implementeras vilket gjorde att viss kod som skrevs, i slutändan inte behövdes. Motslutet blev det mer parprogrammering då det var flera delar som behövdes fixas och arbete i pargjorde att kvaliteten höjdes eftersom det är lättare att hitta fel och göra bättre lösningar när manarbetar tillsammans.


Att sätta en standard på hur kod ska se ut var ett bra sätt att få koden att se enhetlig ut. Enhetligoch lättläst kod är bra kod och behöver kanske inte alltid kommenteras. Det som däremot kanbehöva kommenteras, är varför vissa lösningar har valts istället för andra.

Som det tidigare nämndes i diskussion om resultatet så var IEEE 730 en bra grund att utgå ifrånmen att stora delar av den inte behövde användas. Detta beror på att projektet var relativt litetmen det är också en avvägning av vad som behövs och vad som inte behövs.

Att koden blir granskad av andra personer gör att kvaliteten på koden höjs. Den som läser kodenmåste förstå den och även lite av helheten samt hur den interagerar med det redan befintligasystemet. Om koden är lättläst och väl kommenterad, kommer den som läser koden och granskaratt lätt kunna förstå och sedan ge feedback om något behöver fixas, t.ex. mer kommentarer ellervarför vissa lösningar har gjorts.

Projektet i sig är ett väldigt bra projekt ur programvaruutvecklingssynvinkel för att man jobbaragilt. Man sätter upp mål som ska vara uppfyllda men samtidigt ska krav och design kunnaändras hela tiden.

G.6 Slutsatser

Kvalitet i ett programvaruutvecklingsprojekt kan uppnås på flera olika sätt men det beror påvilka aspekter man tittar på.

Att följa en kvalitetsstandard är en bra början för att ha något att utgå ifrån gällande kvali-tetskrav. IEEE 730 valdes i detta projekt som kvalitetsstandard att utgå ifrån. Det fanns bådefördelar och nackdelar med att välja en befintlig kvalitetsstandard att utgå ifrån. Fördelen varatt den omfattade en hel del kriterier som ska vara med men nackdelen var att den är ganskagenerell och i ett litet projekt som detta fungerar det inte att använda hela IEEE 730, utan manfår ta delar av den.

En kvalitetsplan som anpassades efter den valda kvalitetsstandarden skrevs av kvalitetssamord-naren. Kvalitetsplanen sätter upp standarder för kod och dokument som säger hur de ska varautformade. Förutom kvalitetsplanen hade kvalitetssamordnaren i uppgift att se till att projektethåller hög kvalitet.

De standarder som rör kod är för omfattande och innehåller mer än vad vi behövde, vilket gjordeatt man fick ta de delar som kändes relevanta för vårt behov. Det som hämtades från de andrastandarderna var mer hur man namnger saker och ting. Eftersom arbetet utfördes i mer än ettkodspråk, sattes det upp standarder för de olika språken.

Vissa saker hade gjorts annorlunda om vi från början hade haft den kunskap vi besitter idag. Vihade även jobbat mer i par vilket hade höjt kvaliteten. Detta projekt är ett väldigt bra projekt urprogramvaruutvecklingssynvinkel då det finns alltid något att förbättra.



H Tillvägagångssätt vid webbutveckling för flera platformar

Detta bidrag är skrivet av Tomas Doverfelt.

H.1 Inledning

Webbutveckling är ett område som likt många andra tekniska områden har utvecklats i hög fartgenom åren. Därför gäller det att man som utvecklare vågar pröva nya metoder för att självkunna ligga i framkant. Att utveckla webb idag (maj 2015) innebär att man måste lägga myckettid och resurser på att få rätt resultat på en mängd olika platformar. Förutom olika webbläsarefinns det idag en uppsjö av olika mobila enheter som utöver egna webbläsare har varierandeskärmstorlekar.

H.1.1 Syfte

Denna utredning syftar till att ge en inblick till webbprogrammering från en oerfarens synvinkeldär fokus har legat på att lära sig genom att göra.

H.1.2 Frågeställning

Inför projektet valde jag att utforska följande fråga:

1. Vilka hjälpmedel är lämpliga för att skapa en hemsida med fokus på responsivitet ochkompatibilitet mellan platformar?

H.2 Bakgrund

Jag har tidigare endast prövat webbprogrammering på grundläggande nivå med statiska hemsi-dor. För att kunna använda mig av JavaScript har jag fått gå igenom webbprogrammering frångrunden igen vilket betyder att jag har fått lägga mycket tid på att utbilda mig dels genom attlära mig språken som används, dels genom att direkt sätta mina kunskaper i bruk för att kunnabidra till projektets framgång.

H.3 Teori

I detta avsnitt går jag igenom all insamlad teori. För att kunna förstå vad det innebär att enhemsida är responsiv måste man först veta vad det innebär att en hemsida inte är responsiv.

H.3.1 Webbdesign från grunden

I grunden är webbdesign väldigt enkelt (så länge alla parter följer samma standard!). Besökarenpå en hemsida gör en förfrågan om ett HTML-dokument som innehåller all information somkrävs för att en webbläsare ska kunna visa hemsidan. HTML är ett märkspråk och innehållerendast element. Exempel på element kan vara länkar, listor eller bilder. Dessa element bör lämp-ligen formateras för att en viss design ska uppnås, något man kan göra direkt i HTML eller det


mer vanliga som är användadet av en CSS-stilmall.

CSS är ett språk som används för att beskriva hur ett HTML-dokument ska visas. Det är se-dan upp till webbläsaren att tolka detta och rendera slutresultatet.

För att lägga på ett lager med interaktivitet används JavaScript. JavaScript har varit standar-den för webben sedan 1995 och är väldigt hårt knutet till webbprogrammering.

H.3.2 Webb på olika platformar

Det finns två stora indelningar man kan göra gällande platformar som används för att visa webb-innehåll. Först och främst kan man komma åt webbinnehåll från olika hårdvaror vilket medförvissa skillnader man måste tänka på. Utifrån vald hårdvara finns det även olika mjukvarurelate-rade skillnader, främst val av webbläsare vilket i sig betyder olika renderingsmotorer.

När det gäller hårdvara så måste man främst tänka på att visningsstorleken, det vill säga den vyman har på sin skärm, skiljer väldigt mycket om man använder en dator jämfört med om mananvänder en telefon. Den andra stora skillnaden är hur man navigerar, då man i ena fallet oftahar mus och tangentbord och i andra fallet endast en touch-skärm.

För olika mjukvaror är det oftast svårare att hitta vilka exakta skillnader som finns. Det manbehöver hålla koll på är hur en webbläsare är programmerad att visa visst innehåll, för att kunnage samma alla användare samma upplevelse. Det finns i dagsläget fem större webbläsare somman brukar behöva lägga fokus på:

• Mozilla Firefox

• Google Chrome

• Safari

• Opera

• Internet Explorer

Själva webbläsaren i sig är sällan den del som skapar problem, utan det är istället den underlig-gande renderingsmotorn. De problem som uppstår löser man bäst genom att testa sin design idessa vanliga webbläsare och anpassa sina lösningar.

H.3.3 Responsiv webbdesign

Responsiv webbdesign innebär webbdesign som anpassar sig till olika enheter genom att im-plementera objekt på ett smart sätt så att de visas korrekt utan att vara beroende av uniformaskärmstorlekar. Detta ställer höga krav på layouten hos en hemsida, ända från grunden. Justdärför börjar man ofta med den minsta enheten som är mobiltelefonen - ’Mobile first’. Ofta ärdet svårare att få rum med information ju mindre plats man har att placera den på. Det följerdärför ganska naturligt att om ens design fungerar på små skärmar så är det ofta enklare att skalaupp ju mer plats man får tillgängligt än att försöka göra tvärt om. Denna typ av design krävermycket omtanke för varje litet moment, men som tur är finns det resurser att tillgå vilka nämnsi nästa avsnitt.



H.3.4 Olika hjälpmedel för responsiv design

Designen av en hemsida är starkt knutet till CSS-delen. Det är därför naturligt att manipuleradenna del för att uppnå önskat resultat för olika konfigurationer.

För att undvika att folk återuppfinner hjulet finns det många tillgängliga hjälpmedel man kananvända när man ska utveckla webb. Som med alla hjälpmedel så är de bra för det blir enkelt attsnabbt producera mycket innehåll, men det kan medföra att man blir låst och inte kan modifieraenkelt hur man vill. Detta beror helt på vilket hjälpmedel man använder.

H.3.4.1 BootstrapBootstrap [7], tidigare kallat Twitter Bootstrap, är ett populärt front-end-framework utvecklatför att skapa responsiva hemsidor. Bootstrap bistår med en serie av stilmallar för responsivakomponenter. Stilmallarna är skrivna i Less, ett hjälpspråk till CSS, och går att justera ochkompilera om själv.

Bootstrap följer tidigare nämnt paradigm “mobile-first” och använder sig av ett rutnätsystemmed 12 kolumner och ett fritt antal rader, vilka sedan skalas beroende på visningsstorleken.Genom att använda Bootstraps fördefinierade klasser kan man anpassa hur många kolumner ettelement ska spänna upp vid olika visningsstorlekar. Figur 12 visar ett exempel med 9 elementfördelade över tre rader där elementen tilldelats X antal kolumner utav de 12 tillgängliga förvarje rad.

Figur 12: Element fördelade i Bootstraps rutnätssystem med klassen “.col-md”.

Det finns även klasser för att helt dölja innehåll vid en viss visningsstorlek. På så sätt kan manhelt ändra hur information ska visas utifrån hur stor visningsstorlek besökaren har på sin skärm.Ett vanligt exempel är menyraden som gärna kan innehålla mer information på stora skärmar,för att istället ersättas av något mer minimalistiskt på mobiler och surfplattor.

Om man väljer att använda sig av Bootstrap i full utsträckning finns det även stilmallar förbland annat bilder, knappar och tabeller. Väljer man att använda allting precis som det levererasbrukar resultatet bli att man enkelt kan se att hemsidan är utvecklad med Bootstrap.

H.3.4.2 FoundationFoundation [51] är ett annat front-end-framework som utvecklas utav ZURB. Foundation harmånga likheter med Bootstrap, men urskiljer sig genom att ge större möjligheter för till anpass-ning.


H.3.4.3 SkeletonEtt lättviktigt alternativ till Bootstrap är Skeleton [52]. Skeleton har många grundläggande lik-heter med Bootstrap, men urskiljer sig genom att begränsa sig till det absolut nödvändigasteinom responsiv design. Skeleton är förhållandevis väldigt enkelt att sätta sig in i; själva stilmal-len i sig är “bara” runt 400 rader kod.

H.4 Metod

I detta avsnitt beskrivs metoderna som använts för att besvara frågeställnignarna.

H.4.1 Förstudie

När projektet började fick vi ett projektdirektiv från vår kund med lite grundläggande kravpå hemsidan som skulle utvecklas. Genom möte med kund och interna möten med gruppenbestämdes hur vi skulle arbeta och vad som skulle produceras.

Valet av hjälpmedel för responsiv design föll på Bootstrap då projektets arkitekt ansåg det sommest lämpat med tanke på gruppens erfarenheter och projektets storlek. Det kom även somförslag från kundens tekniska representant, även om kunden inte hade några preferenser.

H.4.2 Implementation

Under implementationsfasen använde vi oss av Bootstraps hjälpmedel för responsiv design. In-nehåll delades in i behållare (.container) och Bootstraps rutnätsystem användes för att dela uppinformationen. För att låta bilder skalas korrekt användes klassen .img-responsive. Vi experi-menterade med andra tillgängliga element som Bootstrap tillgår, som knappar och tabeller, menefter återkoppling från kundmöten fick dessa ersättas av mer neutrala varianter.

H.4.3 Jämförelser

För att jämföra resultatet med hur det hade sett ut om vi valt något annat hjälpmedel så valdejag att ersätta Bootstrap-kod med liknande funktionallitet från Skeleton. Detta gjordes genomatt läsa om dokumentationen för respektive framework, för att sedan översätta den kod vi hadeskrivit med motsvarande kod för Skeleton.

H.5 Resultat

I detta avsnitt tar jag upp resultaten som samlats in enligt metoden beskriven i föregående kapi-tel.

H.5.1 Förstudie

Under förstudien fick vi en vag bild av vad kunden ville ha. Våra förslag kring responsivitet fickpositiv kritik vilket ledde till att vi började implementera med Bootstrap.



H.5.2 Implementation

Med hjälp av Bootstrap blev hemsidan responsiv i den utsträckningen att den skalar om sig kor-rekt när visningsstorleken ändras. Då hemsidan är väldigt minimalistisk och enkel i sin designbehövde vi inte göra några stora förändringar i hur innehåll visas för små respektive stora skär-mar. De skillnader som finns rör mest hur många element som får plats i horisontell led innande staplas vertikalt.

H.5.3 Jämförelser

Skillnaderna mellan Bootstrap och Skeleton blev minimala om ens mätbara för denna typ avimplementation. Se bild 13 nedan för skillnad i användning av rutnätssystemet hos Bootstrapjämfört med Skeleton.

Figur 13: Skeleton till vänster, Bootstrap till höger

Rent utseendemässigt är skillnaderna i de flesta fall minimala. Skillnaderna som uppstår äristället hur man skriver kod beroende på valt framework.

H.6 Diskussion

Diskussion av resultat och metod.

H.6.1 Resultat

Under förstudien började vi få en bild av vad kunden ville ha, men desto tydligare fick vi redapå vad hon inte ville ha. Hon ville ha en minimalistisk design, vilket i slutändan kom att betydaatt det också blev minimalt med styling och interaktiva element på hemsidan. Detta kan ansessom ett misslyckande då vi gick miste om möjligheter att experimentera med allt som Bootstraperbjuder. Det ska dock nämnas att de delar som användes fungerade bra och både vi och kundenblev nöjda.

Med tanke på hur liten del responsivitetsdelen av hemsidan blev hade vi förmodligen klarat ossmed det mer nerskalade Skeleton. Min egna uppfattning är att projektets visuella del kunde löstsmed enklare metoder, där Skeleton kunde fått skina genom att vara precis tillräckligt.

H.6.2 Metod

Valet att hålla oss till Bootstrap ledde till att vi inom projektet fick en förkärlek för detta; någotsom ofta händer när man lär sig något nytt och det flyter på bra.

Då kraven på hemsidan var förhållandevis enkla blev även implementationen minimal. Dettaledde till att vi inte hade behovet av att använda oss av alla finesser som Bootstrap bistår med.När vår kod ersattes med likvärdig kod från Skeleton visade det sig även att vi fick likvärdig


funktionallitet, där skillnaderna främst var olika namn på klasser. Detta förklaras av att de olikaframework:en i slutändan producerar CSS-kod.

H.7 Slutsatser

För att uppnå en responsiv design är det högst lämpligt att använda sig av hjälpmedel i form avfärdiga frameworks. Valet av framework bör väljas utifrån ens tidigare erfarenheter av webb-programmering. Om man är ny inom webbprogrammering och ska skriva en responsiv hemsidafrån grunden bör man först sätta sig in i grundtänket “mobile-first”. Om man endast är ute efteratt få till responsivitet på redan uttänkt design så räcker Skeleton. Är man ute efter en helhets-lösning som i grunden är responsiv så är Bootstrap det bättre alternativet.

Även om det finns många alternativ så är det samma grundläggande principer som används.


Appendix A

from s e l e n i u m . common . e x c e p t i o n s importE l e m e n t N o t V i s i b l e E x c e p t i o n

from s e l e n i u m . w e b d r i v e r . common . a c t i o n _ c h a i n s importA c t i o n C h a i n s

import u n i t t e s tfrom t ime import s l e e pimport s h u t i limport s y simport r e

# R e s o l u t i o ni f ( l e n ( s y s . a rgv ) >1) :

s c r e e n _ w i d t h = i n t ( s y s . a rgv [ 1 ] )s y s . a rgv . remove ( s y s . a rgv [ 1 ] )

e l s e :s c r e e n _ w i d t h = 1920

i f ( l e n ( s y s . a rgv ) >1) :s c r e e n _ h e i g h t = i n t ( s y s . a rgv [ 1 ] )s y s . a rgv . remove ( s y s . a rgv [ 1 ] )

e l s e :s c r e e n _ h e i g h t = 1200

def setUpTestDbAndImages ( ) :s h u t i l . move ( " . . / . . / s e r v e r / app . db " , " temp . db " )s h u t i l . move ( " app . db " , " . . / . . / s e r v e r / app . db " )s h u t i l . move ( " . . / . . / s e r v e r / app / s t a t i c / images " , " temp " )s h u t i l . move ( " images " , " . . / . . / s e r v e r / app / s t a t i c / images " )

def tearDownTestDbAndImages ( ) :s h u t i l . move ( " . . / . . / s e r v e r / app . db " , " app . db " )s h u t i l . move ( " temp . db " , " . . / . . / s e r v e r / app . db " )s h u t i l . move ( " . . / . . / s e r v e r / app / s t a t i c / images " , " images " )s h u t i l . move ( " temp " , " . . / . . / s e r v e r / app / s t a t i c / images " )

c l a s s c o l l e c t i o n T e s t C a s e ( u n i t t e s t . T e s t C a s e ) :e r r o r s = 0def se tUp ( s e l f ) :

setUpTestDbAndImages ( )

s e l f . b rowse r = w e b d r i v e r . Chrome ( )s e l f . b rowse r2 = w e b d r i v e r . F i r e f o x ( )s e l f . b r o w s e r s = [ s e l f . browser , s e l f . b rowse r2 ]s e l f . b rowse r . s e t _ w i n d o w _ s i z e ( s c r e e n _ w i d t h / 2 ,

s c r e e n _ h e i g h t )s e l f . b rowse r2 . s e t _ w i n d o w _ s i z e ( s c r e e n _ w i d t h / 2 ,


s c r e e n _ h e i g h t )s e l f . b rowse r . s e t _ w i n d o w _ p o s i t i o n ( 0 , 0 )s e l f . b rowse r2 . s e t _ w i n d o w _ p o s i t i o n ( s c r e e n _ w i d t h / 2 , 0 )

s e l f . a c t i o n s = A c t i o n C h a i n s ( s e l f . b rowse r )s e l f . b rowse r . i m p l i c i t l y _ w a i t ( 3 )# s e l f . addCleanup ( s e l f . browser . q u i t ) # Only q u i t i f

s u c c e s f u l l y opened

def tearDown ( s e l f ) :tearDownTestDbAndImages ( )

f o r bwsr in s e l f . b r o w s e r s :bwsr . q u i t ( )

def t e s t C o l l e c t i o n ( s e l f ) :f o r bwsr in s e l f . b r o w s e r s :

bwsr . g e t ( ’ h t t p : / / l o c a l h o s t : 3 0 0 0 / ’ )

t r y :s e l f . a s s e r t I n ( ’ Susan ’ , s e l f . b rowse r . t i t l e )

e xc e p t A s s e r t i o n E r r o r a s e :s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( " s c r e e n s h o t

"+ s t r ( s e l f . e r r o r s ) +" . j p g " )p r i n t ( " E r r o r " + s t r ( e ) + " c a u g h t . See

s c r e e n s h o t "+ s t r ( s e l f . e r r o r s ) +" . j p g t o s e e a s c r e e n s h o t o f when t h e

e r r o r o c c u r r e d " )s e l f . e r r o r s += 1r a i s e e

c o l l _ l i n k = s e l f . b rowse r . f i n d _ e l e m e n t _ b y _ x p a t h (" / / a [ @href = ’# / c o l l e c t i o n s ’ ] " )

t r y :c o l l _ l i n k . c l i c k ( )

e xc e p t E x c e p t i o n as e :s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( " s c r e e n s h o t




images = s e l f . b rowse r . f i n d _ e l e m e n t s _ b y _ c s s _ s e l e c t o r (’ img . img�r e s p o n s i v e . c o l l e c t i o n ’ )


s l e e p ( 1 )i f ( images ) :

s e l f . a s s e r t I n ( ’ c l a s s =" img�r e s p o n s i v e c o l l e c t i o n ’ ,s e l f . b rowse r . p a g e _ s o u r c e )

s i z e = s e l f . b rowse r . ge t_w indow_s i ze ( )wid th = s i z e [ ’ wid th ’ ]f o r i in range ( 1 2 ) :

wid th = width �40f o r bwsr in s e l f . b r o w s e r s :

bwsr . s e t _ w i n d o w _ s i z e ( width , s i z e [ ’ h e i g h t ’ ] )

f o r bwsr in s e l f . b r o w s e r s :bwsr . s e t _ w i n d o w _ s i z e ( s i z e [ ’ wid th ’ ] , s i z e [ ’ h e i g h t ’ ] )

f o r i in range ( l e n ( images ) ) :images [ i ] . c l i c k ( )i f ( l e n ( images ) > 1) :

t r y :s e l f . a s s e r t R a i s e s (

E l e m e n t N o t V i s i b l e E x c e p t i o n ,images [ ( i +2)%l e n ( images ) ] .

c l i c k )e x c e p t A s s e r t i o n E r r o r a s e :

s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( "s c r e e n s h o t "+ s t r ( s e l f . e r r o r s ) +" . j p g " )

p r i n t ( " E r r o r " + s t r ( e ) + " c a u g h t . Sees c r e e n s h o t "+ s t r ( s e l f . e r r o r s ) +

" . j p g t o s e e a s c r e e n s h o t o f when t h ee r r o r o c c u r r e d " )

s e l f . e r r o r s += 1r a i s e e

t r y :images [ i ] . c l i c k ( )

e xc e p t E x c e p t i o n as e :s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( " s c r e e n s h o t




def t e s t S h o p ( s e l f ) :f o r bwsr in s e l f . b r o w s e r s :

bwsr . g e t ( ’ h t t p : / / l o c a l h o s t : 3 0 0 0 / ’ )


s h o p _ l i n k = s e l f . b rowse r . f i n d _ e l e m e n t _ b y _ x p a t h (" / / a [ @href = ’# / shop ’ ] " )

t r y :s h o p _ l i n k . c l i c k ( )

e xc e p t E x c e p t i o n as e :s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( " s c r e e n s h o t "+

s t r ( s e l f . e r r o r s ) +" . j p g " )p r i n t ( " E r r o r " + s t r ( e ) + " c a u g h t . See s c r e e n s h o t "

+ s t r ( s e l f . e r r o r s ) +" . j p g t o s e e a s c r e e n s h o t o f when t h e e r r o r

o c c u r r e d " )s e l f . e r r o r s += 1r a i s e e

p r o d u c t s = s e l f . b rowse r . f i n d _ e l e m e n t s _ b y _ c l a s s _ n a m e (’ p r o d u c t b o x ’ )

i f ( p r o d u c t s ) :t r y :

p r o d u c t s [ 0 ] . c l i c k ( )e xc e p t E x c e p t i o n as e :

s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( " s c r e e n s h o t"+ s t r ( s e l f . e r r o r s ) +" . j p g " )




t r y :s e l f . a s s e r t I n ( ’ P r i c e ’ , s e l f . b rowse r . p a g e _ s o u r c e )s e l f . a s s e r t I n ( ’ Co lo r ’ , s e l f . b rowse r . p a g e _ s o u r c e )s e l f . a s s e r t I n ( ’ S i z e ’ , s e l f . b rowse r . p a g e _ s o u r c e )s e l f . a s s e r t I n ( ’ D e t a i l s ’ , s e l f . b rowse r .

p a g e _ s o u r c e )e xc e p t A s s e r t i o n E r r o r a s e :

s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( " s c r e e n s h o t"+ s t r ( s e l f . e r r o r s ) +" . j p g " )




boxes = s e l f . b rowse r . f i n d _ e l e m e n t s _ b y _ c l a s s _ n a m e ( "p r o d u c t B u t t o n " )


b o x e s _ t e x t = s e l f . b rowse r .f i n d _ e l e m e n t s _ b y _ c l a s s _ n a m e ( " b u t t o n H i d e " )

t r y :s e l f . a s s e r t E q u a l ( l e n ( boxes ) , l e n ( b o x e s _ t e x t ) )

e xc e p t A s s e r t i o n E r r o r a s e :s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( "

s c r e e n s h o t "+ s t r ( s e l f . e r r o r s ) +" . j p g " )p r i n t ( " E r r o r " + s t r ( e ) + " c a u g h t . See



f o r i in range ( l e n ( boxes ) ) :box_image = boxes [ i ] . g e t _ a t t r i b u t e ( " s r c " )t e x t _ s t a t u s = b o x e s _ t e x t [ i ] . g e t _ a t t r i b u t e ( "

s t y l e " )t r y :

boxes [ i ] . c l i c k ( )e x c e p t E x c e p t i o n as e :

s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( "s c r e e n s h o t "+ s t r ( s e l f . e r r o r s ) +" . j p g " )




s l e e p ( 0 . 3 )t r y :

s e l f . a s s e r t N o t E q u a l ( boxes [ i ] . g e t _ a t t r i b u t e (" s r c " ) , box_image )

s e l f . a s s e r t N o t E q u a l ( b o x e s _ t e x t [ i ] .g e t _ a t t r i b u t e ( " s t y l e " ) , t e x t _ s t a t u s )

e x c e p t A s s e r t i o n E r r o r a s e :s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( "

s c r e e n s h o t "+ s t r ( s e l f . e r r o r s ) +" . j p g " )p r i n t ( " E r r o r " + s t r ( e ) + " c a u g h t . See



def t e s t S t o r y B o a r d ( s e l f ) :f o r bwsr in s e l f . b r o w s e r s :


bwsr . g e t ( ’ h t t p : / / l o c a l h o s t : 3 0 0 0 / ’ )s b _ l i n k = s e l f . b rowse r . f i n d _ e l e m e n t _ b y _ x p a t h (

" / / a [ @href = ’# / b log ’ ] " )t r y :

s b _ l i n k . c l i c k ( )e xc e p t E x c e p t i o n as e :

s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( " s c r e e n s h o t "+s t r ( s e l f . e r r o r s ) +" . j p g " )

p r i n t ( " E r r o r " + s t r ( e ) + " c a u g h t . See s c r e e n s h o t "+ s t r ( s e l f . e r r o r s ) +

" . j p g t o s e e a s c r e e n s h o t o f when t h e e r r o ro c c u r r e d " )


# Date f o r m a t : Tue , 26 May 2015 02:58r e g e x _ f o r _ d a t e = r e . compi le (

r ’ [ a�zA�Z ] { 3 } , \ d {2} [ a�zA�Z]{3} \ d{4} \ d { 2 } : \ d {2} ’ )

s l e e p ( 1 )

l i n k s = s e l f . b rowse r . f i n d _ e l e m e n t s _ b y _ t a g _ n a m e ( " l i " )

t r y :s e l f . a s s e r t T r u e ( r e g e x _ f o r _ d a t e . s e a r c h ( s e l f . b rowse r .

p a g e _ s o u r c e )i s not None )

e xc e p t A s s e r t i o n E r r o r a s e :s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( " s c r e e n s h o t "+

s t r ( s e l f . e r r o r s ) +" . j p g " )p r i n t ( " E r r o r " + s t r ( e ) + " c a u g h t . See s c r e e n s h o t "

+ s t r ( s e l f . e r r o r s ) +" . j p g t o s e e a s c r e e n s h o t o f when t h e e r r o r

o c c u r r e d " )p r i n t ( "=" ⇤80)p r i n t ( s e l f . b rowse r . p a g e _ s o u r c e )p r i n t ( "=" ⇤80)s e l f . e r r o r s += 1r a i s e e

f o r l i n k in l i n k s :i f " work i n p r o g r e s s " in l i n k . t e x t . l ower ( ) :

t r y :l i n k . c l i c k ( )

e x c e p t E x c e p t i o n as e :s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( "

s c r e e n s h o t "+ s t r (s e l f . e r r o r s ) +" . j p g " )

p r i n t ( " E r r o r " + s t r ( e ) + " c a u g h t . See


s c r e e n s h o t "+ s t r (s e l f . e r r o r s ) +" . j p g t o s e e a s c r e e n s h o t o f when

t h e e r r o r o c c u r r e d " )s e l f . e r r o r s += 1r a i s e e

s l e e p ( 1 )

t r y :s e l f . a s s e r t T r u e ( r e g e x _ f o r _ d a t e . s e a r c h ( s e l f . b rowse r .

p a g e _ s o u r c e ) i sNone )

e xc e p t A s s e r t i o n E r r o r a s e :s e l f . b rowse r . g e t _ s c r e e n s h o t _ a s _ f i l e ( " s c r e e n s h o t "+

s t r ( s e l f . e r r o r s ) +" . j p g " )

p r i n t ( " E r r o r " + s t r ( e ) + " c a u g h t . See s c r e e n s h o t "+ s t r ( s e l f . e r r o r s )

+" . j p g t o s e e a s c r e e n s h o t o f when t h e e r r o ro c c u r r e d . Found \ " "

+ r e g e x _ f o r _ d a t e . s e a r c h ( s e l f . b rowse r . p a g e _ s o u r c e) . group ( ) +

" \ " i n \ s o u r c e . " )s e l f . e r r o r s += 1r a i s e e

i f __name__ == ’ __main__ ’ :u n i t t e s t . main ( v e r b o s i t y =2 , w a r n i n g s = ’ i g n o r e ’ )


Appendix B

{" devDependenc ie s " : {

" browser�sync " : " ^2.0 .0 � r c 6 " ," b r o w s e r i f y " : " ^ 9 . 0 . 3 " ," imagemin " : " l a t e s t " ," r i m r a f " : " l a t e s t " ," html�m i n i f i e r " : " l a t e s t " ," onchange " : " l a t e s t " ," mkdirp " : " l a t e s t "

} ," d e p e n d e n c i e s " : {

" r e a c t " : " ^ 0 . 1 2 . 2 " ," r e a c t �r o u t e r " : " ^ 0 . 1 2 . 4 " ," s u p e r a g e n t " : " ^ 1 . 1 . 0 "

} ," s c r i p t s " : {

" c l e a n " : " r i m r a f . / app " ," b u i l d " : "npm run min i fy�html && npm run s c s s t o c s s && npm

run image�min && npm run r e a c t " ," p r e b u i l d " : "npm run c l e a n && mkdirp . / app && mkdirp . / app /

j s && mkdirp . / app / images " ," p o s t b u i l d " : "npm run watch && npm run s e r v e " ," s c s s t o c s s " : " s a s s � t compressed �I . / bower_components /

b o o t s t r a p �s a s s�o f f i c i a l / a s s e t s / s t y l e s h e e t s . / s r c / s c s s /s t y l e . s c s s > . / app / s t y l e . c s s " ,

" min i fy�html " : " html�m i n i f i e r ��remove�comments ��c o l l a p s e �w h i t e s p a c e �o . / app / i n d e x . h tml . / s r c / i n d e x . h tml " ,

" r e a c t " : " b r o w s e r i f y � t r e a c t i f y . / s r c / r e a c t / main . j s x �o . /app / j s / r e a c t . j s " ,

" watch : r e a c t " : " onchange ’ . / s r c / r e a c t / ⇤ ⇤ / ⇤ . j s x ’ �� npm runr e a c t &" ,

" watch : h tml " : " onchange ’ . / s r c / ⇤ . h tml ’ �� npm run min i fy�html &" ,

" watch : s c s s " : " onchange ’ . / s r c / s c s s / ⇤ . s c s s ’ �� npm runs c s s t o c s s &" ,

" s e r v e " : " node s e r v e . j s " ," watch " : "npm run watch : r e a c t && npm run watch : h tml && npm

run watch : s c s s " ," image�min " : " imagemin . / s r c / images / ⇤ ⇤ / ⇤ . j p g . / app / images "

}}


På svenska

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under en längretid 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 ensta-ka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning ochför undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva dettatillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För attgarantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och admini-strativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattningsom god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot attdokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkandeför upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsidahttp://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible replacement -for a considerable time from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read,to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revokethis permission. All other uses of the document are conditional on the consent of the copyrightowner. The publisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/herwork is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its proce-dures for publication and for assurance of document integrity, please refer to its WWW homepage: http://www.ep.liu.se/

c� Johannes Klasson, Jakub Binieda, Sebastian Sundin, Daniel Sjövall, Jonas Tarassu,Harald Pettersson, Johan Lindberg och Tomas Doverfelt


Referenser

[1] “E-barometern helårsrapport 2014,” http://www.hui.se/statistik-rapporter/index-och-barometrar/e-barometern. Hämtad: 2015-05-13.

[2] R. Wirfs-Brock, ed., OOPSLA’95, Proceedings of the Tenth Annual Conference on Object-Oriented Programming Systems, Languages, and Applications, Austin, Texas, USA, Octo-ber 15-19, 1995, ACM, 1995.

[3] “Aspects of kanban,” http://www.methodsandtools.com/archive/archive.php?id=104.Hämtad: 2015-05-26.

[4] “Slack,” https://slack.com/. Hämtad: 2015-05-25.

[5] “Trello,” https://trello.com. Hämtad: 2015-05-26.

[6] “Gulp,” http://gulpjs.com. Hämtad: 2015-05-13.

[7] “Bootstrap,” http://getbootstrap.com. Hämtad: 2015-05-23.

[8] “Node package manager,” https://www.npmjs.com. Hämtad: 2015-05-25.

[9] “Pip,” https://pip.pypa.io/en/stable/. Hämtad: 2015-05-25.

[10] “Bower,” http://bower.io/. Hämtad: 2015-05-25.

[11] A. Ronacher, “Flask web development, one drop at a time,” http://flask.pocoo.org/, 2014.Hämtad: 2015-05-12.

[12] “Werkzeug,” http://werkzeug.pocoo.org/. Hämtad: 2015-05-25.

[13] “Jinja,” http://jinja.pocoo.org/. Hämtad: 2015-05-25.

[14] “Sqlalchemy,” http://www.sqlalchemy.org//. Hämtad: 2015-06-11.

[15] “Sass,” http://sass-lang.com/. Hämtad: 2015-05-25.

[16] “Docker,” https://www.docker.com/. Hämtad: 2015-05-26.

[17] “React,” https://facebook.github.io/react/. Hämtad: 2015-05-25.

[18] “Nginx,” https://nginx.org. Hämtad: 2015-06-11.

[19] “Gunicorn,” http://gunicorn.org/. Hämtad: 2015-05-25.

[20] S. Szatmáry, “Susan szatmáry modewebb,” 2015.

[21] S. L. Pfleeger and J. M. Atlee, Software engineering: theory and practice. Pearson Educa-tion International, third ed., 2006.

[22] C.-C. Hsu and B. A. Sandford, “The delphi technique: making sense of consensus,” Practi-cal assessment, research & evaluation, vol. 12, no. 10, pp. 1–8, 2007.

[23] “Text-Editor.org,” http://www.text-editor.org/. Hämtad: 2015-05-27.


[24] “Ordbehandlare,” http://www.babylon.com/definition/ordbehandlare/. Hämtad: 2015-05-25.

[25] “Microsoft word,” https://support.office.com/en-us/article/Office-training-and-tutorials-b8f02f81-ec85-4493-a39b-4c48e6bc4bfb. Hämtad: 2015-05-25.

[26] “Openoffice.org writer,” https://www.openoffice.org/product/writer.html. Hämtad: 2015-05-25.

[27] “Google docs,” http://learn.googleapps.com/docs. Hämtad: 2015-05-25.

[28] “Latex,” http://www.latex-project.org/. Hämtad: 2015-05-25.

[29] “Tex users group,” http://www.tug.org/. Hämtad: 2015-06-11.

[30] “IEEE,” https://www.ieee.org/index.html. Hämtad: 2015-05-25.

[31] A. Cottrell, “Word processors: Stupid and inefficient,” Essay,http://www.ecn.wfu.edu/cottrell/wp. html, 1999.

[32] M. Schlotter, “Development of course material in a multi-author environment,” Australa-sian Journal of Educational Technology, vol. 25, no. 4, 2009.

[33] R. F. Goldsmith, Discovering Real Business Requirements for Software Project Success.Artech House, Incorporated, 2004.

[34] M. Christel and K. Kang, “Issues in requirements elicitation,” Tech. Rep. CMU/SEI-92-TR-012, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA,1992.

[35] “Angularjs,” https://angularjs.org. Hämtad: 2015-05-25.

[36] A. Leff and J. T. Rayfield., “Web-application development using the model/view/con-troller design pattern.,” in Enterprise Distributed Object Computing Conference, 2001.EDOC’01. Proceedings. Fifth IEEE International. IEEE, 2001., pp. 118–127, IEEE, 2001.

[37] D. Spinellis, “Software builders,” Software, IEEE, vol. 25, no. 3, pp. 22–23, 2008.

[38] “Node.js,” https://nodejs.org. Hämtad: 2015-05-25.

[39] C. Macrae, “Building with gulp,” http://www.smashingmagazine.com/2014/06/11/building-with-gulp/. Hämtad: 2015-05-13.

[40] F. Ricca and P. Tonella, “Anomaly detection in web applications: a review of already con-ducted case studies,” in Software Maintenance and Reengineering, 2005. CSMR 2005.Ninth European Conference on, pp. 385–394, March 2005.

[41] P. S. Foundation, “26.3. unittest - unit testing framework,”https://docs.python.org/3/library/unittest.html, 2015. Hämtad: 2015-05-12.

[42] “Selenium,” http://www.seleniumhq.org/projects/webdriver/. Hämtad: 2015-05-25.

[43] G. J. Myers, C. Sandler, and T. Badgett, The art of software testing. John Wiley & Sons,2011.


[44] I. S. T. Q. Board, “Certified tester - foundation level syllabus,”http://certifications.bcs.org/upload/pdf/swt-foundation-syllabus.pdf. Hämtad: 2015-05-25.

[45] “Browsersync,” http://www.browsersync.io. Hämtad: 2015-05-25.

[46] W3Schools, “Browser statistics,” http://www.w3schools.com/browsers, 2015. Hämtad:2015-05-12.

[47] K. Beck, M. Beedle, A. Van Bennekum, A. Cockburn, W. Cunningham, M. Fowler,J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, et al., “Manifesto for agile software deve-lopment,” 2001.

[48] R. Petrasch, “The definition of software quality: a practical approach,” in Proceedings ofthe 10th International Symposium on Software Reliability Engineering, pp. 33–34, 1999.

[49] “Git,” https://git-scm.com/. Hämtad: 2015-05-25.

[50] M. Huo, J. Verner, L. Zhu, and M. A. Babar, “Software quality and agile methods,” inComputer Software and Applications Conference, 2004. COMPSAC 2004. Proceedings ofthe 28th Annual International, pp. 520–525, IEEE, 2004.

[51] “Foundation,” http://foundation.zurb.com. Hämtad: 2015-05-23.

[52] “Skeleton,” http://getskeleton.com. Hämtad: 2015-05-23.

Linköpings universitet Institutionen för datavetenskap



15/025

Institutionen för datavetenskap825659/FULLTEXT01.pdf · 3 Teori Detta kapitel behandlar teori som...

Documents

Transcript of Institutionen för datavetenskap825659/FULLTEXT01.pdf · 3 Teori Detta kapitel behandlar teori som...