webbutveckling med flask och wordpressliu.diva-portal.org/smash/get/diva2:1114517/fulltext01.pdf ·...

Linköpings universitetSE–581 83 Linköping

013-28 10 00 , www.liu.se

Linköpings universitet | Institutionen för datavetenskapExamensarbete på grundnivå, 15hp | Datateknik

Vårterminen 2017 | LIU-IDA/LITH-EX-G--17/035--SE

Webbutveckling medFlask och WordPressWeb development with Flask and WordPress

Viktor AgbrinkFredrik BengtssonJanos R. DaniAndreas JärveläTobias LundbergAdrian ShosholliHans TchouViktor Wällstedt

Handledare : Lena BuffoniExaminator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 årfrån publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstakakopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och förundervisning. Ö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öratt garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sättsamt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende elleregenart. För ytterligare information om Linköping University Electronic Press se förlagetshemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement– for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone toread, to download, or to print out single copies for his/hers own use and to use it unchangedfor non-commercial research and educational purpose. Subsequent transfers of copyrightcannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measuresto assure authenticity, security and accessibility. According to intellectual property law theauthor has the right to be mentioned when his/her work is accessed as described above andto be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of documentintegrity, please refer to its www home page: http://www.ep.liu.se/.

c© Viktor Agbrink, Fredrik Bengtsson, Janos R. Dani, Andreas Järvelä, Tobias Lundberg,Adrian Shosholli, Hans Tchou, Viktor Wällstedt

SammanfattningDenna rapport handlar om ett projekt åtta studenter på Linköpings universitet genomförde våren2017, inom ramarna för kursen TDDD96: Kandidatprojekt i programvaruutveckling. Fokuset iprojektet var att bygga upp en ny webbplats åt en kund, Musikaliska konstföreningen, som skaersätta deras gamla webbplats. Projektgruppen valde att göra detta med hjälp av verktygetWordPress. Gruppen valde också att göra en alternativ webbplats med programmeringsspråketPython och ramverket Flask, för att sedan jämföra resultatet mot WordPress-resultatet. Detgruppen valde att jämföra är vilket stöd WordPress respektive Flask ger åt utvecklarna, ochvilket av dem som ger lämpligast resultat för kunden. Resultatet blev en färdig hemsida uppbyggdmed WordPress, och en prototypsida uppbyggd med Python och Flask. Resultatet visar att detär enklare att få en färdig sida med hjälp av WordPress, men att man genom att skriva kod frångrunden i Flask kan få ett betydligt mer användaranpassat system. När det kommer till faktorersom driftkostnader och stöd så visade det sig att WordPress har en klar fördel i jämförelse medFlask.

Tillkännagivanden

Vi vill börja med att tacka Musikaliska konstföreningen för att ha gett oss möjligheten att utföraett givande och roligt projekt! Speciellt vill vi tacka Alf Westelius och Donald Lavery som harfått stå ut med mängder av frågor och bollande av idéer.

Vi vill också passa på att uppmärksamma vår handledare Lena Buffoni som aldrig svikit oss påvåra veckomöten. Du kommer alltid med energi och input som vi tagit till oss och haft stor nyttaav. Tack för din vägledning och ditt outtröttliga engagemang!

ProjektidentitetGrupp 1

Linköpings tekniska högskola (LiTH)

Namn Ansvarsområde E-postadress

Viktor Agbrink Analysansvarig [email protected]

Fredrik Bengtsson Arkitekt [email protected]

János R. Dani Konfigurationsansvarig [email protected]

Andreas Järvelä Utvecklingsledare [email protected]

Tobias Lundberg Testledare [email protected]

Adrian Shosholli Kvalitetssamordnare [email protected]

Hans Tchou Dokumentansvarig [email protected]

Viktor Wällstedt Teamledare [email protected]

KundkontaktAlf Westelius, [email protected]

Donald Lavery, [email protected]

HandledareLena Buffoni, [email protected]

KursansvarigKristian Sandahl, [email protected]

Innehåll1 Introduktion 1

1.1 Motivering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Bakgrund 32.1 Nuvarande situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Projekterfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Förbättringspunkter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Bra erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Teori 53.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Scrummästare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Git och GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.4 Scrumban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.5 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.6 Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.7 LATEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.7.1 ShareLaTeX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.8 Google Docs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.9 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.10 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.11 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.12 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.13 MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.14 WordPress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.15 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.16 Flask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.17 SQLAlchemy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.18 Jinja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.19 Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.20 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.21 AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.22 Hållbarhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.22.1 Hållbarhetskrav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.23 Systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Metod 114.1 Roller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Arbetsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2.1 Scrumban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2.2 Kommunikation via Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3 Utvecklingsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3.1 Workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3.2 Systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3.3 Moduluppdelning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3.4 Parprogrammering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3.5 Testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.4 Utvecklingsverktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4.1 WordPress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4.2 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4.3 Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4.4 PyCharm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.5 Metod för att fånga erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.6 Arbetsförlopp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.6.1 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.6.2 Utveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.7 Hållbarhet ur ett miljöperspektiv . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Resultat 165.1 Systembeskrivning för WordPress-webbplatsen . . . . . . . . . . . . . . . . . . . 16

5.1.1 Webbutikens innehåll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.1.2 Webbutikens utseende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1.3 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.1.4 Vad har kunden för värde av det som skapats? . . . . . . . . . . . . . . . 19

5.2 Systembeskrivning av Flask-hemsidan . . . . . . . . . . . . . . . . . . . . . . . . 195.2.1 Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2.2 Vy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2.3 Visningsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3 Jämförelse mellan de två webbplatserna . . . . . . . . . . . . . . . . . . . . . . . 205.3.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.3.2 Funktionalitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.3.3 Arkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.4 Gemensamma erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.4.1 Iteration ett . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.4.2 Iteration två . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.4.3 Iteration tre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.5 Hållbarhet ur ett miljöperspektiv . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.6 Översikt över individuella bidrag . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Diskussion 256.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1.1 Alternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.1.2 Tidigare erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.1.3 Kostnad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.1.4 Kundens behov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.1.5 Sammanställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.1.6 Vad återstår för att kunden skall få ut fullt värde av produkten? . . . . . 266.1.7 Tidsåtgång . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.1.8 Hur vi har utvecklats sedan tidigare projekt . . . . . . . . . . . . . . . . . 276.1.9 Viktigaste lärdomar inför framtiden . . . . . . . . . . . . . . . . . . . . . 276.1.10 Systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2.1 Arbetsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.2.2 Utvecklingsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.2.3 Utvecklingsverktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2.4 Dokumenteringsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.2.5 Metod för att fånga erfarenheter . . . . . . . . . . . . . . . . . . . . . . . 30

6.3 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.3.1 Samhälleliga aspekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.3.2 Miljöaspekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.3.3 Etiska aspekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7 Slutsatser 327.1 Hur kan webbplatsen implementeras så att man skapar värde för kunden? . . . . 327.2 Vilka erfarenheter kan dokumenteras från programvaruprojekt ”Webbutveckling

med Flask och WordPress” som kan vara intressanta för framtida projekt? . . . . 327.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . . 327.4 Vilket stöd har projektgruppen haft av WordPress vid utveckling av en webbplats? 337.5 Vilket stöd har projektgruppen haft av Flask vid utveckling av en webbplats? . . 347.6 Nåddes syftet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

A Gruppens syn på WordPress 35

B Hur arkitekturen beror på ramverk 46

C Hur olika arbetsflöden påverkar ett projekt 56

D Hur Scrumban skiljer sig åt mellan mjukvaruprojekt 64

E Hur en grupps syn på testning förändras under ett projekt 73

F Hållbar webbutveckling 85

G Dokuments inverkan på projektet 92

H En teamledares roll under gruppens olika faser 108

Referenser 115

Bilagor 119

Figurer1 WordPress-webbplatsen, som den levererades till Musikaliska konstföreningen . . 162 Flask-webbplatsen, som den ser ut i dagsläget . . . . . . . . . . . . . . . . . . . . 173 Webbutikens utseende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Popup-informationens utseende . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Statistik över aktiva hemsidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Gruppens sammanfattade svar på fråga 1. . . . . . . . . . . . . . . . . . . . . . . . . 397 Gruppens sammanfattade svar på fråga 2. . . . . . . . . . . . . . . . . . . . . . . . . 398 Gruppens sammanfattade svar på fråga 3. . . . . . . . . . . . . . . . . . . . . . . . . 409 Gruppens sammanfattade svar på fråga 4. . . . . . . . . . . . . . . . . . . . . . . . . 4010 Gruppens sammanfattade svar på fråga 5. . . . . . . . . . . . . . . . . . . . . . . . . 4111 Gruppens sammanfattade svar på fråga 6. . . . . . . . . . . . . . . . . . . . . . . . . 4112 Gruppens sammanfattade svar på fråga 7. . . . . . . . . . . . . . . . . . . . . . . . . 4213 Gruppens sammanfattade svar på fråga 8. . . . . . . . . . . . . . . . . . . . . . . . . 4214 Gruppens sammanfattade svar på fråga 9. . . . . . . . . . . . . . . . . . . . . . . . . 4315 Dokument repository utdrag vid en merge . . . . . . . . . . . . . . . . . . . . . . 5816 Python repository utdrag vid en merge . . . . . . . . . . . . . . . . . . . . . . . . 5817 En skala mellan 1-10, 1 betyder dåligt och 10 betyder jättebra. . . . . . . . . . . . . . 6818 1-Ingen Skillnad Från Wordpress 5-Mycket bättre . . . . . . . . . . . . . . . . . . . . 6919 Resultat av fråga ett, i före-enkäten . . . . . . . . . . . . . . . . . . . . . . . . . 7620 Resultat av fråga tre, i före-enkäten . . . . . . . . . . . . . . . . . . . . . . . . . 7721 Resultat av fråga fyra, i före-enkäten . . . . . . . . . . . . . . . . . . . . . . . . . 7722 Resultat av fråga fem, i före-enkäten . . . . . . . . . . . . . . . . . . . . . . . . . 7823 Resultat av fråga två, i efter-enkäten . . . . . . . . . . . . . . . . . . . . . . . . . 8024 Resultat av fråga tre, i efter-enkäten . . . . . . . . . . . . . . . . . . . . . . . . . 8125 Resultat av fråga fyra, i efter-enkäten . . . . . . . . . . . . . . . . . . . . . . . . 8126 Andel som använt sig av Word innan projektet . . . . . . . . . . . . . . . . . . . 9727 Andel som använt sig av LATEX innan projektet . . . . . . . . . . . . . . . . . . . 9728 Andel som använt sig mer av LATEX eller Word innan projektet . . . . . . . . . . 9829 Val av ordbehandlare som föredrogs till projektet . . . . . . . . . . . . . . . . . . 9830 Val av ordbehandlare som föredras till ett nytt projektet . . . . . . . . . . . . . . 9831 Svar från enkäten om för- och nackdelar med Word . . . . . . . . . . . . . . . . . 10032 Svar från enkäten om för- och nackdelar med LATEX . . . . . . . . . . . . . . . . 10133 Svar från enkäten om hur stor inverkan dokumenten har haft i projektetarbetet . 10234 Svar från enkäten om vilka dokument som spelat en stor roll i projektet . . . . . 10335 Antal Git commits under projektets gång för dokument . . . . . . . . . . . . . . 104

Tabeller1 Tabell med definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Resultat för undersökning av WordPress arkitektur . . . . . . . . . . . . . . . . . 493 Nätverksprestanda utan cachelagring . . . . . . . . . . . . . . . . . . . . . . . . . 894 Nätverksprestanda med cachelagring . . . . . . . . . . . . . . . . . . . . . . . . . 89

1 INTRODUKTION

1 Introduktion

Denna kandidatrapport har skrivits av projektgruppen Grupp 1 under vårterminen 2017. Irapporten presenteras projektet som gruppen genomfört, dess resultat, och arbetsmetoder.Rapporten innehåller även individuella delrapporter som skrivits av varje gruppmedlem.

1.1 Motivering

En ny webbplats åt Musikaliska konstföreningen har skapats. Den har många funktioner och ärskräddarsydd för att uppfylla Musikaliska konstföreningens behov. Projektgruppen kommer attgå in på hur man går till väga för att skapa en webbplats. Även hemligheterna kring hur manfår igång ett effektivt och roligt samarbete inom en grupp kommer att avslöjas. Läsaren får ävenlära sig mer om skillnaderna mellan att använda ett färdigt verktyg för webbutveckling jämförtmed att bygga allt själv.

1.2 Syfte

Syftet med projektet är att, tillsammans med kunden (Musikaliska konstföreningen), skapa enwebbnärvaro för föreningen som båda parter är stolta och nöjda med. Vidare vill gruppen lärasig mer om webbutveckling och hur ett teamarbete i större skala fungerar.

Syftet med rapporten är att gruppen ska få dela med sig av sina erfarenheter med projektarbetet,i form av lärdomar och insikter om utvecklingsprocessen som användes. Utöver det är syftet medrapporten att jämföra hur det är att utveckla med WordPress jämfört med Flask, och analyseravilket stöd man kan få när man använder de olika verktygen.

1.3 Frågeställning

1. Hur kan webbplatsen implementeras så att man skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från programvaruprojekt ”Webbutveckling med Flaskoch WordPress” som kan vara intressanta för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?

4. Vilket stöd har projektgruppen haft av WordPress vid utveckling av en webbplats?

5. Vilket stöd har projektgruppen haft av Flask vid utveckling av en webbplats?

1.4 Avgränsningar

Projektgruppen hade en tidsbudget på 3200 timmar, och har inte ägnat mer än den tiden påprojektet. Webbplatsen som togs fram med hjälp av WordPress avser att uppfylla kraven somkunden ställde på oss, och avgränsar sig genom att inte ha mer funktionalitet än den som krävs.Webbplatsen som togs fram med hjälp av Flask avser endast att visa upp hur en alternativadministrationspanel kan se ut, och saknar därmed mycket av den funktionalitet som krävs föratt webbplatsen ska vara användbar för kunden.

1

1 INTRODUKTION

1.5 Definitioner

Här tas flera akronymer och förkortningar upp för att läsaren ska kunna förstå dem. Tabell 1beskriver definitionen av termer som används i rapporten.

Term Definition

HTML Hypertext Markup Language

CSS Cascading Style Sheets

WYSIWYG What you see is what you get

IDE Integrated Development Environment

CMS Content Management System

Tabell 1: Tabell med definitioner

2

2 BAKGRUND

2 Bakgrund

Projektgruppen har fått i uppgift att utveckla Musikaliska konstföreningens webbnärvaro, föratt låta deras notförsäljning ta nästa steg i utvecklingen. Detta inkluderar både att kommamed en ny design till webbplatsen, men också att skapa en webbshop. Så här lydde den givnauppdragsbeskrivningen enligt föreningen:

Musikaliska konstföreningen är Sveriges äldsta fortfarande verksamma musikförlag.Inriktningen är västerländsk konstmusik. Det grundades 1857 för att göra det lättareför svenska tonsättare att ge ut sina verk. (Notutgivningen dominerades då avtyska förlag.) Bakgrunden är alltså en form av IT-historia – att kunna utnyttjadåtidens mass-spridningsform, på papper tryckta noter – till en bred, förhoppningsvisinternationell publik. Under 1800-och 1900-talen var spridningsformen någorlundaoförändrad, även om man gradvis övergav den ursprungliga crowd-funding-formen(en medlemskrets prenumererade på kommande utgåvor genom en årsavgift)till förmån för försäljning via återförsäljare – nothandlar och så småningomStatens musiksamlingar. Efter millennieskiftet tog föreningen fram en egen web,http://www.musikaliskakonstforeningen.se/, där utbudet visas upp och beställningarkan läggas via mail. Det har lett till en kraftig försäljningsökning (fortfarande somideell verksamhet och i belopp relativt blygsam) och internationalisering (numerakommer ofta över hälften av beställningarna utomlands ifrån: Europa, men ävenAsien och Nordamerika). Typiskt sett packas och skickas pappersnoter. Försäljningav pdf-er är ovanlig, inte minst av spridningstekniska skäl. Vissa trögrörliga äldreverk finns nedladdningsbara gratis. I Sverige har gireringar (plus- och bankgiro) ochinom EU elektronisk banköverföring länge varit smidiga betalsätt. Utvecklingen avelektroniska betaltjänster som Paypal gör det numera möjligt att ta emot betalningaräven från ett bankmässigt efterblivet land som USA, och att till rimlig kostnad taemot kortbetalningar (via PayPal). Tiden verkar dock kommen att ta nästa steg iutvecklingen av föreningens webbnärvaro.

Uppdragsbeskrivningen återfinns i sin helhet under Bilaga 1 i slutet av rapporten.

2.1 Nuvarande situation

Musikaliska konstföreningen har för närvarande en gammal webbplats där webbhotellet one.comär värd för webbplatsen. Det är en webbplats uppbyggd av många enskilda HTML-filer ochhar ett rörigt filsystem. Webbplatsen använder ingen databas där den lagrar information, utanallt som visas på webbplatsen finns i HTML-filerna. Detta medför att det är svårt att ändrainformationen på webbplatsen, och det existerar inget administrationsgränssnitt så föreningenmåste ändra informationen direkt i HTML-filerna. Föreningen har dessutom ingen digitaliseradbetallösning utan får i dagsläget manuellt fakturera användare som köper noter. Slutligen postaräven föreningen noterna till användarna manuellt.

2.2 Projekterfarenheter

Detta delavsnitt berättar om tidigare erfarenheter och lärdomar.

Alla gruppmedlemmar har varit med om ett mjukvaruprojekt tidigare. De sju datateknologsstu-denter som är med i gruppen har genomfört kursen ”Konstruktion med mikrodatorer - KMM”

3

2 BAKGRUND

vilket är ett stort projekt som omfattade sex personer. Den mjukvaruteknolog som är med i grup-pen har istället genomfört ett större Android-projekt. Till skillnad från tidigare projekt omfattardetta projekt en verklig beställare som har tänkt använda slutprodukten.

2.2.1 Förbättringspunkter

Den här sektionen avser att förklara vad medlemmarna i projektgruppen anser att de kan görabättre i jämförelse med tidigare mjukvaruprojekt de har varit delaktiga i.

• Viktigt att samtliga i gruppen berättar hur det går och vad de håller på med, varje vecka.Alla ska känna sig inkluderade.

• Ha ett konkret och effektivt kommunikationssätt som Slack.

• Att alla medlemmar i projektet ska ha koll på vad alla håller på med och därmed ha enchans att ta över/bidra.

• Ta tag i arbetet direkt och bli klar i tid.

• Se till att kommunikationen mellan medlemmarna är bättre än i KMM:en, framförallt skaändringar loggas och förmedlas.

2.2.2 Bra erfarenheter

Här listas några punkter som gruppen har tagit med sig som extra viktiga från tidigaremjukvaruprojekt de har varit delaktiga i.

Parprogrammering - Gör det enklare att upptäcka misstag och korrigera fel i koden. Bidraräven till att ge ett perspektiv från två olika individer, och det är skönt att kunna bolla idéer ochdiskutera om man sitter fast i något problem. Oftast löser sig problem genom att diskutera demeller att säga dem högt.

Veckomöten - Bra för kommunikationen inom gruppen, bidrar till att alla håller sig uppdateradeoch känner till projektets status. Alla sätts in i vad som ska göras under veckan och hur det går,vilket motverkar missförstånd och förseningar.

Planering - Gör det enklare att få en överblick av arbetet, och veta hur projektgruppen liggertill. En bra planering tidigt i ett projekt gör att man kan avgöra när projektet kommer attavslutas, och om gruppen ligger efter med något arbete.

4

3 TEORI

3 Teori

Här presenteras teori som läsaren behöver veta för att förstå resten av rapporten.

3.1 Scrum

Scrum är en agil arbetsmetod som används som ett ramverk inom produktutveckling med mindrearbetslag. Metoden är skapad för att ge en mer dynamisk utveckling och närkontakt med kund,och för att underlätta arbetsprocessen. Scrum är enkelt att lära sig men besvärligt att bemästra. Igrund och botten så består Scrum av Sprintar. En Sprint omfattar ungefär två till fyra veckor därsyftet för den aktuella Sprinten är att bli färdiga med en godtycklig prototyp. En Sprint bestårav planering för vad som skall göras, dagliga möten, själva utvecklingen, och en granskning avhur det gått i slutskedet samt en återkoppling på Sprinten. [1]

3.1.1 Scrummästare

En Scrummästare är en coach för gruppen som skall finnas som stöd för alla och se till attarbetet går som det skall. Scrummästaren jobbar nära tillsammans med produktägaren genomatt rapportera status för projektet och ge en bild av hur det går. En Scrummästare ser tillatt valet av arbetsflöde uppdateras och att uppgifter som är klara noteras i sprintbackloggen.Scrummästaren håller även i dagliga möten, start- och slutsprintsmöten.[2]

3.2 Trello

Trello är ett visuellt samarbetsverktyg som används av grupper i olika storlekar för att få sakergjorda. Trello består av flera delar, bland annat tavlor, listor och kort. En Trello-tavla kananvändas för att organisera en ny webbplats, eller en semesterplanering. Trello-tavlan kan ocksåanvändas för att samarbeta med sina kollegor. Trello-tavlan är uppbyggd av listor. Dessa listoranvänds för att organisera Trello-kort och för att skapa arbetsflöden, där korten kan flyttasmellan olika listor från start till slut. Trello-kort används för att beskriva uppgifter, idéer, samtsaker som ska bli gjorda, och förflyttas mellan listor för att visa framsteg som gjorts. [3]

3.3 Git och GitLab

Git är en öppen versionshanteringsmjukvara för projekt av alla storlekar. Git gör det enkelt attutveckla och lagra mjukvara med olika arbetsflöden och arbetsmetodiker. I huvudsak består Gitav ett förvaringsutrymme kallat repository där information om projektet lagras, allt ifrån filertill tydliga flöden över utvecklarnas bidrag. De enskilda bidragen kallas inom Git för en commit.Ett bidrag består av en beskrivande text och innehåller de förändringar som utvecklaren hargjort sedan det senaste bidraget. Git ger även utvecklarna möjlighet att grena ut projektet i fleragrenar så kallade branches. Detta gör att en utvecklare kan göra ändringar eller lägga till nyafunktioner utan att påverka de andra utvecklarnas delar. Vanligtvis används ett repository påen server genom att varje utvecklare laddar ner en lokal version där de arbetar. När utvecklarenarbetat färdigt laddar denna upp sina ändringar med en så kallad push. En push laddar upp

5

3 TEORI

sina bidrag(commits) till det gemensamma repository:t på servern. Detta gör att flera utvecklaresamtidigt kan arbeta med samma kodbas. [4]

För att kunna använda Git behövs alltså ett repository på en server och en tjänst för justdetta är GitLab. GitLab är en webbaserad mjukvara där en projektgrupp kan ha ett gemensamtrepository. GitLab är även ett komplement till Git vilket ger användaren möjlighet att arbetamed Git grafiskt i webbläsaren. [5]

3.4 Scrumban

Scrumban är en agil arbetsmetod baserad på Scrum och Kanban. Det finns skillnader i hurScrumban kan se ut då man i vissa fall tar mer av Kanban, medan man i andra fall tar mer avScrum. I det fallet man tar mer av Scrum ser arbetsmetoden liknande ut, undantaget är sättetman jobbar med arbetsuppgifter, som istället sker genom en Kanban metod. [6]

3.5 Kanban

Kanban är en agil arbetsmetod där fokus ligger på ett tydligt arbetsflöde. En typisk Kanbanskulle vara att ha en whiteboard med nedskrivna uppgifter uppdelade i olika rubriker så som:Inte Påbörjat, Påbörjat, Testning och Färdigt. Uppgifterna är nedskrivna på exempelvis post-itlappar och flyttas från en rubrik till nästa när det är lämpligt. De fyra olika principerna förKanban förklarar hur metoden bidrar till agilt arbete genom att visualisera, begränsa uppgifter,fokusera på flödet och kontinuerligt förbättra. [7]

3.6 Slack

Slack är en kostnadsfri överföringsapplikation speciellt anpassad för kommunicering i grupp-och projektarbeten. Konversation i Slack kan ske enskilt eller gruppvis där meddelanden sändsdirekt, detta ger en mer fokus på konversationen. Samtal med eller utan video finns tillgänglig iapplikationen som även stödjer delning av filer. [8]

3.7 LATEX

LATEX är ett typsättningssystem skapat för att säkerställa hög kvalitet på dokument. LATEX kananvändas till alla typer av dokument, men används oftast till tekniska och naturvetenskapligadokument. [9]

3.7.1 ShareLaTeX

ShareLaTeX är en webbaserad LATEX-redigerare som körs genom webben. Till skillnad från andraLATEX-redigerare är ShareLaTeX en server-baserad applikation, alltså krävs en webbläsare föratt komma åt verktyget. Dokument som skrivs genom ShareLaTeX kan kompileras direkt ochpresenteras i PDF-format vid sidan av källkoden. [10]

6

3 TEORI

3.8 Google Docs

Google Docs är ett ordbehandlingsprogram med smarta redigerings- och formateringsverktygsom hjälper till att formatera text, stycken och layout. [11]

3.9 HTML

HTML, eller HyperText Markup Language, används för att bygga webbplatser. HTML-kodstrukturerar innehållet på en webbplats. HTML gör det möjligt att publicera dokument påinternet med rubriker, tabeller, bilder, och listor. Formulär för transaktioner och bokningar kanskapas och video- och ljudklipp kan även inkluderas. Innehåll i en HTML-fil är bland annatparagrafer, listor och tabeller. [12]

3.10 CSS

CSS, eller Cascading Style Sheets, är ett stilmallsspråk som används för att beskriva hurinnehållet i en HTML-fil ska se ut. Detta inkluderar färger, layout, och fonter. CSS gör det möjligtatt anpassa webbplatsens presentation till olika typer av enheter med varierande skärmstorlekar.[12]

3.11 Bootstrap

Bootstrap är ett populärt HTML-, CSS- och JavaScript-ramverk som används för att utvecklaresponsiva och mobilanpassade webbplatser. Ramverket underlättar möjligheten att anpassawebbplatser för mobiltelefoner, surfplattor samt datorer, och erbjuder flera komponenter såsomknappar, listor, paneler och menyer som kan användas för att designa webbplatser. Bootstrap3 stödjer de senaste versionerna av webbläsarna Chrome, Firefox och Safari på mobila enheter,samt Chrome, Firefox, Internet Explorer (8-11, på Windows), Opera och Safari (på Mac) pådatorer. [13]

3.12 PHP

PHP är ett skriptspråk som körs på webbservern och används för att generera HTML-kod. När enförfrågan görs från en webbläsare till en webbserver exekveras PHP-koden och resultatet skickastillbaka till webbläsaren. Tillägg av PHP ger en mer avancerad funktionalitet på webbplatsendär PHP-koden kan bäddas in bland HTML-koden. [14]

3.13 MVVM

I projektet valdes arkitekturmönstret Model View Viewmodel, vanligtvis förkortat MVVM, förimplementation av webbplatsen i Flask [15]. Uppdelningen som genomförs med det här mönstretabstraherar presentationen, View, från hur informationen lagras, Model. I rapporten kommerdessa skrivas med svenska översättningar och det är därför både de engelska och svenska namnenfinns med i beskrivningarna nedan.

7

3 TEORI

Model/Modell: Det här lagret innehåller information som används av programmet. Detta kanvara vilket tillstånd applikationen är i eller lagret som är ansvarig för att hämta in data frånnågon form av lagring, exempelvis en databas.

View/Vy: Detta lager är presentationslagret. Det omfattar användargränssnittets struktur ochlayout.

Viewmodel/Visningsmodell: Det här lagret binder samman de två andra lagren. Via dettalager kan förändringar till modellen göras från användargränssnittet, på så vis leder detta till attlogiken för programmet ligger i det här lagret.

3.14 WordPress

WordPress är ett så kallat Content Management System, förkortat CMS. Ett CMS hanterar blandannat lagringen av innehållet på webbplatsen, men också presentationen av innehållet. I praktikenkan man alltså göra en webbplats utan att skriva någon kod när man använder WordPress.Det betyder också att när man utvecklar för WordPress, så finns specifika komponenter somkan användas för att bygga webbplatsen där dessa komponenter är teman och plugins. Temanär hur webbplatsen ser ut och fungerar från en användares perspektiv och plugins utökarfunktionaliteten av WordPress. [16]

I WordPress är det möjligt att skapa och uppdatera en webbplats utan att behöva ha djupakunskaper inom webbprogrammering och webbdesign. WordPress är i grunden skapat för bloggar,men kan även användas till alla möjliga typer av webbplatser eftersom det finns många färdigaplugins att utgå ifrån. WordPress kan laddas ner kostnadsfritt och har öppen källkod, vilketinnebär att alla kan få tillgång till källkoden samt har rätt till att ändra och förbättra koden.[16]

3.15 Python

Python är ett dynamiskt typat interpreterat programmeringsspråk. Att det är ett dynamiskttypat språk betyder att variabler och funktioner inte behöver deklarera vilken typ av datade innehåller eller ger tillbaka. Att det är interpreterat betyder att koden tolkas under självakörningen av programmet. [17]

3.16 Flask

Flask är ett ramverk för Python som underlättar utvecklingen av serversidan på en webbplats.Ramverket hjälper exempelvis till med att hantera trådar och att tolka vilken funktion som skaköras då en specifik sida på webbplatsen besöks. [18]

3.17 SQLAlchemy

SQLAlchemy är ett bibliotek för Python som används för att kommunicera med enrelationsdatabas. En stor del av biblioteket är en så kallad ORM eller Object-Relational Mapping.Detta innebär att det går att skapa tabeller i databasen baserade på Python-klasser. En instans aven sådan klass motsvarar en rad i motsvarande tabell i databasen. Användningen av SQLAlchemy

8

3 TEORI

tillåter en att använda sig av dessa klasser för att lägga till, hämta, ta bort eller förändrainnehållet i databasen. [19]

3.18 Jinja

Jinja (Jinja2) är en mall-motor (template engine) för Python och har stöd för unicode, möjlighetatt utveckla i en sandboxmiljö, och används av många, bland annat av Mozilla och Instagram.Jinja förbättrar bland annat webbplatsens säkerhet genom att förhindra farlig kod från att köras(cross site scripting), samt genom att kunna övervaka varje del av exekveringen i ett sandbox-läge. [20]

3.19 Widgets

Det som benämns som Widgets i denna rapport är projektgruppens egna definition. En Widgetär en HTML-komponent som bygger upp innehållet på webbplatsen. En sådan komponent tarupp hela bredden av undersidan den är placerad på. För varje Widget finns också en motsvarandePython-klass som används för att generera komponenten.

3.20 JSON

JSON (en. JavaScript Object Notation) är en kompakt textbaserad standard som använd vidutbyte av data. [21]

3.21 AJAX

AJAX (engelska Asynchronous JavaScript and XML) är ett samlingsnamn på vissa tekniker somanvänds vid konstruktion av webbapplikationer. AJAX används huvudsakligen för att skapainteraktiva applikationer, genom att möjliggöra hämtning och sparande av data utan att enanvändare behöver ladda om sidan. [22]

3.22 Hållbarhet

En stor debatt som pågår i dagsläget omfattar hållbarhet och hållbar utveckling. Det sägs attjordens resurser är begränsade och till slut kommer förbrukas helt. För att inte förbruka deåterstående resurserna är det viktigt att använda resurserna klokt och på ett återvinnande sätt.[23]

En ingenjör bör konstant tänka på de olika hållbarhetsaspekterna, bland annat underutvecklingen av en produkt. Det finns tre viktiga effekter på miljöhållbarhet man bör ta hänsyntill:

1. Den direkta påverkan av resultatet eller existensen av produkten såsom växthusgas,strålning, elektronikavfall, farliga och ovanliga ämnen.

2. Den påverkan av följdmomentet såsom införskaffande eller transporteringen av produkten.

9

3 TEORI

3. Den långsiktiga påverkan såsom ändringar av till exempel energiintensiteten eller utbyteav delar. [24]

Tillsammans med effekterna på miljön beskrivs även fem typer av hållbarhet:

1. Mänsklig hållbarhet, att upprätthålla liv, hälsa och utbildning.

2. Socialmässig hållbarhet, att upprätthålla det sociala beteendet.

3. Ekonomisk hållbarhet, att upprätthålla de ekonomiska kapitalen.

4. Miljömässig hållbarhet, att upprätthålla miljön och resurser.

5. Teknisk hållbarhet, att upprätthålla den långsiktiga användningen av systemet samt desspåverkan. [24]

3.22.1 Hållbarhetskrav

Hur kan man som produktutvecklare bidra till en mer hållbar utveckling? Kunden tänker oftainte alls på hållbarhet när de yttrar sin vilja kring produkten, däremot tänker kunden oftapå exempelvis säkerhetsegenskaperna i produkten. Kravanalys är en kravsättningsmetod sombehandlar analysering av ”elicitation”, dokumentation och systemkrav. Kravanalytikerna börtänka på vilka intressenterna är, vad det är för produkt som skall byggas och hur produktenskall byggas. Här bör olika typer av hållbarhetsinverkan alltid finnas i åtanke. Det finns tre olikatyper av kravinverkan:

1. Direkta effekter av användning.

2. Indirekta effekter av användning.

3. Storskaliga och långsiktiga effekter av användning. [24]

3.23 Systemanatomi

En systemanatomi beskriver ett system som en riktad graf, där varje nod representerar ettdelsystem eller delfunktionalitet och båge mellan två noder indikerar ett beroende. Fokus försystemanatomin ligger på vilken funktionalitet som systemet ska ha[25]. Exempel på sådanfunktionalitet är "köpa noter", vilket i sin tur kräver bland annat ett betalningssystem och endatabas för att spara noterna i.

10

4 METOD

4 Metod

Detta kapitel omfattar gruppens arbetsgång i projektet under utveckling och vilka verktyg somanvänts.

4.1 Roller

AnalysansvarigAnsvarade för kravspecifikationen och kontakten mellan Musikaliska konstföreningen ochprojektgruppen, samt såg till att båda parter var överens.

ArkitektTog fram den övergripande strukturen för systemet och såg till att kraven på produkten gick attuppfylla med den arkitektur som valdes.

DokumentansvarigSkrev en mall för dokument och såg till att leveranser blev utförda i tid. Ansvarade även föranvändarmanualen och installationsmanualen.

KonfigurationsansvarigTog hand om versionshanteringen genom att besluta om vilket system som skulle användas ochhur.

KvalitetssamordnareSkrev en kvalitetsplan. Ansvarade även för att kvalitetsarbetet genomfördes.

TeamledareLedde arbetet och ansvarade för att gruppen uppnådde målen. Ansvarade också för projektplanenoch gruppens gemensamma kalender. Vidare hade teamledaren även sista ordet när det behövdes.

