• No results found

Webbutveckling med Flask och WordPress

N/A
N/A
Protected

Academic year: 2021

Share "Webbutveckling med Flask och WordPress"

Copied!
130
0
0

Loading.... (view fulltext now)

Full text

(1)

Linköpings universitet

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

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

Webbutveckling med

Flask och WordPress

Web development with Flask and WordPress

Viktor Agbrink

Fredrik Bengtsson

Janos R. Dani

Andreas Järvelä

Tobias Lundberg

Adrian Shosholli

Hans Tchou

Viktor Wällstedt

Handledare : Lena Buffoni Examinator : Kristian Sandahl

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år frå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 enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att 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 i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt 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 eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida 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 to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot 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 measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, 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

(3)

Sammanfattning

Denna rapport handlar om ett projekt åtta studenter på Linköpings universitet genomförde våren 2017, inom ramarna för kursen TDDD96: Kandidatprojekt i programvaruutveckling. Fokuset i projektet var att bygga upp en ny webbplats åt en kund, Musikaliska konstföreningen, som ska ersätta deras gamla webbplats. Projektgruppen valde att göra detta med hjälp av verktyget WordPress. Gruppen valde också att göra en alternativ webbplats med programmeringsspråket Python och ramverket Flask, för att sedan jämföra resultatet mot WordPress-resultatet. Det gruppen valde att jämföra är vilket stöd WordPress respektive Flask ger åt utvecklarna, och vilket av dem som ger lämpligast resultat för kunden. Resultatet blev en färdig hemsida uppbyggd med 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ån grunden i Flask kan få ett betydligt mer användaranpassat system. När det kommer till faktorer som driftkostnader och stöd så visade det sig att WordPress har en klar fördel i jämförelse med Flask.

(4)

Tillkännagivanden

Vi vill börja med att tacka Musikaliska konstföreningen för att ha gett oss möjligheten att utföra ett givande och roligt projekt! Speciellt vill vi tacka Alf Westelius och Donald Lavery som har få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 nytta av. Tack för din vägledning och ditt outtröttliga engagemang!

(5)

Projektidentitet

Grupp 1

Linköpings tekniska högskola (LiTH)

Namn

Ansvarsområde

E-postadress

Viktor Agbrink

Analysansvarig

vikag322@student.liu.se

Fredrik Bengtsson

Arkitekt

frebe780@student.liu.se

János R. Dani

Konfigurationsansvarig

janda553@student.liu.se

Andreas Järvelä

Utvecklingsledare

andja235@student.liu.se

Tobias Lundberg

Testledare

toblu302@student.liu.se

Adrian Shosholli

Kvalitetssamordnare

adrsh715@student.liu.se

Hans Tchou

Dokumentansvarig

hantc350@student.liu.se

Viktor Wällstedt

Teamledare

vikwa174@student.liu.se

Kundkontakt

Alf Westelius, alf.westelius@liu.se

Donald Lavery, donald.lavery@me.com

Handledare

Lena Buffoni, lena.buffoni@liu.se

Kursansvarig

(6)

Innehåll

1 Introduktion 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställning . . . 1 1.4 Avgränsningar . . . 1 1.5 Definitioner . . . 2 2 Bakgrund 3 2.1 Nuvarande situation . . . 3 2.2 Projekterfarenheter . . . 3 2.2.1 Förbättringspunkter . . . 4 2.2.2 Bra erfarenheter . . . 4 3 Teori 5 3.1 Scrum . . . 5 3.1.1 Scrummästare . . . 5 3.2 Trello . . . 5

3.3 Git och GitLab . . . 5

3.4 Scrumban . . . 6 3.5 Kanban . . . 6 3.6 Slack . . . 6 3.7 LATEX . . . . 6 3.7.1 ShareLaTeX . . . 6 3.8 Google Docs . . . 7 3.9 HTML . . . 7 3.10 CSS . . . 7 3.11 Bootstrap . . . 7 3.12 PHP . . . 7 3.13 MVVM . . . 7 3.14 WordPress . . . 8 3.15 Python . . . 8 3.16 Flask . . . 8 3.17 SQLAlchemy . . . 8 3.18 Jinja . . . 9 3.19 Widgets . . . 9 3.20 JSON . . . 9 3.21 AJAX . . . 9 3.22 Hållbarhet . . . 9 3.22.1 Hållbarhetskrav . . . 10 3.23 Systemanatomi . . . 10 4 Metod 11 4.1 Roller . . . 11 4.2 Arbetsmetod . . . 11 4.2.1 Scrumban . . . 11