TestledareSkrev en testplan som specificerar hur testning skulle genomföras under projektets gång, samtsåg till att testerna som skrevs är heltäckande.

UtvecklingsledareAgerade Scrummaster i projektet, samt såg till att kraven för kodstandarder uppfylldes.

4.2 Arbetsmetod

Gruppen kom överens om att arbeta med Scrumban-metodiken. Kommunikationen inom gruppenskedde genom applikationen Slack.

4.2.1 Scrumban

Arbetsuppgifter som skall eller bör göras lades upp som ett kort på en gemensam tavla på Trello.Uppgifterna sorterades sedan utifrån dess prioritet, med de viktigaste uppgifterna överst. Dettainnebar att de mest prioriterade uppgifterna, det utvecklarna bör utföra först, hamnade överstpå tavlan.

11

4 METOD

Metoden valdes då gruppen ansåg att Scrumban bidrog till en planering som är flexibel ochtillät att Musikaliska konstföreningen kunde hålla sig involverade i projektet under dess gång.Gruppen ansåg även att nya krav och ändringar som lades till under projektets gång inte blevså röriga att hantera om de använde sig av Scrumban.

4.2.2 Kommunikation via Slack

Större delen av gruppens kommunikationen skedde genom Slack där bland annat sjukdomar,förseningar, information om kommande möten och påminnelser om viktiga deadlines meddelades.

Slack kan även användas till att dela filer, men detta har gruppen inte utnyttjat då verktyg Gitoch Drive användes för det ändamålet. Istället användes Slack för att länka till externa filer ochkällor med koppling till projektet.

Utöver Slacks användningsområde som kommunikation för viktiga meddelanden så fanns detäven en kanal för diskussioner som inte var relaterade till projektet.

4.3 Utvecklingsmetod

För att utveckla produkten har följande utvecklingsprocedurer använts.

4.3.1 Workshop

En Workshop går ut på att gruppen under ett kortare arbetspass gemensamt arbetar med ettverktyg för att lära sig hur det används. Anledningen till att workshop infördes var för attalla i gruppen skulle få en grundläggande kunskap om hur de olika verktygen fungerar. Detgenomfördes workshops i Git, LATEX, WordPress, samt HTML och CSS.

4.3.2 Systemanatomi

Tidigt under projektet togs en systemanatomi fram. Denna har sedan hjälpts oss ta framarkitekturerna för båda projekten. Den har använts för att få en övergripande koll på systemetsfunktionalitet och dessa funktioners beroenden.

4.3.3 Moduluppdelning

Med moduluppdelning så menas det att gruppen delade upp produkten i mindre delar, så kallademoduler, där varje modul representerar en deluppgift av hela projektet. Modulerna deladessedan in i mindre moduler, och detta upprepades tills varje modul var stor nog att kunnagenomföras inom rimlig tid av en person. Hur dessa moduler användes varierade mellan detvå olika delprojekten.

12

4 METOD

4.3.4 Parprogrammering

Inom Scrumban är parprogrammering en metod där två personer arbetar sida vid sida vid engemensam dator. Denna metod prövades under den andra sprinten genom att en person kodadeoch en person observerade. Observatören hade i uppgift att vara uppmärksam och följa arbetet,samt att kontinuerligt komma med förslag och förbättringar.

Parprogrammering har möjlighet att bidra till att koden får en bättre struktur och design, samten minskad risk att buggar uppstår [26]. På grund av detta ansåg gruppen att parprogrammeringvar en lämplig metod att använda.

4.3.5 Testning

En testplan skrevs under ett tidigt stadium uppdaterades inför varje sprint. Testplanen går attläsa i [27]. I huvudsak användes ett verktyg som kontrollerar att webbplatsen följer HTML-standarder, och Google Insights för att kontrollera att webbplatsen inte laddar långsamt. Utöverdet så utfördes också enhetstester, samt ett acceptanstest med Musikaliska konstföreningen.

4.4 Utvecklingsverktyg

Följande utvecklingsverktyg har använts till projektet.

4.4.1 WordPress

Gruppen konstruerade den nya webbplatsen i WordPress och byggde upp en WordPress-designfrån grunden. Ett fåtal plugins för WordPress utnyttjades också.

4.4.2 Git

Versionshanteringen av dokumentation och kod gjordes med GitLab, som är en hanterare förgit-arkiv. Ändringar i koden och dokumenten laddades alltså upp till GitLab, så att samtligagruppmedlemmar hade tillgång till den senaste versionen. På så sätt kunde alla hålla siguppdaterade och undvika krångel med koden.

Gruppens storlek leder till att många ändringar från många personer behöver kunna spåras,vilket gjorde att versionshantering var mycket viktigt.

4.4.3 Trello

Gruppen utgick från en tavla, i Trello, uppdelad i fyra sektioner med faserna: att göra, underutveckling, granskning, och klart. Nya kort som lades till hamnade först under ”att göra” och efteratt någon eller några skrivit upp sig på kortet så hamnade kortet i stadiet ”under utveckling”.När kortet verkade vara utfört så flyttades det till ”granskning” där gruppen kontrollerade attdet verkligen var färdigt. Om kortet blev godkänt av gruppen så hamnade det till slut under”klart”. Om kortet inte blev godkänt så flyttades det tillbaka till ”under utveckling”.

13

4 METOD

4.4.4 PyCharm

PyCharm [28] är den IDE som användes för utvecklingen av Flask-hemsidan. Den användes föratt skriva och modifiera kod, installera Python-bibliotek samt undersöka innehållet i SQLite-databasen. Från PyCharm startades också exekveringen av programmet och de enhetstester somskrevs för systemet.

4.5 Metod för att fånga erfarenheter

Under varje veckomöte hade projektgruppen en punkt i agendan där varje gruppmedlem kort fickberätta om vad de har lärt sig under den senaste veckans arbete. Dessa berättelser skrevs ned iprotokollet så att det gick att titta tillbaka på vad gruppen lärt sig under de olika veckorna. Pådetta sätt kan gruppmedlemmarnas utveckling spåras. I diskussionen sammanställs lärdomarnasom fångas upp med denna metod.

4.6 Arbetsförlopp

Projektet började med ett gruppmöte och där alla projektmedlemmar tilldelas en specifikansvarsroll. Under varje vecka hade gruppen ett möte tillsammans med handledaren. Inför varjemöte hade ett protokoll förberetts där samtliga medlemmar fick skriva in det de vill ta upp påmötet. Veckomötena hade rullande sekreterare, och en lista över vem som är sekreterare undervilken vecka förberedes i början av projektet.

4.6.1 Dokumentation

De stora dokumenten såsom kravspecifikationen, projektplanen, arkitekturdokumentation,testplanen, kvalitetsplanen och kandidatrapporten är alla skrivna i LATEX-kod som senarekompilerades till PDF-format. Alla dessa dokument följer en egen standard som framtagitsi en stilmall av gruppens dokumentansvarig. I stilmallen finns bland annat en framsida,dokumenthistorik, projektidentitet, sidhuvud och en standard för hur källhänvisningar skase ut i dokumenten. I mallen finns även en standard för hur dokumenten bör utformas, engrupplogga och LATEX-kod för vanliga framkommande implementationer som tabeller, bilder,citering, teckensnittsegenskaper med mera.

De mindre dokumenten som exempelvis statusrapport, mötesprotokoll och granskningsdokumentär framtagna med Google Docs.

4.6.2 Utveckling

Från och med iteration två planerades ett sprintmöte in en gång varannan vecka. Under varjesprintmöte lyfte Scrummastern fram de uppgifter som bör genomföras under nästa sprint.

4.7 Hållbarhet ur ett miljöperspektiv

Flertalet olika webbhotell undersöktes, för att se vad de själva skriver om hållbar utveckling ochmiljöaspekten av att vara servervärd åt hemsidor. Med utgångspunkt från listan över webbhotell

14

4 METOD

som finns på Svenska webbhotell - Topplista gjordes en snabb men systematisk undersökningöver vad de webbhotell som ligger i topp 15 skriver om hållbar utveckling [29]. Undersökningengår ut på att någon, med start på webbhotellets förstasida, ska kunna navigera sig till en textdär det står något om miljöaspekter inom loppet av några minuter. Om sådan text inte gick atthitta inom några minuter gjordes bedömningen att text saknas.

Resultatet av denna undersökning användes inte i projektet, men det diskuteras i en senaresektion.

15

5 RESULTAT

5 Resultat

Projektet resulterade i två olika versioner av en webbplats. Dels en fullständig webbplats byggdmed PHP och WordPress samt en prototyp byggd från grunden. Prototypens serversida ärbyggd med hjälp av Python-ramverket Flask och SQLAlchemy. En bild över den slutgiltigawebbplatsen, som den levererades till Musikaliska konstföreningen, visas i figur 1. En bild påwebbplatsprototypen visas i figur 2.

Figur 1: WordPress-webbplatsen, som den levererades till Musikaliska konstföreningen

5.1 Systembeskrivning för WordPress-webbplatsen

Utvecklingen av webbplatsen har gjorts i WordPress och har därför följt den arkitektur somkrävs för att arbeta mot det ramverket. För att få den önskade designen utvecklades ett egetWordPress-tema.

5.1.1 Webbutikens innehåll

Musikaliska konstföreningen ville kunna skriva text både för kompositörer och verk, och dessutomkunna associera ett verk med en kompositör. För att lösa detta skapades två egendefinieradeinläggstyper, ”composer” och ”product”, som dyker upp som flikar i administrationspanelenför WordPress-sidan. Till varje WordPress-inlägg går det att associera extrainformation utövertexten som står i inlägget (även kallad metadata eller ”anpassade fält”) i WordPress. Med hjälpav detta så kunde ett verk kopplas ihop med en kompositör, genom att låta ett fält för verketinnehålla kompositörens ID. Detta gjordes som en anpassning efter vad WordPress tillåter en attgöra, och i ett ramverk med mer kontroll så hade det varit möjligt att lagra denna informationdirekt i en relationsdatabas, med lämpliga JOINs när data ska hämtas.

För att göra det enklare för Musikaliska konstföreningen att uppdatera metadatan för varje verk,så skapades ett par olika speciella ”metaboxes” för inläggstyperna. En metabox är en ”låda” som

16

5 RESULTAT

Figur 2: Flask-webbplatsen, som den ser ut i dagsläget

kan sättas in på varje inlägg av en viss inläggstyp, och vars innehåll kodas i PHP och HTML.Exempelvis så skapades en metabox för att låta en administratör kunna välja kompositör från enlista, som i sin tur uppdaterar metadatan, istället för att låta administratören modifiera datandirekt.

Musikaliska konstföreningen ville kunna uppdatera ordningen verken står listade under varjekompositör i webbutiken. För att lösa detta valdes att en metabox för kompositörsinlägg görs,där alla kompositörens verk står listade. Bredvid varje verk finns en siffra som går att redigera,som representerar ordningen som verken listas i webbutiken.

För att låta Musikaliska konstföreningen kunna skriva in priser, pristyp, och eventuell länk tillden digitala filen, så gjordes en metabox som består av en stor matris där de kan fylla i lämpligprisinformation. Hela matrisen sparas sedan som metadata i JSON-format.

5.1.2 Webbutikens utseende

En bild på webbutikens utseende går att se i figur 3. Större delen av webbutiken byggs upp ifilen sheets.php, bortsett från sidomenyn som byggs upp i sidebar.php. I sheets.php så användsWP_Query (funktion som fungerar som mellanlager till databasen) för att hämta inlägg av typenkompositör/verk, som sedan stiliseras med HTML och CSS.

För att se mer information om verket (eller om en kompositör) går det att trycka på knappen”Mer information”, för att få upp en popup-ruta med mer information. Ett exempel på en sådan

17

5 RESULTAT

Figur 3: Webbutikens utseende

ruta går att se i figur 4. I denna informationsruta finns stora objekt som musikspelare (Youtube,Spotify, Soundcloud), vilket gör det olämpligt att ladda in allt popup-innehåll när webbutikenbesöks. För att lösa detta användes AJAX. Ett AJAX-anrop som laddar in innehållet i popup-rutan, och sedan visar den, görs när ”Mer information”-knappen trycks på.

Figur 4: Popup-informationens utseende

5.1.3 Plugins

Standardfunktionaliteten i WordPress går att utöka med hjälp av plugin. Detta gjordes på någraställen, för att undvika att återskapa funktionalitet som redan finns tillgänglig. Följande pluginutnyttjades:

WordPress Simple Paypal Shopping Cart hanterar kontakt med Paypal, som sköterbetalningar. Pluginet ger en två funktioner: möjlighet att skriva ut en ”Lägg till i kundvagnen”-

18

5 RESULTAT

knapp och möjlighet att skriva ut en kundvagn. Kundvagnen skrivs ut i sidomenyn, och en ”Läggtill i kundvagnen”-knapp skrivs ut under varje verk som går att köpa.

Polylang hanterar översättningar av webbplatsen. Gör det möjligt att skapa flertalet olikaspråkversioner av varje inlägg och undersida. På webbplatsen skapas även knappar som gör detmöjligt för besökare att byta språkversioner.

Broken Link Checker är ett plugin som med regelbundna mellanrum agerar spindel på delänkar som finns i inlägg och på undersidor. Om någon av dem returnerar en olämplig HTTP-status (exempelvis 404) eller tar för lång tid på sig att ladda, så meddelas sidans administratörvia e-post, och de kan gå in och rätta till felet.

5.1.4 Vad har kunden för värde av det som skapats?

De huvudsakliga värdet för Musikaliska konstföreningen kommer från:

1. Lättare att underhålla webbplatsen

2. Underlätta försäljningen av noterna

3. Lätt att få hjälp med webbplatsen

Tidigare har Musikaliska konstföreningen behövt ändra direkt i HTML-filerna för att kunnauppdatera innehållet på webbplatsen, både för att ändra information och lägga upp nyaobjekt då webbplatsen saknade databas. Nu kan webbplatsens information uppdateras via detadministrationsgränssnitt som finns inbyggt med WordPress. Via administrationsgränssnittet gårdet också att enkelt att lägga till nya verk i databasen.

Kunderna som köper noter via webbplatsen kan nu sköta betalningen via PayPal på webbplatsen.Det gör det också lättare för Musikaliska konstföreningen som inte behöver hantera betalningenutan endast behöver skicka de noter som fortfarande skickas via post. En del av verken går ocksåatt ladda ner direkt som PDF och kräver då inget arbete för Musikaliska konstföreningen.

Eftersom webbplatsen utvecklades i WordPress som har en stor användarbas så är det lättför Musikaliska konstföreningen att i framtiden få hjälp med webbplatsen samt att om detuppkommer nya behov lägga till nya funktioner till webbplatsen.

5.2 Systembeskrivning av Flask-hemsidan

Det här systemet är utvecklat från grunden av projektgruppen med hjälp av ramverket Flask.Arkitekturen för systemet är baserad på en MVVM-arkitektur. Vilket alltså står för Model-View-Viewmodel och dessa tre lager i applikationen finns beskrivna nedan.

5.2.1 Modell

Modellen består av ett Python-paket med ett flertal Python-klasser som har skapats med hjälpav biblioteket SQLAlchemy. Eftersom de har skapats med hjälp av biblioteket så motsvararklasserna till stor del tabellerna som är lagrade i databasen. Undantaget är att vissa av fälteni klasserna är relationer som alltså är information som kan hämtas ur databasen men som intedirekt motsvaras av en kolumn i databasen.

19

5 RESULTAT

5.2.2 Vy

Vyn är det som användarna kommer att se, där användare både kan vara besökare på webbplatseneller administratören som använder administrationsgränssnittet. Det här lagrets funktion är attpresentera informationen på ett bra och användbart sätt samt att låta användaren interageramed informationen. Det här lagret är uppdelat i två olika komponenter home och admin somalltså är de två olika gränssnitten som finns beroende på om användaren är en administratöreller en besökare av webbplatsen. De olika vyerna är implementerade så att de är helt oberoendeav varandra.

5.2.3 Visningsmodell

Visningsmodellen är ett lager som ligger mellan de två andra lagren. Lagret är till för attförändringar till modellen inte ska leda till stora omskrivningar av koden för vyn. Här arbetasmodellens information om till ett format som fungerar bättre för att vyerna ska kunna arbeta meddet. Det är också här logiken för hur en användarens interaktion med vyn förändrar informationensom finns lagrad i modellen.

PageVM är en av de huvudsakliga filerna och klasserna i det här lagret. En instans av den härklassen fungerar som en undersidas koppling till modellen. Detta betyder att när en användareska dirigeras till en webbplats så skapas en instans av PageVM-klassen som hämtar sidansinformation från databasen. Vyn kan sedan med klassens metoder hämta färdig genererad HTML-komponenter med den information som finns i databasen. Dessa HTML-komponenter refererastill som Widgets och alla Widget-typer har en motsvarande Python-klass i detta lager.

5.3 Jämförelse mellan de två webbplatserna

I följande del jämförs fördelar och nackdelar med de två olika systemen.

5.3.1 Design

Designen är olika för de två webbplatserna. Detta visualiseras tydligt i introduktionen till kapitletResultat. WordPress-hemsidans design är influerad i hög grad av Musikaliska konstföreningenmedan Flask-hemsidans design är skapad utefter eget tycke inom gruppen. Designen är helt färdigoch implementerad för WordPress-hemsidan och i stort sett klar för Flask-hemsidan (undantagetadminpanelen).

5.3.2 Funktionalitet

WordPress-hemsidan är en fullt fungerande hemsida med möjlighet att köpa och sälja verk,kontrollera länkar, flera språkval med mera. Flask-hemsidan har i nuläget funktionalitet för attbyta undersidor och representera information från databasen. Det finns också stöd för framtidaimplementation av adminpanel, webbshop och dynamiskt tillägg av undersidor via adminpanel.

20

5 RESULTAT

5.3.3 Arkitektur

För WordPress-hemsidan så görs kontakten med databasen direkt i presentationslagret medanför Flask-hemsidan är ansvaret för databaskontakten och presentationslagret skilda frånvarandra. Som nämnts tidigare är modellen ansvarig för kommunikationen med databasen ochvisningsmodellen översätter modellen till presentationslagret.

5.4 Gemensamma erfarenheter

I den här sektionen diskuteras de gemensamma erfarenheterna som gruppen har haft under deolika iterationerna.

5.4.1 Iteration ett

Under iteration ett jobbade gruppen främst med att få en bra struktur i gruppen, skrivadokument, och påbörja ett samarbete med Musikaliska konstföreningen.

Positiva erfarenheter

Gruppmedlemmarna var nöjda med sammanhållningen i gruppen, och speciellt kick-off:en varmycket givande för dynamiken. Det gick lätt att dela in gruppens medlemmar i roller och allafick sitt förstahandsval. Tidigt under iterationen skrevs ett gruppkontrakt som specificerar hurgruppen ser på projektet, vilket gjorde att gruppen var överens om mål och ambitioner medprojektet. Dokumenten som skulle skrivas under iterationen blev snabbt färdiga och gruppen varnöjda med innehållet.

Negativa erfarenheter

Dokumenten delades upp mellan gruppens medlemmar, och de flesta hade ett specifikt dokumentsom de hade ansvar att skriva. Detta gjorde att dokumentskrivandet blev effektivt, men då detsaknades struktur för granskning så orsakade detta också att dokumenten inte blev lästa av alla.Testplanen, kravspecifikationen, och arkitekturdokumentet blev endast lästa av de som skrevdem. Även om alla hade en övergripande koll på vad som stod i dem så skulle det vara bättreom alla hade bra koll på dem i mer detalj. Det gruppen saknade var en bättre struktur fördokumenten, där varje dokument i något stadium blir läst av gruppens alla medlemmar.

5.4.2 Iteration två

Under iteration två så började gruppen med arbetet på webbplatsen, och hade gemensammagenomgångar av de tekniska verktyg som användes.

21

5 RESULTAT


Gruppen var överens om att det var givande att ha gemensamma workshops där de fick lära sigom LATEX, Git, WordPress, och HTML/CSS. Strukturen där gruppen hade en eller två personersom höll i aktiviteten fungerade mycket bra och gjorde att tiden användes effektivt.

Gruppmedlemmarna var mycket nöjda med de verktyg som användes, samt hur gruppen valtatt använda dem. Kommunikationen via Slack, versionshanteringen via Git, och aktiviteter viaTrello upplevde alla som något mycket positivt.


Gruppmedlemmarna hade inte någon gemensam databas som de jobbade mot under WordPress-utvecklingen, och alla arbetade med varsin lokala databas. Det gjorde att arbetet blevfragmenterat, och att gruppen i efterhand behövde kopiera över informationen manuellt.

Under sprinten så hade gruppen ganska begränsat med tid, vilket gjorde att utvecklingsledareninte hade tid att förbereda allt. Detta gjorde att gruppen inte jobbade strikt efter de mallar somskulle användas för Scrum.

5.4.3 Iteration tre

Under iteration tre färdigställdes Musikaliska konstföreningens webbplats byggd med WordPress.Gruppen arbetade även hårt med att försöka få fram en prototyp av en alternativ webbplatsbyggd med Python och ramverket Flask.


Gruppen kom hela tiden framåt i projektet och det kändes aldrig som de kört fast. Gruppmötenblev effektivare, diskussioner har flutit på bättre och det kändes som att gruppen hadehunnit med mer på möten. Gruppen hade också blivit bättre på att hålla sig till ämnetoch vidare hade gruppen förbättrat sina processer såsom versionshantering, Scrumban ocharbetsrapportering. Granskning och testning genomfördes och det var tydligt vad som skullegöras. Sammanslagningen mellan gruppens två delgrupper gick smidigt.


Samarbetet försämrades inom gruppen eftersom gruppen behövde dela upp sig i två mindregrupper och jobba parallellt. Detta berodde delvis på att kommunikationen mellan gruppernaförsämrades. Gruppen misstänkte också att bristen på en stabil lokal har varit en bidragandefaktor till samarbetsproblem och motivationsbrist. Det kändes inte lika seriöst att behöva bokasina egna salar/sitta hemma när det var dags att arbeta.

När gruppen delade upp sig i mindre grupper upplevdes det jobbigt att träffa hela gruppen.Gruppen hade inte samma känsla av samhörighet. Det upplevdes också som att det blev meranklagande ton.

22

5 RESULTAT

Gruppen missbedömde mängden arbete för WordPress vilket resulterade i att gruppen behövdeskjuta upp planeringen gång på gång. Detta i kombination med att Musikaliska konstföreningenhade svagt intresse för att följa projektgruppens arbete resulterade i att gruppen fick göra omsaker flera gånger vilket tog onödigt mycket tid.

5.5 Hållbarhet ur ett miljöperspektiv

Resultatet är att 5 av 15 webbhotell nämner något om miljöaspekter på sina webbplatser.

Binero nämner bland annat att deras energiförbrukning är låg tack vare virtualisering, och att”Vår kontorsel är enbart Bra miljövalsmärkt el från vind- och vattenkraft”. [30]

Citysites nämner att energin till deras datacenter kommer från vindkraft, och att de ”jobbarkontinuerligt stenhårt för att våra tjänster är så energieffektiva som möjligt”. [31]

Oderland beskriver vad de gör för miljön, hur de minskar sin energiförbrukning, och vilkamiljöcertifikat de har. ”Elen kommer endast från vattenkraft, biobränslen, vindkraft och solenergisom uppfyller Naturskyddsföreningens hårda krav”. [32]

One nämner att deras elektricitet kommer från vindkraft. [33]

Servage säger följande: ”Det finns ingen del i våra affärsprinciper som inte påverkas av detta[miljötänk] och det är en fundamental del av hur vi bedriver vår verksamhet”. [34]

5.6 Översikt över individuella bidrag

Gruppens syn på WordPress är skriven av Viktor Agbrink och är en individuell del avkandidatrapporten. I denna individuella del jämförs gruppens syn på WordPress före respektiveefter att projektet utförts. Syftet med detta är att undersöka varför gruppen tycks ha en negativsyn på WordPress trots att nästan ingen av gruppmedlemmarna har arbetat i verktyget förut.Avslutningsvis diskuterar författaren verktygets framtida användande, utifrån gruppens samtyckeoch statistik över verktygets användande.

Hur arkitekturen beror på ramverk är skriven av gruppens arkitekt, Fredrik Bengtsson. Det ären undersökning av hur den dokumenterade arkitekturen påverkas av vilket typ av ramverksom används under utvecklingen. Speciellt kollar den på skillnaderna vid utveckling med hjälpav WordPress som är ett CMS jämfört med utveckling med hjälp av Flask som är ett mertraditionellt ramverk.

Hur olika arbetsflöden påverkar ett projekt är en individuell rapport skriven avkonfigurationsansvarige, János R. Dani, i gruppen. Denna rapport ger en överblick över de olikaarbetsflöden som har använts under projektet för att versionshantera både dokument och kod.

Hur Scrumban skiljer sig åt mellan projekt är skriven av en av gruppens medlemmar ochutvecklingsansvarig vid namn Andreas Järvelä. Den jämför utvecklingsprocessen vid användningav Scrumban i två olika projekt. Den tar även upp hur olika arbetsmetoder kan påverka gruppensprestation på olika sätt.

Hur en grupps syn på testning förändras under ett projekt är skriven av gruppens testledare,Tobias Lundberg. Den behandlar hur utförandet av projektet har påverkat hur dess medlemmarser på testningens roll inom mjukvaruutveckling.

23

5 RESULTAT

Hållbar webbutveckling är skriven av gruppens kvalitetssamordnare, Adrian Shosholli. Denhandlar om hållbar utveckling och projektets ekologiska hållbarhetsaspekter.

Dokuments inverkan på projektet, en individuell rapport som omfattar styrkan i dokumentationensamt vilken påverkan och roll den har spelat i projektet. Denna delrapport är skriven avprojektgruppens dokumentansvarig, Hans Tchou.

En teamledares roll under gruppens olika faser är en delrapport skriven av gruppens teamledare,Viktor Wällstedt. Den fokuserar på att besvara frågan hur en teamledare kan agera under engrupps olika faser för att bättre bidra till teamets fortsatta utveckling.

24

6 DISKUSSION

6 Diskussion

6.1 Resultat

Valet av WordPress som arkitektur för projektet grundar sig i de krav Musikaliskakonstföreningen hade på webbplatsen. Nedan diskuteras de kraven och varför WordPress ansågsvara det som passade bäst. Dessutom motiveras varför gruppen valde att göra ett projekt iPython med Flask under den andra halvan av projektet.

6.1.1 Alternativen

Följande programmeringsspråk med ramverk övervägdes i projektet:

• Python med Flask

• Python med Django

• PHP med WordPress

• Node.js med Express.js

• Ruby med Ruby on Rails

6.1.2 Tidigare erfarenheter

I gruppen fanns olika erfarenheter av de olika språk och ramverk som togs upp ovan. Dessaerfarenheter bidrog till valet av ramverk. En stor fördel med att välja Python är att allamedlemmar i projektgruppen sedan tidigare hade erfarenhet av språket från tidigare kurser.Vissa medlemmar hade också tidigare erfarenhet av PHP, vilket används när man utvecklar etttema i WordPress. Dessutom hade några av gruppens medlemmar erfarenhet av ramverken Flaskoch WordPress.

6.1.3 Kostnad

Det gjordes en undersökning av kostnaden för olika webbhotell. Anledningen till undersökningenär att Musikaliska konstföreningen önskade att webbplatsen skulle ligga på ett webbhotell iställetför på en egen server. Det konstaterades att Musikaliska konstföreningens nuvarande webbhotell,One.com, var det absolut billigaste och passade bra med deras behov. Dock så stödjer One.comendast PHP.

One.com kostade Musikaliska konstföreningen cirka 15 kr/månad, vilket gjorde det till detabsolut billigaste webbhotellet. Det alternativ som kom på andraplats kostar ca 100 kr/månadför motsvarande tjänst.

6.1.4 Kundens behov

Det var tydligt att prestanda inte kommer vara ett problem för Musikaliska konstföreningen dådet är ett ganska lågt antal besökare till webbplatsen per månad. Musikaliska konstföreningenhar ett stort behov av att enkelt kunna lägga till nya verk till försäljning på webbplatsen

25

6 DISKUSSION

och ändra informationen på webbplatsen. Därför är det lämpligt med någon form avadministrationsgränssnitt, vilket som standard finns inbyggt i WordPress.

WordPress ger Musikaliska konstföreningen möjligheten att få hjälp med webbplatsen från annanpersonal, som exempelvis kundtjänsten hos deras webbhotell. Det gör att webbplatsen får enmycket längre livslängd, då de kan få hjälp att uppdatera webbplatsen.

En lösning designad i exempelvis Python inte är lika lätt att hitta personal som kan hjälpatill att underhålla. Anledningen till detta är att WordPress är enklare och har ett stort antalanvändare, medan Python med Flask har färre användare.

6.1.5 Sammanställning

Det konstaterades att WordPress var det uppenbara valet eftersom det fyller ut Musikaliskakonstföreningens behov, är lätt att underhålla, och framförallt att det är det billigastealternativet.

Python valdes som det språk som kommer användas under den andra delen av projektet, eftersomPython är det språk som medlemmarna i projektgruppen är mest familjär med sedan tidigare.Det gör att uppstartstiden blir kortare, vilket är viktigt i och med den begränsade tid somfinns kvar till projektet efter utveckling av WordPress-sidan. Flask valdes framför Django medmotiveringen att det inom gruppen finns en viss erfarenhet av ramverket sedan tidigare, samt attdet borde vara lättare att komma igång med eftersom att det är ett mindre omfattande ramverkän Django.

Flask har också ett flertal fördelar jämfört med WordPress vilket är anledningen till att Flaskvarianten också tas fram. Vid utveckling med Flask så finns det en större kontroll över vadsom lagras i minnet, vilket gör att det finns större möjligheter för optimering av specifika delarav systemet. Det är också lättare att kontrollera exakt vad som lagras, och hur det lagras idatabasen. WordPress administrationsgränssnitt är gjort för att vara väldigt generellt, men detinnebär också att det finns delar som inte fyller någon funktion för Musikaliska konstföreningen.Det går därför att göra det lättare för administratören av webbplatsen genom att skapa en egenadministrationspanel för ett system i Flask, som enbart har relevanta delar. Det gör också attett eventuellt byte av administratör blir enklare, eftersom det är färre saker att lära sig.

6.1.6 Vad återstår för att kunden skall få ut fullt värde av produkten?

WordPress-hemsidan uppfyller alla Musikaliska konstföreningens krav på deras nya webbplats,och således saknas det inte någonting. Det finns dock vissa tillägg man skulle kunna göra, somskulle göra sidan ännu bättre för Musikaliska konstföreningen. Man skulle kunna skriva en merutförlig dokumentation över hur man modifierar temat, så att de kan ändra designen på sidansjälva i framtiden. Man skulle även kunna lägga till fler alternativ för att modifiera vissa enklasaker, såsom färgtema direkt från det administrativa gränssnittet.

Flask-hemsidan uppfyller i nuläget inte alla de uppsatta kraven på Musikaliska konstföreningensnya webbplats. Det som saknas är huvudsakligen en koppling till PayPal, och en administrativpanel där de kan ändra innehållet på sidan. Utöver detta så måste även försäljningsverken läggastill i databasen, och möjlighet att administrera fler språkversioner behövs.

26

6 DISKUSSION

6.1.7 Tidsåtgång

Gruppen fick vid ett flertal tillfällen skjuta upp datumet för när WordPress-sidan skulle varafärdig. Det finns flera möjliga orsaker till detta, vilka kommer listade nedan.

• Gruppen är oerfaren när det kommer till tidsuppskattning. Det här är det första projektetav den här storleken som gruppens medlemmar genomför inom ramen för utbildningen,vilket gör att de kanske inte har fått tillräcklig övning i att uppskatta tid. Det kan ävennämnas att gruppen mestadels var oerfaren inom WordPress-utveckling, och underskattadetiden det tar att få saker gjorda med WordPress.

• Gruppen ville få WordPress-sidan färdig så snart som möjligt. Gruppen var från börjaninte positivt inställda till att göra en hemsida i WordPress, och många ville därför få denfärdig så snart som möjligt för att kunna ta tag i Python-delen av projektet. På grundav detta kan gruppen ha planerat in sina leveransdatum för WordPress-sidan alldeles förtidigt, istället för att planera och uppskatta tiden ordentligt.

• Musikaliska konstföreningen ändrade krav och idéer ett par gånger. När WordPress-sidannästan var färdig ville kunden att sidans design skulle ändras. Detta gjorde att gruppen fickplanera om för att kunna tillgodose kundens behov, och leveransdatumet flyttades fram.

Den feluppskattade tidsåtgången är troligtvis en kombination av de ovan föreslagna orsakerna.

6.1.8 Hur vi har utvecklats sedan tidigare projekt

Gruppen har blivit bättre på versionshantering. Git har dessutom fungerat bättre och bättreunder projektets gång. Kodkonflikter har varit små och enkla att hantera, medan de i tidigareprojekt har varit större och jobbigare att hantera.

Kommunikationen har fungerat bättre, jämfört med tidigare projekt. Slack har varit tillstor hjälp, och att använda emojis vid kommunikation har bidragit till gruppens personligaunderhållning och nöje. Slack har bidragit till att det har varit enkelt att få tag på varandra ochdiskutera saker.

Gruppens möten har har fungerat bättre än i tidigare projekt, och de har varit mer struktureradeän tidigare. Protokoll har fungerat som agenda och har alltid varit förberedda, medan tidigaremöten har haft något av en ”ta det som det kommer”-struktur. Det finns även protokoll frånsamtliga möten, vilket det inte har i tidigare projekt.

Gruppens medlemmar upplever att de är bättre på att använda (följa) utvecklingsmetodiker, ochnågra medlemmar nämnde att det här är första gången de lyckats använda en agil arbetsmetodik.

Dokument har varit till större hjälp än tidigare, då samtliga medlemmar nu har läst och använtsig av dokumenten som gruppen har skrivit, och inte bara skrivit dem för att kursen kräver det.

6.1.9 Viktigaste lärdomar inför framtiden

Det kanske absolut viktigaste som gruppen tar med sig från projektet är vikten av att tidigt tafram designförslag/prototyper. Detta hjälper projektgruppen och Musikaliska konstföreningenatt få samma bild av vad som ska produceras och sparar ofantliga mängder tid man annarslägger på att göra om saker som blivit fel. Så ofta man har möjlighet bör man visa Musikaliska

27

6 DISKUSSION

konstföreningen hur långt man kommit och hur produkten ser ut i nuläget för att undvika attjobba vidare på något de inte vill ha.

En annan viktig sak gruppen lärt sig är att allt löser sig. Även om saker känns jobbiga så ärdet ingen mening att drabbas av panik. Saker kommer inte alltid gå som man tänkt sig, ochom är man medveten om det så går det alltid att anpassa sig och lösa även de mest jobbigasituationerna.