4.2.2 Kommunikation via Slack . . . 12

(7)

4.3.2 Systemanatomi . . . 12 4.3.3 Moduluppdelning . . . 12 4.3.4 Parprogrammering . . . 13 4.3.5 Testning . . . 13 4.4 Utvecklingsverktyg . . . 13 4.4.1 WordPress . . . 13 4.4.2 Git . . . 13 4.4.3 Trello . . . 13 4.4.4 PyCharm . . . 14

4.5 Metod för att fånga erfarenheter . . . 14

4.6 Arbetsförlopp . . . 14

4.6.1 Dokumentation . . . 14

4.6.2 Utveckling . . . 14

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

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

5.1.1 Webbutikens innehåll . . . 16

5.1.2 Webbutikens utseende . . . 17

5.1.3 Plugins . . . 18

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

5.2 Systembeskrivning av Flask-hemsidan . . . 19

5.2.1 Modell . . . 19

5.2.2 Vy . . . 20

5.2.3 Visningsmodell . . . 20

5.3 Jämförelse mellan de två webbplatserna . . . 20

5.3.1 Design . . . 20 5.3.2 Funktionalitet . . . 20 5.3.3 Arkitektur . . . 21 5.4 Gemensamma erfarenheter . . . 21 5.4.1 Iteration ett . . . 21 5.4.2 Iteration två . . . 21 5.4.3 Iteration tre . . . 22

5.5 Hållbarhet ur ett miljöperspektiv . . . 23

5.6 Översikt över individuella bidrag . . . 23

6 Diskussion 25 6.1 Resultat . . . 25 6.1.1 Alternativen . . . 25 6.1.2 Tidigare erfarenheter . . . 25 6.1.3 Kostnad . . . 25 6.1.4 Kundens behov . . . 25 6.1.5 Sammanställning . . . 26

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

6.1.7 Tidsåtgång . . . 27

6.1.8 Hur vi har utvecklats sedan tidigare projekt . . . 27

6.1.9 Viktigaste lärdomar inför framtiden . . . 27

6.1.10 Systemanatomi . . . 28

(8)

6.2.1 Arbetsmetod . . . 28

6.2.2 Utvecklingsmetod . . . 28

6.2.3 Utvecklingsverktyg . . . 29

6.2.4 Dokumenteringsmetod . . . 30

6.2.5 Metod för att fånga erfarenheter . . . 30

6.3 Arbetet i ett vidare sammanhang . . . 30

6.3.1 Samhälleliga aspekter . . . 30

6.3.2 Miljöaspekter . . . 31

6.3.3 Etiska aspekter . . . 31

7 Slutsatser 32 7.1 Hur kan webbplatsen implementeras så att man skapar värde för kunden? . . . . 32

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

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

7.4 Vilket stöd har projektgruppen haft av WordPress vid utveckling av en webbplats? 33 7.5 Vilket stöd har projektgruppen haft av Flask vid utveckling av en webbplats? . . 34

7.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

(9)

Figurer

1 WordPress-webbplatsen, som den levererades till Musikaliska konstföreningen . . 16

2 Flask-webbplatsen, som den ser ut i dagsläget . . . 17

3 Webbutikens utseende . . . 18

4 Popup-informationens utseende . . . 18

5 Statistik över aktiva hemsidor . . . 38

6 Gruppens sammanfattade svar på fråga 1.. . . 39

7 Gruppens sammanfattade svar på fråga 2.. . . 39

8 Gruppens sammanfattade svar på fråga 3.. . . 40

9 Gruppens sammanfattade svar på fråga 4.. . . 40

10 Gruppens sammanfattade svar på fråga 5.. . . 41

11 Gruppens sammanfattade svar på fråga 6.. . . 41

12 Gruppens sammanfattade svar på fråga 7.. . . 42

13 Gruppens sammanfattade svar på fråga 8.. . . 42

14 Gruppens sammanfattade svar på fråga 9.. . . 43

15 Dokument repository utdrag vid en merge . . . 58

16 Python repository utdrag vid en merge . . . 58

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

18 1-Ingen Skillnad Från Wordpress 5-Mycket bättre . . . 69

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

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

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

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

23 Resultat av fråga två, i efter-enkäten . . . 80

24 Resultat av fråga tre, i efter-enkäten . . . 81

25 Resultat av fråga fyra, i efter-enkäten . . . 81

26 Andel som använt sig av Word innan projektet . . . 97

27 Andel som använt sig av LATEX innan projektet . . . . 97

28 Andel som använt sig mer av LATEX eller Word innan projektet . . . . 98

29 Val av ordbehandlare som föredrogs till projektet . . . 98

30 Val av ordbehandlare som föredras till ett nytt projektet . . . 98

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

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

33 Svar från enkäten om hur stor inverkan dokumenten har haft i projektetarbetet . 102 34 Svar från enkäten om vilka dokument som spelat en stor roll i projektet . . . 103

(10)

Tabeller

1 Tabell med definitioner . . . 2

2 Resultat för undersökning av WordPress arkitektur . . . 49

3 Nätverksprestanda utan cachelagring . . . 89

(11)

1 INTRODUKTION

1

Introduktion

Denna kandidatrapport har skrivits av projektgruppen Grupp 1 under vårterminen 2017. I rapporten 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 är skräddarsydd för att uppfylla Musikaliska konstföreningens behov. Projektgruppen kommer att gå in på hur man går till väga för att skapa en webbplats. Även hemligheterna kring hur man får igång ett effektivt och roligt samarbete inom en grupp kommer att avslöjas. Läsaren får även lära sig mer om skillnaderna mellan att använda ett färdigt verktyg för webbutveckling jämfört med att bygga allt själv.

1.2

Syfte

Syftet med projektet är att, tillsammans med kunden (Musikaliska konstföreningen), skapa en webbnärvaro för föreningen som båda parter är stolta och nöjda med. Vidare vill gruppen lära sig 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 med rapporten att jämföra hur det är att utveckla med WordPress jämfört med Flask, och analysera vilket 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 Flask och 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 som kunden 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 alternativ administrationspanel kan se ut, och saknar därmed mycket av den funktionalitet som krävs för att webbplatsen ska vara användbar för kunden.

(12)

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 1 beskriver 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

(13)

2 BAKGRUND

2

Bakgrund

Projektgruppen har fått i uppgift att utveckla Musikaliska konstföreningens webbnärvaro, för att låta deras notförsäljning ta nästa steg i utvecklingen. Detta inkluderar både att komma med en ny design till webbplatsen, men också att skapa en webbshop. Så här lydde den givna uppdragsbeskrivningen 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ättare för svenska tonsättare att ge ut sina verk. (Notutgivningen dominerades då av tyska förlag.) Bakgrunden är alltså en form av IT-historia – att kunna utnyttja dåtidens mass-spridningsform, på papper tryckta noter – till en bred, förhoppningsvis internationell publik. Under 1800-och 1900-talen var spridningsformen nå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ör försäljning via återförsäljare – nothandlar och så småningom Statens musiksamlingar. Efter millennieskiftet tog föreningen fram en egen web, http://www.musikaliskakonstforeningen.se/, där utbudet visas upp och beställningar kan läggas via mail. Det har lett till en kraftig försäljningsökning (fortfarande som ideell verksamhet och i belopp relativt blygsam) och internationalisering (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 äldre verk finns nedladdningsbara gratis. I Sverige har gireringar (plus- och bankgiro) och inom EU elektronisk banköverföring länge varit smidiga betalsätt. Utvecklingen av elektroniska 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 ta emot kortbetalningar (via PayPal). Tiden verkar dock kommen att ta nästa steg i utvecklingen 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 och har ett rörigt filsystem. Webbplatsen använder ingen databas där den lagrar information, utan allt som visas på webbplatsen finns i HTML-filerna. Detta medför att det är svårt att ändra informationen på webbplatsen, och det existerar inget administrationsgränssnitt så föreningen måste ändra informationen direkt i HTML-filerna. Föreningen har dessutom ingen digitaliserad betallö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”

(14)

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 omfattar detta 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öra bä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 en chans 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 tidigare mjukvaruprojekt 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 och diskutera om man sitter fast i något problem. Oftast löser sig problem genom att diskutera dem eller att säga dem högt.

Veckomöten - Bra för kommunikationen inom gruppen, bidrar till att alla håller sig uppdaterade

och 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 ligger

till. En bra planering tidigt i ett projekt gör att man kan avgöra när projektet kommer att avslutas, och om gruppen ligger efter med något arbete.