Gruppen har också lärt sig flertalet verktyg/språk under projektets gång, exempelvis: HTML,CSS, Bootstrap, WordPress, PHP, Python, SQLAlchemy, Flask, Angular, Jinja, Blueprints,Selenium, Ajax, Markdown, och Scrumban.

6.1.10 Systemanatomi

Systemanatomin gav en överblick av systemet viket gjorde det lättare att sedan gå vidaremed att ta fram en arkitektur. Det var lättare att få en bild av vilken funktionalitet sombehövdes för att uppfylla olika användningsfall. Den gav också en överblick över de beroendenpå tredjeparts-program och -API:n som systemet har. Eftersom ett webbhotell skulle användasvar dock information om hårdvaran som fanns i systemanatomin ganska ointressant.

6.2 Metod

Här uppföljs de metoder som gruppen har använt sig av under projektet.

6.2.1 Arbetsmetod

Under projektet har gruppen använt sig utav Scrumban som arbetsmetod, med Trellokortmotsvarande post-it lappar. Metoden har fungerat bra under hela projektet, och gruppen harlyckats delat upp arbetet i självständiga moduler som inte överlappar varandra. Detta har gjortatt det alltid har funnits arbete att utföra, samtidigt som risken att utvecklarna förstör någonannans arbete eller skapar kodkonflikter minimeras.

För att upprätthålla en bra gruppkontakt har gruppen använt sig av Slack. Detta har letttill att gruppen enkelt kan få tag i varandra samt meddela övriga medlemmar om viktiginformation. Alternativa kommunikationsmedel som gruppen funderat över en kort period innanprojektstarten var en Facebook Messenger grupp eller sms-grupp, men dessa alternativ var ingaattraktiva val. Detta eftersom alla medlemmar såg Slack som klart överlägsen och enklare attanvända.

6.2.2 Utvecklingsmetod

Gruppen har under projektets gång utfört workshops med hela gruppen, i den takt som behövtsför att alla gruppmedlemmar ska kunna hänga med. Detta har medfört att alla gruppmedlemmarhar kommit igång med sitt arbete och därmed kortat ner inlärningskurvan i början av projektet.Anledningen till att gruppen inte valde endast individuell instudering var att vid workshops kundegruppmedlemmarnas erfarenheter tas upp och delas mellan medlemmar. Workshops skapade ävenen samhörighet mellan gruppmedlemmarna och fick medlemmarna att jobba mer.

28

6 DISKUSSION

Vid utveckling har gruppen använt sig av både parprogrammering och individuell programmering,totalt utfördes det mer individuell programmering än parprogrammering. I början av projektetjobbade gruppen i par, men ändrade arbetssätt till individuell programmering när gruppensplittrades i två. Vid detta skede blev kontakten mellan de två grupperna dålig. När WordPress-gruppen blev klar med webbplatsen slogs grupperna ihop och parprogrammering infördes igen.Varje WordPress-medlem parades ihop med en av Pythonmedlemmarna för att underlättaövergången från WordPress till Python. Vid sammanslagningen utav de två grupperna blevgemenskapen genast bättre och inlärningen för WordPress-gruppen underlättades.

Gruppen har inte lagt någon större ansträngning på testning. Gruppen har en testplan somföljdes, men denna är ganska liten. Den saknar information om exempelvis hur integrationstesterska gå till, vad kraven för enhetstester är, och vad för grundläggande säkerhetstester som bordeutföras. Gruppen kunde med fördel ha gjort en testplan med fler detaljer kring hur saker skatestas. Det kan dock påpekas att den testning gruppen har gjort har fungerat väl, och deaktiviteter gruppen valde att beskriva i testplanen var tydligt definierade.

6.2.3 Utvecklingsverktyg

Git (på GitLab) har använts för versionshantering av projektet, vilket har resulterat i att allagruppmedlemmar har kunnat arbetat samtidigt. Vid ett tillfälle under projektets gång råkade enutav gruppmedlemmarna ta bort hela projektet från GitLab. Detta är ett exempel på hur viktigtdet är att versionshantera sin kod, för tack vare GitLabs versionshantering lyckades gruppenåterställa projektet.

PyCharm underlättade skrivandet av koden i Flask-hemsidan på ett flertal olika punkter. Detgjorde det lätt att installera nya bibliotek eftersom det kunde göras direkt i IDE:n. Den inbyggdakontrollen för PEP8 gjorde det lättare att upptäcka fel mot standarden vilket ökar kvaliteten påkoden. Verktyget för att visa innehåll i en databas gjorde det enkelt att se att det som förväntasfinnas i databasen faktiskt är där. Det gjorde det också lätta att redigera innehållet de gångerinnehållet i databasen inte var det önskade. En av de problem gruppen stötte på med PyCharmvar att den ibland markerade inkluderade paket som ”inte använd” trots att de användes i koden.

Trello upplevdes professionellt och smidigt eftersom gruppen visuellt har kunnat lista upp arbeteni kort som skulle göras. Detta verktyget har haft en stor inverkan och bidragit till mer ordningoch reda eftersom medlemmarna skrev upp sig på det kort de ville arbeta med. Detta sätt harlett till att konflikter i arbete och arbetsuppdelning undvikits. Med Trello kunde gruppen ävenfå en blick över arbetsflödet och hela tiden se vad som skulle göras, på så sätt hittas arbetesmidigt vilket bidrog till effektivitet. Trello redigeras och uppdateras i varje startsprintsmöte därgruppen lägger till nya kort. Till början så lades alla kort som skulle göras upp på en och sammagång, detta gjorde det rörigt och skapade förvirring. Senare in i projektet bestämde gruppen föratt istället lägga upp allt på en gång och samma gång, kunde gruppen istället lägga upp någrakort i taget, alltså under varje startsprintsmöte.

WordPress visade sig vara ett ganska bra verktyg för att skapa webbplatser. WordPress har varitenkelt att använda och det fanns mycket information på internet när det uppstod problem. Detvar mer eller mindre ”straightforward” att få igång en webbplats och väldigt lite programmeringkrävdes för att ha någonting att börja med. Webbhotellet som Musikaliska konstföreningenanvänder hade även endast stöd för PHP-sidor, vilket var bra eftersom det inkluderar WordPress-sidor. I början av projektet trodde gruppen dock att en WordPress-sida inte skulle vara tillräckligtmed arbete för åtta personer, eftersom det hade varit svårt att dela ut arbetsuppgifter som skulle

29

6 DISKUSSION

räcka till alla. Det var bra att gruppen delade upp sig istället för att hela gruppen skulle arbetamed WordPress, för det hade bara krånglat till det.

6.2.4 Dokumenteringsmetod

Dokument har skrivits i LATEX, dessa dokument har sedan versionshanterats med Git där varjekapitel har delats upp i separata filer med kort på Trello. Detta har lett till att gruppen enkeltkunnat arbeta på dokumenten samtidigt utan att riskera kodkonflikter. I början av projektetfunderade gruppen på att använda sig utav ShareLaTeX för hantering av dokument, men efteren demokratisk röstning beslutade gruppen att LATEX och Git skulle användas.

Att jobba i ShareLaTeX kan leda till problem när man arbetar i en större grupp, det blir enkelt såatt man jobbar ”på varandra”. Det fungerar relativt bra när man sitter tillsammans och arbetardå man enkelt kan diskutera sitt arbete, men jobbar man på olika håll kan detta bli ett problem.Det är inte ett problem om man använder sig utav LATEX och Git då det är enklare att dela upp ienskilda kapitel. Däremot är kombinationen av LATEX och Git irriterande utefter det faktum attman ständigt måste byta gren när man ska byta dokument. Detta leder även till väldigt mångacommits samt onödig tid vid byte av dokument. Det hade kanske varit bättre att inte ha enenskild branch för varje dokument utan istället ha alla dokument i en och samma branch.

6.2.5 Metod för att fånga erfarenheter

Vid slutet av varje veckomöte har alla gruppmedlemmar fått berätta om sina erfarenheter frånden gångna veckan. Detta har genomförts med tanken att gruppen ska kunna följa upp gruppensutveckling. Tyvärr har detta inte riktigt följts upp under projektets gång, utan det är förstvid skrivandet av denna kandidatrapport gruppen sammanfattat resultatet. Vid flera tillfällenhar gruppmedlemmar haft svårt att formulera vad de har lärt sig under en arbetsvecka. Om engruppmedlem exempelvis skrivit dokument en hel vecka har hen inte lärt sig att skriva dokument,det kunde ju hen innan. Svaret på frågan vad har du lärt dig under veckan blir då ”ingenting”.

6.3 Arbetet i ett vidare sammanhang

6.3.1 Samhälleliga aspekter

Webbplatsen gruppen har skapat är till för en ideell förening som ger ut ”svensk konstmusik”.Föreningen själva skriver att ”Det kan röra sig om nyskriven musik, men föreningen väljer ävenibland att lyfta fram äldre mästerverk som förblivit outgivna”. Det föreningen syftar till attgöra är alltså att kunna göra svensk musik, känd som okänd, lätt tillgänglig för allmänhetatt köpa och ta del av. Detta kan ses som ett försök att besvara vissa delar av det svenska(konstnärliga) kulturarvet. Kultur i sig har en kraftig inverkan på hur människors identitet ochlivsmiljö formas, men även på ekonomi och social sammanhållning [35]. De exakta inverkningarnaav kulturbevarandet som den Musikaliska konstföreningen ägnar sig åt är ett alltför stort ämneför att ordentligt kunna behandlas i den här rapporten, och ämnet kan med fördel avhandlas avstudenter inom ett samhällsvetenskapligt program. Här nöjer gruppen sig med att konstatera attarbetet i det här projektet har bidragit till att göra viss svensk kultur mer lättillgänglig, vilketkan ha vissa samhälleliga implikationer.

30

6 DISKUSSION

6.3.2 Miljöaspekter

När gruppen undersökte vad webbhotellen själva skriver om sin energiförbrukning, såkonstaterades att de flesta inte behandlar den aspekten av sin verksamhet inom ett par klickfrån startsidan. Av ren tur ligger dock gruppens WordPress-sida på One, vilket är ett av dewebbhotell som skriver om sitt arbete för miljön på sin webbplats.

Från vad webbhotellen själva skriver om miljö, så är det främst energiförbrukning hos servrarnasom är den viktigaste faktorn när det kommer till miljöaspekten av hemsidor. I detta projektkan det vara lite knepigt att komma på några övriga faktorer som bidrar till en mer hållbarutveckling. En mindre faktor är att man utvecklar webbplatsen så att den anpassar sig till olikatyper av energisnåla datorer, surfplattor och mobiltelefoner.

Ytterligare faktorer som även kan spela roll kan till exempel vara webbplatsens struktur ellerflödet av data mellan enheterna. Dessa faktorer kan vara bra att ta hänsyn till om det härprojektet ska vidareutvecklas.

6.3.3 Etiska aspekter

Det finns en del etiska aspekter som man kan ta hänsyn till när man skapar en webbplats.

Lika tillgänglighet för alla

En webbplats bör sträva efter att vara tillgänglig för alla. Detta är något som man kan bidra tillpå flera sätt, varav de viktigaste berör webbdesignen. Man kan tänka på att inte använda färgersom är olämpliga för färgblinda. Personer som har nedsatt syn eller är blinda kan av naturligaorsaker inte ta till sig information som presenteras i en bild, vilket är en anledning till att man böranvända alt-taggar på sina bilder. Om en bild har en alt-tagg så kan en textuppläsare läsa upptexten, och innehållet finns tillgängligt även för de med nedsatt syn. Det är bra om man kan geanvändaren av webbplatsen möjlighet att själv anpassa hur information presenteras, exempelvisgenom att ge dem möjlighet att ställa in storleken på texten eller typsnitt. Det sistnämnda kanman åstadkomma genom att inte ladda in egna typsnitt på webbplatsen, utan istället användade typsnitt som definieras av användarens egen webbläsare.

I arbetet med Musikaliska konstföreningens nya webbplats har gruppen inte tänkt på att göraden tillgänglig för alla, men några av punkterna ovan har ändå prickats in. Exempelvis haralt-attribut på bilder och mestadels svart text på vit bakgrund, vilket gör sidan lättläst.

Innehållet på webbplatsen

Innehållet på en webbplats bör i sig inte vara oetiskt, vilket i den här rapporten syftar påinnehåll som är diskriminerande eller kränkande. Gruppen har gett Musikaliska konstföreningenen plattform där de på ett enkelt sätt kan publicera material. På så sätt har gruppen alltsågjort det enklare för Musikaliska konstföreningen att sprida oetiskt material eller propagandaöver Internet. Dock gjordes bedömningen att det inte är troligt att Musikaliska konstföreningenkommer att använda sin nya webbplats i några oetiska syften, vilket är varför gruppen intekänner att det skulle vara moraliskt tvivelaktigt att hjälpa dem att ta fram en ny webbplats.

31

7 SLUTSATSER

7 Slutsatser

Under denna rubrik presenteras slutsatserna som dragits utifrån resultatet.

7.1 Hur kan webbplatsen implementeras så att man skapar värde förkunden?

Den webbplats som levereras till Musikaliska konstföreningen är den som är implementerad iWordPress. Det värde som webbplatsen skapar för Musikaliska konstföreningen är ett mer lättanvänt system där de inte längre behöver ändra direkt i HTML-koden när de vill lägga till ettnytt verk till försäljning utan istället använda sig av WordPress administrationspanel. På den nyawebbplatsen kan också betalning tas via PayPal vilket gör det lättare för besökare på webbplatsenatt köpa noter, detta kan leda till en ökad försäljning för Musikaliska konstföreningen.Administrationen av försäljningen blir lättare då Musikaliska konstföreningen direkt får enbeställningsorder till sin e-mail samt i administrationspanelen. Tidigare behövde Musikaliskakonstföreningen hantera mail-kontakt med den som köper noter samt kontrollera att betalningenär genomförd. För att summera så kommer produktens värde för Musikaliska konstföreningen uren effektivisering av processen för administration av webbplatsen samt försäljning av noter ochatt en lättare betalningsmetod potentiellt kan öka föreningens omsättning.

7.2 Vilka erfarenheter kan dokumenteras från programvaruprojekt”Webbutveckling med Flask och WordPress” som kan varaintressanta för framtida projekt?

Det är viktigt att ha regelbunden kontakt med Musikaliska konstföreningen så att fel ochmissförstånd upptäcks i tid. Det är även viktigt att hela tiden hålla god kontakt inom helagruppen, speciellt när det blir svårt. Bra sammanhållning inom gruppen hjälper till att hållamotivationen uppe. Planeringar ger en tydlig bild av vad som ska prioriteras och visualiserarvad gruppen förväntas genomföra i projektet. Planeringen gör att medlemmarna vet vad deska göra härnäst efter att de genomfört en aktivitet. Det har varit nyttigt att genomföraett mjukvaruprojekt i en större grupp med en riktig kund. Det känns som att projektet ochsituationen har varit mer realistisk jämfört med tidigare projekt. Det har varit en bra lärdom attgöra saker på ”det rätta sättet”, med en ordentlig förstudie innan implementationen påbörjas.

7.3 Vilket stöd kan man få genom att skapa och följa upp ensystemanatomi?

I samband med framtagandet av systemanatomin, så togs också en beskrivning av användningsfallfram. Systemanatomin gav en tydlig bild av vilken funktionalitet som krävs för att en användareska kunna genomföra de användningsfall som fanns. Den ger också en bild av hur systemet passarin med övriga system. Ett exempel i detta projekt var kopplingen till både PayPal och databasen.Det gör att det blir lättare att se vilka gränssnitt som systemet måste ha mot andra system. Urett arkitektoniskt perspektiv så blir det lättare att identifiera begränsningar som gränssnittenkan sätta på systemet. Det som hamnar på de lägre delarna av systemanatomin, som kontakt tillelnätet, har inte bidragit till projektet eftersom dessa hanteras av webbhotellet som Musikaliskakonstföreningen använder sig av.

32

7 SLUTSATSER

7.4 Vilket stöd har projektgruppen haft av WordPress vid utvecklingav en webbplats?

WordPress är ett verktyg som ger en mycket hjälp på vägen vid skapandet av en webbplats.WordPress beskrivs vanligtvis som ett CMS, vilket per automatik innebär att WordPresshanterar och presenterar information. En WordPress-installation har per automatik ettadministrationsgränssnitt, där en administratör kan skriva in den information som ska finnastillgänglig. Den information sparas sedan i en databas, som administratören inte behöver brysig om hur den är utformad. När man utvecklar en webbplats med WordPress behöver man iallmänhet alltså inte bry sig om hur och var datan lagras i bakgrunden, utan endast vad det ärför data.

Det som man främst fokuserar på när man utvecklar i WordPress är hur datan presenteras, detvill säga det som besökaren möts av när de besöker sidan. Till detta har WordPress också rättmycket stöd att erbjuda, i form av en stor samling av färdiga teman. En del av dessa temanhar dessutom ganska stor frihet i hur man kan modifiera dem, i form av färg och placering avkomponenter. Slutsatsen är att man kan komma ganska långt i WordPress utan någon störreteknisk kunskap.

Ovan så diskuteras WordPress i allmänna termer, men frågan är hur WordPress har varit till hjälpi det här specifika projektet? I och med att gruppen valde att bygga ett eget tema från grundenså faller resonemanget om front-end i föregående paragraf. WordPress rekommenderar starkt attman följer en viss struktur när man bygger upp sitt tema, och denna struktur måste man till vissdel anpassa sig efter för att temat ska gå att använda. Lyckligtvis är detta väl dokumenterat,vilket har varit ett stort stöd under utveckling. WordPress som verktyg tillhandahåller ocksåmånga funktioner som hämtar och ritar ut det man vill. För att skriva ut innehållet av allainlägg på en undersida kan man exempelvis använda följande kodstycke (även kallad för ”TheLoop” i WordPress-dokumentationen).

// index.phpwhile ( have_posts() ) : the_post();

the_content();endwhile;

För att filtrera och sortera de inlägg man vill skriva ut så används funktionen WP_Query, varsargument är en associativ array av de egenskaper man vill filtrera eller sortera efter. Sådanafunktioner har underlättat arbetet mycket när gruppen har utvecklat temat, då gruppen intebehöver skicka in queries till databasen själva.

Gruppen har inte varit i lika stor kontakt med WordPress back-end, då gruppen inte riktigthar behövt det för det här projektet. Det närmaste gruppen har kommit är när gruppenskapade egna inläggstyper, vilket i princip var som att skapa ett plugin. WordPress erbjuderen del stöd för denna typ av arbete också. Från filen functions.php kan man skapa ”hooks” tillstandardfunktioner, vilket innebär att en egenskriven funktion körs i samband med att ett eventinträffar. Exempelvis så skapar gruppen en hook till det WordPress-event som sparar ett inlägg(och som startas när en administratör klickar på ”Uppdatera” eller ”Publicera”), för att modifieralite metadata. Det går alltså att utnyttja annan WordPress-funktionalitet när man vill utöka detadministrativa gränssnittet, vilket underlättar arbetet då man inte behöver återuppfinna hjulet.

33

7 SLUTSATSER

7.5 Vilket stöd har projektgruppen haft av Flask vid utveckling av enwebbplats?

Flask har inbyggt stöd för ett flertal olika bibliotek så som Jinja och SQLAlchemy, därför kommerdessa bibliotek även diskuteras som en del av det stöd som Flask ger till utvecklingen.

Flask

Flask gjorde det enkelt att koppla en ”HTTP-request” för en specifik sida till en viss funktionsom sedan kördes på servern. Flask skötte även tråd- och processhanteringen vilket gjordeatt gruppen istället kunde fokusera på att utveckla applikationen. Med hjälp av ”blueprints”kunde applikationen delas upp i delapplikationer. Detta hjälpte projektgruppen med attseparera presentationslagret för de två typer av användare som finns i systemet, besökare ochadministratörer.

SQLAlchemy

Istället för att skriva SQL-kod och skapa helt egna klasser för att hämta information fråndatabasen användes SQLAlchemy som innehöll färdiga klasser. Dessa klasser kunde sedan byggasvidare på. Klasserna användes bland annat för att kommunicera med databasen direkt. Relationermellan tabeller kunde även modelleras i dessa klasser, vilket varit mycket användbart.

Jinja

Jinjas mallar underlättade skapandet av sidor som laddades med information från databasen.Jinja gjorde det också möjligt att läsa in information från variabler i Python direkt i HTML-koden. Jinja gav även stöd för att skapa loopar för att exempelvis gå igenom en Python-lista påservern och lägga in det direkt i HTML-filen.

7.6 Nåddes syftet

Syftet med projektarbetet nåddes eftersom gruppen lyckades skapa en ny webbplats åt kundenutefter deras tankar och tycke. Genom att skapa ytterligare en prototypsida med ett annatramverk lyckades medlemmarna att lära sig fler nya språk och ramverk för olika typer avwebbapplikationer. Gruppen lärde sig även hur det var att jobba i både små och stora teammed webbutveckling.

Gruppen har i rapporten delat med sig av sina erfarenheter kring grupparbetet. Dessutom har enjämförelse mellan WordPress och Flask gjorts, i form av både en analys kring teorin och en analysav det färdiga resultatet, vilket gjorde att gruppen har lyckats uppnå syftet med rapporten.

34

A GRUPPENS SYN PÅ WORDPRESS

A Gruppens syn på WordPress

En utredning av Viktor Agbrink, analysansvarig i grupp 1.

A.1 Inledning

Utredningen speglar gruppens syn på WordPress. WordPress är i dagsläget världens mestanvända CMS-verktyg och bedriver i dagsläget (8 maj 2017) 27.9 procent av internet [36]. Trotsdess popularitet är det sällan jag hör studentet prata gott om verktyget. Detta var inget undantagför min projektgrupp, trotts att majoriteten av gruppen aldrig hade konstruerat en webbplats iverktyget förut. Jag tänkte därför ta tillfället i akt och jämföra deras åsikt angående verktygetföre respektive efter projektet, för att se om denna åsikt ändrats.

A.1.1 Syfte

Syftet bakom utredningen är att få en insikt på gruppens syn på WordPress och försöka draslutsatser angående verktygets framtida användande.

A.1.2 Frågeställning

1. Har gruppens inställning till Wordpress ändrats efter att projektet utförts?

2. Hur kommer webbplatser konstrueras i framtiden?

A.2 Bakgrund

Utredningen är baserad på ett projekt som utförts i kuren TDDD96 Kandidatprojekti programvaruutveckling. Vid projektstart bestämde sig gruppen väldigt tidigt för attimplementera en webbplats med ramveken Flask, utan att ta upp det med kunden eftersomdet inte var specificerat i projektbeskrivningen. I mitten av itteration ett fick gruppen tänkaom helt vid val av ramverk eftersom kunden ville att webbplatsen skulle bli implementerad iWordPress. Detta besked gjorde gruppen väldigt besviken, det var få som blev glada över dethär beskedet och frågar man runt bland studenter på universitetet är det väldigt få som serpositivt på WordPress. Jag har personligen aldrig konstruerat en webbplats i WordPress ochförsöker stå neutral i frågan, men lyckas inte riktigt och känner att jag har blivit påvärkad avomvärlden. Jag har alltså fått en negativ uppfattning om något jag aldrig testat. Detta gjordemig trollbunden vilket i sin tur ledde till denna utredning.

35


A.3 Teori

Här förtydligas de begrepp som används i rapporten. Den teori som nämns nedan kommer frånkandidatraportens gemensamma teoridelen under kapitel 3. Jag har valt att ta upp detta ännuen gång för att förenkla läsandet. Därav är detta inget viktigt för dig som kännder dig bekantmed detta.

A.3.1 WordPress

WordPress är ett så kallat Content Management System, förkortat CMS. Ett CMS hanterarbland annat lagringen av innehållet på webbplatsen, men också presentationen av innehållet. Ipraktiken kan du alltså göra en webbplats utan att skriva någon kod när du använder WordPress.Det betyder också att när du utvecklar för WordPress, så finns specifika komponenter som enkan använda för att bygga webbplatsen. Dessa komponenter är teman och plugins. Teman ärhur webbplatsen ser ut och fungerar från en användares perspektiv och plugins utökar funktio-naliteten av WordPress. [16]

I WordPress är det möjligt att skapa och uppdatera en webbplats utan att behöva ha dju-pa kunskaper inom webbprogrammering och webbdesign. WordPress är i grunden skapat förbloggar, men kan även användas till alla möjliga typer av webbplatser eftersom det finns mångafärdiga plugins att utgå ifrån. WordPress kan laddas ner kostnadsfritt och har öppen källkod,vilket innebär att alla kan få tillgång till källkoden och har rätt till att ändra samt förbättrakoden. [16]

A.3.2 Python

Python är ett dynamiskt typat interpreterat programmeringsspråk. Att det är ett dynamiskttypat språk betyder att variabler och funktioner inte behöver deklarera vilken typ av datade innehåller eller ger tillbaka. Att det är interpreterat betyder att koden tolkas under självakörningen av programmet. [17]

A.3.3 Flask

Flask är ett ramverk för Python som underlättar utvecklingen av serversidan av en webbplats.Ramverket hjälper exempelvis till med att hantera trådar och att tolka vilken funktion som skaköras då en specifik sida på webbplatsen besöks. [18]

36


A.4 Metod

Utredningen är i första hand baserad på en enkät med frågor angående gruppens syn påWordPress samt min personliga uppfattning om verktyget. Utöver detta kommer jag användamig utav statistik från internet för att dra slutsatser om WordPress framtida användande.

A.4.1 Praktiskt arbete

Gruppen kommer konstruera en webbplats i WordPress. Utefter denna erfarenhet ska jag bildamin personliga uppfattning om verktyget och representera den i utredningen.

A.4.2 Statistik

Statistik över aktiva webbplatser byggda med CMS-verktyg jämfört med webbplatser som inteär konstruerade med CMS-verktyg. [36]

A.4.3 Svar på enkät utskickad till gruppen

Här representeras de frågor som ställts i enkäten, tanken bakom frågorna och hur de kommeranvändas i utredningen. Enkäten skickades ut till gruppmedlemmarna efter att gruppen utförtprojektet.

1. Har du programmerat en hemsida mha WP innan projektet?

2. Skulle du kunna tänka dig att programmera en hemsida i WP innan projektet? (Vad hadedu för inställning till WP innan projektet?)

3. Om du hade en negativ inställning till WP innan projektet startade, varför hade du dådet?

4. Skulle du kunna tänka dig att programmera en hemsida i WP efter projektet? (Vad hardu för inställning till WP idag/i slutet av projektet?)

5. Har din inställning till WP ändrats under projektets gång? Mer positivt eller negativt ochisf varför?

6. Tror du att folk kommer att arbeta med att konstruera hemsidor i framtiden?

7. Tror du att det kommer att finnas en marknad för det?

8. Tror du att det kommer vara så pass enkelt att utveckla en hemsida i framtiden så attingen anställer något för att utföra arbetet utan gör det själva. (Är användarna framtidenswebbutvecklare?)

9. Tror du att WP är framtiden inom webbprogrammering?

Fråga 1 används för att ta reda på om gruppmedlemmarna har använt sig utav WordPress vidkonstruktion av webbplatser i ett tidigare skede.

Fråga 2 och 3 kommer att användas för att ta reda på gruppmedlemmarnas syn på Word-Press innan projektets start samt varför de tycker som de gör angående verktyget. Medans fråga4 och 5 kommer att användas för att ta reda på gruppmedlemmarnas syn på WordPress efter

37


projektet. Denna information kommer sedan användas för att ta reda på om gruppmedlemmar-nas syn på WordPress har ändrats efter att gruppmedlemmarna utfört ett projekt i WordPress.

Frågorna 6 till 9 används för att få insikt på gruppmedlemmarnas syn angående framtiden innomwebbprogrammering. Denna information kommer sedan användas tillsammans med WordPressanvändarstatistik för att dra dessa slutsatser.

A.5 Resultat

Här representeras utredningens resultat.

A.5.1 Statistik

Figur 5: Statistik över aktiva hemsidor

Statistik över aktiva webbplatser som är byggda med CMS-verktyg motsvarande hemidor byggdautan CMS-verktyg, statistiken är dokumenterad från 1 januari 2011 fram till 21 april 2017 [36].Figur 5 visar de CMS-verktyg som har 1 procent eller mer utav alla aktiva hemsidor jämtemothemsidor byggda utan CMS [36].

A.5.2 Enkät utskickad till gruppen

Här sammanfattas deltagarnas svar på den enkät som skickades ut. Det var totalt 6st som deltogi undersökningen.

38


Figur 6: Gruppens sammanfattade svar på fråga 1.


39



Noob betyder att man är en nybörjare, detta är inte uppenbart för alla. Därav förtydligas detta.


40




41




42



43


A.6 Diskussion

Projektet som gruppen fått i uppdrag att utföra motsvarar 400 timmar per persson som pååtta perssoner motsvarar 3200 timmar totalt. Att bygga en webbplats i WordPress tar inte sålång tid och omfattar därmed inte projektets storlek. Detta var en utav anledningarna till varförgruppen inte ville bygga en webbplats i WordPress. Detta nämns det inget om i enkäten men jagvet att det var en anledning bakom gruppens negativa inställning till WordPress och tar därmedupp det. Det var dock inte den enda anledningen bakom gruppens negativa syn på verktyget.Det verkar som att det saknas prestige i att bygga en webbplats i WordPress, man vill intebehöva anpassa sig till dess struktur och det är inte lika flexibelt som att bygga en hemsida frångrunden. Utöver detta tolkar jag att gruppen hällre ville utföra ett projekt i Python med Flaskför att det helt enkelt kändes roligare.

Enligt fråga 1, figur 6 i enkäten besvarar gruppmedlemmarna vilket erfarenhet de har utavWordPress sen tidigare. Det visar sig att enbart en utav sex deltagare har utfört ett mer djupgå-ende projekt i WordPress tidigare. Utav de resterande fem personerna hade tre personer testatverktyget lite, men inte något djupgående och två perssoner hade inte använt sig utav verktygettidigare. En utav de deltagarna som inte hade konstruerat en webbplats i WordPress tidigaresvarade ett på fråga 2, figur 7 och hade därmed en negativ inställning till verktyget innan projek-tet. Samma person hade på fråga 3, figur 8 motiverat detta enl följande ”För jag hört att der ären noobs väg till webbutveckling”. En utav de som hade arbetat lite i WordPress admingränssnittgav en trea på fråga 2 och besvarade frågan enl följande ”Jag tyckte att det var ett enkelt sättatt starta en blogg, och jag visste att det gick att använda till att göra andra typer av hemsidor.”.

Den förstnämnda perssonen har alltså en negativ syn på verktyget fasten personen inte hararbetat i verktyget tidigare. Denne persson har alltså bildat en uppfattning om verktyget uteftervad andra tycker. Den andra perssonen som besvarade fråga 3 hade en mer öppen syn angåendeWordPress men visste inte att verktyget var så flexibelt som det är. De övriga gruppmedlem-marna som inte svarade på fråga 3 tolkar jag som neutrala angående ämnet.

Fråga 2 och 4 figur 9 visar att gruppmedlemmarnas uppfattning angående verktyget har ändratsefter att ha utfört ett projekt i verktyget. Detta motiveras i fråga 5, figur 10 där medlemmarnabesktiver verktyget som ett smidigt, bra verktyg som snabbt ger resultat. De som fortfarandehar samma syn angående verktyget tycker inte om att koda i PHP och tycker inte att verktygetär tillräckligt flexibelt.

Personligen fick jag en positiv uppfattning av WordPress efter att ha arbetat i verktyget.Det är som sagt väldigt enkelt att komma igång med verktyget och det ger snabbt resultat.Innom viss mån håller jag med om att WordPress begränsar en, du får anpassa dig till WordPressplugins, back-end och dess tillhörande admingränssnitt. Utöver detta är WordPress flexibelt, dukan i stort sätt programmera webbplatsens front-end utefter din egna vilja.

För att få en bättre uppfattning om gruppens syn angående framtidens konstruktion av hem-sidor går jag djupare in på fråga 6,7,8 och 9 vilket motsvarar figur 11, 12, 13 och 14. Fråga6 och 7 ifrågasätter gruppmedlemmarnas uppfattning om den framtida arbetsmarknaden in-nom webbprogrammering. Här var alla gruppmedlemmar överens om att det kommer finnas enmarknad för konstruktion av webbplatser i framtiden och att folk fortfarande kommer arbetamed att konstruera webbplatser i framtiden. Fråga 8 ifrågasätter om gruppen tror att privat-perssoner i framtiden kommer vända sig mot en webbyrå vid konstruktion av sin webbplats,

44


eller om det kommer vara så pass lätt att konstruera en webbplats själv så de utför arbetesjälva istället. Här vart det lite mer spridda skurar, 6 svarade på frågan varav 4 svarade nejoch 2 övrigt där övrigt tolkas som ett neutralt svar i frågan. Fråga 9 går rakt på sak och frågargruppmedlemmarna om de tror att WordPress är framtiden inom webbprogrammering. Majori-teten utav de som svarade tyckte inte att det stämde, medans vissa var lite mer neutrala i frågan.

Ur statistiken som representeras i figur 5 ser vi att WordPress användarbas kontinueligt ökatsedan 2011 då ca 11 procent av alla aktiva hemsidor använde sig utav verktyget. 2017 har dennasiffra ökat till 27 procent men kommer denna trenden att fortsätta? Kollar man WordPress-kurvan ser man att den dalar ut en aning i slutet 2017 men det gör den vid andra tillfällen ocksåså det är svårt att dra någon slutsats utefter det.

A.7 Slutsatser

Här dras slutsatser kring utredningens frågeställningar, utefter de material som representerats iutredningen.

A.7.1 Har gruppens inställning till WordPress före projektet ändrats efter attprojektet utförts?

Enligt enkäten har gruppens syn angående WordPress ändrats åt det mer positiva hålletän det negativa hållet efter att ha utfört projektet. Detta gäller inte alla men majoritetenav gruppmedlemmarna tolkar jag som positivare till WordPress. Därmed skulle jag påståatt gruppens inställning till WordPress har ändrats under projektets gång, till en positivareinställning.

A.7.2 Hur kommer framtidens konstruktion av webbplatser att se ut?

Enligt figur 5 syns det att WordPress användarstatistik har ökat kontinueligt medans dess kon-kurerande CMS-verktyg kämpar för att hålla sig över 1 procentsgränsen. Att kurvan har gått idenna riktningen under så lång tid är ingen slump, dock tror jag att denna kurva kommer attdala ut med tiden. I den enkäten som skickades ut till gruppmedlemmarna var det ingen somtrodde att det inte skulle finnas en marknad för utveckling av hemsidor i framtiden och därhåller jag med. Däremot tror jag att framtidens konstruktion av hemsidor till viss del kommeratt bli ett vardagligt kunnande. Barn får i dagsläget lära sig programmering i skolan och denuvarande CMS-verktygen utvecklas konstant för att uppnå denna vision. Men större företagdär kvalitet, service och säkerhet är viktigare kommer förmodligen fortfarande vända sig tillföretag som konstruerar hemsidor, för att få en professionell webbplats.