(15)

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 mindre arbetslag. 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. I grund och botten så består Scrum av Sprintar. En Sprint omfattar ungefär två till fyra veckor där syftet för den aktuella Sprinten är att bli färdiga med en godtycklig prototyp. En Sprint består av planering för vad som skall göras, dagliga möten, själva utvecklingen, och en granskning av hur 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 att arbetet går som det skall. Scrummästaren jobbar nära tillsammans med produktägaren genom att rapportera status för projektet och ge en bild av hur det går. En Scrummästare ser till att 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å saker gjorda. Trello består av flera delar, bland annat tavlor, listor och kort. En Trello-tavla kan anvä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 listor används för att organisera Trello-kort och för att skapa arbetsflöden, där korten kan flyttas mellan olika listor från start till slut. Trello-kort används för att beskriva uppgifter, idéer, samt saker 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 att utveckla och lagra mjukvara med olika arbetsflöden och arbetsmetodiker. I huvudsak består Git av ett förvaringsutrymme kallat repository där information om projektet lagras, allt ifrån filer till 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 har gjort sedan det senaste bidraget. Git ger även utvecklarna möjlighet att grena ut projektet i flera grenar så kallade branches. Detta gör att en utvecklare kan göra ändringar eller lägga till nya funktioner 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 utvecklaren arbetat färdigt laddar denna upp sina ändringar med en så kallad push. En push laddar upp

(16)

3 TEORI

sina bidrag(commits) till det gemensamma repository:t på servern. Detta gör att flera utvecklare samtidigt 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 just detta är GitLab. GitLab är en webbaserad mjukvara där en projektgrupp kan ha ett gemensamt

repository. GitLab är även ett komplement till Git vilket ger användaren möjlighet att arbeta

med Git grafiskt i webbläsaren. [5]

3.4

Scrumban

Scrumban är en agil arbetsmetod baserad på Scrum och Kanban. Det finns skillnader i hur Scrumban kan se ut då man i vissa fall tar mer av Kanban, medan man i andra fall tar mer av Scrum. I det fallet man tar mer av Scrum ser arbetsmetoden liknande ut, undantaget är sättet man 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 Kanban skulle 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-it lappar och flyttas från en rubrik till nästa när det är lämpligt. De fyra olika principerna för Kanban 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änds direkt, detta ger en mer fokus på konversationen. Samtal med eller utan video finns tillgänglig i applikationen som även stödjer delning av filer. [8]

3.7

L

A

TEX

LATEX är ett typsättningssystem skapat för att säkerställa hög kvalitet på dokument. LATEX kan

användas till alla typer av dokument, men används oftast till tekniska och naturvetenskapliga dokument. [9]

3.7.1 ShareLaTeX

ShareLaTeX är en webbaserad LATEX-redigerare som körs genom webben. Till skillnad från andra

LATEX-redigerare är ShareLaTeX en server-baserad applikation, alltså krävs en webbläsare för

att komma åt verktyget. Dokument som skrivs genom ShareLaTeX kan kompileras direkt och presenteras i PDF-format vid sidan av källkoden. [10]

(17)

3 TEORI

3.8

Google Docs

Google Docs är ett ordbehandlingsprogram med smarta redigerings- och formateringsverktyg som 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-kod strukturerar 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 kan skapas och video- och ljudklipp kan även inkluderas. Innehåll i en HTML-fil är bland annat paragrafer, listor och tabeller. [12]

3.10

CSS

CSS, eller Cascading Style Sheets, är ett stilmallsspråk som används för att beskriva hur innehållet i en HTML-fil ska se ut. Detta inkluderar färger, layout, och fonter. CSS gör det möjligt att 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 utveckla responsiva och mobilanpassade webbplatser. Ramverket underlättar möjligheten att anpassa webbplatser för mobiltelefoner, surfplattor samt datorer, och erbjuder flera komponenter såsom knappar, listor, paneler och menyer som kan användas för att designa webbplatser. Bootstrap 3 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 en förfrågan görs från en webbläsare till en webbserver exekveras PHP-koden och resultatet skickas tillbaka till webbläsaren. Tillägg av PHP ger en mer avancerad funktionalitet på webbplatsen dä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ör implementation av webbplatsen i Flask [15]. Uppdelningen som genomförs med det här mönstret abstraherar presentationen, View, från hur informationen lagras, Model. I rapporten kommer dessa skrivas med svenska översättningar och det är därför både de engelska och svenska namnen finns med i beskrivningarna nedan.

(18)

3 TEORI

Model/Modell: Det här lagret innehåller information som används av programmet. Detta kan

vara vilket tillstånd applikationen är i eller lagret som är ansvarig för att hämta in data från någon form av lagring, exempelvis en databas.

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

layout.

Viewmodel/Visningsmodell: Det här lagret binder samman de två andra lagren. Via detta

lager kan förändringar till modellen göras från användargränssnittet, på så vis leder detta till att logiken 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 bland annat lagringen av innehållet på webbplatsen, men också presentationen av innehållet. I praktiken kan 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 som kan 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ökar funktionaliteten av WordPress. [16]

I WordPress är det möjligt att skapa och uppdatera en webbplats utan att behöva ha djupa kunskaper 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ä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 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 dynamiskt typat språk betyder att variabler och funktioner inte behöver deklarera vilken typ av data de innehåller eller ger tillbaka. Att det är interpreterat betyder att koden tolkas under själva kö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 ska kö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 en relationsdatabas. 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 av en sådan klass motsvarar en rad i motsvarande tabell i databasen. Användningen av SQLAlchemy

(19)

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ändra innehå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öjlighet att 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 tar upp hela bredden av undersidan den är placerad på. För varje Widget finns också en motsvarande Python-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 vid utbyte av data. [21]

3.21

AJAX

AJAX (engelska Asynchronous JavaScript and XML) är ett samlingsnamn på vissa tekniker som används vid konstruktion av webbapplikationer. AJAX används huvudsakligen för att skapa interaktiva applikationer, genom att möjliggöra hämtning och sparande av data utan att en anvä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 att jordens 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 under utvecklingen av en produkt. Det finns tre viktiga effekter på miljöhållbarhet man bör ta hänsyn till:

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

(20)

3 TEORI

3. Den långsiktiga påverkan såsom ändringar av till exempel energiintensiteten eller utbyte av 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 dess påverkan. [24]

3.22.1 Hållbarhetskrav

Hur kan man som produktutvecklare bidra till en mer hållbar utveckling? Kunden tänker ofta inte alls på hållbarhet när de yttrar sin vilja kring produkten, däremot tänker kunden ofta på exempelvis säkerhetsegenskaperna i produkten. Kravanalys är en kravsättningsmetod som behandlar analysering av ”elicitation”, dokumentation och systemkrav. Kravanalytikerna bör tänka på vilka intressenterna är, vad det är för produkt som skall byggas och hur produkten skall byggas. Här bör olika typer av hållbarhetsinverkan alltid finnas i åtanke. Det finns tre olika typer 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 ett delsystem eller delfunktionalitet och båge mellan två noder indikerar ett beroende. Fokus för systemanatomin ligger på vilken funktionalitet som systemet ska ha[25]. Exempel på sådan funktionalitet är "köpa noter", vilket i sin tur kräver bland annat ett betalningssystem och en databas för att spara noterna i.

(21)

4 METOD

4

Metod

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

4.1

Roller

Analysansvarig

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

Arkitekt

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

Dokumentansvarig

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

Konfigurationsansvarig

Tog hand om versionshanteringen genom att besluta om vilket system som skulle användas och hur.

Kvalitetssamordnare

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

Teamledare

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

Testledare

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

Utvecklingsledare

Agerade 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 gruppen skedde 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. Detta innebar att de mest prioriterade uppgifterna, det utvecklarna bör utföra först, hamnade överst på tavlan.

(22)

4 METOD

Metoden valdes då gruppen ansåg att Scrumban bidrog till en planering som är flexibel och tillä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 blev så 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 Git och Drive användes för det ändamålet. Istället användes Slack för att länka till externa filer och kä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 ett verktyg för att lära sig hur det används. Anledningen till att workshop infördes var för att alla i gruppen skulle få en grundläggande kunskap om hur de olika verktygen fungerar. Det genomfö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 fram arkitekturerna för båda projekten. Den har använts för att få en övergripande koll på systemets funktionalitet och dessa funktioners beroenden.

4.3.3 Moduluppdelning

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

(23)

4 METOD

4.3.4 Parprogrammering

Inom Scrumban är parprogrammering en metod där två personer arbetar sida vid sida vid en gemensam dator. Denna metod prövades under den andra sprinten genom att en person kodade och 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, samt en minskad risk att buggar uppstår [26]. På grund av detta ansåg gruppen att parprogrammering var 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 att lä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över det 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-design frå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ör git-arkiv. Ändringar i koden och dokumenten laddades alltså upp till GitLab, så att samtliga gruppmedlemmar hade tillgång till den senaste versionen. På så sätt kunde alla hålla sig uppdaterade 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, under utveckling, granskning, och klart. Nya kort som lades till hamnade först under ”att göra” och efter att 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 att det 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”.

(24)

4 METOD

4.4.4 PyCharm