45

B HUR ARKITEKTUREN BEROR PÅ RAMVERK

B Hur arkitekturen beror på ramverk

En undersökning av arkitektur för webbutveckling gjord av Fredrik Bengtsson, arkitekt i grupp1, TDDD96.

B.1 Inledning

Arkitekturens syfte är att under ett projekt hålla en struktur som gör det möjligt att underhållasystemet. Om alla utvecklare har en gemensam bild av hur systemet fungerar och hur systemethänger ihop så får man en väl strukturerad kod. Valet av arkitektur påverkar också huruvidasystemet uppfyller de krav som finns på det. Ett felaktigt val av arkitektur kan göra det svårareän nödvändigt att utveckla systemet.

I projektet användes två olika arkitekturer för att ta fram en webbplats. Den ena användersig av WordPress, ett Content management system, medans den andra använder sig av ram-verket Flask. I rapporten kommer dessa olika delprojekt för enkelhetens skull refereras till somWordPress-hemsidan och Flask-hemsidan.

B.1.1 Syfte

Syftet är att undersöka arkitekturens roll i detta projekt. Speciellt hur arkitekturens roll förändrasbaserad på om man använder Flask som är ett mer traditionellt ramverk jämfört med Wordpresssom är ett CMS.

B.1.2 Frågeställning

1. Hur ändras den dokumenterade arkitekturens roll beroende på om WordPress eller Flaskanvänds?

2. Hur väl följer implementationen den dokumenterade arkitekturen?

B.2 Bakgrund

I kursen TDDD96, Kandidatkurs i programvaruutveckling, hade jag rollen som arkitekt. Somtidigare nämnts genomfördes utvecklingen med två olika arkitekturer, den ena baserades påWordPress och den andra på ramverket Flask. Arkitekturen i WordPress är baserad på denstandard som finns för teman i WordPress, vilket är där majoriteten av utvecklingen är ge-nomförd. På grund av de begränsningar som WordPress sätter på strukturen så är alltså enhel del av de arkitektoniska besluten redan fattade. För en hemsida utvecklad med Flask ärdet däremot helt upp till utvecklarna hur strukturen ser ut. Därmed fattades de arkitekto-niska besluten av projektgruppen för Flask-hemsidan. Till en början arbetade hela gruppenpå WordPress-hemsidan och under den tiden tog dess arkitektur fram. Under iteration tre sådelades gruppen i två mindre grupper, ena gruppen fortsatte utveckla WordPress och den andrapåbörjade Flask-hemsidan. Jag var en av de fyra personer som var med i gruppen som börjadepå Flask-hemsidan, för att som arkitekt kunna vara med och ta fram arkitekturen även för detsystemet.

46


Att dokumentera och behålla arkitekturen för ett system är svårt även för de som jobbar iindustrin. Detta är något som Simon Brown tar upp i sitt tal Software architecture vs code.I talet ligger fokuset på att koden och arkitekturen måste hänga ihop för att arkitekturenska vara användbar. Detta är bakgrunden till frågeställningen om hur väl arkitekturen ochimplementationen följer varandra.[37]

B.3 Teori

Majoriteten av den teori som behövs för att förstå följande undersökning finns beskrivet ihuvudrapportens teorikapitel, kapitel 3. Speciellt av intresse är :

• Teori om MVVM-arkitektur i kapitel 3.13

• Teori om ramverket WordPress i kapitel 3.14

• Teori om ramverket Flask i kapitel 3.16

• Beskrivning om projektet definition av widgets i kapitel 3.19

B.3.1 Arkitektur

Arkitektur syftar i rapporten till mjukvaruarkitektur som enligt IEEE definieras som ”〈system〉fundamental concepts or properties of a system in its environment embodied in its elements,relationships, and in the principles of its design and evolution”. Det är alltså en abstraheradbeskrivning av ett mjukvarusystem och hur olika delar av systemet hänger ihop.[38]

B.4 Metod

För att undersöka frågeställning 2 gjordes en jämförelse av koden och den dokumenteradearkitekturen. För att sedan svara på frågeställning 1 gjordes det en analys av innehållet i dendokumenterade arkitekturen för båda systemen. I analysen görs även en jämförelse där bådasystemens arkitekturer jämförs med fokus på vad de faktiskt beskriver. För att få en bättrebild av hur arkitekturen faktiskt använts under projektet och där med dess roll så har ämnetdiskuterats med projektgruppen vid ett flertal tillfällen.

B.4.1 Jämförelse av arkitektur och kod för WordPress

Arkitekturen i WordPress bygger på specifika fil- och mappnamn, detta gör att dendokumenterade arkitekturen innehåller beskrivningar för vilka filer som finns och vad som skafinnas i dessa. Jämförelsen gjordes därför delvis mellan vilka filer som finns i arkitekturen och iimplementationen samt att dessa filer i implementationen gör det som är beskrivet i arkitekturen.

B.4.2 Jämförelse av arkitektur och kod för Flask

Arkitekturen för Flask projektet är framtagen av projektgruppen och beskrivs i dokumentationensom en MVVM-arkitektur. Jämförelsen görs för att se att koden på ett logiskt sätt går att dela

47


upp i de tre distinkta lagren som beskrivs i arkitekturdokumentet. Jämförelsen gjordes också förvarje enskilt lager för att se att de utför de uppgifter som beskrivs i dokumentationen.[39]

B.4.3 Analys av den dokumenterade arkitekturen

Analysen fokuserade på hur arkitekturens beskrivning varierar med avseende på vilken av detvå teknologierna som används. Analysen fokuserade då på vilka av de fyra olika arkitekturernasom beskrivs i studien ”Software Architecture in Industrial Applications” som finns närvarandei arkitekturen och om det finns variationer mellan de två arkitekturerna.[40]

Förutom själva arkitekturen undersöktes också de begränsningar till arkitekturen som tasupp i dokumentationen. För att bättre förstå dessa begränsningar och besluten om arkitekturundersöks också hur dessa hänger ihop med kraven på de två systemen.

B.5 Resultat

Här presenteras resultatet av jämförelsen mellan arkitektur och kod samt resultatet från analysenav arkitekturdokumentationen. En sammanfattning av diskusionerna om arkitekturen medprojektgruppens medlemmar presenteras också här.

B.5.1 Jämförelse mellan arkitektur och WordPress-hemsidan

Det här avsnittet behandlar resultatet från undersökningen av hur den webbplats somimplementerades med hjälp av WordPress stämmer överens med den dokumenteradearkitekturen. På grund av WordPress fokus på vilken fil som gör vad så redovisas resultateti tabell 2.

48


Fil Resultat

index.php Filen utgör startsidan för webbplatsen vilket också stämmer medbeskrivningen i arkitekturen.

header.php Filen innehåller metainformation om webbplatsen samt omslags-bild och navigationsfält vilket också stämmer med arkitekturen.

footer.php Filen innehåller webbplatsens sidfot vilket stämmer medarkitekturen.

page.php Används för alla undersidor på webbplatsen utom för startsidanoch e-handelssidan vilket stämmer med arkitekturen.

functions.php Innehåller funktioner som används av temat vilket stämmer medarkitekturen. Det finns avancerad funktionallitet som inte riktigtär inom omfattningen av ett tema.

sheet.php Filnamnet är inte specifikt noterad i arkitekturdokumentet. Denhär filen utgör sidan för e-handelssystemet. Den använder ocksåWordPress för att lägga till del komponenterna sidebar.php ochsearchform.php på sidan

sidebar.php Denna fil innehåller ett tillägg till e-handelssystemet och är intedokumenterad som en specifik fil i arkitekturen. Tillägget läggertill en ruta för att välja filtrering baserat på kategorier, en sökrutaoch kundvagnen till e-handeln.

searchform.php Denna fil innehåller ett tillägg till e-handelssystemet och är intedokumenterad som en specifik fil i arkitekturen. Tillägget skaparden sökruta som sedan placeras i sidebar.php.

style.css Innehåller all CSS som skrivits av projekt gruppen vilket följerarkitekturen.

Tabell 2: Resultat för undersökning av WordPress arkitektur

För att sammanfatta resultatet i tabell 2 så är stora delar av arkitekturen även på en fil-nivåöverstämmande med implementationen. De filer som inte finns dokumenterade i arkitekturenär de filer som skapats för e-handelssystemet. Dessa finns alltså inte dokumenterade på fil-nivå men e-handelssystemet är dokumenterat som en huvudmodul i moduluppdelningen. E-handelssystemet är också skilt från övriga sidor i systemanatomin och är alltså konceptuellt skiltfrån övriga sidor i arkitekturen.

49


B.5.2 Jämförelse mellan arkitektur och Flask-hemsidan

Det här avsnittet behandlar resultatet från undersökningen av hur webbplatsen som implemen-terades med hjälp av Python och ramverket Flask stämmer överens med den dokumenteradearkitekturen. Resultatet kommer presenteras utifrån de tre lager som beskrivs i arkitekturen. Detre lagren i MVVM-arkitekturen är model, viewmodel och view vilket här är översatt till modell,vy och visningsmodell.

Modell: Det här lagret i arkitekturen ansvarar för kommunikationen med databasen, dettamotsvaras av paketet ”model” i implementationen. Den består av traditionella klasser i Pythonsom är länkade till databasen genom biblioteket SQLAlchemy, mer information om SQLAlchemyåterfinns i kapitel 3.17. I implementationen är detta ett paket innehållande två filer. Den enafilen heter store.py och innehåller modeller för e-handelssystemet. Den andra filen är content.pyoch innehåller modeller för att lagra information om vilken information som visas på olika sidor.Dessa filer är inte dokumenterade i arkitekturen men finns representerade som var sin modul imoduluppdelningen.

Vy: Det här lagret i enlighet med arkitekturen är webbplatsens presentationslager. Både iarkitekturen och i koden består det här lagret av två komponenter home och admin. Homeinnehåller den vy som vanliga besökare av webbplatsen ser och admin är den admin-panel somadministratörer av webbplatsen använder. De båda vyerna är implementationen så som arkitek-turen antyder oberoende av varandra. Vyn kan hämta en lista innehållande ”widgets”, som finnsbeskrivna i kapitel 3 i huvudrapporten, via en klass i visningsmodellen. Dock är majoritetenav vyn inte kopplad på det här sättet utan är enbart statisk information. Systemet är alltsåi nuläget inte sammankopplat så som det är i arkitekturen, detta är dock enbart på grund avutvecklingen av webbplatsen inte har kommit så långt.

Visningsmodell: Ska i arkitekturen vara ett lager som binder samman de två andra lagren.Tanken är alltså att det skapar en separation så att koden för presentationslagret inte måsteskrivas om när det görs förändringar till modellen. I implementationen motsvarar detta lager avett paket som heter ”viewmodel”. Värt att notera är att en del av den HTML som visas upp påwebbplatsen genereras av klassen PageVM med hjälp av system för widgets som bland annatbestår av de Jinja-mallar som finns i vyn. Det betyder att visningsmodellen har ett beroende avden HTML-kod i vyn som beskriver widgets.

Sammanfattning av jämförelsen: Vid undersökning av modellens implementation såframgår det att klasserna här enbart består av data och inte har någon egen logik i linjemed vad som förväntas av en modell. Undersökningen av den implementerade visningsmodellenvisar att ingen av klasserna i modellen släpps igenom utan datan bearbetas eller lagras i nyadatastrukturer. Det gör att vyn inte har någon kontroll över datan i modellen utan måste gå viavisningsmodellen för att göra förändringar. Alltså är abstraktionen den som förväntas utifrånarkitekturen. Det som inte helt framgår ur arkitekturen är den kommunikation som går mellanvyn och visningsmodellen vid skapandet av Widgets.

50


B.5.3 Analys av den dokumenterade arkitekturen

Här beskrivs resulatatet från analysen av den dokumenterade arkitekturen. Resultatet äruppdelat efter de fyra olika arkitekturer som identifieras i studien Software Architecture inIndustrial Application samt en del om krav och begränsningar. De fyra arkitekturerna är översattatill deras svenska motsvarighet. [40]

Krav och begränsningar: De begränsingar som tas upp i arkitekturdokumentationen ärfrämst riktade till WordPress-hemsidan. De är att det måste gå att ha på ett webbhotell somkunden har råd med samt att standarden för hur en WordPress-hemsidas arkitektur ser ut måsteföljas. Den sista begränsingen omfattar båda systemen och det är att PayPal måste kunnaanvändas som betalningsmetod. Detta hade inte en direkt påverkan på arkitekturen men vägdesin vid undersökning av olika ramverk och programmeringspråk. [39]

De två systemen är i stort baserade på samma krav men Flask-hemsidan har något färre.Eftersom Flask-hemsidan var menad som en prototyp för ett alternativt system så är detta inteförvånande. Ett krav som tydligt har influerat arkitekturen för Flask-hemsidan är kravet på enmySQL-databas. Vid undersökningen används inte detta utan en SQLite-databas men att bytatill mySQL är enbart ändringar till konfigurationsfilen. Vilket betyder att arkitekturen har stödför att enkelt byta mellan dessa olika för att kunna använda en mySQL-databas vid leverans avprodukten. Det krav som haft tydligast inverkan på WordPress-hemsidan är kravet som ocksåfinns med i begränsningarna, nämligen kravet på ett webbhotell som kunden har råd med. Dettakrav var en stor faktor i valet av WordPress som teknologi och där med den arkitektur som ingårvid arbete med en WordPress-hemsida.

Konceptuell arkitektur: Som nämns i Software Architecture in Industrial Application är detvanligt att den konceptuella arkitekturen implicerad från dokumentation och inte en explicit delav arkitekturdokumentet. Så är även fallet för dessa system och därför undersöktes ett flertalstrukturer. Gemensamt för båda arkitekturerna är att det har samma systemanatomi eftersomvalet av ramverk och körmiljö är bort abstraherat. Systemanatomin hör alltså till den del avarkitekturen som kan ses som den konceptuella arkitekturen. Till den här delen hör också be-skrivningen av användingsfallen som finns för systemet.[40]

För Flask-hemsidan finns det också en beskrivning av MVVM-arkitekturen som är det arki-tekturmönserter som används för det systemet. Arkitekturmönstret har ingen knytning till ettspecifikt språk eller ramverk och bör därför anses som en del av den konceptuella arkitekturen.[40]

Modul-arkitektur: För både WordPress- och Flask-hemsidan så finns det en uppdelning imoduler. Vid undersökning av de uppdelade modulerna så går att konstatera att alla dessa inteföljer den definition av moduler som finns i Software Architecture in Industrial Application. En delav modulerna är snarare arbetsuppgifters som ska genomföras snarare än moduler till systemen,detta gäller alltså för båda arkitekturerna.[40]

Exekverings-arkitektur: Ingen av de två arkitekturerna innehåller en del som går attbeskriva som en exekveringens-arkitekturen.

51


Kod-arkitektur: För WordPress-hemsidan finns beskrivningar av ett flertal filer som byggergrunden för ett tema i WordPress. Det är specificerat vad som ska finnas i de filerna vilket i sigär baserat på den standard och krav som finns för WordPress teman.

I arkitekturen för Flask-hemsidan är beskrivningen på en något högre nivå. Där beskrivs hurkoden delas upp i olika mappar. I implementationen är dessa mappar även Python-paket, sommotsvarar de två lagren, modell och visningsmodell, i MVVM-arkitekturen. Det finns också be-skrivet hur vyn är uppdelad i de två delarna home och admin som är beskrivna i arkitekturen ochär implementerade som ”blueprints”. ”Blueprints” är ett sätt att dela upp en Flask-applikationi flera mindre applikationer.

B.5.4 Sammanställning av diskussioner om arkitekturens användning

Det har utifrån diskussioner med den grupp som efter uppdelningen arbetade på WordPress-hemsidan framgått att arkitekturdokumentationen inte använts under utvecklingen mer än demoduler som använts för att fördela arbetet. Gruppens förklaring till arkitekturdokumentet inteanvändes var att den helt enkelt glömdes bort. Det påpekades i diskussionerna att WordPresshar ett begränsat antal sätt att konstruera ett tema och det kan vara en anledning till attarkitekturen och implementationen följer varandra så mycket som de ändå gör. Det påpekadesockså att funktionaliteten i functions.php är något mer komplex än vad som normalt ingår i etttema och borde brytas ut till ett separat plug-in.

Gruppmedlemmarna har från arkitekturen framför allt använt sig av den moduluppdelningsom även gjordes för Flask-hemsidan. Modulerna fanns i verktyget Trello som användes underutveckling. Det gjorde att modulerna kunde användas utan att kolla i arkitekturdokumentatio-nen som de flesta i gruppen berättade att de inte har använts sig av. De som arbetade medvyn sa att det berodde på mapp-strukturen. Eftersom projektet redan var uppbyggt från ar-kitekturen vilket gjorde att den inte kändes som det fanns ett behov av att kolla på arkitekturen.

B.6 Diskussion

Dokumentationens roll i det här är att se till att alla arbetar på samma system och har engemensam bild av det som byggs. Dock kan behovet av vad som dokumenteras variera beroendepå den teknologi som ett projekt användes sig av. Behovet av en tydlig arkitektur är också någotsom blir tydligare för stora system och system som utvecklats och underhållits under en långtid. Detta gör att denna undersökning optimalt skulle ha gjorts för två system som med högrekomplexitet och som utvecklats betydligt längre.

B.6.1 Resultat

Implementationen av Flask-hemsidan följer arkitekturen väldigt väl. Det kan bero på att jag somarkitekt har tagit fram arkitekturen och skrivit stora delar av koden på serversidan. Speciellt ärdet sant för koden som är i visningsmodellen och modellen i projektet. Eftersom min mentalamodell och arkitekturen sannolik är den samma så kan det ha haft som resultat att kodenstämmer bättre med arkitekturen än vad den annars hade gjort.

52


Att arkitekturen för WordPress inte innehöll alla de filer som använts i projektet berodde delvispå min överflyttning till Flask-projektet. Det ledde till att min inblick i WordPress-projektetblev väldigt låg och att de filerna inte upptäcktes för än mot slutet av projektet. De filer somsaknades i arkitekturen var: sheet.php, sidebar.php och searchform.php. Det var sedan tidigaresannolikt att dessa filer skulle skapas, det gick nämligen från arkitekturen att se nödvändighetav dessa. Speciellt syntes detta i hur moduluppdelningen tydligt skiljer e-handelssidan frånövriga undersidor för webbplatsen och att det har sin egen del i systemanatomin. Intressant ärockså att temat innehåller funktionalitet som snarare ligger på ett plug-in. Detta kan bero påprojektgruppens ovana av WordPress eller att funktionaliteten vuxit fram över tid och att brytaut funktionaliteten till ett eget plug-in inte har prioriterats.

Att få av kraven har haft en inverkan på hur arkitekturen har utformats kan bero på attdet är en funktionellt ganska enkel applikation. Det kan också bero på att jag inte har någontidigare erfarenhet av rollen som arkitekt. Därmed kan jag ha missat detaljer som hade kunnatleda till andra arkitektoniska beslut eller inte känt till en specifik arkitektur som hade varitbättre. De arkitekturer som övervägdes är också generella arkitekturer som är vanliga vid web-butveckling och alltså vad som för mig vart ett naturligt val för webbplatserna.

Det finns ett flertal parametrar som kan ha påverkat resultatet över jämförelsen mellan im-plementation och arkitekturdokumentation för båda systemen. En av dessa är att arkitekturernasaknade en exekveringsarkitektur, vilket gör att det inte går att jämföra på den nivån. Dettaberodde på att de verktyg som använts har abstraherat mycket av hanteringen av trådar ochprocesser vilket har gjort att det inte har tagits in i utvecklingen av arkitekturen. En annan saksom togs upp under huvudrubriken är komplexiteten och tiden som utvecklingen pågått. Bådadessa system har en förhållandevis låg komplexitet. För WordPress-sidan finns många färdigakomponenter att använda för de mer avancerade delarn och Flask-hemsidan är en prototyp därkomplexa delar som exempelvis transaktioner av pengar inte ännu är implementerat. Utveck-lingen har också pågått under mindre än ett halvår vilket betyder att arkitekturen inte haft tidatt börja falla sönder och bli en ”big ball of mud”, något som Simon Brown säger händer medett system som växer utan kontroll. Detta är alltså en arkitektur där allt är så sammankopplatatt det inte går att bryta ut delar ur systemet utan att ta sönder något.[37]

Något som skulle kunnat påverka resultatet är att arkitekturen för WordPress-projektet togsfram innan arkitekturen för Flask-projektet. Jag skulle argumentera för att så inte är fallet dåde två teknologierna är väldigt olika varandra. Det var alltså få lärdomar från WordPress somkunde appliceras när arkitekturen för Flask skulle tas fram. Arkitekturen för Flask-projektetanser jag inte har någon tydlig koppling till den som användes för WordPress. Vilket styrker minsyn att ordningen i vilken arkitekturerna har tagits fram har inte har påverkat arkitekturerna.

Som kontext till resultatet sammanfattas nedan också hur de olika arkitekturerna har vari-erat över tid. Arkitekturen för WordPress gick igenom ett fåtal små variationer medans den förFlask gick igenom ett par mindre och två stora förändringar. För WordPress gjordes förändring-arna utifrån det att jag fick mer kunskap om hur WordPress fungerade. För Flask gjordes denförsta större förändringen för att bättre passa med gruppens syn på hur data borde flöda genomsystemet. Den andra stora förändringen var ett förtydligande i hur vyn skulle delas upp i mindrekomponenter men fortfarande använda gemensamma visningsmodeller. Skillnaden i frihet mellande två teknologierna tror jag är den huvudsakliga anledningen till att Flask gick igenom flerstora förändringar. WordPress har en tydligt dokumenterad standard och vissa av dem drivsäven igenom av ramverkets krav på specifika filer för att fungera. Delvis beror det också på att

53


i Flask så behövs det skrivas en hel del serverlogik som redan hanteras av WordPress.

B.6.2 Metod

Ingen standardiserad metod för jämförelse av implementation och arkitektur kunde hittas. Därmed gjordes jämförelsen utgående från arkitekturen och undersökte om de delar som togs upp iarkitekturen kunde återfinnas i koden. En alternativ metod hade kunnat vara att först undersökakoden och utifrån den skapa en arkitektur och sedan genomföra denna med den dokumenteradearkitekturen. Anledningen till att denna metod inte valdes är att jag tagit fram arkitekturen ochskrivit stora delar av implementationen. Därför skulle detta inte gett något annat resultat. Dockskulle den alternativa metoden rekommenderas för analys av ett system och arkitektur som ärkonstruerat av någon annan.

Analysen av arkitekturen gjordes utgående ifrån den uppdelning som beskrivs i studien ”SoftwareArchitecture in Industrial Applications”. Detta gav en tydlig uppdelning av olika delar av arkitek-turen och gjorde det där med lättare att se skillnader på olika nivåer för de två arkitekturerna.[40]

Båda arkitekturerna har varierat över tid vilket inte tas hänsyn till i den använda metoden. Dådet från den informationen går att undersöka arkitekturens stabilitet så är det information somgår förlorad i den här undersökningen. Anledningen till att detta inte undersöktes är att detunder ett projekt som är så kort som det här var är svårt att se tydliga trender för stabiliteten.Under rubrik B.6.1 finns en sammanfattning av hur arkitekturerna har varierat som kontext tillresultatet.

B.7 Slutsatser

Syftet var att undersöka arkitekturens roll i projektet och hur den förändras vid användningav de två olika ramverken Flask och WordPress. Detta uppfylls genom undersökning av hur välarkitekturdokumentationen och koden stämmer överens. Tillsammans med diskussionerna medprojektgruppen kan detta användas för att förstå hur arkitekturen har använts i de två olikaprojekten, i WordPress och Flask. Genom att analysera dokumentationen framgår också vadarkitekturen beskriver och hur detta skiljer sig mellan de två projekten. Nedan besvaras ocksåde frågeställningar som undersökts för att uppfyllas syftet med undersökningen.

B.7.1 Hur ändras den dokumenterade arkitekturens roll beroende på omWordPress eller Flask används?

Uppenbart är att arkitekturen för WordPress-hemsidan har fokus på specifika filer till skillnadfrån Flask-hemsidan som har mer fokus på mapp/paket nivå med ett få tal namngivna filer.Detta beror sannolikt på att med ett verktyg som WordPress så är stora delar av systemet påplats och det blir då naturligt att fokusera in på detaljerna eftersom det är de som ska utvecklas.

Utifrån jämförelsen av kod-arkitekturen går det också att se en stor skillnad. I WordPress-arkitekturen beskrivs något som inte bara är sant för projektet utan för varje tema som byggs iWordPress. Medans i Flask-arkitekturen beskrivs ett system som är specifikt för det här projek-tet. Vissa delar som exempelvis att paketet för modellen kallas ”model” är förvisso något som

54


borde göras vid användning av en MVVM-arkitektur men det är inte givet. Uppdelningen avvyn är också specifika designbeslut för projektet.

B.7.2 Hur väl följer implementationen den dokumenterade arkitekturen?

Det går att se hur arkitekturen och implementationen för båda delprojekten tydligt följervarandra. Som framgick ur diskussionen med WordPress gruppen så var inte det på grund avarkitekturdokumentationen utan snarare på dem ramar som WordPress sätter på ett tema.Det som mest skiljer implementationen från arkitekturen är komplexiteten i functions.php sompåpekades i både min analys och i diskussionen med gruppen som ansvarade för utvecklingen.Anledningen är att den bryter mot den fundamentala uppdelningen som görs i WordPress mellanteman och plug-ins. Vilket är värre än de filer som inte finns i arkitekturen då dessa existerar iform av en egen del av systemanatomin och som en egen stor modul i moduluppdelningen. FörFlask-hemsidan så följs arkitekturen på grund av att det tidigt i implementationen togs framen tydlig uppdelning i mappar som följer arkitekturen. Detta sätt att få implementationen attfölja arkitekturen benämner Simon Browns i sitt tal, som han fick från ”Just enough softwarearchitecture” av George Fairbanks, ”architecturally-evident coding style”. Vilket är idéen attdelar av koden ska namnges på ett sådant sätt att det är uppenbart hur de hänger ihop medarkitekturen.[37] Det här skulle kunna leda till att även om arkitekturdokumentet i sig intehar använts särskilt mycket så har strukturen som byggts upp ifrån arkitekturen lett till attden ändå följts. Något som också togs upp i diskussionerna med övriga projektmedlemmar iFlask-projektet.

B.7.3 Vad finns att göra?

Något värt att notera var att få faktiskt kollade på arkitekturen. Som nämns i diskussionensyns ofta problemen med att utvecklare inte har kolla på arkitekturen först efter längre utveck-lingstid och är tydligare för komplexa system. Det är därför svårt att bedöma hur stor inverkandenna brist på koll skulle ha haft i längden för det framtagna systemet. Att arkitekturen inteanvändes särskilt mycket under utvecklingen kan också bero på en bristande kommunikationav arkitekturen. En fråga som kan ställas från det här är om studerande vid civilingenjörs-programmen i datateknik och mjukvaruteknik borde lära sig mer om mjukvaruarkitektur. Vaddet är, vikten av att använda det för stora system och hur man kommunicera det på ett bra sätt?

Hade en större undersökning kunnat göras hade det varit intressant att studera vad som händerifall två grupper får utveckla samma system, där ena gruppen använder en ”architecturally-evident coding style” och den andra inte gör det. Alltså att namngivningen i koden stämmeröverens med motsvarande delar i arkitekturen. Leder detta till ett system som är mer lättunderhållet och en utvecklingsgrupp med en bättre bild av systemet de bygger?

55

C HUR OLIKA ARBETSFLÖDEN PÅVERKAR ETT PROJEKT

C Hur olika arbetsflöden påverkar ett projekt

En utredning skriven av János R. Dani, konfigurationsansvarig i grupp 1.

C.1 Inledning

Versionshantering sker dagligen inom industrin i olika storlekar och modeller. Under åren hardet tillkommit olika modeller och arbetsflöden för hur versionshantering ska göras och med dessaolika verktyg. Det relativt nya verktyget Git är ett flexibelt verktyg som används i både storaoch små projektgrupper. Det används med olika arbetsflöden som oftast väljs beroende på antalgruppmedlemmar, storleken på koden eller strukturen av projektet. Då kommer frågan vilken ärden bästa och hur ska det användas på det mest effektiva sett.

C.1.1 Syfte

Syftet med denna utredning är för att se hur olika arbetsflöden ser ut för olika delar av ettprojekt. Den ska även ge svar på vilka arbetsflöden som gruppmedlemmarna upplevde var mesteffektiva och användbara. Slutsatsen ska ge en uppfattning om vad som var bra och dåligt medde olika arbetsflöden och ge förslag till förändringar som kan göras för framtida bruk.

C.1.2 Frågeställning

De frågor utredningen avser att besvara är följande:

1. Vilket arbetsflöde upplevde teamet som mest effektiv?

2. Vilket arbetsflöde upplevde teamet vara enklast att använda?

3. Hur användbart upplevede teamet att verktygen för arbetsflödena var?

4. Vilka skillnader fanns det mellan de olika arbetsflöderna?

C.2 Bakgrund

När kandidatprojektet gick av stapeln våren 2017 delades vi in slumpmässiga grupper på åttapersoner där majoriteten inte kände varandra sedan tidigare. Detta ledde till att vi i min gruppville strukturera så mycket som möjligt med gruppkontrakt, bra dokumentation, kick-off, medmera. Däremot var det hel del oklarheter gällande versionshantering och hur vi skulle gå tillväga med det. Hela gruppen tyckte att vi skulle använda Git och GitLab med den motiveringenatt alla i gruppen hade någon erfarenhet av Git tidigare och alla ägde ett GitLab konto somstudenter vi Linköpings universitet. De delar vi var överens om var att Git skulle användas tillkod och där vi skillde oss var om det skulle användas till dokument och vilket arbetsflöde vi villearbeta efter.

56


C.3 Teori

Teorin för Git och GitLab kan läsas under kapitel 3 i huvudrapporten medans arbetsflödernaCentralized workflow och Feature branch workflow förklaras djupare här nedan.

C.3.1 Centralized workflow

Centralized workflow är ett arbetsflöde som bygger på att flera utvecklare jobbar emot ettcentraliserat repository, kod lagring, där koden lagras. Vid centralized workflow används endasten gren på det centeraliserade repository som utvecklarna jobbar emot och gör ändringar till. Vidvissa tillfällen kan det även finnas en till gren som används för stabila versioner eller leveranser.Då alla jobbar mot samma gren måste utvecklarna hämta uppdaterad information kontinuerligtom inte annat vid uppladdning av förändringar för att ha möjlighet att ladda upp arbetet.[42]

C.3.2 Feature branch workflow

Feature branch workflow är ett arbetsflöde som är liknar centralized workflow med den skillnadenatt här används flera grenar som grenas ut ifrån utvecklingsgrenen, kan även vara leveransgrenen.Varje gren utifrån de en eller två grenar som finns i centralized workflow används för en feature,funktion, denna funktion utvecklas då tills den är färdig och därefter slår man ihop den med dengren man bröt ut ifrån. Vid detta stadie då de ska slås ihop sker oftast granskning och testningav någon annan i teamet eller en utomstående som inte har skrivit koden för att få sin kod ochgren godkänd för att slås ihop med utvecklar-/leveransgrenen.[43]

C.4 Metod

Det kommer att användas tre olika metoder för att samla information och skapa referenser tilldetta projekt.

Enkät: En enkät kommer att skickas ut till samtliga medlemmar i gruppen där frågor somexempelvis “Har du arbetat med versionshantering innan?” och “Hur upplevde du arbetsflödet?”används för att få en överblick över hur medlemmarna upplevde arbetsgången samt för att seförbättringsförslag.

Personliga erfarenheter: Personliga erfarenheter kommer att användas då vissa delar endasthar upplevts eller upptäckts av konfigurationsansvarige. Det kommer även att användas för attfå en bättre syn på förbättringar samt visa vilka erfarenheter som har fångats.

GitLab utdrag och etablerade arbetsflöden: Sista delen kommmer att användas för attfå en syn på hur vissa arbetsflöden enligt teorin fungerar men som i praktiken kanske behöverändras då det inte passade med projektet. Denna del kommer även att användas för refereneseroch för att tydliggöra begrepp och projektets struktur. Etablerade arbetsflöden refereras till Gitsegna hemsida [42] och Atlassians [43] för att visa hur teorin fungerar.

57


C.5 Resultat

Under rubriken resultat redovisas all insamlad data för denna undersökning. Datan består av enförklaring och utdrag ifrån arbetsflöderna från GitLab samt en enkätundersökning som övrigamedlemmar i gruppen har besvarat.

C.5.1 Arbetsflöden under projektet

Under projektet användes ett flertal olika arbetsflöden för de tre olika delarna i projektet vilkavar dokument, WordPress och Python/Flask. Samtliga av dessa delar låg på GitLab med ettrepository för varje. Under dokumenthanteringen bröts varje dokument ut till en egen gren såatt olika gruppmedlemmar kunde arbeta sammtidigt på två olika dokument utan att skapakonflikter för varandra, vilket visas i figuren 15 där alla pilar in till det röda sträck är varsin grenmed varsit dokument.

Figur 15: Dokument repository utdrag vid en merge

Detta arbetsflöde är en typ av feature branch workflow [43] där varje dokument räknas somen feature. Python projektet startade med ett fåtal olika utgreningar men drogs ihop till enleveransgren och en utvecklingsgren. Utvecklingsgrenen grenades ut för varje ny modul och närmodulen var färdig granskades och testades modulen av en annan gruppmedlem för att bligodkänd och därefter grenas in i utvecklingsgrenen vilket kan ses i figur 16. Den gröna sträckanär en mindre modul som grenas ut och grenas in till den röda utvecklingsgrenen.

Figur 16: Python repository utdrag vid en merge

Detta arbetsflöde har liknelser till feature branch workflow[43] men har även en liknelse tillContinous integration[44] då dessa moduler är betydligt mindre än hela funktioner. WordPressanvände sig av endast två grenar en utvecklingsgren och en leveransgren där utvecklingsgrenen

58


användes för utveckling av samtliga WordPress medlemmar. WordPress projektet använde sigäven av ett lokalt repository på en server hos webbhotelet One [45] var värd för hemsidan dettaled till att arbetsflödet följde en variant av centralized workflow[42].

C.5.2 Enkätresultat

Medlemmarna fick svara på en enkät med både öppna och slutna frågor angående deras syn påversionshantering av de olika delarna i projektet samt vad det tyckte och kände om de olikaverktygen. Följande frågor användes i enkäten och resultatet representeras under varje frågadär en procentuell andel har räknats fram utifrån svarsalternativen från de sju deltagarna. Devanligaste svaret/svaren för de öppna frågorna visas under respektive fråga som deltagarnasvarade.

Vilken grupp tillhörde du majoriteten av projektet?Wordpress = 42.9%Python flask = 57.1%

Har du använt dig av versionshantering innan?Ja = 100%Nej = 0%

Vad har du använt för versionshantering innan projeket?Git = 100%Svn = 85,7%Molnlagring(ex. Google drive) = 57,1%Lokalt(ex. Byte av filnamn) = 57,1%Övrigt = 14,3%

Har du versionshanterat dokument innan?Nej = 14,3%Ja, men bara lokalt (ex. Byte av filnamn, nya mappar, mm) = 0%Ja, med hjälp av molnlagring (ex. Google drive, Dropbox, mm) = 71,4%Ja, med hjälp av ordbehandlingsprogram (Microsoft Office Word, Overleaf, mm)= 0%Ja med hjälp av versionshanteringsprogram (Git, Svn, mm) = 14,3%Övrigt = 0%

Hur enkelt var det att använda Git som versionshantering till dokument?1, Svårt = 0%2 = 14,3%3 = 14,3%4 = 42,9%5, Enkelt = 28,6%

Hur effektivt tyckte du Git var som verionshantering till dokument?1, Ineffektivt = 0%2 = 0%3 = 42,9%4 = 42,9%

59


5, Effektivt = 14,3%

Var Git/GitLab användbart för att se ditt egna arbetsflöde över dokument?1, Stämmer inte = 14,3%2 = 28,6%3 = 42,9%4 = 14,3%5, Stämmer helt = 0%

Gav Git/GitLab en bra överblick över hela dokument arbetet?1, Stämmer inte = 0%2 = 42,9%3 = 42,9%4 = 14,3%5, Stämmer helt = 0%

Tyckte du git/GitLab var bra/dåligt till dokument? om ja vad var bra och omnej vad var dåligt (Nämn minst två saker)Vanligaste svaren gav att överlag uppskattades Git för att versionshantera dokument då “Detär faktiskt versionshanterat på riktigt”. De negativa kommentarerna var tydligt riktade mot attdet blev väldigt stökigt då varje dokument bröts ut till en separat gren och några föredrog ävenatt ha använt någon typ av molnlagring ex. ShareLatex

Har du några förbättringsförslag eller vad som kunde ha gjorts annorlunda?Medlemmarna föreslog i huvudsak bättre versionshantering men även idéer som mer användningav rebase och en bättre granskningsmetodik.

Har du versionshanterat kod innan?Nej = 0%Ja, men bara lokalt (ex. Byte av filnamn, nya mappar, mm) = 0%Ja, med hjälp av molnlagring (ex. Google drive, Dropbox, mm) = 0%Ja med hjälp av versionshanteringsprogram (Git, Svn, mm) = 100%Övrigt = 0%

Hur enkelt var det att använda Git som versionshantering av kod?1, Svårt = 0%2 = 0%3 = 14,3%4 = 42,9%5, Enkelt = 42,9%

Hur effektivt tyckte du Git var som verionshantering av kod?1, Ineffektivt = 0%2 = 0%3 = 0%4 = 28,6%5, Effektivt = 71,4%

60


Var Git/GitLab användbart för att se ditt egna arbetsflöde över koden?1, Stämmer inte = 0%2 = 14,3%3 = 28,6%4 = 14,3%5, Stämmer helt = 42,9%

Gav Git/GitLab en bra överblick över hela kod arbetet?1, Stämmer inte = 0%2 = 28,6%3 = 0%4 = 28,6%5, Stämmer helt = 42,9%

Tyckte du Git/GitLab var bra/dåligt till kod om ja vad var bra och om nej vad vardåligt? (Nämn minst två saker)Samtliga deltagare tyckte att Git var ett bra sätt att arbeta med kod. Deltagarna tryckte mycketpå effektiviteten att jobba parallellt och att de kunde se arbetsflödet enkelt och bra.

Har du några förbättringsförslag eller vad som kunde ha gjorts annorlunda?Deltagarna var överlag nöjda och de enda förbättringsförslagen som nämndes var att ha enbättre metod för att fånga upp och lösa buggar.

Vad tyckte du generellt var bra/dåligt med Git? (Nämn minst tre saker totalt)Generellt tyckte deltagarna att Git var ett smidigt och enkelt vektyg att använda, de negativapunkterna riktade sig mestadels mot svårigheten att använda Git och även strukturen för ar-betsflöden så som strukturen på WordPress delen

Vad tyckte du generellt var bra/dåligt med GitLab? (Nämn minst tre saker to-talt)De vanligaste kommentarerna var positiva här, där deltagarna kommenterade att GitLab varenkelt och snyggt samt att arbetsflödet blev lättare att följa och kommentera på. Den endanegativa kommentaren var “Det hade varit bättre med ett repository på One-servern så attuppdateringar på sidan sker automatiskt med en push”.

Skulle du rekommendera Git/GitLab för någon annan? (motivera kort)Kommentarerna här var samtliga positivt riktade där samtliga deltagare kunde rekommenderaGit och de flesta kunde även rekommendera GitLab, en deltagare rekommenderade däremot Git-Hub istället för GitLab då “github som har en väldigt stor user-base och som många i industrinanvänder”

C.6 Diskussion

Enligt enkäten var deltagarna generellt positivta till Git och GitLab däremot fanns det en heldel skilda åsikter angående till vad Git ska användas till, det var även många av deltagarnasom kom med förbättringsförslag och synpunkter på vad som skulle behövts förbättras. Detskall också tilläggas här innan vi fortsätter att Git och GitLab endast användes för artefakterdå buggar och kommentarer rapporterades i Trello eller på Slack. Detta ger då att svaren på

61


enkäten endast syftar på användandet av Git och GitLab för se hur flödet av nätverket pågrenarna och projektets struktur såg ut samt ge möjligheten till en backup.Vi börjar med dokumenten där det var störst mixade tankar, det stora problemet som deltagarnaupplevde var i huvudsak att då alla dokument låg på varsin gren blev det väldigt stökigt. Dettaär en punkt jag själv håller med om och har funderat mycket på under projektets gång. Jagkom fram till, efter att diskuterat med flera parter och förslag via enkäten, att det hade varitbättre med att dela upp färre grenar. Varje gren skulle då istället innehålla en grupp med doku-ment eller att det bara fanns en gren med alla dokument. Det positiva med att ha en naturliggruppering av dokument på en gren, om nu en sådan skulle exsisterar, är att det blir ett braarbetsflöde. Vilket ger bra struktur då en grupp enkelt kan jobba på en gren medans en annangrupp jobbar på en annan. Detta hjälper även medlemmarna att enkelt byta mellan dokumentsom har relevans till varandra. Exempelvis gjorde vi detta för testrapport och testplan vilketgjorde att vi enkelt kunde byta mellan dokumenten och fortsätta arbeta effektivt utan att bliavbrutna med att behöva utföra massor med Git kommandon. När man ser på att arbeta medendast en gren skulle detta varit enklare speciellt om det inte funnits någon naturlig grupperingav dokumenten eller att alla dokument hade haft direkt relevans till varandra. Detta skulle ävenmedfört möjligheten till att använda utgrening för granskning, som exempel säg att en medlemgrenar ut för den ska ändra något eller lägga till något. Då medlemmen är färdig begär den avnågon medlem att granska sin text och vid godkänande foga ihop sin gren med huvudgrenen.Vid ett sådant arbetsflöde har du kontinuerlig granskning vilket skulle leda till mindre mentroligen mer effektiva granskningstimmar samt att granskningen sprids ut över projektet.

När det kom till kod delen så var alla överrens om att Git klart var det kraftfullaste verk-tyget att hantera kod med. Då de flesta hade arbetat med Git för kod innan kändes dettaockså som ett lite mer naturligt val än till dokumenten. Dock fanns även här vissa åsiktermen dessa var mer riktade mot hur arbetsflödet var uppbyggt, exempelvis WordPress flödet.WordPress hade stora begränsningar vilket tvingade oss att strukturera arbetetsflödet efter detoch gjorde speciellt mitt arbete väldigt ostrukturerat. Däremot kom ett förbättringsförslag upppå både enkäten av en deltagare och under en diskussion jag hade om att vi skulle ha placeratrepository:t på One istället för GitLab. Detta hade underlättat mycket då till en början hadeuppdateringarna av repository:t visats direkt på utvecklingshemsidan istället för att jag somkonfigurationsansvarig fick uppdatera det lokala repository:t på One hela tiden. Det hade ävenhjälpt med att lösa vissa WordPress relaterade problem som exempelvis databasen som nu varväldigt svår att kontrollera och använda. Detta då den fullständiga databasen endast fanns påOne och om vi hade repository:t på One kunde vi fått en stor möjlighet med att använda en typav kontinuerlig integration då WordPress enkelt kunde delas upp i små moduler.

När jag betraktade resultatet från enkäten, teorin från tidigare kapitel samt granskade hurnätverket för de olika repository:n såg ut, se figur 15 och figur 16 i resultat, såg jag att vi inteföljde något etablerat arbetsflöde. Det var istället en blandning av olika principer och metoder.Detta var då på grund av att ingen av de etablerade arbetsflöderna sågs passande för oss i börjanav projektet. Utöver detta fanns det en faktor till som påverkade hur arbetsflödet struktureradesvilket var att vi inte använde GitLab för att kommentera fel eller logga buggar. Nu i efterhanddäremot, när jag har svar från enkäten och har mina egna erfarenheter anser jag att vi gjordeett bra beslut med att blanda olika arbetsflöden. Detta då ett projekt har sina egna små egen-skaper och svårigheter vilket kan underlättas med hjälp av bra och skräddarsytt arbetsflöde sompassar projektet och dess medlemmar. Däremot hade en fråga till medlemmarna angående omde tyckte att det blev jobbigt med att följa projektet på två olika platser (GitLab och Trello)varit passande. Det generella resultatet blev dock bra men denna faktor kan vara en bidragande

62


faktor till att medlemmarna upplevde Git/GitLab lite förvirande. Då vi alla även var relativtnya inom ämnet hade det möjligen varit klokt att följa ett redan etablerat arbetsflöde men våralärdommar hade då gått miste. För kommande projekt kommer jag att använda mig av GitLabmer då denne kan ge betydligt mer stöd med buggar, kommentarer och liknande och även tänkapå ändringarna som föreslogs i enkäten.

C.7 Slutsatser

1. Vilket arbetsflöde upplevde teamet som mest effektiv?När man ser på resultatet ifrån enkäten ser man tydligt att de flesta av gruppmedlemmarnatyckte att arbetet med koden var det mest effektiva. Speciellt effektivt var medPython/Flask projektet då gruppen fick ett bra arbetsflöde med denna del. Anledningen tillatt många av medlemmarna kände att arbetet med dokumenten var ineffektiv var att detvar stökigt med hanteringen av dokumenten med alla olika grenarna. Då alla dokumentenvar på varsin gren blev effektiviteten väldigt dålig då man behövde hoppa mellan varje gren.Vid kommande projekt rekomenderas därför inte denna lösning utan en mer struktureradgren hantering där varje gren innehåller en grupp dokument eller bara använda en grenmed alla dokument, detta kommer att ge ett mer effektivt arbete.

2. Vilket arbetsflöde upplevde teamet vara enklast att använda?När det kommer till enkelhet var svaren samma som för effektivitet men det var flermedlemmar som upplevde att arbetsflöderna var enklare än de var effektiva. Dettaberor på att arbetsflödet inte var komplext eller komplicerat utan hade en mer enkeluppbyggnad. Detta gäller även dokument då det inte var svårt för medlemmarna att förstågrenhanteringen vilket gjorde att frågor som uppstod berodde inte på arbetsflödet utanmer tekniska frågor om Git och GitLab.

3. Hur användbart upplevede teamet att verktygen för arbetsflödena var?De flesta team-medlemmarna tyckte i det här fallet att verktygen var mer användbart uren grupps syn och inte på sitt egna arbete. Detta beror på att då det blir många commitsskapar det ett väldigt stort nätverk vilket gör det svårt för en enskild medlem att följasitt egna arbetsflöde. Däremot upplevde gruppen att de kunde följa flödet för projektetoch även kunde se hur andra arbetade och med vad. Det var även enkelt för medlemmarnaatt gå tillbaka till äldre versioner och ta bort fel. Detta ger då att Git och GitLab är braverktyg för att se och arbeta med projektet i helhet men lite svårt för att se ens egnautveckling.

4. Vilka skillnader fanns det mellan de olika arbetsflöderna?Slutsatsen ger då att de skillnader som fanns mellan de olika arbetsflöderna var attdokument delen följde nästan en feature branch workflow, WordPress delen följde en mercentralized workflow stil medans Flask följde i slutet en typ av continous integration. Demer specifika skillnaderna var att dokument delen var den mest spridda med flera grenaoch mycket spridning på arbetsbelastningen på varje gren. WordPress och Flask följdeen liknande flöde med den skillnaden att Flask gav möjligheten till mer effektiva ochanvändbara modulgrenar då databasen delades. WordPress struktur var väldigt enkelt mendäremot inte möjlighet till samma modularitet.

63

D HUR SCRUMBAN SKILJER SIG ÅT MELLAN MJUKVARUPROJEKT

D Hur Scrumban skiljer sig åt mellan mjukvaruprojekt

En utredning skriven av Andreas Järvelä, Utvecklingsledare i grupp 1.

D.1 Inledning

När stora grupper arbetar så kan det vara bra att ha en tydlig arbetsmetod. Scrumban användsinom olika sorters utveckling men är väldigt centralt för mjukvarutveckling och härstammar fråntvå andra arbetsmetoder, Scrum och Kanban.

Scrum och Kanban är idag väldigt centrala agila arbetsmetoder som används av många företag.En agil arbetsmetod så som Scrumban med närkontakt med kund, ger en justerbar och flexibelarbetsprocess som tillåter ett kontinuerligt inflytande under projektets gång.

Eftersom Scrumban används på många ställen så skall denna rapport gå in djupare på hurskillnaderna i att arbeta med Scrumban kan se ut för olika projekt och varför det är så. Ärarbetsmetoden tillräcklig? Hur påverkas prestationen utefter arbetsmetod?

D.1.1 Syfte

Syftet är att jämföra hur Scrumbanmodellen skiljer sig åt från olika projekt och ta lärdom avdessa skillnader för att få en ökad förståelse för agilt arbete. Dessa lärdomar kan senare kommaatt användas i framtida projekt.

D.1.2 Frågeställning


1. Har Scrumban följts enligt modellen eller skedde förändringar beroende på projekt?

2. Hur skiljer sig Scrumbanmodellen mellan dem två olika projekten?

3. Har gruppens prestation förändrats utefter arbetsmetod?

D.2 Bakgrund

Under projektets gång så har gruppen fått testa på att arbeta enligt den agila utvecklingsmetodenScrumban. Projektet gruppen blev tilldelad från början förväntades inte uppnå en högarbetsbelastning, därför så kändes det som att Scrumban skulle bli överflödigt. I koppling till attprojektet delades upp i två olika delar så var det intressant att undersöka hur det är att arbetamed Scrumban under två tillfällen och jämföra dessa, speciellt eftersom arbetsbelastningen blevhögre än förväntad.

64


D.3 Teori

Här listas all teori som kan tänkas behövas för att förstå resterande del av rapporten.

D.3.1 Scrum

Som tidigare nämnt i kapitel 3 så är Scrum en agil arbetsmetod. Det finns några ytterligarebeståndsdelar för Scrum som tas upp här.

• SprintEn Sprint är en iteration. Varje sprint har ett antal krav som skall uppfyllas under en visstid, oftast 1-4 veckor. Syftet med Sprintar är att dela upp ett projekt i mindre delar föratt få en mer agil process samt en överblick över vad som gjorts. Sprintar bidrar också tillatt ge gruppen möjligheter att ta med sig erfarenheter från tidigare Sprintar i förhoppningom att kunna utvecklas som grupp. [1]

• Dagligt SprintmöteUnder en Sprint så skall det enligt Scrum-modellen hållas ungefär 15 minuter långa mötenvarje morgon där gruppen diskuterar vad dom gjort sedan sist, vad som skall göra tillsnästa möte och om de har stött på några problem eller ser några problem som kan påverkaarbetet. Syftet är att gruppen skall få en helhetsbild av arbetet och lättare kunna få hjälpom så skulle behövas.[1]

• ProduktbackloggEn produktbacklogg är ett växande dokument som beskriver produkten. Dokumentetinnehåller krav, egenskaper och annan nödvändig information som kan behövas för attbeskriva produkten som helhet. Produktägaren ansvarar över denna genom att se till attden är uppdaterad.[1]

• SprintbackloggIstället för att under en sprint jobba med en hel Produktbacklogg så tar man delar av denoch stoppar in i en Sprintbacklogg. Syftet med detta dokument är att planera vad som skallgöras under nuvarande Sprint genom att innehålla en prioriteringslista av uppgifter.[1]

• StartsprintsmöteVarje Sprint påbörjas med ett Startsprintmöte där målet för Sprinten tas upp samt därplaneringen för kommande arbete sker. Ett par exempel skulle vara moduluppdelning,tidsestimering och vilka olika arbetsmetodiker som kan komma prövas.[1]

• SprintslutsmöteI slutet av varje sprint så hålls det ett Sprintslutsmöte som innehåller återkoppling ochgranskning av hur det gått. Detta för att lära sig av misstag och försöka förbättra kvaliteteninför nästa Sprint.[1]

• ProduktägareEn Produktägare står till ansvar för Produkt- samt Sprintbackloggen och ser till att detsom står där är uppdaterat. Produktägaren har även sista ordet när det kommer till någraändringar av projektet och jobbar väldigt nära Scrummästaren. [1]

• ScrummästareTeori om Scrummästare hittas i kapitel 3.

65


• UtvecklingsteamEtt utvecklingsteam är de personer som utgör hela gruppen som jobbar med projektet. Ettutvecklingsteam brukar bestå av 3-9 personer. [1]

D.3.2 Kanban

Kanban är en agil arbetsmetod där fokus ligger på ett tydligt arbetsflöde. En typisk Kanbanskulle vara att ha en whiteboard med nedskrivna uppgifter uppdelade i olika rubriker så som:Inte Påbörjat, Påbörjat, Testning, Färdigt. Det finns fyra olika principer för Kanban. [7]

• Visualisera ArbeteGenom att skapa en visuell modell av allt arbete som finns att göra, så uppmuntras dettill bättre kommunikation och samarbete. [7]

• Begränsa uppgifter i arbetsprocessenDet är enkelt att begränsa uppgifter och på så sätt minska tiden för uppgifter i systemet.Detta gör man då för att undvika att uppgifter blir utelämnade. Genom begränsning såbehöver man inte heller omprioritera uppgifter.[7]

• Fokus på flödetGenom att använda sig av Kanban kan man skapa ett bättre arbetsflöde eftersom man harfull kontroll på vilka uppgifter som ligger ute för processen. [7]

• Kontinuerlig FörbättringAnvändning av Kanban tillåter laget att mäta deras effektivitet genom att analysera flöde,kvalitet och så vidare. På så sätt kan man förändra utvecklingsprocessen och förbättralagets effektivitet. [7]

D.3.3 Scrumban

Scrumban är en agil arbetsmetod som tillsammans med Kanban och Scrum utgör ett nytt sättatt arbeta på. Det finns skillnader i hur Scrumban kan se ut då i ett visst fall tas mer av Kanban.I det andra fallet så tas mer av Scrum. I detta fall så ser arbetsmetoden liknande ut Scrum baraatt sättet att jobba med arbetsuppgifter istället sker genom en Kanban metod.[6]

D.4 Metod

Denna undersökning kommer att använda sig av några metoder för att hitta relevant information,dessa listas nedan:

1. EnkätSom en bas till undersökningen så kommer enkäter skapas för att ta reda pågruppmedlemmarnas tidigare erfarenheter av Scrumban, om någon finns. Enkäternas syftekommer vara att följa gruppen under tiden av arbetet för att ta reda på hur deras inställningtill agilt arbete förändras och varför. Åsiker om Scrumban kommer hämtas i olika tiderunder projektets gång, både från Wordpress- samt Pythongruppen.

2. Andra efterforskningarFör att stödja påståenden och slutsatser så kommer en tidigare undersökning av Scrumban

66


användas. Rapporten är skriven av Zahoor Ahmad Khan [6]. Detta är för att inte enbartutgå ifrån gruppens erfarenheter inom Scrumban eller för att jämföra modellskillnader.

3. ArbetsmetoderUnder projektets gång så kommer olika metodiker att presenteras för gruppen därparprogrammeringen kommer ligga i fokus. Syftet med att presentera dessa olika teknikerär för att lättare kunna dra slutsatser kring hur arbetsprocessen skiljer sig åt mellan domolika projekten. Frågor som besvaras här är bland annat om det fanns något skillnad i attarbeta med parprogrammering när fokus låg på WordPress till skillnad från Flask.

4. Dagliga StatusrapporterEftersom dagliga möten inte finns som en möjlighet för projektet så kommer enstatusrapport att behöva fyllas i två gånger i veckan för att ge Scrummästaren en möjlighetatt hitta problem i gruppen tidigt, den tappar dock lite syftet bakom dagliga möten omman kollar på Scrummodellen genom att hela gruppen inte får ta del av helheten. I enkätenså besvaras följande frågor:

(a) Hur känner du att det går just nu?

(b) Har du koll på vad du skall göra härnäst?

(c) Om du inte har koll på vad du skall göra, vart tycker du att det är otydligt?

(d) Vad tycker du om kommunikationen?

(e) Disponering av arbete från måndag till idag (timmar)

(f) Har du stött på något problem under ditt arbete?

(g) Vad?

(h) Behöver du hjälp med något?

(i) Övrigt

D.5 Resultat

D.5.1 Första Enkäten utskickad till gruppen

I den här enkäten så besvarades frågor om hur mycket förståelse gruppen hade om agilaarbetsmetoder sedan innan och om vad de tycker om parprogrammering.

1. Har du jobbat enligt någon agil arbetsmetod innan?

(a) Två stycken svarade: Ja

(b) Fem stycken svarade: Nej

2. Vad tycker du om parprogrammering?

(a) Jag vet inte, har aldrig testat men är nyfiken på vad det kan åtstadkomma.

(b) Jag tycker att det är en rolig och motiverande metod att använda sig av när manlabbar.

(c) Vet inte, har inte jobbat med parprogrammering innan

(d) Tror det kan vara bra, enligt dom uppfattningar jag har fått.

67


(e) Kul

(f) Kan vara jobbigt när man är på samma nivå.

(g) Att det skall bli kul att testa

Enkätens svar blev en grund av tankar kring arbetsmetoden och parprogrammering för att sehur det skiljer sig åt i projektet.

D.5.2 Andra Enkäten utskickad till gruppen

Första delen av enkäten handlade om WordPressdelen av projektet:

1. Vad tyckte du om att jobba enligt den agila arbetsmetoden Scrumban? 1-dåligt10-bra

Figur 17: En skala mellan 1-10, 1 betyder dåligt och 10 betyder jättebra.

2. Vad tyckte du om att arbeta enligt metodiken parprogrammering? Fanns detskillnader i arbetsbelastning, motivation, kvalitet och implementationshastig-het?

(a) Helt okej, lite ineffektiv om paren var på lika hög nivå men om båda var påinlärningsstadiet tyckte jag var ett bra koncept, belastningen blev lika med bra kvalitetmen hastigheten var låg

(b) Bra, ger motivation om någon annan är beroende av en själv, mindre arbetsbelastning,koden blir bättre (tror jag). Bra att två är ansvariga och kan förklara samma kod.

(c) Bra motivation, arbetsbelastningen kunde skiljas lite, men definitivt bättre kvalitéoch implementeringen av feature kunde gå söligare då Wordpress är väldigt enkelt påsitt sätt.

(d) Det är väldigt smidigt att ha någon att diskutera att problem med. Dock skulle jagsäga att många gånger fyller personen man par-programmerar lite funktionen av enRubber ducky". Det känns därför som en metod som är ganska inneffektiv i meningenatt prestera bättre kod. Från projektet skulle jag säga att det tydligt ökar motivationen

68


för vissa men i övrigt , minskar implementationshastigheten och kvalitetet är nog påungefär samma nivå. Arbetsbelastningen kändes det inte som att det påverkade

(e) Det kan vara lite frustrerande att sitta och titta på när någon annan programmeraroch man får känslan av att vilja ta över. Motivationen att komma igång och arbetablir större eftersom att man har ett gemensamt ansvar. Kvaliteten på koden kan blibättre eftersom två personer kollar på koden samtidigt. Implementationshastighetenkan jag tycka varierar på svårighetsgrad. I WordPress fallet så skulle jag säga att detgick söligare.

3. Att använda sig av Trello till arbetsfördelning och uppgifter, hur tycker du attdet har gått?

(a) Både bra och dåligt, bra att man hade skrivna uppgifter dåligt då personer inte skrevupp och flyttade på korten.

(b) Bra för att se vad som behöver göras och vad andra arbetar på. Mindre bra till atthålla koll på buggar, tycker jag.

(c) Det har gått bra, men alla är inte helt aktiva i Trello och uppdaterar.

(d) Upplever att jag använde det för kort tid för att kunna säga så mycket om det. Hadeenbart ett kort. Med tanke på att vi tidigt bestämde vilka som skulle göra vad såkänns det som att det inte tillförde något

(e) Det har haft sina bra och dåliga tillfällen. En viktig sak att göra när man jobbar medTrello är att se till att korten man arbetar med har tydliga uppgifter och så modulärasom möjligt.

Nästa del handlade om Flask delen av projektet:

1. Vad tyckte du om att jobba enligt den agila arbetsmetoden Scrumban efter attdu bytt till Flaskgruppen?

Figur 18: 1-Ingen Skillnad Från Wordpress 5-Mycket bättre

2. Vad tyckte du om att arbeta enligt metodiken parprogrammering? Fanns det

69


skillnader i arbetsbelastning, motivation, kvalitet och implementationshastig-het?

(a) Har inte jobbat med det

(b) Bra, ger motivation om någon annan är beroende av en själv, mindre arbetsbelastning,koden blir bättre (tror jag). Bra att två är ansvariga och kan förklara samma kod.

(c) Bra motivation, arbetsbelastningen kunde skiljas lite, men definitivt bättre kvalitéoch implementeringen av större features gick fortare.

(d) Har inte parprogrammerat speciellt mycket i under flask delan.

(e) Inte arbetat speciellt mycket med parprogrammering i Flask, samma tankar som ovan.

3. Att använda sig av Trello till arbetsfördelning och uppgifter, hur tycker du attdet har gått?

(a) Mycket bättre, pga av att modulerna var bättre uppdelade och korten kändes meroberoende och lika i tidsmägnd.

(b) Bra för att se vad som behöver göras och vad andra arbetar på. Mindre bra till atthålla koll på buggar, tycker jag.

(c) Det har gått bra, men alla är inte helt aktiva i Trello och uppdaterar.

(d) Jag skulle säga att speciellt sista veckorna så har det varit smidigt och fungerat bra.Men innan det så kändes det som att inte gav så mycket. Detta skulle kunna beropå att uppdelningen inte var tillräckligt bra eller att det var mer komplexitet ännödvändigt när man är 4 personer i ett team.

(e) Bättre för Flask men inte nödvändigtvis för att projektet var lättare att struktureraupp i moduler utan för att man lärt sig från WordPress delen hur man skall jobba.En stor fördel i att jobba agilt.

D.6 Diskussion

Denna rapport är en undersökning på hur en grupp på åtta personer arbetat med Scrumban iolika projekt. Eftersom gruppen som från början var åtta blev uppdelade i grupper om fyra ochfyra så påverkade det hur Scrumban jobbades med eftersom det är lättare med kommunikationoch överenskommelse i mindre grupper. I teorin kring Scrumban så är en grupp på fyra precisinom ramen för att kunna utgå ifrån en agil arbetsmetod, vilket i sin tur är bra.

D.6.1 Arbetsmetoder

Gruppen fick testa på lite arbetsmetoder genom projektets gång där de flesta tyckte att detfungerade bra. Det svåra med parprogrammering är att hitta två personer som ligger på så passolika nivå att den som granskar känner sig behövd och inte enbart håller med, samtidigt så skallden som kodar känna att den får det stöd som behövs. Arbetsmetoden parprogrammering kanbli fel på två sätt om man tittar på att lära upp en annan. Det ena sättet är när två personermed liknande kompetens parprogrammerar, då kan det bli svårare att utvecklas men samtidigtså kan man föra bra diskussioner. I den andra situationen så har fel person tagit på sig ansvaretatt sitta och koda samtidigt som en person med mindre erfarenhet sitter och granskar. Är det

70


dålig kommunikation i paret så kan det bli så att den som granskar inte hinner med.Även om grupperna inte alltid höll den balans som beskrivs ovan så håller majoriteten av gruppenändå med om att det blev mer effektivt och motiverat att utveckla, eftersom ansvaret inte enbartlåg i ens egna händer. Parprogrammeringen verkade också vara en fördel i början av en Sprintför att komma igång och sätta sig in i projektet men efter drygt en vecka så blev man så insattaatt det kändes överflödigt.

D.6.2 Sprintmöten

Gruppen använde sig till en början inte av några Sprintmöten. Det gjorde att de veckoliga mötensom ägde rum blev en sorts sammankoppling med status, återkoppling och Sprintmöte. Dettaskapade väldigt långa och till slut ineffektiva möten på tre till fyra timmar. Något som kundeha gjorts annorlunda till en annan undersökning är att införa Start- och Slutsprintsmöten redanfrån början med ett tydligt mötesprotokoll. Gruppen delade in sig i två mindre grupper om fyraså Start- och Slutsprintsmöten blev en väldigt vital del av projektet för att separera oberoendepunkter från det gemensamma mötet, som då istället agerade som en statusuppdatering frånbåda projektsidorna för att ge hela gruppen en gemensam syn på vad som pågår, ungefär somett Startsprintsmöte.

D.6.3 Veckolig Statusrapport

Som ersättning av dagliga möten fungerade en veckolig statusrapport väldigt dåligt. För atthålla koll på gruppen och deras problem så var det en bra metod. Eftersom det oftast blev såatt problem kom upp sent på veckan om inte veckan efter, och vissa personer suttit helt fast ochinte kommit någonstans, så infördes denna rapport för att underlätta coachningen av gruppen.Den stora förändringen som skedde här var att Scrummästaren fick gå ifrån implementationoch ta över rollen som coach på heltid. Det var en bra metod men inte alls lika smidig somett 15 minuters möte varje morgon eftersom det tar lite tid att gå igenom varje enkät somScrummästare, men det kan vara värt effektiviteten som fås ut, av gruppen.

D.6.4 Enkätmetod

Att fråga gruppen om eventuella förbättringar eller försämringar i arbetsmetoden fungeradesådär. Resultatet av enkäterna blev väldigt varierande eftersom gruppen från början inte hadestörre koll på hur Scrumban skulle fungera och ifrågasatte därmed inte metoden. Det blev liteatt gruppen bara följde med på den metod som fanns. I en annan undersökning hade detbehövts en workshop eller liknande i början så att gruppen hade fått en chans att sätta sigin i utvecklingsmetoden och därmed ha lite mer koll på vad för- och nackdelarna är med demolika arbetsmetoderna.

D.7 Slutsatser

1. Har Scrumban följts enligt modellen eller skedde förändringar beroende påprojekt?Eftersom metoden ser likadan ut för båda projekten så är slutsatsen att ingen störreförändring skedde mer än att en tydligare uppdelning av front- och backend utvecklare

71


blev till. På grund av erfarenhet och återkoppling från tidigare sprints så blev Flaskprojektet betydligt bättre strukturerat och därmed fick bättre betyg i enkätundersökningen.Förändringarna skedde inte direkt baserat på projekt utan snarare utefter erfarenhet.

2. Hur skiljer sig Scrumbanmodellen mellan de två olika projekten?I resultatet för om Scrumban fungerade bättre så angav majoriteten att det blev en storförändring när dom gick över till Flask och att metoden för Scrumban var bättre. Någramotiveringar som angavs för att stödja slutsatsen om att det finns en skillnad är att detvar bättre struktur på möten och att Trello var mer användbart i Flask delen. Skillnadenberor inte enbart på projekt utan snarare på utförandet av olika projekt.

3. Har gruppens prestation förändrats utefter arbetsmetod?Gruppen visade på en stor prestationsskillnad utefter arbetsmetod då parprogrammeringgav snabbare och mer effektiva resultat. Många sa att parprogrammeringen var överflödigoch att det kändes som att man satt och tittade på men ändå att det var användbart tillen början. Prestationen påverkas markant beroende på hur utförandet av projektet ser ut.

Om projektet hållit en tydlig och välstrukturerad struktur av Scrumban från början hade ingadirekta skillnader skett beroende på Flask eller WordPress. Den betydliga påverkan på metodenär erfarenheten som fås efter varje sprint. Slutsatsen skulle i så fall vara att det inte alls beror påprojekt utan snarare utförandet av den agila metoden och att se till att använda erfarenheternasom en agil arbetsmetod ger upphov till för att förbättra processen. I framtida projekt så ärdet värdefullt att strukturera upp en tydlig arbetsmetod redan från start. Genom att ha tydligaStart- och Slutsprintsmöten så underlättar det för utvecklingsprocessen. En annan sak som börinföras till skillnad från detta projekt är dagliga scrummöten.

72

E HUR EN GRUPPS SYN PÅ TESTNING FÖRÄNDRAS UNDER ETT PROJEKT

E Hur en grupps syn på testning förändras under ettprojekt

En utredning skriven av Tobias Lundberg, testledare i grupp 1.

E.1 Inledning

Den moderna teorin inom mjukvarutveckling lär oss att testning av programvara är ett väsentligtsteg i en utvecklingsprocess [46]. Det får mig dock att börja fundera; delar utvecklare uppfattningmed litteraturen, och används testning på det rigorösa sätt som proponeras av teoretikerna? Minpersonliga uppfattning är att de studenter jag språkar med om programmering inte har någonvidare koll på testning. Snarare så är jag av uppfattningen att tekniker inom testning är någotsom de först får lära sig om i kurser om mjukvaruutvecklingsteori, även i de fall där personeni fråga har sysslat med programmering sedan tidigare. Nu när vi genomför ett större projekt isamband med att vi får lära oss teorin om testning så är det ett utmärkt läge för mig att sättamina uppfattningar på prov.

E.1.1 Syfte

Syftet med denna utredning är att få djupare insikter i hur en grupp civilingenjörsstudenter serpå testning, och om deras syn förändras av att de genomför ett större mjukvaruprojekt där entestplan finns definierad.

E.1.2 Frågeställning

Den här utredningen avser att svara på följande frågor:

1. Hur har projektets genomförande (med avseende på testning) påverkat utvecklarnasattityder gentemot testning?

2. Hur var utvecklarnas förväntningar om testning i jämförelse med verkligheten?

E.2 Bakgrund