PyCharm [28] är den IDE som användes för utvecklingen av Flask-hemsidan. Den användes för att 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 som skrevs 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 fick berätta om vad de har lärt sig under den senaste veckans arbete. Dessa berättelser skrevs ned i protokollet 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ärdomarna som fångas upp med denna metod.

4.6

Arbetsförlopp

Projektet började med ett gruppmöte och där alla projektmedlemmar tilldelas en specifik ansvarsroll. Under varje vecka hade gruppen ett möte tillsammans med handledaren. Inför varje mö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 under vilken 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 senare

kompilerades till PDF-format. Alla dessa dokument följer en egen standard som framtagits i en stilmall av gruppens dokumentansvarig. I stilmallen finns bland annat en framsida, dokumenthistorik, projektidentitet, sidhuvud och en standard för hur källhänvisningar ska se ut i dokumenten. I mallen finns även en standard för hur dokumenten bör utformas, en grupplogga 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 varje sprintmöte lyfte Scrummastern fram de uppgifter som bör genomföras under nästa sprint.

4.7

Hållbarhet ur ett miljöperspektiv

(25)

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ökningen går ut på att någon, med start på webbhotellets förstasida, ska kunna navigera sig till en text där det står något om miljöaspekter inom loppet av några minuter. Om sådan text inte gick att hitta 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 senare sektion.

(26)

5 RESULTAT

5

Resultat

Projektet resulterade i två olika versioner av en webbplats. Dels en fullständig webbplats byggd med PHP och WordPress samt en prototyp byggd från grunden. Prototypens serversida är byggd med hjälp av Python-ramverket Flask och SQLAlchemy. En bild över den slutgiltiga webbplatsen, 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 som krävs för att arbeta mot det ramverket. För att få den önskade designen utvecklades ett eget WordPress-tema.

5.1.1 Webbutikens innehåll

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

(27)

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 en lista, som i sin tur uppdaterar metadatan, istället för att låta administratören modifiera datan direkt.

Musikaliska konstföreningen ville kunna uppdatera ordningen verken står listade under varje kompositö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 till den digitala filen, så gjordes en metabox som består av en stor matris där de kan fylla i lämplig prisinformation. 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 i filen sheets.php, bortsett från sidomenyn som byggs upp i sidebar.php. I sheets.php så används WP_Query (funktion som fungerar som mellanlager till databasen) för att hämta inlägg av typen kompositö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

(28)

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 webbutiken besö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ågra ställen, för att undvika att återskapa funktionalitet som redan finns tillgänglig. Följande plugin utnyttjades:

(29)

5 RESULTAT

knapp och möjlighet att skriva ut en kundvagn. Kundvagnen skrivs ut i sidomenyn, och en ”Lägg till 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 olika

språkversioner av varje inlägg och undersida. På webbplatsen skapas även knappar som gör det möjligt för besökare att byta språkversioner.

Broken Link Checker är ett plugin som med regelbundna mellanrum agerar spindel på de

lä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ör via 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 kunna uppdatera innehållet på webbplatsen, både för att ändra information och lägga upp nya objekt då webbplatsen saknade databas. Nu kan webbplatsens information uppdateras via det administrationsgränssnitt som finns inbyggt med WordPress. Via administrationsgränssnittet går det 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 betalningen utan 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ätt för Musikaliska konstföreningen att i framtiden få hjälp med webbplatsen samt att om det uppkommer 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älp av biblioteket SQLAlchemy. Eftersom de har skapats med hjälp av biblioteket så motsvarar klasserna till stor del tabellerna som är lagrade i databasen. Undantaget är att vissa av fälten i klasserna är relationer som alltså är information som kan hämtas ur databasen men som inte direkt motsvaras av en kolumn i databasen.

(30)

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å webbplatsen eller administratören som använder administrationsgränssnittet. Det här lagrets funktion är att presentera informationen på ett bra och användbart sätt samt att låta användaren interagera med informationen. Det här lagret är uppdelat i två olika komponenter home och admin som alltså är de två olika gränssnitten som finns beroende på om användaren är en administratör eller en besökare av webbplatsen. De olika vyerna är implementerade så att de är helt oberoende av varandra.

5.2.3 Visningsmodell

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

PageVM är en av de huvudsakliga filerna och klasserna i det här lagret. En instans av den här klassen fungerar som en undersidas koppling till modellen. Detta betyder att när en användare ska dirigeras till en webbplats så skapas en instans av PageVM-klassen som hämtar sidans information 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-HTML-komponenter refereras till 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 kapitlet Resultat. WordPress-hemsidans design är influerad i hög grad av Musikaliska konstföreningen medan Flask-hemsidans design är skapad utefter eget tycke inom gruppen. Designen är helt färdig och implementerad för WordPress-hemsidan och i stort sett klar för Flask-hemsidan (undantaget adminpanelen).

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 att byta undersidor och representera information från databasen. Det finns också stöd för framtida implementation av adminpanel, webbshop och dynamiskt tillägg av undersidor via adminpanel.