När kursen TDDD96 Kandidatprojekt i programvaruutveckling startade, så bildadesgrupper av slumpmässigt utvalda kursdeltagare. Grupp ett, som jag hamnade i, bestod av åt-ta personer där varje person snart fick ett tilldelat ansvarsområde. Mitt ansvarsområde blevtestledare, vilket innebär att jag har huvudansvar för allt som involverar testning. Gruppmed-lemmarna har tidigare läst kurser där de fått lära oss om vad testning är och hur det används iteorin, och för många är det här projektet första gången under utbildningen då de får användatestning i praktiken.

Under projektet så skrev vi en testplan utifrån [47].

73


E.3 Teori

Du behöver inte känna till teorierna bakom mjukvarutestning för att kunna ta del av den härrapporten. Det viktigaste i sammanhanget att känna till är vad det innebär att man ”testar”något. I exempelvis [46] så beskrivs mjukvarutester som aktiviter för att hitta fel i en mjukvara.Då delar av rapporten handlar om olika typer av mjukvarutester, så definieras dessa här.

• enhetstester testar en mjukvaras enskilda komponenter och mindre delar, exempelvisfunktioner och metoder [46].

• integrationstester testar att sammanslagningen mellan de enskilda komponenterafungerar [46].

• systemtester är ett samlingsord för tester som berör huruvida mjukvaran uppfyllerkundens krav [46].

• acceptanstester testar om kunden är nöjd med produkten [46].

• regressionstester testar om nya fel har introducerats i samband med att andra fel harrättats till [46].

• säkerhetstester testar om systemet når upp till säkerhetskraven [46].

Enkätundersökningar finns beskrivna i bland annat [48]. Det som är viktigt att veta isammanhanget är skillnaden mellan öppna och slutna frågor. Slutna frågor avser de typer avfrågor där respondenterna (de som svarar på enkäten) får välja ett eller flera alternativ. Öppnafrågor avser de typer av frågor där respondenterna får uttrycka sitt svar i egna ord. En viktigskillnad mellan öppna och slutna frågor är att man måste göra tolkningar av svaren när utvärderaroch analyserar svaren på öppna frågor.

E.4 Metod

Den här utredningen ska först och främst genomföras med hjälp av två enkätundersökningar. Enenkät ska skickas ut i ett tidigt stadie av projektet, när projektet fortfarande är i planeringsfasen.Den andra enkäten ska skickas ut efter projektets genomförande. Resultaten av de båda enkäter-na undersöks sedan, och förändringar analyseras. Enkätundersökning är en lämplig metodik attanvända för att besvara frågeställningarna, då frågeställningarna handlar om personers åsikteroch uppfattningar [48].

Följande frågor kommer att ställas i före-enkäten:

1. Vilka av följande testtyper har du använt i mjukvaruprojekt du har varit del av tidigare?

2. Berätta mer om dina tidigare erfarenheter av testning i mjukvaruprojekt. Hur noga brukardu testa din kod? Har du haft negativa eller positiva erfarenheter av tidigare testning?

3. När anser du att man borde skriva enhetstester till ens kod?

4. Vilka av följande testtyper tror du kommer bli nödvändiga för att säkerställa kvalitén i dethär projektet?

5. Hur mycket tid (som andel av effektiv utvecklingstid) räknar du med att du kommer läggapå att skriva och genomföra tester i det här projektet?

74


6. Hur tror du att testning i allmänhet kommer att påverka det här projektet (positivt ochnegativt)?

7. Vad tror du kommer orsaka mest problem när det kommer till testning av det här projektet?

Fråga 1, 3, 4, och 5 samlar upp rå data som man kan utföra en statistisk analys på. De övrigafrågorna låter svarsobjekten skriva fritt i en textruta, vilket gör att man kan kategorisera demsom ”öppna frågor”. Enligt Ejlertsson i [49], så kan man analysera svaren till öppna frågor ge-nom att hitta olika gemensamma teman i dem, och sedan använda dessa teman som kategorier.Dessa kategorier kan man sedan utföra statistisk analys på. Denna metod kommer att (ganskainformellt) användas i resultat-kapitlet.

Det finns två syften med före-enkäten: att fånga upp tidigare erfarenheter inom mjukvarutest-ning och att hitta förväntningar inför testning av det här projektet. De tidigare erfarenheternafrågas det om i fråga 1, 2, och 3. De resterande frågorna handlar om förväntningar inför kandi-datprojektet.

Följande frågor kommer att ställas i efter-enkäten:

1. Berätta mer om dina erfarenheter av testning i det här mjukvaruprojekt. Hur noga hardu testat din kod? Har du haft negativa eller positiva erfarenheter av testning i det härprojektet?


3. Vilka av följande testtyper anser du har varit nödvändiga för att säkerställa kvalitén i dethär projektet?

4. Hur mycket tid (som andel av effektiv utvecklingstid) har du lagt på att skriva ochgenomföra tester i det här projektet?

5. Hur anser du att testning i påverkat det här projektet (positivt och negativt)?

6. Vad anser du har orsakat mest problem när det kommer till testning av det här projektet?

Syftet med efter-enkäten är att få reda på hur svarsobjekten har upplevt testningen av kandidat-projektet, vilket samtliga frågor undersöker. Frågorna är snarlika de som ställdes i före-enkäten,men skrivna i ett annat tempus för demonstrera att frågorna nu handlar om det nu utfördaprojektet.

De frågor där svarsobjekten får välja ”testtyper” har följande alternativ: enhetstester, integ-rationstester, systemtester, acceptanstester, regressionstester, och säkerhetstester.

E.5 Resultat

Här presenteras resultatet från de båda enkätundersökningarna.

E.5.1 Före-enkäten

I den här delen presenteras resultatet från före-enkäten.

75


1. Vilka av följande testtyper har du använt i mjukvaruprojekt du har varit delav tidigare?

Som figur 19 visar, så har 5 av 7 gruppmedlemmar i projektet haft tidigare erfarenhet avnästan alla testtyper. Undantagen är Regressionstester, som endast 2 av 7 medlemmar haranvänt tidigare, och säkerhetstester som ingen medlem har använt tidigare.

5Enhetstester5Integrationstester5Systemtester5Acceptanstester

2Regressionstester0Säkerhetstester

0 7

Figur 19: Resultat av fråga ett, i före-enkäten

2. Berätta mer om dina tidigare erfarenheter av testning i mjukvaruprojekt. Hurnoga brukar du testa din kod? Har du haft negativa eller positiva erfarenheterav tidigare testning? Den här frågan fick följande svar:

(a) Brukar testa allteftersom. När en funktion är färdig testar man den enskilt först.Sedan testar jag den med hela systemet. Sedan testar jag hela systemet i den riktigamiljön. Positivt - man vet att saker fungerar, negativt - kan ta lång och onödig tidom det gäller mindre projekt eller små oviktiga delar av större projekt.

(b) Brukar testa koden efter att den skrivs

(c) Har ingen direkt erfarenhet av så pass noggrann testning, har mestadels använt migav trial and error. Är sugen på att testa mer noggrann och organiserad testning.

(d) Jag har använt mig utav många av dessa testmetoder när jag testat en android-applikation. Alla funktioner som kommunicerat med server eller övergripandefunktioner i kodbasen testades på förväntade utdatan. Jag brukar nog inte ha testeri åtanke när jag påbörjat ett projekt men ser ändå hur det kan vara viktigt. Jag harhaft positiva erfarenheter av testning.

(e) Jag brukar testa ganska noga. Jag har haft positiva erfarenheter av testning

(f) Antagligen inte lika noggrant som man bör testa. Men tills det fungerar, typ. Börförmodligen bli bättre på att kommentera mitt testande. Jag har haft positivaerfarenheter av testning i den mån att få fel uppstått i slutet av ett projekt pgaatt man noggrant enhetstestat separata moduler.

(g) Inte jätte erfaren, men har inte upplevt så många problem i tidigare projekt. Testutfördes konstant hos enheter och integrerade enheter, en typ av bottom-up struktur.

Påståenden som ”ingen direkt erfarenhet av så pass noggrann testning”, ”Jag brukar noginte ha tester i åtanke när jag påbörjat ett projekt”, ”Antagligen inte lika noggrant somman bör testa”, ”Inte jätte erfaren” får det att låta som att gruppmedlemmarna uppleveratt de borde testa sin kod mer än vad de har gjort tidigare.

76


Påståenden som ”Jag har använt mig utav många av dessa testmetoder [...]”, ”Jag brukartesta ganska noga.”, och ”Test utfördes konstant hos enheter och integrerade enheter, en typav bottom-up struktur” visar på att vissa av gruppmedlemmarna har förståelse för testningav mjukvara och känner till testerna sedan tidigare, vilket stämmer överrens med resultatetfrån fråga ett. Tre av gruppmedlemmarna påpekar enbart de positiva erfarenheterna medtestning som de har haft tidigare, med påståenden som ”Jag har haft positiva erfarenheterav testning”. En medlem pekar ut både positiva och negativa erfarenehter.


Resultatet till denna fråga visas i figur 20. Samtliga respondenter tycker att man bordeskriva enhetstester, med åsikterna varieras lite om när enhetstester ska skrivas. Detpopuläraste alternativet är att man ska skriva enhetstester efter att koden är skriven,medan det minst populära är att man ska skriva enhetstester före att koden är skriven.

14.3%28.6%

57.1%0%

Innan koden är skrivenUnder tiden som koden skrivsEfter att koden är skrivenAnser inte att man borde skriva enhetstester till koden

Figur 20: Resultat av fråga tre, i före-enkäten

4. Vilka av följande testtyper tror du kommer bli nödvändiga för att säkerställakvalitén i det här projektet?

Resultatet till den här frågan visas i figur 21. Samtliga respondenter trodde attsäkerhetstester skulle vara nödvändiga, men utöver det varierar resultaten lite. Mer änhälften trodde att alla testtyper skulle bli nödvändiga.

5Enhetstester6Integrationstester6Systemtester

5Acceptanstester4Regressionstester

7Säkerhetstester

0 7

Figur 21: Resultat av fråga fyra, i före-enkäten

5. Hur mycket tid (som andel av effektiv utvecklingstid) räknar du med att dukommer lägga på att skriva och genomföra tester i det här projektet?

77


Resultatet till den här frågan visas i figur 22.

28.6%

71.4%

0-15%15-30%

Figur 22: Resultat av fråga fem, i före-enkäten

Varje person i projektet ska lägga ungefär 400 timmar. Fem personer (71.4% av 7 personer)uppskattade att de skulle lägga 15-30% av den tiden på testning, vilket innebär mellan 60och 120 timmar per person. Två personer uppskattade att de skulle lägga 0-15% av tidenpå testning, ville innebär mellan 0 och 60 timmar per person. Sammanlagt uppskattadealltså medlemmarna att de skulle lägga mellan 420 och 720 timmar (av medlemmarnas2800) på testning.

6. Hur tror du att testning i allmänhet kommer att påverka det här projektet(positivt och negativt)?

Den här frågan fick följande svar:

(a) Tror det är viktigt och positivt. Om kunden ska bli nöjd är det en självklarhet att visjälva måste testa produkten på alla sätt tänkbara för att vara säkra på att den hållermåttet.

(b) Det kommer bidra till att färre buggar uppstår ju längre in på projektet vi kommer.

(c) Positivt

(d) Positivt, man undviker en del overhead och man kan lättare hitta vart problemetligger när eventuella buggar uppstår.

(e) Jag tror att det kommer påverka det positivt. Speciellt tror jag att säkerhetstester ärviktiga eftersom vi kommer arbeta med en hemsida som alltså är väldigt öppen förattacker. Eftersom det också är E-handel på sidan är säkerhet mycket viktigt.

(f) positivt. Eftersom kunden vill ha en stabil driftsäker lösning kan det vara bra om alltfungerar som det ska vid överlämning av projektet

(g) Funktionaliteten, komminikation mellan enheter och användbarheten samt säkerhetenpåverkas positivt.

Gruppen är positivt inställd till testning av projektet, och sex av sju medlemmar svararrakt ut att testning kommer att påverka ”positivt”. Den enda personen som inte skrev ordet”positivt” rakt ut svarade att ”Det kommer bidra till att färre buggar uppstår ju längre inpå projektet vi kommer” vilket är ett positivt svar.

7. Vad tror du kommer orsaka mest problem när det kommer till testning av dethär projektet?

78



(a) Oerfarenhet inom gruppen kring vad testerna innebär och hur de skiljer sig.

(b) Att veta vad det är som behöver testas, och hur det ska göras.

(c) Integrations tester

(d) Att det kan ta väldigt mycket tid beroende på vad som ska testas och hur stor kodbasenär.

(e) Buggar i UI tror jag kan komma att leda till en del problem speciellt då det finns såmånga olika browsers att arbeta mot och det är fortfarande inte helt standardiserathur en websida ska tolkas av browsers

(f) kommer inte på ngt :PP

(g) Betalning och inköp.

Tre av gruppens medlemmar pekar ut någon specifik del av projektet som kommer attorsaka problem, men svar som ”Buggar i UI ”, ”Integrations tester”, och ”Betalning ochinköp”. Övriga medlemmar visar på en mer allmän oro, där svar som ”Oerfarenhet inomgruppen”, ”Att veta vad det är som behöver testas” och ”kan ta väldigt mycket tid” tyderpå att en viss osäkerhet finns bland medlemmarna. Denna osäkerhet stämmer inte överrensmed resultatet från fråga ett, vars resultat tyder på att gruppens medlemmar har koll påtester.

E.5.2 Efter-enkäten

I den här delen så presenteras resultaten från efter-enkäten, och svaren jämförs med svaren frånmotsvarande frågor i före-enkäten.

1. Berätta mer om dina erfarenheter av testning i det här mjukvaruprojekt. Hurnoga har du testat din kod? Har du haft negativa eller positiva erfarenheter avtestning i det här projektet?


(a) Jag har framför allt arbetat med att skriva unit-tests. Jag har skrivit tester förmajoriten av koden men har inte varit så nog med att testa att verkligen försökata sönder funktionen. Jag har framför allt haft positiva erfarenheter av testning.

(b) Har inte testat så mycket

(c) Jag har använt mig av verktyget https://validator.w3.org för att testa html-kod förpythonprojektet. Jag har testat min kod lagom noga. Jag har haft positiva erfarenheterav testning.

(d) Jag har testat en hel del olika html och css filer men inget mer utöver det, jag serpositivt på testning och tycker det är positivt för kvaliteten på koden

(e) Jag har inte testat något, har bara granskat så jag kan inte svara på frågan

(f) Jag har testat sidan nästan varje gång jag har ändrat något i HTML-koden. Jag haräven testat ett flertal gånger med PageSpeed Insights. Jag har dock inte dokumenterattester, förutom att dokumentera buggar som kan ha uppstått efter tester.

79


(g) Har testat egen kod under parprogrammering. Varit bra erfarenhet då det är lättareatt prova ju fler.

Två respondenter skriver att de har ”inte testat så mycket” eller ”inte testat något”. Deövriga skriver att de har utfört någon typ av test, där alla utom en använder uttryck som”positivt” eller ”bra erfarenhet” för att besrkiva sina erfarenheter.

I föreenkäten svarade fyra personer att de har haft tidigare positiva erfarenheter, vilket ärsamma antal som i efterenkäten.


Resultatet till den här frågan visas i figur 23. Samtliga respondenter tycker att manborde skriva enhetstester, med åsikterna varieras lite om när enhetstester ska skrivas. Detpopuläraste alternativet är att man ska skriva enhetstester under tiden som koden skrivs,medan de övriga alternativen för när man ska skriva enhetstester är lika populära.

28.6%

42.9%

28.6%

0%

Innan koden är skrivenUnder tiden som koden skrivsEfter att koden är skrivenAnser inte att man borde skriva enhetstester till koden

Figur 23: Resultat av fråga två, i efter-enkäten

I föreenkäten svarade fyra personer att de ansåg att enhetstester borde skrivas ”efter attkoden är skriven”, medan två personer svarade ”efter att koden är skriven” i efterenkäten.

I föreenkäten svarade två personer att de ansåg att enhetstester borde skrivas ”undertiden som koden skrivs”, medan tre personer svarade ”under tiden som koden skrivs” iefterenkäten.

I föreenkäten svarade en person att de ansåg att enhetstester borde skrivas ”innan kodenskrivs”, medan två personer svarade ”innan koden skrivs” i efterenkäten.

3. Vilka av följande testtyper anser du har varit nödvändiga för att säkerställakvalitén i det här projektet?

Resultatet till den här frågan visas i figur 24. Fem av sju anser att säkerhetstester,systemtester, och enhetstester har varit viktiga, vilket gör dem till de mest populäraalternativen.

I föreenkäten hade samtliga testtyper högre siffror än i efterenkäten.

4. Hur mycket tid (som andel av effektiv utvecklingstid) har du lagt på att skrivaoch genomföra tester i det här projektet?

Resultatet till den här frågan visas i figur 25.

80


5Enhetstester3Integrationstester

5Systemtester4Acceptanstester

0Regressionstester5Säkerhetstester

0 7

Figur 24: Resultat av fråga tre, i efter-enkäten

100%0-15%

Figur 25: Resultat av fråga fyra, i efter-enkäten

Varje person i projektet ska lägga ungefär 400 timmar. Alla sju respondenter uppskattadeatt de har lagt 0-15% av tiden på testning, vilket motsvarar 0-60 timmar. Sammanlagtuppskattade alltså medlemmarna att de har laft mellan 0 och 480 timmar (avmedlemmarnas 2800) på testning.

I föreenkäten var motsvarande resultat mellan 420 och 720 timmar.

5. Hur anser du att testning i påverkat det här projektet (positivt och negativt)?


(a) positivt

(b) Inget speciellt

(c) Det har hjälpt oss förbättra vår kod och kvalité.

(d) Positivt

(e) Positivt, all testning är positiv

(f) Positivt, det bidrar till att produkten håller högre kvalitet.

(g) Positivt, alltid bra med testning innan man ska leverera en produkt. Negativt är attdet kan ta lite mycket tid att testa.

Fem personer använder ordet ”positivt”, och skriven en person att testning ”hjälpt ossförbättra vår kod och kvalité”, vilket ska ses som ett positivt svar. Totalt är det alltså sexav sju som anser att testning har påverkat projektet postivit. En person skriver om något

81


”negativt” och en person skriver att testning inte har gjort något ”speciellt” för projektet,vilket ska ses som ett negativt svar. Två av sju anser alltså att testning har påverkatnegativt i någon mening.

Samtliga respondenter svaradde att de trodde att testning skulle påverka projektet positivti föreenkäten, medan fem personer bara pekar ut något positivt i efterenkäten.

6. Vad anser du har orsakat mest problem när det kommer till testning av dethär projektet?


(a) Alla delar är inte helt lätta att tester eller veta hur man ska testa dom

(b) Att det kan bli överflödigt att testa små funktioner som kanske inte egentligen har ensäkerhetsrisk.

(c) Att pythonsidan inte ligger uppe online.

(d) Wordpress kanske ?, kunden

(e) Har inte funnits så mycket att testa

(f) Vet ej.

(g) Inget speciellt. Man kanske borde ha två test personer och prova på personer som intevarit med med och utvecklat produkten.

Den här frågan fick väldigt varierade svar. Svar som ”inte helt lätt [att veta] hur manska testa” , ”Wordpress kanske ?”, ”Vet ej.”, ”Inget speciellt.” tyder på att det finns enviss osäkerhet på vad svårigheterna har varit. De fyra första respondenterna nämner någotspecifikt som de har haft problem med när det kommer till testning.

I föreenkäten var det tre personer som pekade ut något specifik del de trodde skulle bliett problem. I efterenkäten var det fyra person som pekade ut något specifikt de har haftproblem med.

E.6 Diskussion

E.6.1 Metod

Antalet personer var åsikter undersöks i det här rapporten är endast sju personer, vilket inteär speciellt många. Detta gör att man ska vara mycket försiktig med att dra några allmänaslutsater om ingenjörsstudenter i allmänhet. För att vidareutveckla den här rapporten så skulleman kunna skicka ut enkäterna till samtliga studenter som utför ett kandidatprojekt, för att påså sätt få mer tillförlitlig data.

Frågeställningarna den här rapporten riktar in sig på berör hur gruppens åsikter förändrasunder projektets gång. Men om gruppen av någon anledning inte fokuserar så mycket på test-ning, på grund av exempelvis projektets natur eller testledarens inkompetens, så kan resultatetatt bli mycket annorlunda i jämförelse med en grupp som från början lägger stor vikt vidtestning. En intressant uppföljning på den här rapporten hade varit att utföra samma typ avundersökning i flera grupper, för att se hur olika projekt och testplaner påverkar olika grupper.Det kan även nämnas att utvecklarna i det här projektet hade en annan förväntan på projektet

82


när före-enkäten skickades ut. Då handlade våra diskussioner mestadels om Python och Flask,och vi hade höga förhoppningar om att webbplatsen skulle utvecklas med dessa verktyg. Pythonoch Flask kräver lite andra utvecklingsförmågor än vad PHP och WordPress gör, vilket såklartpåverkar vad man tror om testningen.

En annan metod som kunde ha använts för att besvara frågeställningarna är intervjuer medgruppmedlemmarna. Intervjuer är en utforskande metod, där det är lättare att följa upp re-spondentens svar [48]. Om man ska göra en intervjuundersökning så kan det vara lämpligt attintervjua en annan grupps medlemmar, för att undvika att vara partisk.

E.6.2 Resultat

En sak som är mycket anmärkningsvärd är svaren på fråga 3 i efter-enkäten. Fem av sju personeransåg att säkerhetstestning har varit nödvändigt för att säkerställa kvalitén i projektet. I testpla-nen finns det dock inte några säkerhetstester definierade (och inte heller integrationstester). Dettagör att man kan fundera över hur respondenterna egentligen har tolkat ordet ”tester” i frågan.Räknas det som testning att sitta och slumpmässigt leta efter sätt att förstöra webbplatsen, somett par medlemmar vid ett tillfälle gjorde? Eller räknas det bara som testning när man följer enrigorös metod? Vad ett test är borde ha definierats tydligare, för att göra svaren mer tillförlitliga.

I svaren på fråga ett i efter-enkäten nämner fem av sju respondenter att de har utfört nå-gon typ av testning. Det stämmer visserligen att de flesta har gjort någon typ av test någongång, men det är ganska få tester som varje enskild utvecklare har gjort. Detta kan man ävense i svaren till fråga fyra i efterenkäten. Här är det dessutom lämpligt att påpeka att det inteär någon utvecklare som har utfört alla definierade testtyper. Det gör att man kan ifrågasättasvaren till fråga 5, där utvecklar verkar ha en positivt inställning till testning, trots att det ärmycket lite testning som har gjorts.

E.6.3 Resultatet i framtida projekt

Från resultaten framgår det att utvecklarna inte lyckades uppskatta tiden till en önskadnoggranhet, och att de var osäkra på hur testning skulle genomföras. Detta kan bero på enviss oerfarenhet hos utvecklarna. Om man jobbar i ett projekt kan det alltså vara bra att tidigtutbilda oerfarna utvecklare, för att säkerställa att de har koll på vad testning är och hur det skagenomföras. Detta kan bland annat åstadkommas med hjälp av en tydlig testplan som definierarhur testning ska genomföras på olika nivåer i projektet, och vad målen med testningen är.

E.7 Slutsatser

1. Hur har projektets genomförande (med avseende på testning) påverkat ut-vecklarnas attityder gentemot testning? Utvecklarnas åsikter om när man ska skrivaenhetstester har ändrats. I föreenkäten var det populäraste alternativet ”efter att kodenär skrivet”, medan det i efterenkäten var ”under tiden som koden skrivs”. Eftersom attalternativet ”innan koden är skriven” också har ökat i popularitet, kan man dra slutsatsenatt utvecklarna under projektets gång har börjar föredra att skriva enhetstester tidigare, änvad de gjorde innan projektet började. Här kan det vara värt att notera att det i testplaneninte står något om när enhetstester ska skrivas, utan det har varit fritt för utvecklarna att

83


göra som de vill.

2. Hur var utvecklarnas förväntningar om testning i jämförelse med verkligheten?Utvecklarna räknade med att lägga mellan 420 och 720 timmar på testning under projektet,medan de i verkligheten endast la mellan 0 och 480 timmar. Detta är ett tecken på attutvecklarna inte lyckades uppskatta tiden de skulle lägga på testning. Svaren på fråga sju iföre-enkäten tyder på att det fanns en viss osäkerhet på hur testning ska gå till, vilket göratt man kan dra slutsatsen att oerfarenhet är en anledning till varför tidsuppskattningeninte var korrekt. En annan anledning skulle kunna vara att projektet i sig ändrades efteratt före-enkäten skickades ut, vilket självfallet inte reflekteras i tidsuppskattningen.

Alla sju utvecklare svarade i före-enkäten att de trodde att testning skulle påverka projek-tet positivt, medan det i efterenkäten var fem personer som anser att testning har påverkatpositivt och en person som anser att testning påverkade både positivt och negativt. Fråndetta kan man dra slutsaten att utvecklarna tycker att testningens påverkan på projektetinte var lika bra som förväntat. Skillnaden i antal är dock så pass liten att man ska varaförsiktig att dra någon slutsats.

84

F HÅLLBAR WEBBUTVECKLING

F Hållbar webbutveckling

En utredning skriven av Adrian Shosholli, kvalitetssamordnare i grupp 1.

F.1 Inledning

Hållbar utveckling är ett begrepp som blir vanligare och viktigare för varje dag som går. Hållbarutveckling handlar om hur mänskligheten ska kunna använda jordens resurser på ett sätt somskapar ekonomisk hållbarhet utan att påverka miljön, människor och framtida generationer.Världen globaliseras och det blir vanligare att ha en internetuppkoppling. Internet blir barastörre och större och använder samtidigt mer och mer av jordens resurser.

Att arbeta för en hållbar utveckling är mer relevant än någonsin. Ingenjörer har en viktig roll idenna utveckling. Det är de som skapar ny teknologi och driver utvecklingen framåt. Det gällerbara att styra den mot rätt riktning.

F.1.1 Syfte

Syftet med denna utredning är att undersöka hur gruppen har arbetat för en hållbar utvecklingi detta projekt, och vad som hade kunnat förbättras, med fokus på ekologisk hållbarhet. Dennarapport fokuserar främst på gruppens arbetsprocess och den nya WordPress-webbplatsen.

F.1.2 Frågeställning

1. Hur har detta projekt bidragit till en hållbar utveckling?

2. Hur hade detta projekt kunnat genomföras, med hållbar utveckling i åtanke, om det hadegjorts igen?

F.2 Bakgrund

Under projektets gång har jag, som kvalitetssamordnare, försökt se till att produkten hållernågorlunda hög kvalitet. Jag skrev en kvalitetsplan i början av projektet, och har ibland behövtpåminna gruppmedlemmarna om att granska kod och dokument.

När kursens hållbarhetsmoment dök upp tyckte jag att det var ett intresseväckande ämne.Hållbar utveckling och kvalitet hör även delvis ihop eftersom det finns flera kvalitetsaspekterinom mjukvara som är relevanta i båda sammanhangen, som prestanda, användbarhet,återanvändbarhet och effektivitet. Efter hållbarhetsmomentet undersökte jag hållbarhetsaspektersom finns i projektet och vad som skulle kunna förbättras, och beslutade mig därefter för attskriva om det.

F.3 Teori

Denna del tar upp ämnen som är viktiga för att förstå denna utredning, bland annatGREENSOFT-modellen och hållbar webbdesign.

85


F.3.1 Ekologisk hållbarhet

Om vi inte har en jord, vad ska vi göra med våra pengar? All påverkan på naturen är dock intealltid ohållbar. Det finns en skillnad mellan att hugga ner ett träd och att skövla en hel skog.Hur kan vi tillgodose våra behov av naturens resurser samtidigt som vi håller det på en hållbarnivå, utan att drabba framtida generationer? [50]

F.3.2 Grön mjukvara

Utveckling, distribuering, och användning av mjukvara kan ha en påverkan på ekonomin,samhället, människor och miljön. Att mjukvara är grön och hållbar innebär att dess negativapåverkan inom dessa faktorer är så liten som möjligt eller till och med bidrar positivt till enhållbar utveckling. [51]

F.3.3 GREENSOFT-modellen

GREENSOFT-modellen kan användas av mjukvaruutvecklare för att skapa mjukvara som kananvändas på ett hållbart sätt. En del av modellen, ”Life Cycle of Software Products”, behandlarfem faser som handlar om mjukvaruproduktens livscykel från början till slut. I den första fasen,utvecklingsfasen, ska hållbarhetsaspekter som har med utvecklingen av mjukvaran utvärderas.Ekologiska hållbarhetsaspekter i utvecklingsfasen kan bland annat vara elenergi som krävs förutvecklarnas datorer, lokalernas värme, belysning och luftkonditionering. [52]

Distribueringsfasen handlar om hur produktens distrubering kan påverka en hållbarutveckling. Sådant som en bör ta hänsyn till är bland annat hur produkten levereras,transporteras, packas och vilken typ av datamedium (CD, USB) som används. Ommjukvaruprodukten levereras via internet bör en ta hänsyn till dess filstorlek, samt elenergisom krävs för att mjukvarans infrastruktur ska fungera. Disponeringsfasen handlar om vilkenpåverkan produktens avveckling och återvinning har. [52]

Användningsfasen behandlar vilken slags påverkan produkten har under användning,distribuering, och underhåll (till exempel uppdateringar och konfigurering av datorsystem).Mjukvarans energikonsumtion kan minskas med hjälp av energisparlägen, eller genom attkonfigurera systemet för att använda mindre energi. Att lära kunden om hur produkten användskan minska tiden det tar för denne att göra uppgifter, som i sin tur minskar energiförbrukningen.Ny mjukvara kräver ibland extremt kraftfull hårdvara, och på grund av detta kan äldre hårdvarabehöva bytas ut. Att producera den nya hårdvaran och att återvinna den gamla hårdvaran krävermånga resurser och mycket energi. Samtidigt är oftast ny hårdvara effektivare än äldre hårdvara.[52]

Inaktiveringsfasen handlar om vad som händer med produkten när den avvecklas. Nymjukvara som ersätter äldre mjukvara bör till exempel kunna återanvända den gamla mjukvaransinformation. [52]

F.3.4 Hållbar webbdesign

En genomsnittlig webbplats är idag 2,6 MB stor och består till 66 % av bilder [53]. Ju störrewebbplatsen är, desto mer energi krävs av den. Kunder vill oftast ha flashiga bilder och avancerade

86


funktioner, och det ökar webbplatsens storlek. Istället för att ha videoklipp, så kan dessa ersättasmed stillbilder. Det är även bättre att ersätta text mot bilder, så länge samma syften uppnås.Många bilder är sparade i fel filformat, fel storlek, eller är inte optimerade. [54]

Webbplatsens interaktionsdesign kan bidra till att webbplatsen blir stor. En bildkarusell, tillexempel, består av flera stora bilder samt JavaScript som behövs för att animera den, vilket kankräva hundratals kilobyte. ”Front-end”-optimeringar som att reducera mängden JavaScript ochminska nedladdningar hjälper till med snabba upp webbplatsen. [54]

F.4 Metod

Litteraturstudier om hållbar utveckling, GREENSOFT-modellen och grön webbdesign. Dethar även gjorts en undersökning av ekologiska hållbarhetsaspekter inom detta projekt.Undersökningen har delvis utgått ifrån GREENSOFT-modellens faser.

F.5 Resultat

Detta resultat beskriver flera hållbarhetsaspekter som uppkommit inom detta projekt.

F.5.1 Arbetsprocess

Gruppen delades upp i två mindre grupper efter ungefär halva projekttiden. Inom dessagrupper har, enligt min observation, projektmedlemmarna arbetat enskilt under större delenav projekttiden. På grund av detta kunde gruppmedlemmarna arbeta hemifrån.

Under korta perioder har gruppen parprogrammerat. Enligt min observation användes färredatorer när gruppmedlemmarna programmerade i par. Det innebär att mindre elenergi användesnär gruppen parprogrammerade.

Med hjälp av Trello och Slack har gruppen kunnat hålla koll på vad alla gör, utan att behöva frågavarandra. Det har bidragit till att uppgiftsupprepning och missförstånd har kunnat undvikas,som i sin tur kan skapa större tidskrävande problem.

F.5.2 Notförsäljning

Kunden brukade sälja sina noter via post och hantera all betalning själva. Det nya systemettar hand om betalningen och leverans av PDF-filer. Flera delar av kundens arbetsuppgifter harnu automatiserats. Kunden behöver inte längre hantera betalningen själva och sköta produktensleverans via internet.

F.5.3 Optimering av bilder

Med hjälp av verktyget ImageMagick har vissa bilder optimerats, bland annat bilden i sidhuvudet,logotypen, och ett fåtal omslagsbilder. Enligt testverktyget Google PageSpeed Insights kundebilderna på den gamla webbplatsen optimeras för att minska storleken med 98 % (3,7 MB).Detta har genomförts på den nya webbplatsen vars startsida har liknande innehåll som dentidigare startsidan. Alla bilder på den nya startsidan tar sammanlagt upp 98,4 KB.

87


Bilderna på den gamla webbplatsen har inte optimerats och tar upp onödigt stor plats. Denstörsta boven på den tidigare webbplatsen är en inskannad bild av ett omslag som är 2,18 MBstor. En likadan bild, som uppfyller samma syfte på den nya startsidan, är nu 9,6 KB stor. Enminskning har gjorts med 99,6 %.

F.5.4 Övriga optimeringar

Ett WordPress-tillägg, Autoptimize, har använts för att optimera webbplatsens HTML, CSS ochJavaScript-kod. Tillägget tar bort ”white space” (mellanrum, tabbar och radbrytningar) frånfilerna, som i sin tur minskar storleken på filerna.

Webbplatsens HTML-filer komprimeras automatiskt av servern innan de skickas till användare.En av den nya webbplatsens större undersidor är 456,99 kB stor när den skapas av servern. Efteratt den har komprimerats är den 43,09 kB stor. En storleksminskning med 90,6 %.

F.5.5 Stöd för flera plattformar

I och med att webbplatsen använder CSS-ramverket Bootstrap, så är det möjligt att utvecklaför flera webbläsare och plattformar samtidigt. Den nya webbplatsens stilmall och innehåll haranpassats och testats för att stödja flera webbläsare och fungerar på olika skärmstorlekar.

F.5.6 WordPress

I och med att webbplatsen använder WordPress kan det underlätta för kunden att hittainformation och få hjälp om hur webbplatsen kan åtgärdas om det skulle uppstå problem.Gruppen har även tillhandahållit en användarmanual till kunden för att underlätta systemetsadministrering. Det har bidragit till att systemet delvis har framtidssäkrats och kommer kunnaanvändas av kunden i flera år framöver utan att behöva uppdatera eller uppgradera sitt system.

F.5.7 Datalagring

I kundens tidigare system har kunden behövt redigera webbplatsens HTML-kod manuellt för attändra något på webbplatsen. Med den nya tjänsten är det enklare att lägga in och redigera textpå webbplatsen.

Noternas och kompositörernas information finns nu i en databas som skulle kunna återanvändasför framtida system, utan att behöva lägga mycket tid för att återanvända den igen.

F.5.8 Webbplatsens nätverksprestanda

Nätverksprestandan testades genom att använda webbläsaren Google Chromes verktyg förprogrammerare och genomfördes tio gånger på den nya och gamla startsidan, både utan ochmed cachelagring.

I tabell 3 och 4 visas resultatet från undersökningen av webbplatsernas nätverksprestanda.Webbplatsernas storlek som visas är storleken på HTML-filen som komprimerats innan denskickas till användaren.

88


Tidigare webbplats Ny webbplats

Storlek 3,8 MB 176 KB

Laddningstid (Load) 789 ms 535 ms

DOMContentLoaded 103 ms 542 ms

Klar (Finish) 789 ms 568 ms

Tabell 3: Nätverksprestanda utan cachelagring

Tidigare webbplats Ny webbplats

Storlek 5,9 KB 29,5 KB

Laddningstid (Load) 126 ms 464 ms

DOMContentLoaded 103 ms 451 ms

Klar (Finish) 126 ms 478 ms

Tabell 4: Nätverksprestanda med cachelagring

I både tabell 3 och 4 syns att den nya webbplatsen tar längre tid för att visa startsidans innehållutan bilder (DOMContentLoaded) än den tidigare webbplatsen. För att uppnå resultatet i tabell4 behöver användaren gå in på webbplatsen en första gång, för att kunna ladda in bilderna tillsitt egna cacheminne. Tabell 4 visar att den tidigare webbplatsens startsida mer responsiv ochladdar snabbare när bilderna har cachats. Tabell 4 visar att den gamla webbplatsens startsidatar upp 5,9 KB när dess innehåll har cachats, vilket är mindre än den nya startsidan (29,5 KB).Tabell 3 och 4 visar att den nya webbplatsens startsida har längre responstid och tar längre tidatt ladda klart, oavsett om cachelagring används eller inte.

F.6 Diskussion

Jag måste tyvärr erkänna att kundens verksamhet inte har så stor påverkan på miljön, men detbetyder inte att det inte har någon betydelse. Alla bör dra sitt strå till stacken på ett eller annatsätt. Mänskligheten bör sträva efter att arbeta för en hållbar utveckling. I framtiden blir detsäkert vanligare att arbeta för en hållbar utveckling, så det var bra för mig att få se det från densidan.

Uppfräschningen av deras system bidrar till en hållbar utveckling på flera sätt, både ekonomisktoch ekologiskt. Den nya webbplatsen uppfyller samma syfte som den gamla, men är bättre påflera sätt. Kunden behöver bland annat inte underhålla webbplatsen lika mycket som förut,betalningar sker automatiskt, och de har även fått möjligheten att nå en större marknad mednoter i PDF-format. Samtidigt har webbplatsen optimerats för att inte kräva lika mycket resurseroch omarbetats för att kunna användas lättare.

Den nya webbplatsen har längre responstid än den gamla. Google rekommenderar att servernsresponstid är under 200 ms [55]. Den gamla webbplatsen har inget underliggande system somskapar overhead, medan den nya har ett databassystem som servern hämtar information från.Långsamma databasfrågor, ramverk och bibliotek kan göra serverns responstid långsammare [55].

89


Det är en avvägning som får göras. I detta fall handlar det om att ha en snabb webbplats somär krånglig att underhålla jämfört med en webbplats som är lite långsammare, men lättare attunderhålla.

Att bilderna på den gamla webbplatsen inte har optimerats kan bero på att kunden inte harhaft tekniska kunskaper, eller varit omedveten om att det kan vara ett problem. I detta fallanser jag dock att det egentligen inte har varit ett så pass stort problem att kunden behövtgöra något åt det. På webbplatser med ett stort antal besökare kan det dock vara intressant attminska webbplatsens storlek, även om responstiden och laddningstiden redan är minimal. Enstorleksminskning på en bild med ett fåtal bytes på en webbplats med miljontals besökare kanha en märkbar skillnad.

Flera av webbplatsens optimeringar skedde inte på grund av att göra den grönare. Kunden krävdebland annat att webbplatsen skulle ha stöd för flera plattformar och skärmstorlekar, som i sin turbidrar till att äldre hårdvara inte behöver bytas ut. Testverktyget Google PageSpeed Insights,som användes för att testa webbplatsens responstid och storlek, tyckte att webbplatsen var förlångsam och tog stor plats. Eftersom jag tog på mig ansvaret att lösa dessa problem, så gick jagin djupare inom ämnet och bytte även ämne på min individuella del för att kunna skriva om vadjag hittade och gjorde.

Visst hade gruppen kunnat slutföra projektet utan att ens behöva träffa varandra i verkligheten,men hur roligt vore det? Sociala aspekter kan försvinna när gruppen delas upp och arbetarindividuellt. Det känns inte lika viktigt att försöka arbeta effektivt i ett projekt som detta, närden enda motivationen är några högskolepoäng. Det är visserligen bra att tänka på datorernasenergianvändning och pendlingssträckor, men i detta fall anser jag att gruppens drivkraft ochmotivation är viktigare.

F.7 Slutsatser

F.7.1 Hur har detta projekt bidragit till en hållbar utveckling?

Det finns flera ekologiska hållbarhetsaspekter i projektet, även om gruppen inte aktivt tänkt påoch planerat för dem. Webbplatsen kräver nu färre resurser i och med att webbplatsens bilder ochinnehåll har optimerats, samt att webbplatsen fungerar på flera plattformar och skärmstorlekar.Den gamla webbplatsens innehåll finns nu i en databas som kan återanvändas i framtiden.Den nya webbplatsen är enklare att underhålla, betalningssystemet har automatiserats, och harframtidssäkrats i och med att WordPress används.

Vissa delar av arbetsprocessen har bidragit till att projektet använder mindre elenergi(parprogrammering). Slack och Trello har sannolikt bidragit till att undvika att det uppstårstörre energikrävande problem.

F.7.2 Hur hade detta projekt kunnat genomföras, med hållbar utveckling i åtanke,om det hade gjorts igen?

Arbetsprocessen hade kunnat förbättras, till exempel med hjälp av parprogrammering. Enligtmig har gruppen inte parprogrammerat särskilt mycket och skulle kunna ha gjort det oftare.Parprogrammering skulle kunna bidra till att färre arbetsstationer används, som i sin tur

90


minskar energianvändningen. Att ha möten på distans skulle kunna minska resor till universitetet.Gruppen skulle kunna ha upprätt en arbetsmetod som tillåter arbete hemifrån.

Webbplatsen skulle kunna ha optimerats ännu mer och dess storlek hade kunnat minskasytterligare. Främst genom att undvika JavaScript eller att minska mängden skript genom att tabort delar av koden som inte används. Storleken som Bootstrap tar upp skulle kunna reduceraseftersom stora delar av den inte används. Webbplatsen skulle även kunna cachas på servern föratt minska belastningar på servern och för att minska responstiden.

En bit in på projektet bestämde sig kunden för att webbplatsens design skulle ändras. Dettaskapade ett tidskrävande problem som hade kunnat undvikas. Att ha god och regelbundenkommunikation med kunden skulle kunna bidra till att undvika missförstånd och otydligheter.

F.7.3 Slutord

Det hade varit bra att tänka på hållbar utveckling redan från början av projektet. Samtidigt vardet bra att ämnet togs upp, annars hade jag nog inte skrivit om det. Det kanske räcker medatt gruppmedlemmarna är medvetna om vilka förbättringspunkter som finns, och har hållbarutveckling i bakhuvudet under projektets gång. Hållbar utveckling är viktigt att ta upp ocharbeta utifrån, och många kommer säkert stöta på det i sin karriär. Jag vet i alla fall att jagkommer försöka bidra till en hållbar utveckling i framtiden.

91

G DOKUMENTS INVERKAN PÅ PROJEKTET

G Dokuments inverkan på projektet

En utredning skriven av Hans Tchou, dokumentansvarig i grupp 1.

G.1 Inledning

I ett projekt, utan dokument angående dess produkt så spelar det ingen roll hur väl utfördprodukten är. Helheten ligger både i dokumentation och produkt, om inte båda håller en brastandard så bedöms ett projekt som misslyckad. Dokument skrivs oftast alltid innan produktenbörjar sin utveckling och fortsätts under hela projektets gång. Det framgår klart och tydligt attdokument påverkar de kvaliteter produkten åstadkommer, och blir som det blir.

Just det! Koll, planering och hantering är vad det handlar om och de alla finns dokumente-rade i en form av kontrakt, kravspecifikation, projektplan eller designplan m.m.

Syftena med dokument är många. Det ena är att verkligen hålla koll på att alla krav verk-ligen finns med i kravspecifikationen och det andra är att kraven uppfylls genom utförandet. Enstruktur som produkten ska erhålla finns framtagen i ett arkitekturdokument som även är viktigför framtida underhållare av programvaran. Dokumentation är mest för projektgruppens egenskull där samtliga medlemmar kan följa sina framsteg under projektets gång. Denna rapportutreder vilket av Word eller LATEX är att föredra.

G.1.1 Syfte

Det finns två syften med denna rapport. Den ena utredningen går ut på att jämföra olikaordbehandlare, vilket huvudsakligen berör Microsoft Word och LATEX. Den andra utredningengår ut på att utreda hur stor inverkan dokument har på olika projekt samt vilket dokument somansågs viktigast. Resultaten kommer att värderas, och reflekteras för att slutligen övergå till enslutsats.

G.1.2 Frågeställning

Den här utredningen avser att svara på följande frågor:

1. Vad för skillnad gör det att skriva dokument i LATEX i jämförelse med Microsoft Word?

2. Hur stor inverkan ansågs dokument ha på projektarbetet?

G.2 Bakgrund

Denna projektkurs introducerades samtidigt som alla projektgrupper redan hade skapats om åttaslumpmässigt utvalda kursdeltagande i varje grupp. Gruppens samtliga medlemmar tilldeladesalla olika ansvarsroller och eftersom att alla kom bra överens med varandra gick tilldelningen avroller mycket smidigt.

-Jag som inte har någon erfarenhet av stora projekt eller deltagit i ett sådant innan,fick rollen som dokumentansvarig. Som dokumentansvarig innebär det att jag bland

92


annat ansvarar för att dokumentmallar framställs, ser till att dokumenten påbörjasoch utförs innan deadline, samt ansvarar för användar- och installationsmanualen.

Dokumentansvarige bör samarbeta en hel del med gruppens kvalitetssamordnare, så det ärviktigt att kommunikation sker regelbundet mellan dessa två.

När det kommer till val av verktyg att behandla dokument i skulle Microsoft Word säkerli-gen vara det första som slår i tanken bland de flesta. Word är känt då många redan har lärtsig det på gymnasiet i kursen Datorkunskap. I detta fall, ett projekt i mjukvaruutveckling därmajoriteten av projektmedlemmarna redan bekantat sig med andra ordbehandlare såsom LATEX,resulterade med att det blev LATEX.

Under första gruppmötet efter tilldelningen av projekt fördes en diskussion angående val avordbehandlare till projektet. Utan några djupa detaljer eller motiveringar fick alla i projekt-gruppen rösta vilket ordbehandlingsprogram som skulle användas. Utifrån rösterna visade sigatt fem utav gruppmedlemmarna föredrog LATEX, en Word och två hade ingen åsikt. Gruppenbeslutade sig för att dokumenten skulle skrivas i LATEX. Eftersom röstningen genomfördes utanmotivering till varför just LATEX valdes och inte Microsoft Word som alla säkerligen har använttidigare, väcktes en hel del nyfikenhet.

Mycket av tiden används just till att skriva dokument, på så vis väcktes även nyfikenhetenom hur viktigt är det med dokument och hur har de inverkat i projektet? Har det varit värt attlägga ner så mycket tid på att dokumentera och skriva dokument, och vad har det bidragit till?

-Jag finner detta projekt mycket spännande eftersom att detta är första gången förmig att få arbeta med en riktig kund. Jag gör mitt bästa och går in med målsättningom att tillfredsställa både projektgruppen och kunden, och samtidigt hoppas få ettgodkänt kandidatprojekt.

93


G.3 Teori

Dokument och dokumentation är två olika ord som folk ibland missuppfattar. Dokument är etträknebart substantiv och kan vara ett fysiskt papper, eller en rapport som innehåller bevis ellermaterial av något slags ämne nedskrivet. Dokumentation är ett icke-räknebart substantiv ochär insamlingen av information eller material av något ämne som möjligen kan skrivas ner i ettdokument.

Det finns många typer av dokument, och det finns även många olika verktyg att bearbetadokument med. I detta avsnitt kommer bland annat verktygen LATEX och Microsoft Word attundersökas där en jämförelse mellan dessa två kommer att genomföras. Utöver dessa två finnsandra populära ordbehandlingsprogram, såsom Google Docs.

G.3.1 LATEX

LATEX är en dokumentberedande system för textsättning med hög kvalité som släpptes år1985. LATEX kan användas till alla typer av dokument, men används oftast till tekniskaoch vetenskapliga dokument. LATEX uppmuntrar författaren att inte oroa sig för mycket pådokumentets utseende, men fokusera sig mer på att få det rätta innehållet.[9] Idéen med LATEXär att lämna dokumentets design och layout åt dokumentdesignaren och låta författen utformatexten och dess innehåll. Dokument utformas med koder från LATEX standardbibliotek.

ShareLaTeX

ShareLaTeX är en webbaserad LATEX-redigerare som körs genom webben. Till skillnad från andraLATEX-redigerare är ShareLaTeX en server-baserad applikation, alltså krävs en webbläsare föratt komma åt verktyget. Dokument som skrivs genom ShareLaTeX kan kompileras direkt ochpresenteras i PDF-format vid sidan av källkoden. [10]

Overleaf

Mycket lik ShareLaTeX, är Overleaf ett annat alternativ av webbaserad LATEX-redigerare attanvända sig till att skapa och publicera dokument. Dokumentets utseende uppdateras automatiskmed källkoden vid sidan om, som på så vis bidrar till en bekvämlig och användarvänligWYSIWYG-ordbehandlingsprogram. [56]

G.3.2 Microsoft Word

Microsoft Word är ett ordbehandlingsprogram som är väldigt populärt som tillhandahålls avMicrosoft. I Word får man hjälp med att skapa dokument med professionell kvalité där mallarkan framställas direkt med bara ett par musklickar. Ordbehandlaren innehåller redigerings-och revideringsverktyg som gör det enkelt och effektivt. [57] Word är ett WYSIWYG-verktygsom står för What you see is what you get. WYSIWYG innebär att man utformar och skriverdokumentet exakt så som den kommer att se ut. Likt ShareLaTeX finns det även ett webbaseradordbehandlare vid namnet Word Online som tillåter samarbete på samma dokument genomwebbläsaren med molnlagring.

94


G.3.3 Git och GitLab

Git är en öppen versionshanteringsmjukvara för projekt av alla storlek. GitLab är även ettkomplement till Git för att ge användaren möjlighet till att arbeta med Git grafiskt. För en merutförlig beskrivning om Git och GitLab, se 3.3.

G.4 Metod

I detta avsnitt presenteras de metoder som används till att samla information.

G.4.1 Fånga erfarenheter

För att fånga information om hur gruppen arbetat med dokumenten och för att se till attdokumenten skrivs planeras gruppmöten in varje vecka där bland annat statusrapporten tasupp. Utifrån statusrapporten får gruppen en översikt om vilka dokument som har bearbetats,om planerna följs samt om kraven har uppfyllts enligt dokumenten.

För att undersöka och samla information angående frågeställningarna skickas en enkät uttill samtliga kursdeltagande. Frågorna som ställs i enkäten används för att besvara den förstafrågeställingen, som handlar om hur stor inverkan projektdokumenten har inom ett projekt:

• Hur stor påverkan tycker du att dokumenten i helhet har spelat roll i projektet?

• Vilka av dokumenten ansåg du har spelat en större roll?

Frågorna som ställs i enkäten för att utreda vad det gör för skillnad att skriva dokument i LATEXi jämförelse med Word angående den andra frågeställingen är:

• Har du använt dig av LATEX innan projektet?

• Har du använt dig av Word innan projektet?

• Vilket av LATEX eller Word har du använt dig mer av i tidigare projektarbeten?

• Vilken ordbehandlare föredrog du till detta projektet?

• Vad tycker du är för- och nackdelarna med LATEX?

• Vad tycker du är för- och nackdelarna med Word?

• Om ett nytt projekt startas, vilket ordbehandlingsprogram skulle du föredra?

G.4.2 Intern intervju

Intern utredning angående LATEX och Word görs för att skaffa mer information om gruppen.En individuell intervju av varje gruppmedlem genomförs där frågorna handlar om vilketordbehandlingsprogram individen föredrog och varför just det programmet. På samma sätt som ienkätundersökningen ställer intervjun även frågan om hur stor inverkan de ansåg att dokumentenhar haft i projektet, och vilket eller vilka av dokumenten som ansågs har spelat en viktig roll iprojektet.

95


G.4.3 Artikelanalys

För att hitta material och samla ytterligare information samt fördjupa sig mer i ämnetanvänds Google Scholar för att hitta relaterade artiklar samt böcker angående vilken inverkandokument har på ett projektarbete. En artikel, ”Cost, benefits and quality of software developmentdocumentation: A systematic mapping”[58] betraktas och övervägs under analysen.

G.4.4 Git commits

För att ta reda på hur ofta dokument arbetas med inom projektgruppen görs granskningar utifrångrafer angående Git commits att tas fram från ”dokumentgrenarna” med GitLab. Grafernapresenterar antalet Git commits i olika tidpunkter under projektets gång, på så vis utreds näroch hur ofta dokumenten har bearbetats. Detta är tänkt att gälla för de större dokumenten somkandidatrapporten, kravspecifikationen, arkitekturdokumentet, projektplanen, kvalitetsplanensamt testplanen.

G.5 Resultat

I detta avsnitt presenteras de resultat som framställts av undersökningen som utförts.

G.5.1 Användarerfarenheter

Det framkom att samtliga i gruppen hade goda erfarenheter av Microsoft Word och att enstor majoritet av gruppmedlemmarna mer eller mindre redan hade använt LATEX sedan tidigare.Diskussioner i gruppmöten har lett till att LaTeX är det dokumentverktyg som föredras.

G.5.2 Intern intervju

Intervju med gruppmedlemmarna säger att utav åtta medlemmar så föredrog fem LATEX, enWord och två saknade åsikter på frågan angående vilket orbehandlingsverktyg som föredrogsunder projektet. De som hade åsikt konstaterade att LaTeX är ett mer professionellt verktyg,det blir enklare att följa en stilmall och de hade erfarenhet av det i tidigare projekt. Personensom föredrog Word hade en vana att arbeta i Word och har använt Word som ordbehandlare itidigare projekt.

Intervju angående dokuments inverkan visar att gruppens dokument fick sex poäng i en skalamellan ett till tio, där ett respresenterar ingen inverkan alls och tio representerar en mycket storinverkan. Dokument, såsom kravspecifikation, projektplan, arkitekturdokument och testplanhar alla enligt intervjuerna spelat en viktig roll, men kravspecifikationen visade sig vara detviktigaste dokumentet.

G.5.3 Enkätundersökning

I denna sektion presenteras svaren som kom in från enkäten som skickades ut till allakursdeltagare.

96


LATEX vs. Microsoft Word

De svar som figur 26 och figur 27 presenterar erhölls från kursdeltagarna i andra projekt, figur26 och figur 27 har alltså inte besvarats av den här projektgruppens medlemmar. Svar frånsamtliga 32 personer som deltog i enkäten visar att alla någongång har använt sig av Word inågot tidigare projekt, se figur 26. Å andra sidan visar det att 53.1% av de 32 som besvaradeenkäten sagt att de någongång tidigare har använt sig av LATEX i ett projekt, se Figur 27. Det in-nebär att nästan hälften av deltagarna hade erfarenhet inom LATEX innan kursprojektet startades.

100% 0%JaNej

Figur 26: Andel som använt sig av Word innan projektet

53.1%

46.9%

JaNej

Figur 27: Andel som använt sig av LATEX innan projektet

En annan fråga som besvarades i enkäten visar att utav de 44 som deltog hade 63.6% använt sigmer av Word i tidigare projektarbeten, 20.5% LATEX och 15.9% av någon annan ordbehandlare,se Figur 28.

97


63.3%

20.5%15.9%

WordLATEXAnnat

Figur 28: Andel som använt sig mer av LATEX eller Word innan projektet

Till kursprojektet enligt Figur 29 kan man avläsa att 88.6% hade föredragit LATEX, 6.8% Wordoch 4.6% hade föredragit något annat verktyg som visade sig vara Google Docs. Till frågan om ettnytt projekt skulle startas, visar enkätundersökningen att LATEX är det mest sannolika verktygetför att producera dokument eftersom LATEX också fick en ökning i antal. Resultatet visar att90.9% av de 44 personerna som svarat föredrog LATEX. Bland de resterande 9.1% föredrog 6.8%,motsvarande 3 personer Word som verktyg efter att projekterna hade startats, se Figur 30.Antalet kursdeltagare som hade föredragit Word innan projekterna startades hade minskat medtvå i antal och LATEX fick en ökning med ett.

6.8%88.6% 4.6%

WordLATEXAnnat

Figur 29: Val av ordbehandlare som föredrogs till projektet

2.3%90.9%6.8%

WordLATEXAnnat

Figur 30: Val av ordbehandlare som föredras till ett nytt projektet

98


För- och nackdelar med Word och LATEX

Information angående för- och nackdelar med Word och LATEX som samlades från enkäten visaratt både Word och LATEX har sina starka och svaga egenskaper. I denna rapport är 23 utav de44 svaren medtagna, se Figur 31 & Figur 32.

Word

Microsoft Word är inte kostnadsfri, men är en kraftfull ordbehandlare som oftast inte utnyttjastill sin fulla potential. Åsikter från andra säger att det är mycket användarvänligt som gör detmycket enkelt att komma igång och många är redan vana vid att arbeta med det. I Word är alltgrafiskt, man ser ändringar direkt och resultatet blir det man ser, på detta sätt bidrar det tillatt det blir ännu enklare att sätta sig in i andras dokument för att redigera.

Nackdelar med Word som verktyg är att det lider av stark problematik att behålla en en-hetlig struktur. Dessutom är det också knepigt att versionhantera eftersom Git inte förstårdoc/docx-formatet som Word behandlar. För att versionhantera med Git bör man först konver-tera dokumentfilen till en fil som Git kan avläsa. Ytterligare en nackdel med Word är att det ärkrångligare att skriva matematiska uttryck och ekvationer.

LATEX

Enligt enkäten hade många svarat att fördelen med LaTeX är att det är kostnadsfritt. Detär lättare att hålla en standard och medför att designen på dokumenten blir identiska ochser professionella ut. Eftersom det är källkod som skrivs behövs en textredigerare samt ettkompileringsprogram för att avläsa koden. Detta kan orsaka att kompileringsfel uppstår, vilketupplevs jobbigt. LATEX föredras inte när det gäller mindre dokument eftersom det kräver merförberedelser, men fungerar utmärkt när det gäller större dokument. Dessutom är samarbetegenom LATEX mycket uppskattat eftersom man kan versionhantera källkoden med Git.

LATEX anses komplicerat av många, det är svårare att lära sig hur man använder det tillskillnad från vissa andra ordbehandlare. Det är en hög inlärningskurva, men innehåller mångahjälpmedel i paket vilket gör LATEX kraftfullt och kan anpassa sig till alla typer av dokument.Det kan vara mycket svårt att förstå LATEX om man inte har haft tidigare erfarenhet av det, menså fort man lärt sig grunderna så blir det bara lättare att förstå. En anledning till att LATEX ärsvårt att förstå är att det saknar grafisk hantering av till exempel bilder, listor samt tabeller,vilket gör att det upplevs knepigare att implementera dessa i dokument.

99


Figur 31: Svar från enkäten om för- och nackdelar med Word

100


Figur 32: Svar från enkäten om för- och nackdelar med LATEX

101


Dokumentinverkan

Denna sektion omfattar svaren som samlats från enkäten angående dokuments inverkan påprojektet.

44 kursdeltagare hade besvarat frågan angående dokuments inverkan i enkäten. Figur 33 visaratt de dokument som framtagits har i helhet haft en ganska stor inverkan i projektet, med ensnittpoäng på sju mellan skalan ett till tio där ett representerar ingen påverkan och tio en mycketstor inverkan. Utav de 44 kursdeltagarna fanns det två som tyckte att dokumenten endast hadeen liten inverkan eller ingen inverkan alls på projektet.

1 2 3 4 5 6 7 8 9 10

0

5

10

15

Figur 33: Svar från enkäten om hur stor inverkan dokumenten har haft i projektetarbetet

Figur 34 nedan visar 23 av de 44 svaren i enkäten. Resultatet bekräftar att kravspecifikationenvar det dokument som hade spelat en mycket viktig roll i projektet där nästan alla svar inne-höll kravspecifikation. På tur efter kravspecifikationen framkom projektplanen som näst mestomnämnande och framhävdes i cirka hälften av svaren, och näst på plats var arkitekturplanensamt därefter kandidatrapporten.

102


Figur 34: Svar från enkäten om vilka dokument som spelat en stor roll i projektet

G.5.4 Git commits

Det visar sig att gruppen har arbetat med dokument under hela projektets gång. Dokumentenbearbetades kraftigast under början av projektet och slutet enligt Figur 35. Samtliga dokumentskapades samtidigt under första iterationen och byggts på olika mycket under projektets gång.

103


Projektplanen har hela tiden redigerats och uppdaterats till skillnad från kravspecifikationensom knappt behövt redigeras under de andra iterationerna.

Figur 35: Antal Git commits under projektets gång för dokument

104


G.6 Diskussion

Detta avsnitt diskuterar utredningen och dess resultat.

Utifrån egen erfarenhet som inte hade någon erfarenhet av LATEX innan projektet, så tycktejag att LATEX i början var mycket knepigt, men så fort man lärt sig grunderna om hur man ko-dar och hur man kompilerar så går det bara fortare att lära sig och allt blir så mycket mer logiskt.

Anledningen till att alla är bekanta med Microsoft Word beror på att Word har lärts ut igymnasiet, inte bara till tekniska och vetenskapliga studenter, men även för studenter i andrainriktningar. De som känner till LATEX är oftast självlärda och omfattar oftast tekniska ochnaturvetenskapliga studenter.

I Word skriver man ingen kod, utan man arbetar direkt på utseendet, med andra ord WY-SIWYG. Anledningen till att LaTeX är väldigt uppskattad här är just att man utformardokument genom kodning, detta eftersom de flesta projektmedlemmarna består av programme-rare. Om man jämför Word med LATEX så är Word som visuell programmering, också känt somett WYSIWYG-verktyg. I Word kan tabeller eller bilder infogas, medan i LATEX får man skapaen genom att koda utifrån deras standardbibliotek för att implementera sådant. Eftersom det ärgrafisk hantering med Word så är det mycket enkelt att komma igång med och det underlättaräven redigering av dokument.

Eftersom gruppen har haft en stilmall att följa så hade alla de större dokumenten (projektplan,kravspecifikation, kvalitetsplan, testplan och arkitekturdokument) en liknande utformning. Stil-mallen har varit uppskattad och fungerar utmärkt när det handlar om LATEX eftersom det baraär att kopiera från stilmallen och klistra in i ett annat dokument.

Orsaken till att Word inte användes var dels för att det kunde bli knepigare att versionhanteraoch dels för att det blir svårt att anpassa dokument till en standard. Till dokument i dettaprojekt användes en valfri textredigerare tillsammans med en valfri LATEX-kompilator och ver-sionhanteras med Git. Nu väcktes frågan varför man inte använder sig av ShareLaTeX. Fördelenmed ShareLaTeX är att man kan ge någon annan rättighet att redigera sitt LATEX-projekt, på såvis kan flera personer samarbeta med flera dokument samtidigt. En annan fördel med ShareLa-TeX är att den inkluderar både textredigerare och LATEX-kompilator där dokumentets utseendepresenteras vid sidan av Källkoden. Nackdelen med ShareLateX är att det tar längre tid attkompilera i ShareLaTeX till skillnad från en valfri kompilator, samt att det är en webbaseradapplikation medför att det krävs Internet för att få åtkomst till ShareLaTeX och dokument somlagrats där.

En efterstudie av alternativa WYSIWYG-ordbehandlare visar att Overleaf skulle kunna va-ra ett alternativ till att producera dokument i LATEX. Denna applikation har inte varit ettalternativ till val av ordbehandlare till projektet eftersom den har varit okänt inom gruppen.En jämförelse som senare genomfördes visar faktiskt att Overleaf är mycket lik ShareLaTeX.Fördelen med Overleaf är att den är mer användarvänlig eftersom den har mer funktioner attimplementera med enbart musen, såsom matematiska symboler, listor och hänvisningar. Over-leaf kompilerar även källkoden automatisk vilket skapar effektivitet och, om önskas kan ävendokument redigeras i ett läge anpassad just enbart för texten i dokumentet. En liten nackdel medOverleaf är att enskilda delar och kapitel inte kan hämtas ner som PDF-format, utan man måsteladda ner hela dokumentet. Overleaf har en maxkapacitet på 1 GB när det gäller gratisversionen,

105


detta bör inte spela någon roll eftersom det är mycket stort utrymme för dokument. Det är syndatt Overleaf var ett främmande verktyg för gruppen innan projektet startades, Overleaf skullemöjligtvis kunna väljas som ordbehandlare till att producera dokumenten.

Olika ansvarsroller har olika mycket behov av dokumenten. Anledningen till att kravspecifi-kationen nämndes mest kan vara för att de andra dokument har utgått från kravspecifikationen,där kundens önskemål finns dokumenterat. Man kan se kravspecifikation som grunden till deandra dokumenten, till exempel projektplanen som specificerar hur produkten kan byggas föratt uppfylla kraven, eller arkitekturdokumentet för hur systemet bör struktureras enligt kravensom står i kravspecifikationen. Kravspecifkationen är det dokument som leder till att produktenblir som den blir och det kunden vill ha bör vara dokumenterat i kravspecifikationen.

Hur stor inverkan dokument har på ett projekt beror på hur stort projektet är. Större pro-jekt har mera saker att hålla reda på, det kan då vara värt att spendera timmar på en utförligplanering, alltså att skriva dokument för att försäkra att projektet inte spårar ur. Mindre projektbrukar ha mindre saker att hålla reda på, så att skriva ett utförligt dokument till ett miniprojektblir inte alltid lönsamt. Det kan kosta mer resurser i form av tid när man producerar dokument,dessa timmar skulle istället kunna tillägnas åt produktutvecklingen.

I början av projektet under första iterationen, vid slutet av januari och mitten av februari,blev alla dokumenten utformade. Under denna fas har det handlat mycket om att sätta upp kravoch planera arbetet. Detta är endast dokumentarbete. Kravspecifikationen har fått redigeratsunder utvecklingsfasen, anledning till detta var att kunden, Musikaliska konstföreningen ställdenya krav på webbplatsen. Hur noga dokumentarbetet utförs visar sig bidra till kvalitet, ju utför-ligare dokumenten är, desto bättre kvalitet erhålls i produkten. Det finns även andra dokumentsom inte tagits med, såsom gruppkontrakt och mallar som skapats och gjort nytta i projektet.

G.7 Slutsatser

Detta avsnitt omfattar slutsatserna som dras utifrån resultatet av utredningen.

G.7.1 Vad för skillnad gör det att skriva dokument i LATEX i jämförelse med Word?

LATEX och Word är två mycket kraftfulla ordbehandlare. LATEX är kostnadsfritt medan Wordinte är det och det visar sig tydligt också att LATEX är mer uppskattad än Word när det handlarom tekniska eller vetenskapliga dokument. En anledning är att matematiska formler och uttryckblir lättare att föra fram i LATEX till skillnad från Word som behöver ett programtillägg för attgenerera dem. Det är mycket lättare att hålla en stilstandard med LATEX till skillnad från Word.

Det krävs ingen speciell kunskap för att använda Word. Det gör att det är mycket enklareatt komma igång med dokument då det hanteras grafiskt, alltså ett WYSIWYG-verktyg med ettanvändarvänligt gränssnitt till skillnad från LATEX som endast kodas för att sedan kompilerastill PDF-format.

Efter att ha använt mycket LATEX under projektet, från en total oerfaren LATEX-användaretill en erfaren LATEX-användare kan jag dra slutsatsen att LATEX har en mycket hög inlärnings-kurva, problemet ligger bara i början när det är ett helt främmande verktyg. Jag anser att det

106


är värt att ta sin tid att lära sig LATEX och rekommenderar LATEX som ordbehandlare till allamöjliga projektarbeten som kräver dokument, såsom kravspecifikation, projektplan, testplan,rapport.

G.7.2 Hur stor inverkan ansågs dokument ha på projektarbetet?

Dokumenten ansågs ha gjort en väldig stor nytta i projektet under produktutvecklingen. Framförallt är kravspecifikationen ett mycket viktigt dokument som flesta andra dokument refererar tilloch på så sätt anses den ha en stor inverkan på projektarbetet. Storleken och belastningenpå projektet är faktorer som kan avgöra hur viktiga dokumenten är. Dokument anses inte likaeffektivt för ett litet projekt som för ett stort projekt, eftersom det är tidskrävande att skrivadokument. Produktens kvalitet är mycket beroende av dokumenten, ju utförligare dokument,desto bättre kvalitet.

G.7.3 Slutord

-Det har varit mycket givande att ha fått delta i detta projekt. Efter att ha arbetatmycket med LATEX kan jag konstatera att LATEX har en mycket hög inlärningskurva.Det är sannerligen en mycket bred och kraftfull ordbehandlingsprogram och det finnsså många funktionalitet man kan implementera. Jag rekommenderar LATEX till desom är obekanta med LATEX som arbetar mycket med dokument, det är värt det trotsatt det kan vara knepigt och svårt till en början.

107

H EN TEAMLEDARES ROLL UNDER GRUPPENS OLIKA FASER

H En teamledares roll under gruppens olika faser

En utredning skriven av Viktor Wällstedt, teamledare i grupp 1.

H.1 Inledning

Grupparbete är något som existerar överallt i samhället. Det går att inte att förneka attkunskaper om hur man ska jobba i en grupp är något man måste lära sig nästan oavsett vadman arbetar med. En av de viktigaste rollerna i en grupp (om inte den viktigaste) är ledarrollen.Eftersom jag själv garanterat kommer jobba med grupper resten av mitt arbetsliv ser jag dettakandidatarbete som ett utmärkt tillfälle att lära mig själv mer om hur grupper fungerar och isynnerhet hur man bör agera i en ledarroll.

H.1.1 Syfte