(31)

5 RESULTAT

5.3.3 Arkitektur

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

5.4

Gemensamma erfarenheter

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

5.4.1 Iteration ett

Under iteration ett jobbade gruppen främst med att få en bra struktur i gruppen, skriva dokument, 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 var mycket givande för dynamiken. Det gick lätt att dela in gruppens medlemmar i roller och alla fick sitt förstahandsval. Tidigt under iterationen skrevs ett gruppkontrakt som specificerar hur gruppen ser på projektet, vilket gjorde att gruppen var överens om mål och ambitioner med projektet. Dokumenten som skulle skrivas under iterationen blev snabbt färdiga och gruppen var nöjda med innehållet.

Negativa erfarenheter

Dokumenten delades upp mellan gruppens medlemmar, och de flesta hade ett specifikt dokument som de hade ansvar att skriva. Detta gjorde att dokumentskrivandet blev effektivt, men då det saknades 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 skrev dem. Även om alla hade en övergripande koll på vad som stod i dem så skulle det vara bättre om alla hade bra koll på dem i mer detalj. Det gruppen saknade var en bättre struktur för dokumenten, 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 gemensamma genomgångar av de tekniska verktyg som användes.

(32)

5 RESULTAT

Positiva erfarenheter

Gruppen var överens om att det var givande att ha gemensamma workshops där de fick lära sig om LATEX, Git, WordPress, och HTML/CSS. Strukturen där gruppen hade en eller två personer

som 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 valt att använda dem. Kommunikationen via Slack, versionshanteringen via Git, och aktiviteter via Trello upplevde alla som något mycket positivt.

Negativa erfarenheter

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 blev fragmenterat, och att gruppen i efterhand behövde kopiera över informationen manuellt. Under sprinten så hade gruppen ganska begränsat med tid, vilket gjorde att utvecklingsledaren inte hade tid att förbereda allt. Detta gjorde att gruppen inte jobbade strikt efter de mallar som skulle 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 webbplats byggd med Python och ramverket Flask.

Positiva erfarenheter

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

Negativa erfarenheter

Samarbetet försämrades inom gruppen eftersom gruppen behövde dela upp sig i två mindre grupper och jobba parallellt. Detta berodde delvis på att kommunikationen mellan grupperna försämrades. Gruppen misstänkte också att bristen på en stabil lokal har varit en bidragande faktor till samarbetsproblem och motivationsbrist. Det kändes inte lika seriöst att behöva boka sina 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 mer anklagande ton.

(33)

5 RESULTAT

Gruppen missbedömde mängden arbete för WordPress vilket resulterade i att gruppen behövde skjuta upp planeringen gång på gång. Detta i kombination med att Musikaliska konstföreningen hade svagt intresse för att följa projektgruppens arbete resulterade i att gruppen fick göra om saker 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 ”jobbar

kontinuerligt 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 vilka

miljöcertifikat de har. ”Elen kommer endast från vattenkraft, biobränslen, vindkraft och solenergi

som 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 av

kandidatrapporten. I denna individuella del jämförs gruppens syn på WordPress före respektive efter att projektet utförts. Syftet med detta är att undersöka varför gruppen tycks ha en negativ syn 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 samtycke och statistik över verktygets användande.

Hur arkitekturen beror på ramverk är skriven av gruppens arkitekt, Fredrik Bengtsson. Det är

en undersökning av hur den dokumenterade arkitekturen påverkas av vilket typ av ramverk som används under utvecklingen. Speciellt kollar den på skillnaderna vid utveckling med hjälp av WordPress som är ett CMS jämfört med utveckling med hjälp av Flask som är ett mer traditionellt ramverk.

Hur olika arbetsflöden påverkar ett projekt är en individuell rapport skriven av konfigurationsansvarige, János R. Dani, i gruppen. Denna rapport ger en överblick över de olika arbetsflö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 och

utvecklingsansvarig vid namn Andreas Järvelä. Den jämför utvecklingsprocessen vid användning av Scrumban i två olika projekt. Den tar även upp hur olika arbetsmetoder kan påverka gruppens prestation 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 medlemmar ser på testningens roll inom mjukvaruutveckling.

(34)

5 RESULTAT

Hållbar webbutveckling är skriven av gruppens kvalitetssamordnare, Adrian Shosholli. Den

handlar om hållbar utveckling och projektets ekologiska hållbarhetsaspekter.

Dokuments inverkan på projektet, en individuell rapport som omfattar styrkan i dokumentationen

samt vilken påverkan och roll den har spelat i projektet. Denna delrapport är skriven av projektgruppens 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 en grupps olika faser för att bättre bidra till teamets fortsatta utveckling.

(35)

6 DISKUSSION

6

Diskussion

6.1

Resultat

Valet av WordPress som arkitektur för projektet grundar sig i de krav Musikaliska konstföreningen hade på webbplatsen. Nedan diskuteras de kraven och varför WordPress ansågs vara det som passade bäst. Dessutom motiveras varför gruppen valde att göra ett projekt i Python 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. Dessa erfarenheter bidrog till valet av ramverk. En stor fördel med att välja Python är att alla medlemmar 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 ett tema i WordPress. Dessutom hade några av gruppens medlemmar erfarenhet av ramverken Flask och 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ället fö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.com endast PHP.

One.com kostade Musikaliska konstföreningen cirka 15 kr/månad, vilket gjorde det till det absolut billigaste webbhotellet. Det alternativ som kom på andraplats kostar ca 100 kr/månad fö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öreningen har ett stort behov av att enkelt kunna lägga till nya verk till försäljning på webbplatsen

(36)

6 DISKUSSION

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

WordPress ger Musikaliska konstföreningen möjligheten att få hjälp med webbplatsen från annan personal, som exempelvis kundtjänsten hos deras webbhotell. Det gör att webbplatsen får en mycket 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älpa till att underhålla. Anledningen till detta är att WordPress är enklare och har ett stort antal anvä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 Musikaliska konstföreningens behov, är lätt att underhålla, och framförallt att det är det billigaste alternativet.

Python valdes som det språk som kommer användas under den andra delen av projektet, eftersom Python ä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 som finns kvar till projektet efter utveckling av WordPress-sidan. Flask valdes framför Django med motiveringen att det inom gruppen finns en viss erfarenhet av ramverket sedan tidigare, samt att det 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 Flask varianten också tas fram. Vid utveckling med Flask så finns det en större kontroll över vad som lagras i minnet, vilket gör att det finns större möjligheter för optimering av specifika delar av systemet. Det är också lättare att kontrollera exakt vad som lagras, och hur det lagras i databasen. WordPress administrationsgränssnitt är gjort för att vara väldigt generellt, men det innebä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 egen administrationspanel för ett system i Flask, som enbart har relevanta delar. Det gör också att ett 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, som skulle göra sidan ännu bättre för Musikaliska konstföreningen. Man skulle kunna skriva en mer utförlig dokumentation över hur man modifierar temat, så att de kan ändra designen på sidan själva i framtiden. Man skulle även kunna lägga till fler alternativ för att modifiera vissa enkla saker, 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öreningens nya webbplats. Det som saknas är huvudsakligen en koppling till PayPal, och en administrativ panel där de kan ändra innehållet på sidan. Utöver detta så måste även försäljningsverken läggas till i databasen, och möjlighet att administrera fler språkversioner behövs.

References

Related documents

Video lägger till en länk till Youtube (här musikalen Chess) Bild ger utrymme för bild.. Avdelning lägger in en gränslinje samt ett valbart

Vi skulle vara mycket tacksamma ifall vi fick komma och utföra vår undersökning på er gymnasieskola som handlar om självkänsla, självförtroende, fysiska

5 Steve Krug är en användbarhetskonsult och författare med över 20 års erfarenhet som har arbetat med kunder som Apple och Bloomberg.com... med användartester och

Jag går fram och tillbaka för att inte somna, försöker se ut som flera stycken.. Planerar för

klassen som var ganska dum eller hon var inte dum men Alva är lite typ rädd för henne för hon är ganska bossig när dom leker och hon låter så sur och hon har ett stort hus och

Det viktigaste med mallfiler är att WordPress adresser olika mallar för att visa sidans innehåll beroende på vilka filer man har tillgängligt i sitt tema.. Denna förenklade

• Standardisering och harmoniserng minimerar risken för dubbelarbete och skapar förutsättningar att återanvända specifika meddelanden vid utveckling av nya

Detta ligger också i linje med skälen till MAR i vilka sägs att det visserligen kan vara så att kravet på offentliggörande så snart som möjligt innebär en stor administrativ