Syftet med utredningen är att lära mig mer om hur en grupp (eller i vårt fall ett team) fungeraroch framförallt vad man som ledare kan tänka på för att teamarbetet ska fungera bra. Dekunskaper jag tar med mig från den här utredningen ska förhoppningsvis hjälpa mig resten avmitt yrkesliv.

H.1.2 Frågeställning


1. Vilka olika faser genomgår ett team under ett projekt?

2. Vad kan man i en ledarroll tänka på för att arbetet ska fungera bra?

H.2 Bakgrund

Projektet inleddes med att kursdeltagarna blev ihopslumpade i grupper om 8 studenter, jagblev placerad i grupp 1. Första steget gruppen behövde ta var att fördela ansvarsroller somskulle fungera som hjälp under projektet. Jag blev tilldelad rollen som teamledare och har sedandess försökt sköta mina ansvarsområden efter bästa förmåga. Det stod snabbt klart för migatt en ledarroll är komplicerad. I ett tidigt skede försökte jag ta desto mer initiativ för att fåigång ett samarbete och en samhörighet inom gruppen. Halvvägs genom projektet märkte jag attledarrollen förändrats och att mycket av beslutsfattandet låg i huvudsak på utvecklingsledaren dåvi var inne i utvecklingsfasen. Jag har märkt att gruppdynamiken förändrats och att vi fungeratannorlunda under projektets gång. Detta finner jag spännande och väljer nu att genomföra enutredning på ämnet för att bättre förstå hur gruppen utvecklas. Jag vill också undersöka vad jagsom teamledare kan fokusera och tänka på för att bättre bidra till att arbetet fungerar bra ochhjälpa teamets fortsatta utveckling.

108


H.3 Teori

Boken om effektiva team påstår att en grupp genomgår fyra olika faser. Dessa fyra faserpresenterar jag kort här. Informationen är baserad på kapitel 3 ”From Groups to Teams”. [59]

Steg 1: Beroende och inkludering (Dependency and Inclusion)

Gruppen har ett starkt beroende av ledaren. Medlemmar är oroliga över att accepteras ochinkluderas i gruppen. Under den här tiden vänder sig medlemmar ofta till ledaren för att dennaska fatta beslut och ta initiativ. Medlemmar är ofta överdrivet artiga och försiktiga mot varandra.Det är också vanligt att medlemmar inte vågar uttrycka sina åsikter om exempelvis roller/måloch arbetssätt.

Steg 2: Skenbart oberoende och konflikt (Counterdependency and Fighting)

Medlemmar börjar känna sig accepterade och vågar uttrycka sig mer. Konflikter uppstår ochledarens ledarskap utmanas. Under den här fasen är det viktigt att lösa konflikter för att byggaförtroende. Detta för att medlemmar i gruppen ska våga tycka olika och ändå accepteras igruppen. Här är det viktigt att återigen diskutera mål och beslut när medlemmar nu vågaruttrycka sina åsikter.

Steg 3: Förtroende och struktur (Trust and Structure)

Konflikter är fortfarande vanliga men hanteras bra vilket resulterar i att medlemmar fårförtroende för gruppen. Struktur är fokuspunkten under den här fasen. För att kunna ta stegetoch bli ett effektivt team behövs en bra och tydlig struktur för hur man jobbar och samarbetarinom gruppen för att uppnå sina mål. Subgrupper blir vanligt och medlemmar tar eget ansvaroch börjar också ta över delar av ledarens initiala uppgifter.

Steg 4: Arbete (Work)

Gruppen har strukturen på plats och litar på varandra. Allt flyter på och samtliga medlemmarvill bidra till gruppens mål och visioner. Ledarrollen är nu mer av en konsultativ roll och beslutfattas av gruppen gemensamt. Det är inte nödvändigtvis ledaren som leder mötena utan det kanvariera. Gruppen utvärderar regelbundet kvalitén på sina produkter och processer.

Ledarskap

Boken behandlar även specifikt ledarollen under de olika faserna, och vad man bör tänka extrapå under varje fas. Jag presenterar här kort bokens syn på vad en ledare bör tänka på under deolika faserna. Informationen är baserad på kapitel 6 ”Effective Team Leadership”. [59]

109


Steg 1: Var en styrande och självsäker ledare (Be a Directive and Confident Leader)

Wheelan föreslår ett självsäkert och uppgiftsorienterat ledarskap under den första tiden i ettteam. Under första fasen hos ett team är resterande medlemmar oftast passiva och väntar på attledaren ska ta gruppen framåt. Detta innebär att ledaren måste dra i arbetet till en början. Setill att komma förberedd med ett färdigt mötesprotokoll till de första mötena. Fokusera på attfå medlemmarna att känna sig inkluderade och få en slags känsla av samhörighet inom gruppen.Positiv feedback är alltid viktigt i en grupp, men även mer så i början för att bygga trygghet. Föratt gruppen ska kunna ta sig till steg 2 behövs ett öppet klimat där man inom gruppen diskuterarmål, roller, värderingar och uppgifter. Till en början kommer medlemmar troligen vara passivavid dessa diskussioner men när teamet närmar sig steg 2 kommer konflikter att uppstå.

Steg 2: När medlemmar vill ha mer inflytande, ge efter långsamt (When MembersBegin to Demand More Participation in Running the Group, Slowly Begin toEmpower Them)

Teammedlemmarna kommer nu att utmana både varandra och dig som ledare och ditt ledarskap.En viktigt del under den här fasen är att både medlemmarna och du som ledare inte tar attackernapersonligt och att ni håller diskussionerna till arbetet och uppgifterna ni ska utföra. Det är viktigtatt som ledare förespråka öppna diskussioner och konfliktlösning kring frågor såsom värderingar,mål och ledarskap. Försök fatta beslut inom dessa områden tillsammans. Det är viktigt attkonflikthantering fungerar inom en grupp, utan effektiva konflikter kan man inte samarbeta ochlösa problem inom gruppen vilket är vitalt för effektiva team och framgång.

Steg 3: Involvera medlemmar i ledarskapfunktioner (Involve Members in theLeadership Function)

Att låta medlemmar ta mer ansvar och delvis ta på sig ledarskapet för gruppen är viktigt understeg 3. En grupp som gemensamt styr hur arbetet fungerar och fördelas kommer jobba bättre ochmer effektivt. Även under den här fasen är det viktigt med positiv feedback och support till deandra medlemmarna. Uppmuntra medlemmarna till mer ansvar och ledarskapsfunktioner. Härbör du också förespåka utvärdering av gruppens organisation och processer och försöka förbättradessa i syfte att öka teamets produktion.

Steg 4: Fungera som en expertmedlem i ditt team (Participate as an Expert Memberof Your Team)

Ledare i en grupp som befinner sig i steg 4 kan slappna av lite. Saker löser sig själva ochmedlemmarna tar stort ansvar både för sig själva och projektet. Fortsätt utvärdera teametsprocesser och ha noga uppsyn över om teamet visar tendenser på att gå bakåt i utvecklingen.Det svåra för en grupp i steg 4 är att uppehålla sin effektivitet och undvika regression ochbakslag. Se till att en extern källa utanför gruppen granskar arbetet och produktiviteten, ta tilldig av återkopplingen och se till att teamet tillsammans anpassar sig efter den.

110


H.4 Metod

Eftersom jag behöver information kring hur grupper och ledarrollen utvecklas kommer jag sökainformation via Google Scholar på internet. Jag kommer även leta efter böcker och artiklarrelaterade till ämnet på Universitetets bibliotek. Den källa jag tror kommer vara till störst hjälpär en bok som handlar om effektiva team skriven av Wheelan [59].

För att få fram ett resultat kommer jag jämföra de synsätt och påståenden jag finner i mi-na källor med hur väl det stämmer in på vårt eget projekt. Jag kommer också analysera arbetetoch resultaten för vår egen projektgrupp och jämföra detta med källornas syn på teamets ochledarens utveckling. Kunskap om det egna projektet erhålls genom reflektion, speciellt eftermöten, med hjälp av gruppens mötesprotokoll där allt finns antecknat.

H.5 Resultat

Här beskriver jag vårt eget teams utveckling under projektets gång och relaterar till bokens fyrasteg.

Steg 1:

Precis som Wheelan skriver om i sin bok märktes det ett beroende av mig som teamledare iett tidigt skede. Jag fokuserade på att teamet skulle lära känna varandra och ställde mångafrågor för att få folk att prata och känna sig inkluderade. Vi var också tydliga med att hålla enprofessionell ton mot varandra vid diskussioner vilket vi skrev ned i vårt gruppkontrakt. Teametkom också överrens om att skriva protokoll vid samtliga möten och att placera veckomötet tidigtpå veckan. Protokollen skapade ett bra sätt att dokumentera våra beslut och faktiskt skrivaned något som alla accepterade. Veckomötena placerade vi tidigt för att höja motivationen förveckan. Ett möte på en måndag där man planerar arbetet ger mer fart på diskussionerna än omman gör det på en fredag tänkte jag. Efter ett par veckor märktes det att gruppens medlemmarbörjade bli mer bekväma. De vågade nu ta upp diskussioner och uttrycka sina åsikter. Teametvar alltså påväg in i steg 2.

Steg 2:

Det första tydliga tecknet på att gruppen befann sig i steg 2 kom när vår kund i slutet av februaribestämde sig för att vi skulle bygga deras hemsida med WordPress. Detta resulterade i en störrekonflikt inom teamet angående om vi skulle sätta kundens behov framför våra egna. Underdiskussionerna förekom ibland lite sura miner och höjda röster. Här var det bra att vi under steg1 tagit upp att vi skulle hålla professionell ton mot varandra då det var enkelt att lugna nedhetska diskussioner med argumentet ”såhär ska vi inte bete oss, det har vi alla sagt”. Jag somteamledare försökte så gott jag kunde förmedla att allas åsikter var viktiga. Jag fokuserade påatt alla skulle komma till tals, uppmuntra alla att vara delaktiga i våra beslut och således skapaen inkluderande atmosfär. Det tog flera långa diskussioner innan vi till slut kom fram till enkompromiss. Vi beslutade att bygga två hemsidor, en för kundens räkning och en för vårt egetlärandes skull. När vi löst den första större konflikten inom teamet kändes det snabbt bättreoch sammanhållningen inom teamet förbättrades. Att ha öppna diskussioner och låta alla tyckatill fungerade alltså bra för oss och alla accepterade också den lösning vi kom fram till. Teamet

111


befann sig i steg 2 ganska länge under projektet men blev bättre och bättre på att lösa konfliktersnabbt och effektivt. Det var dock först under april det kändes som vi började komma över tillsteg 3.

Steg 3:

Nu hade vi delat upp den större gruppen i två mindre grupper (WordPress & Flask) och samtligateammedlemmar hade kommit in i sina roller och ansvarsområden. Enskilda individer tog störreansvar och hjälpte varandra i större utsträckning. Eftersom vi nu även utvecklade för fullt vardet framförallt mycket beslut kring hur vi skulle implementera saker och vad kunden ville ha.Detta hade gruppen flertalet gemensamma diskussioner om och det var ofta andra personerän jag som hade mest att säga till om då de var mer insatta i ämnet. Gruppen hade ungefärsamma atmosfär under april-maj och under mötena var det allt fler som kunde berätta omhur det gick och statusen för projektet. Jag som teamledare ledde fortfarande mötena men deandra medlemmarna tog alltmer plats och ansvar vilket var skönt. Beslut fattades tillsammansdemokratiskt som en grupp.

Steg 4:

Enligt min mening har gruppen inte tagit sig till steg 4 utan är fortfarande kvar i steg 3. Detsom saknas för att gruppen ska befinna sig i steg 4 är kontinuerlig utvärdering och förbättringav sina processer och även ett större engagemang för kvalitén. Visst utvärderas arbetet och sakerförbättras allteftersom, men jag tycker inte det känns som ett effektivt team riktigt än. Teametkänns i nuläget som ett väl fungerade team men med möjligheter att utvecklas ytterligare. Hadeteamet haft mer tid på sig tror jag potentialen finns där för att utvecklas och nå steg 4.

H.6 Diskussion

Efter att ha läst boken om effektiva team har jag insett att mycket av det som hänt i vårt egetteam går att koppla till de fyra faserna som Wheelan skriver om. Även om det för vårt teambara handlat om de tre första faserna är det nästan skrämmande hur hon kan förutse teametsutveckling med sådan precision.

Boken är dock skriven utifrån ett företagsperspektiv med fokus på vinst och resultat på ettlite annat sätt än hur vi jobbat med vårt studentprojekt. Vi har fokuserat på att lära oss såmycket som möjligt snarare än att generera ett resultat som tjänar pengar åt oss/kunden. Dettainnebär att vissa delar av boken inte är applicerbara på vårt eget projekt. De avsnitt sombehandlar teamets utveckling och problem, samt tips för ledarrollen är dock absolut relevantaför mig själv och vårt team.

Fokuspunkten som jag ofta utgått ifrån i mina resonemang för utredningen är våra möten.Detta beror på att det är på möten när alla teammedlemmar är samlade jag tycker det ärtydligast och enklast att avgöra teamets nuvarande position i utvecklingen. Det är också påmöten jag själv märkt av ledarrollen mest. När vi i teamet skrivit dokument eller utvecklat hardet sällan märkts att jag haft en ledarroll utan alla medlemmar har diskuterat och pratat unge-fär lika mycket. Detta gör det naturligt för mig att belysa ledarrollen utifrån ett mötesperspektiv.

112


Då jag läst igenom boken först under mars-april har jag egentligen inte kunnat använda tipseninnan maj vilket gjort att jag inte haft jättestor hjälp av utredningen under vårt eget projekt.Däremot har jag nu en mycket bättre förståelse för hur en grupp utvecklas och vad man ien ledarroll kan tänka på vilket jag definitivt kommer kunna ta med mig in i nästkommandeprojekt.

H.7 Slutsatser

De frågor utredningen avsåg att besvara var följande:

1. Vilka olika faser genomgår ett team under ett projekt?Efter att ha läst boken om effektiva team och sedan analyserat utvecklingen av vår egengrupp har jag kommit fram till att Wheelan har en väldigt bra bild av hur grupper utveck-las. Jag håller därför med om hennes påstående att en grupp genomgår fyra steg. Dessafyra steg beskrivs tydligt under min teoridel och sammanfattas bra av sina namn som ärenligt följande: Beroende och inkludering -> Skenbart oberoende och konflikt -> Förtroen-de och struktur -> Arbete. Jag anser alltså att frågeställningen är besvarad i min utredning.

2. Vad kan man i en ledarroll tänka på för att arbetet ska fungera bra?Den här frågan är märkbart mer subjektiv än den andra. Man kan alltid hävda att en vissspecifik sak förtjänar mer uppmärksamhet än andra. Det enkla svaret är att det beror pågruppens nuvarande position i utvecklingen. En sak Wheelan tar upp som anses vara brai samtliga faser är positiv feedback. Detta är något jag själv märkt lättar på stämningenoch gör teamets medlemmar glada och mer samarbetsvilliga, oavsett när i projektet manger den. Jag vill också belysa några saker som jag själv noterat under vårt eget projekt dåteamet genomgick steg 1-3.

Steg 1

Här behövs engagemang och strukturering. Gruppen beter sig lite som ett barn som intetar något eget ansvar utan vill bli matad med uppgifter och instruktioner. Här är detviktigt att skapa en känsla av samhörighet inom gruppen och börja bygga en trygghet föratt utrycka sig, alla ska känna sig välkomna. Du som teamledare bör komma förbereddmed en färdig agenda till möten och vara beredd att dela ut arbetsuppgifter till teametsmedlemmar.

Steg 2

Nu börjar det hetta till. Konflikter uppstår och medlemmarna utmanar varandra och digsom ledare. Kom ihåg att inte ta saker personligt och försök fatta viktiga beslut såsom målmed projektet tillsammans och kompromissa om det behövs. Det är absolut nödvändigtatt alla strävar efter samma mål och vill uppnå samma saker. Försök hitta en stabil metodför att hantera konflikter och stressa inte igenom beslut, utan låt alla komma till tals ochuttrycka sig.

113


Steg 3

Nu har teamet kommit igång och saker händer. Medlemmarna tar mer eget ansvar ochdu som ledare bör uppmuntra detta och försöka hjälpa medlemmarna att ta mer ansvar.Något som är svårt men också viktigt är att fokusera på att utveckla teamets processeroch kvalitetstänk. Lyft dessa frågor med gruppen och skapa en diskussion kring hur ni kanförbättra era arbetssätt och metoder.

Det här är alltså mina egna slutsatser angående saker jag tycker att en ledare bör tänkapå och således mitt svar på frågeställningen. Det finns alltid saker man kan tänka på ochjag tror det finns flera rätta svar här, men ovan nämnda punkter är de jag själv anser varade viktigaste under de tre första stegen av teamets utveckling.

Syftet med utredningen var att lära mig mer om hur en grupp (eller i vårt fall ett team) fungeraroch framförallt vad man som ledare kan tänka på för att teamarbetet ska fungera bra. Jag anserabsolut att jag uppfyllt syftet och jag har nu lärt mig vilka faser ett team genomgår. Dessutomtar jag med mig några specifika punkter under de olika faserna som jag anser att man bör tänkaextra på.

114

Referenser

[1] K. Schwaber and J. Sutherland. (2017. maj. 8). Home | Scrum Guides. Finns tillgänglig på:http://www.scrumguides.org.

[2] K. Schwaber. Agile Project Management with Scrum. Microsoft Press, 2004.

[3] Board Basics | Getting Started with Trello. (2017. maj. 5). Trello Inc. Finns tillgänglig på:https://trello.com/guide/board-basics.html

[4] About - Git. (2017. mar. 2). Software Freedom Conservancy. Finns tillgänglig på: https://git-scm.com/about/branching-and-merging.

[5] Help · GitLab. (2017. mar. 2). GitLab. Finns tillgänglig på: https://gitlab.ida.liu.se/help.

[6] A.K. Zahoor, Scrumban - Adaptive Agile Development Process : Using scrumbanto improve software development process, 2014. Masters Thesis, Helsinki MetropoliaUniversity of Applied Sciences.

[7] What is Kanban? | LeanKit. (2017. maj. 8). LeanKit. Finns tillgänglig på: https://leankit.com/learn/kanban/what-is-kanban/.

[8] Slack: Where work happens. (2017. maj. 8). Slack. Finns tillgänglig på: https://slack.com/is, 2017.

[9] Introduction to LATEX. (2017. maj. 8). LATEX Project. Finns tillgänglig på: https://www.latex-project.org/about/

[10] What is ShareLaTeX. (2017. maj. 8). GWDG Finns tillgänglig på: https://info.gwdg.de/docs/doku.php?id=en%3Aservices%3Aemail_collaboration%3Asharelatex

[11] Google Dokument – skapa och redigera dokument gratis online. (2017. maj. 8). Google.Finns tillgänglig på: https://www.google.com/docs/about/

[12] HTML & CSS - W3C. (2017. maj. 5). W3C. Finns tillgänglig på: https://www.w3.org/standards/webdesign/htmlcss

[13] Bootstrap, v3.3.7. (2017. maj. 5). Twitter Inc. Finns tillgänglig på: https://getbootstrap.com

[14] PHP: What is PHP? - Manual (2017. maj. 8). PHP Group. Finns tillgänglig på: http://php.net/manual/en/intro-whatis.php

[15] The MVVM Pattern (2017. juni. 11) Microsoft. Finns tillgänglig på: https://msdn.microsoft.com/en-us/library/hh848246.aspx

[16] Vad är WordPress? | Happiness Webbyrå. (2017. maj. 8). Happiness AB. Finns tillgängligpå: http://www.happiness.se/artiklar/vad-ar-wordpress

[17] Welcome to Python.org. (2017. maj. 19). Python Software Foundation. Finns tillgänglig på:https://www.python.org/

[18] A. Ronacher. (2017. maj. 19). Welcome | Flask (A Python Microframework). Finnstillgänglig på: http://flask.pocoo.org/

[19] SQLAlchemy - The Database Toolkit for Python. (2017. maj. 19). SQLAlchemy authors andcontributors Finns tillgänglig på: https://www.sqlalchemy.org/

115

http://www.scrumguides.org

https://trello.com/guide/board-basics.html

https://git-scm.com/about/branching-and-merging

https://git-scm.com/about/branching-and-merging

https://gitlab.ida.liu.se/help

https://gitlab.ida.liu.se/help

https://leankit.com/learn/kanban/what-is-kanban/

https://leankit.com/learn/kanban/what-is-kanban/

https://slack.com/is

https://slack.com/is

https://www.latex-project.org/about/

https://www.latex-project.org/about/

https://info.gwdg.de/docs/doku.php?id=en%3Aservices%3Aemail_collaboration%3Asharelatex

https://info.gwdg.de/docs/doku.php?id=en%3Aservices%3Aemail_collaboration%3Asharelatex

https://www.google.com/docs/about/

https://www.w3.org/standards/webdesign/htmlcss

https://www.w3.org/standards/webdesign/htmlcss

https://getbootstrap.com

https://getbootstrap.com

http://php.net/manual/en/intro-whatis.php

http://php.net/manual/en/intro-whatis.php

https://msdn.microsoft.com/en-us/library/hh848246.aspx

https://msdn.microsoft.com/en-us/library/hh848246.aspx

http://www.happiness.se/artiklar/vad-ar-wordpress

https://www.python.org/

http://flask.pocoo.org/

https://www.sqlalchemy.org/

[20] A. Ronacher. (2017. maj. 5). Welcome | Jinja2 (The Python Template Engine). Finnstillgänglig på: http://jinja.pocoo.org/

[21] Introduktion till JSON. (2017. maj. 19). Finns tillgänglig på: http://www.json.org/json-sv.html

[22] AJAX Introduction. (2017. maj. 5). w3schools.com. Finns tillgänglig på: https://www.w3schools.com/xml/ajax_intro.asp.

[23] Jordens resurser tar slut 8 augusti | Världsnaturfonden WWF. (2017.maj. 8). WWF. Finns tillgänglig på: http://www.wwf.se/press/aktuellt/1658512-rekordtidig-overshoot-day-jordens-resurser-tar-slut-8-augusti

[24] A. Raturi, B. Penzenstadler, B. Tomlinson och D. Richardson. Developing a sustainabilitynon-functional requirements framework.GREENS 2014, Proceedings of the 3rd InternationalWorkshop on Green and Sustainable Software, pp.1-8. Hyderabad, India, 2014.

[25] C. Berggren, J Järkvik, J Söderlund. Lagomizing, Organic Integration, and SystemsEmergency Wards: Innovative Practices in Managing Complex Systems DevelopmentProjects. Project Management Journal, Vol. 39, 111-122, Project Management Institute,2008.

[26] A. Cockburn, L Williams. The Costs and Benefits of Pair Programming. Proceedings of theFirst International Conference on Extreme Programming and Flexible Processes in SoftwareEngineering, 2005

[27] T. Lundberg, Testplan. Opublicerat.

[28] PyCharm. (2017. maj. 19). IntelliJ IDEA. Finns tillgänglig på:https://www.jetbrains.com/pycharm/

[29] Svenska webbhotell - Topplista | Läs omdömen innan köp - Sveriges BästaWebbhotell. (2017. maj. 19). SverigesBästaWebbhotell.se. Finns tillgänglig på: http://www.sverigesbastawebbhotell.se/topplista/

[30] Bineros miljöhänsyn och miljöpolicy. (2017. maj. 19). Binero AB. Finns tillgänglig på:https://www.binero.se/om-oss/miljohansyn/

[31] Om oss - City Sites. (2017. maj. 19). City Network. Finns tillgänglig på: https://www.citysites.se/supportsidor/om_oss/

[32] Miljöpolicy - Oderland Webbhotell, VPS, domän & hosting. (2017. maj. 19). ODERLANDWEBBHOTEL AB. Finns tillgänglig på: https://www.oderland.se/om/miljopolicy/

[33] Vi använder vindkraft | One.com (2017. maj. 19). One.com. Finns tillgänglig på: https://www.one.com/sv/vi-anvander-vindkraft

[34] Servage.net Hosting - Om Servage - Affärsprinciper. (2017. maj. 19). servage.net Hosting.Finns tillgänglig på: http://www.servage.se/about/principles/

[35] Insyn i EU-politiken: Kultur, film och media. (2017. maj. 8). Europeiska kommissio-nen. Finns tillgänglig på: https://europa.eu/european-union/file/871/download_sv?token=J-Jxt_4h

[36] Historical yearly trends in the usage of content management systems, May 2017. (2017. mar.6). W3Techs. Finns tillgänglig på: https://www.w3techs.com/technologies/history_overview/content_management/all/y.

116

http://jinja.pocoo.org/

http://www.json.org/json-sv.html

http://www.json.org/json-sv.html

https://www.w3schools.com/xml/ajax_intro.asp

https://www.w3schools.com/xml/ajax_intro.asp

http://www.wwf.se/press/aktuellt/1658512-rekordtidig-overshoot-day-jordens-resurser-tar-slut-8-augusti

http://www.wwf.se/press/aktuellt/1658512-rekordtidig-overshoot-day-jordens-resurser-tar-slut-8-augusti

https://www.jetbrains.com/pycharm/

https://www.jetbrains.com/pycharm/

http://www.sverigesbastawebbhotell.se/topplista/

http://www.sverigesbastawebbhotell.se/topplista/

https://www.binero.se/om-oss/miljohansyn/

https://www.citysites.se/supportsidor/om_oss/

https://www.citysites.se/supportsidor/om_oss/

https://www.oderland.se/om/miljopolicy/

https://www.one.com/sv/vi-anvander-vindkraft

https://www.one.com/sv/vi-anvander-vindkraft

http://www.servage.se/about/principles/

https://europa.eu/european-union/file/871/download_sv?token=J-Jxt_4h

https://europa.eu/european-union/file/871/download_sv?token=J-Jxt_4h

https://www.w3techs.com/technologies/history_overview/content_management/all/y

https://www.w3techs.com/technologies/history_overview/content_management/all/y

[37] S. Brown. (2017. mar. 6). Software architecture vs code. Finns tillgänglig på: https://www.youtube.com/watch?v=GAFZcYlO5S0.

[38] IEEE Computer Society, Systems and software engineering — Architecturedescription (IEEE std 42010). 2011.

[39] F. Bengtsson, Arkitekturdokument. Opublicerat.

[40] Dilip Soni, Robert L. Nord och Christine Hofmeister. Software Architecture in IndustrialApplication. 17th International Conference on Software Engineering,196-207, IEEE, 1995.

[41] V. Agbrink, Kravspecifikation. Opublicerat.

[42] Git - Distributed Workflows. (2017, apr. 21). GitLab. Finns tillgänglig på: https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows. 2017.

[43] Git Workflows and Tutorials | Atlassian Git Tutorial. (2017. mar. 6). Atlassian. Finns till-gänglig på: https://www.atlassian.com/git/tutorials/comparing-workflows. 2017.

[44] S. Pfleeger och J.M. Atlee. Software Engineering, fourth edition. Pearson Education Inc,Upper Saddle River, 2010.

[45] One.com, Domain, Hosting, Email. (2017. maj. 19) Finns tillgänglig på: https://www.one.com/sv/

[46] S. Pfleeger och J.M. Atlee. Software Engineering: Theory and practice, third edition. PearsonEducation Inc, Upper Saddle River, 2006.

[47] IEEE Computer Society, IEEE Standard for Software and System TestDocumentation (IEEE std 829). 2008.

[48] R. Ejvegård. Vetenskaplig Metod. Kapitel 4. Studentlitteratur AB, Lund, 2009.

[49] G. Ejlertsson. Enkäten i praktiken. Studentlitteratur AB, Lund, 2005.

[50] F. Hedenus, M. Persson och F. Sprei. Hållbar utveckling - historia, definition & ingenjörensroll. Göteborg: Chalmers University of Technology, 2016, pp, 14-15.

[51] M. Dick et al., A Model and Selected Instances of Green and Sustainable Software.What Kind of Information Society? Governance, Virtuality, Surveillance, Sustainability,Resilience, J. Berleur et al., Springer, 2010, pp.248-259.

[52] S. Naumann, M. Dick, E. Kern och T. Johann, The GREENSOFT Model: A reference modelfor green and sustainable software and its engineering. SUSCOM. 2011;1(4):294-304.

[53] HTTP Archive. Interesting stats (2017. maj. 6). WebPagetest. Finns tillgänglig på: http://httparchive.org/interesting.php

[54] J. Christie. (2017. maj. 8) Sustainable Web Design. Finns tillgänglig på: https://alistapart.com/article/sustainable-web-design

[55] Google Developers. Improve Server Response Time (2017 maj 27). Google. Finns tillgängligpå: https://developers.google.com/speed/docs/insights/Server

[56] Overleaf. (2017. maj. 23) Finns tillgänglig på: https://www.overleaf.com/

[57] Grundläggande uppgifter i Word 2010 - Word. (2017. maj. 8). Microsoft.Finns tillgänglig på: https://support.office.com/sv-se/article/Grundl%C3%A4ggande-uppgifter-i-Word-2010-eeff6556-2d15-47d2-a04a-7ed74e99a484

117

https://www.youtube.com/watch?v=GAFZcYlO5S0

https://www.youtube.com/watch?v=GAFZcYlO5S0

https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows

https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows

https://www.atlassian.com/git/tutorials/comparing-workflows

https://www.one.com/sv/

https://www.one.com/sv/

http://httparchive.org/interesting.php

http://httparchive.org/interesting.php

https://alistapart.com/article/sustainable-web-design

https://alistapart.com/article/sustainable-web-design

https://developers.google.com/speed/docs/insights/Server

https://www.overleaf.com/

https://support.office.com/sv-se/article/Grundl%C3%A4ggande-uppgifter-i-Word-2010-eeff6556-2d15-47d2-a04a-7ed74e99a484

https://support.office.com/sv-se/article/Grundl%C3%A4ggande-uppgifter-i-Word-2010-eeff6556-2d15-47d2-a04a-7ed74e99a484

[58] J. Zhi, V. Garousi-Yusifoğlu, B. Sun, G. Garousi, S. Shahnewaz, G. Ruhe, Benefits andquality of software development documentation: A systematic mapping, 2015. Journal ofSystems and Software, Vol.99, pp.175-198.

[59] S.A. Wheelan Creating effective teams : a guide for members and leaders.Thousand Oaks : SAGE, 2016.

118

Bilaga 1. Uppdragsbeskrivning

Notförsäljning i 21a århundradet: ny web för Musikaliska konstförening-en

1. Bakgrund

Musikaliska konstföreningen är Sveriges äldsta fortfarande verksamma musikförlag. Inriktningenär västerländsk konstmusik. Det grundades 1959 för att göra det lättare för svenska tonsättare attge ut sina verk. (Notutgivningen dominerades då av tyska förlag.) Bakgrunden är alltså en formav IT-historia – att kunna utnyttja dåtidens mass-spridningsform, på papper tryckta noter – tillen bred, förhoppningsvis internationell publik. Under 1800-och 1900-talen var spridningsformennågorlunda oförändrad, även om man gradvis övergav den ursprungliga crowd-funding-formen(en medlemskrets prenumererade på kommande utgåvor genom en årsavgift) till förmån förförsäljning via återförsäljare – nothandlar och så småningom Statens musiksamlingar.

Efter millennieskiftet tog föreningen fram en egen web, där utbudet visas upp och beställningarkan läggas via mail. http://www.musikaliskakonstforeningen.se/ Det har lett till en kraftigförsäljningsökning (fortfarande som ideell verksamhet och i belopp relativt blygsam) ochinternationalisering (numera kommer ofta över hälften av beställningarna utomlands ifrån:Europa, men även Asien och Nordamerika). Typiskt sett packas och skickas pappersnoter.Försäljning av pdf-er är ovanlig, inte minst av spridningstekniska skäl. Vissa trögrörliga äldreverk finns nedladdningsbara gratis.

I Sverige har gireringar (plus- och bankgiro) och inom EU elektronisk banköverföring länge varitsmidiga betalsätt. Utvecklingen av elektroniska betaltjänster som Paypal gör det numera möjligtatt ta emot betalningar även från ett bankmässigt efterblivet land som USA, och att till rimligkostnad ta emot kortbetalningar (via PayPal).

Tiden verkar dock kommen att ta nästa steg i utvecklingen av föreningens webbnärvaro.

2. Mål och Vision

Vi skulle önska oss en lättunderhållen och ändamålsenlig webbnärvaro för spridning ochförsäljning av våra utgåvor.

Nuvarande webblösning är tung att underhålla – ingen databaslösning i botten. Vidare finns ingenmöjlighet att ”no-touch” sälja noter i elektronisk form – vilket vore rimligt idag. Ytterligareen sida är att det vore önskvärt att enkelt ge nyfikna besökare möjlighet att lyssna påexisterande inspelningar av verken – på Spotify, Soundcloud, youtube, etc, (och att ha åtminstonehalvautomatisk identifiering av åtkomliga inspelningar).

Uppgiften skulle alltså handla om att göra en lättunderhållen webbplats (det tillkommer baraett par verk om året), och möjligheter att inte bara sälja tryckta noter, utan även sälja noteri PDF-form worldwide (har sett lösningar där köparen, efter betalning, får ut ett ex på sinskrivare, snarare än att få en fil som kan spridas och skrivas ut oändligt antal gånger – det, ellernågot annat vettigt, vore önskvärt). Önskvärt vore också med funktionalitet som kunde (spåra?och) hänvisa till inspelningar (på youtube, spotify, soundcloud, ...). Och försäljningen bör hadärtill hörande kopplingar till lagersaldo, betalningsformer, registrering av köpare, möjlighet tillportouppgifter från 3PL, etc. Exakt funktionalitet får arbetas fram i dialog, där vi kan beskriva

119

och prioritera behov, och ni kan bidra med kunskap om tänkbara lösningar – och era bilder avtänkbara kundperspektiv.

3. Viktiga krav

Underhållsvänligt – men ändå snyggt.

Innehåll åtkomligt för sökmotorer

Två (eller N st) språkversioner.

Internationellt fungerande lösning för försäljning av noter i elektronisk form.

Stabil (driftsäker) lösning.

4. Programomgivning

Idag är webben byggd i HTML, underhålls mha Dreamweaver och ligger på One. Kundernaaccessar troligen huvudsakligen via persondatorer och plattor, men det är möjligt attsmartphones också kan vara aktuella.

Även den nya webben ska kunna köras i en standardmiljö, billigt, hos en molntjänstleverantör –som One.

Inte orimligt att tänka sig att den nya lösningen utnyttjar komponenter från någon open-source-plattform och att delar av lösningen kan komma att bli nya komponenter / extensions / pluginssom ni tillgängliggör (i eget namn) via den aktuella plattformens extension directory / bibliotek/ marknadsplats.

120

webbutveckling med flask och wordpressliu.diva-portal.org/smash/get/diva2:1114517/fulltext01.pdf ·...

Documents