medietekniskt kandidatprojekt, tnm094weber.itn.liu.se/~karlu20/courses/tnm094/reports/... · en...

Medietekniskt kandidatprojekt, TNM094

Författare:

Sebastian AlfredssonEmma EdvardssonTobias ErlandssonGustav HallströmHannes IngelhagTherese Ramböl

Team Prego

ITN Linköpings UniversitetExaminator: Karl Johan Palmerius

Norrköping, 16 juni 2014

Ordlista

• Team Prego - Utvecklingsgruppen

• Pregosystemet - Det administrationssystem som utvecklades under projektet

• Kund - Anna Palmerius - Ordförande i Tjalve IF

• ER-Diagram (Entity-Relationship-diagram) - Beskriver sambanden mellan de olika tabellerna idatabasen

• JSON - JavaScript Object Notation

• PHP - Hypertext Preprocessor

• JavaScript - Prototypbaserat skriptspråk

• GUI - Graphical User Interface (Grafiskt användargränssnitt)

• SQL - Programmeringsspråk för att ställa förfrågningar till databas

• HTML - HyperText Markup Language

• CSS - Cascading Style Sheets

• Allmänheten - Alla människor som vill besöka hemsidan

• Administratör - Arrangörer eller funktionärer på tävling

• Git - Versionshanteringsverktyg

• GitHub - Tjänst som kan hantera Git

i

Sammanfattning

Pregosystemet är ett tävlingsadministrationssystem för friidrottsklubbar utvecklat av Team Prego påuppdrag av friidrottsföreningen Tjalve IF. Systemet innehåller funktioner som underlättar i anmäl-ningsprocessen, skapandet av startlistor och resultatlistor - något som är trivialt i arrangerandet avfriidrottstävlingar. För att öka mobiliteten är systemet webbaserat och kan nås av både intressenteroch arrangörer.

Framställandet av systemet har skett via en agil arbetsmetod kallad scrum. I scrum arbetar man isprintintervall, i detta fall två veckor, under vilka förbestämda uppgifter ska utföras. Uppgifternabygger på de krav som kunden i samspråk med utvecklare har skapat. Användandet av scrum innebäratt det löpande arbetet kontinuerlig redovisas för kund, vilket ger möjlighet att korrigera eventuellabrister.

Systemet är utvecklat som ett multilagersystem. Detta innebär att filerna har tilldelats specifika upp-gifter för att ge systemet en bra struktur med stor utvecklingsbarhet. Klienten, den enhet som kopplarupp sig mot hemsidan, har ett lager som hanterar sidans layout samt delegerar användarens data tillserverlagret. Följdaktligen hanterar serverlagret den data som användaren vill skicka till eller hämtafrån databasen. Valet av systemarkitektur föll på multilagersystem då det är ett tillförlitligt systemsom ofta förekommer i webbutveckling.

Team Prego har uppnått sitt mål - att skapa ett administrationssystem ämnat för friidrottstävlingar.Flertalet av de funktioner kunden önskade har implementerats och systemet har även varit i bruk hoskund. Responsen har varit god, men det bör beaktas att systemet befinner sig i ett tidigt stadium ochhar stora utvecklingsmöjligheter.

ii

Innehåll

Ordlista i

Sammanfattning ii

Figurer v

1 Inledning 1

1.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Syfte och frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Mål och visioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 Tekniska färdigheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Utvecklingsmetodik 5

2.1 Projekthantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Kravhantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Tävlingsadministration 11

3.1 Befintliga system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 friidrottsanmalan.se . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.2 Wind Athletics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Utformning av Pregosystemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Systemarkitektur 15

4.1 Klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.1 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

iii

4.1.2 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.3 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2.2 Databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Resultat och analys 19

5.1 Allmänhetssidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Administrationssidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3 Databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6 Diskussion och framtida arbete 30

6.1 Arbetsgången . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.2 Slutresultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.3 Förbättringspunkter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7 Slutsatser 33

7.1 Agilt arbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7.2 Kundkontakt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7.3 Systemarkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.4 Testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.5 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.6 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A Bilaga 37

Figurer

2.1 Team Pregos uppskattade tidsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Startsidan för Wind Athletics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Införande av resultat i Wind Athletics . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 Diagram för det implementerade multilagersystemet. . . . . . . . . . . . . . . . . . 16

4.2 En tabell i databasen för en tävling . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Sambandet mellan tävlingstabellen och disciplintabellen . . . . . . . . . . . . . . . 18

4.4 SQL-kod för att få tillgång till information i båda tabellerna med hjälp av länkadetabeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.1 En graf över hur allmänhetssidorna är sammankopplade . . . . . . . . . . . . . . . . 20

5.2 Startsidan för hemsidan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Första anmälningssidan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.4 Andra anmälningssidan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.5 Lägg till klubb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.6 Startlistan för en tävling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.7 En graf över hur administrationssidorna är sammankopplade . . . . . . . . . . . . . 23

5.8 Startsidan för administratörer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.9 Första sidan för att skapa tävling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.10 Sida nummer två för att skapa tävling . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.11 Sidan för att ändra tävlingsinformation . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.12 Sidan för att ändra deltagarinformation . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.13 Sidan för att acceptera sena anmälningar . . . . . . . . . . . . . . . . . . . . . . . . 26

5.14 Sidan för att få ut faktureringsunderlag för klubbar . . . . . . . . . . . . . . . . . . 27

5.15 Sidan för sätta/ändra nummerlapparna för deltagarna . . . . . . . . . . . . . . . . . 27

5.16 ER-diagram över databasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

v

Kapitel 1

Inledning

Norrköpingsbaserade friidrottsföreningen Tjalve IF efterfrågar ett smidigare system för att underlättadet administrativa arbetet kring deras friidrottstävlingar. Med hjälp av ett webbaserat system skullearbetsbördan för föreningen reduceras avsevärt och tillgängligheten skulle öka för arrangörer ochintressenter. Denna rapport kommer att behandla utvecklingsteamet Team Pregos framtagande av ettnytt system kallat Pregosystemet.

Pregosystemet erbjuder Tjalve IF ett användarvänligt system innehållandes funktioner såsom motta-gande av anmälningar, skapande av startlistor samt införande av resultat. Mer om systemets funktionoch design kan läsas om i kapitel 5 - Resultat och analys.

1.1 Bakgrund

Den ideella föreningen Tjalve IF arrangerar varje år ett antal friidrottstävlingar. Inför en tävling krävsmycket planering och många medlemmar är delaktiga i genomförandet. För att underlätta arbetet meddessa event använder Tjalve för närvarande två system parallellt. Systemen fungerar dock inte heltenligt förväntan och det är för kunden önskvärt att samla alla funktioner i ett och samma system.Projektgruppen Team Prego, en grupp om sex civilingenjörsstudenter vid Linköpings universitet, harfått i uppdrag i kursen TNM094 - Medietekniskt Kandidatprojekt att lösa Tjalve IFs problem.

Anna Palmerius, ordförande i Tjalve IF, är kund för projektet och önskar att det nya systemet ska varahelt webbaserat. Detta skulle innebära att systemet hålls lättillgängligt utan att vara versionskänsligt,dock med begränsningen att internetuppkoppling krävs. Systemet ska innehålla ett gränssnitt avsettför intressenter som exempelvis vill anmäla sig till tävling, kolla på startlistor eller läsa resultat.Därtill även ett gränssnitt avsett för klubbens administratörer som ska kunna skapa tävlingar, startlistoreller registrera resultat. Detta innebär att systemet kommer hanteras av användare med varierandeerfarenhet om både sporten och gränssnittet vilket kräver att systemet bör vara lättnavigerat. Kundenser helst att systemet ska kunna visas inte endast på dator utan även på handhållna enheter.

1.2 Syfte och frågeställning

Syftet med projektet är att genom en agil modell utveckla en tävlingsadministrationssida för TjalveIF.

1

Frågeställningarna lyder:

• Går det genom ett webbaserat system att reducera den administrativa arbetsbördan för friid-rottsföreningar?

• Hur skapas ett gränssnitt anpassat för it-noviser?

• Genom vilken systemarkitektur erhålls en vidareutvecklingsbar produkt?

• Hur anpassas den agila metoden för Team Pregos utvecklingsarbete?

1.3 Mål och visioner

Team Pregos mål:

• Att införa ett nytt tävlingsadministrationssystem

Visioner för Pregosystemet:

• Underlätta det administrativa arbetet för arrangören

• Underlätta anmälningsprocessen för tävlande

• Ge möjlighet att uppdatera och visa resultat direkt via hemsidan

• Skapa ett användarvänligt gränssnitt

• Arbeta fram en utvecklingsbar applikation

• Skapa en sida anpassad för olika plattformar

• Förenkla faktureringsunderlag

1.4 Avgränsningar

Pregosystemet ska vara en treskiktslösning med databas, web och GUI. Systemet ska implementerasi webbläsare och bör stödja klient både på dator och tablets. Systemet skall kopplas mot två externasystem: SQL-databas som ligger hos kunden samt en webserver som ägs av kunden.

1.5 Tekniska färdigheter

Många av de tekniska kunskaper som Team Prego besitter har hämtats från tidigare utbildning. Dessakurser har varit till stor nytta i arbetet med Pregosystemet. Flera områden i utvecklandet av syste-met har täckts av dessa tidigare kunskaper, allt från det programmeringsmässiga i uppbyggnad avklasser till det designmässiga i utformandet av gränssnittet. Relevanta kurser från utbildningen samttillämpningen redogörs för nedan.

TND012 Programmering grundkurs Programmering grundkurs gav en första introduktion tillprogrammering och grunden för fortsatt utveckling av programmeringskunskaper vilket varit funda-mentalt för ett projekt som detta. I kursen introducerades programmering med hjälp av C++ och meddetta presenterades väsentliga principer så som datatyper och styrsatser och det redogjordes även förandra grundläggande programmeringsbegrepp så som källkod, parametrar och syntax. Introduktionentill programmering och den första programmeringsvanan uppfattades som oerhört viktig oavsett pro-grammeringsspråk då de grundläggande principer är inkluderade i så när all programmering och såväl i det aktuella projektet.

TND002 Objektorienterad programmering Fortsättningskursen TND002 Objektorienterad pro-grammering har också bidragit med väsentlig teoretisk kunskap som tillämpas i projektet. I kursenhanteras för första gången objektorienterad programmering och principen för att programmera i klas-ser. Kunskapen att designa och implementera klasshierarkier nyttjades väl i den senare delen av pro-jektet då koden strukturerades om för att följa en objektorienterad modell. I kursen indroduceradesäven metoder för att hantera indata av tal och text via kommandofönster eller dialogrutor vilket an-vändes flitigt i den utvecklade applikationen som bland annat hanterar att användaren anmäler sig tilltävlingar.

TNG003 Programmering i C++ Kunskaper om objektorienterad och klassinriktad programme-ring fördjupas ytterligare under kursen TNG003 Programmering i C++. I kursen tillgodogörs ävenmetoder gällande pekare och dynamisk minnesallokering. Kursen hanterade en högre nivå av pro-grammering vilket gett kunskaper och förberedelse för ett projekt som detta. Stora delar av kursenoch då särskilt objektorienterad och klassinriktad programmering samt metoderna gällande pekareoch dynamisk minnesallokering var till stor användning då koden strukturerades om.

TNMK30 Elektronisk publicering Med avseendet på att lösningen ska vara ett webbbaserat ochplattformsoberoende system har endast kursen TNMK30 Elektronisk publicering fokuserat på webpro-grammering och vertyg för att publicera material på nätet. Under denna kurs användes olika teknikeroch format för att presentera text och bild elektroniskt och grundläggande webprogrammeringsspråkså som HTML, CSS, JavaScript och PHP såväl som frågespråket SQL presenterades. Dock var kursengrundläggande och extra förkunskaper inom webprogrammering så som HTML5, jQuery och AJAXvar nödvändiga att införskaffa på egen hand, vilket har gjorts under arbetets gång.

TNM055 Databaser Enskilda individer i gruppen hade även läst kursen TNM055 Databaser somintroducerar grundläggande modellering genom användadet av ER-diagram vilket var fördelaktigtdå ett handritat ER-diagram över en del av databasen var ett av det första modelleringsarbeten somutfördes i projektet. Kursen gav även fortsatt utveckling av frågespråket SQL som används flitigt isystemet. SQL används bland annat för att ändra, lägga till och ta bort ur databasen.

TNM040 Kommunikation och användargränssnitt Då en av visionerna var att implementeraen minimalistisk design som ger en trevlig användarupplevelse har man kunnat relatera till kursenTNM040 Kommunikation och användargränssnitt som introducerat metoder för att utveckla använ-dargränsnitt med hög användarvänlighet baserat på kognitiv psykologi, användarmodeller och utvär-deringsmetoder. Kursen klargjorde tankemönster för både ovana och vana datoranvändare och hurgränssnitt kan utvecklas med avseende på dessa, detta kunde appliceras på projektet då kunden klar-gjort att flera ovana användare kommer utnyttja tjänsten.

TNM042 Design Det finns även tekniska kunskaper inom design att hämta från kursen TNM042Design som implementeras på weblösningen. Från kursen tillämpades bland annat grundläggandeprinciper inom designarbete och tekniska kunskaper inom typografi och layout.

Kapitel 2

Utvecklingsmetodik

När en webbsida ska skapas är det viktigt att utvecklare har klart för sig vad som ska åstadkommasoch vad syftet med sidan är. Uppgiften kan till en början verka stor eller till och med övermäktig. Detär därför viktigt att gå igenom vilka komponenter som behövs för att sidan ska kunna konstrueras[1,kapitel 6]. Det är viktigt att utvecklare tar hänsyn till både vilka funktionaliteter som ska finnas menäven hur de ska presenteras. Många sidor har som syfte att presentera en stor mängd information ochdet är då viktigt att detta görs på ett så smidigt sätt som möjligt. Webbutveckling handlar därför tillväldigt stor del om design i den mån att smarta och lättförståeliga lösningar alltid eftersträvas. En stordel av det som är avgörande för hur lyckad en hemsida blir ligger i hur väl användargränssnittet ärkonstruerat.

En annan viktig aspekt inom webbutveckling är vikten av att hålla en bra filstruktur. Eftersom densida som skapas byggs upp på samma sätt som filerna och mapparna i systemet, måste detta göras påett sofistikerat och väl genomfört sätt[1, kapitel 6]. Det går att argumentera för att webbutveckling iännu större utsträckning än annan typ av utveckling, kräver bra organisation och tydligt struktur. Detfinns givetvis andra fundamentala aspekter som är avgörande för en väl fungerande hemsida. För attfå en snabb och säker sida, måste koden vara skriven på ett tydligt sätt. I många fall har hemsidor somprimär funktionalitet att presentera och lagra information från en databas. Det är då viktigt att dettagörs på ett sätt där data riskerar att gå förlorad samtidigt som laddningstider inte får vara för långa.

De aspekter som nämns i de två styckena ovan motiverar varför en webbprogrammerare måste vara såallsidig som möjligt. En utvecklare måste därför ha känsla för hur en enkel och användarvänlig sidabyggs, samtidigt som denne ska kunna skriva effektiv och tydlig kod. Detta som ställer höga krav påhur utvecklaren går till väga för att genomföra arbetet.

Detta projekt genomfördes enligt den agila metoden scrum. Att arbeta med scrum innebär ett flexibeltarbetssätt där delleveranser av produkten sker regelbundet och med relativt korta intervall [12]. Dessaiterativa tidsintervall kallas sprinter och inleds vanligtvis med en planering av kommande sprint ochavslutas med utvärdering av arbetet [12, s. 7]. Team Prego anpassade scrummetoden så att sprintin-tervallen var två veckor. Under den allra första sprinten, sprint 0, planerades projektet upp i en sprint-backlogg utifrån kundens prioriterade krav och tid lades även på självstudier i programmeringsspråkensom systemet skulle skrivas i. En sprintbacklogg innehåller de funktioner och krav som bör utvecklasoch uppfyllas för vardera sprint, denna ligger till grund för arbetet och ska även uppdateras om nyakrav uppkommer [12, s. 14]. Vardera sprint inleddes med att uppdatera sprintbackloggen då uppläggetkunde förändras beroende på resultatet från föregående sprint. Vid somliga sprinter hade fler uppgif-ter hunnits med än planerat och vid andra hade uppgifter tagit längre tid än förväntat. Vid ett tillfällekrävdes total omstrukturering av all kod vilket medförde att arbetet blev förskjutet en hel sprint. Idetta skede krävdes att dialogen med kunden var god då vissa funktioner nedprioriterades.

5

Ett scrummöte [12, s.10] är ett kort möte där samtliga medlemmar i gruppen ger en reflektion överderas arbete, mötet medför en god överblick över systemets progression mot slutmålet. Team Pregohöll scrummöten näst intill dagligen, dessvärre mer okontinuerligt ju längre projektet löpte. Dettaberodde delvis på att gruppen under en tid jobbade på samma uppgifter flera dagar i följd och intehade mycket att rapportera till övriga medlemmar.

2.1 Projekthantering

För att projektet ska fortskrida på ett smidigt sätt måste arbetet planeras upp och varje medlem igruppen måste veta dess ansvarsområde samt arbetsuppgifter. Inledningsvis är det viktigt att skapaen projektplan [3, s. 149-151] där projektets struktur och arbetssätt enhetligt bestäms av samtligagruppmedlemmar så att den kan användas som guide för framtida arbete. En projektplan bör innehållaföljande:

• Gruppmedlemmar, dess ansvarsområden och kontaktuppgifter

• Kort beskrivning av projektet och målen

• Tidsplan

• Infrastruktur för programmering och systemutveckling

Team Prego valde att använda den första sprinten, sprint 0, som planeringssprint för att skapa projekt-plan, en tidsplan och skriva prioriteringslista. Dessa dokument var levande och reviderades kontinu-erligt utefter projektets gång.

Tidsplanen utformades som ett ganttschema, ett flödesschema som illustrerade olika faser i projektetenligt figur 2.1. Ett Ganttschema är bra då det tydligt synliggörs vilka uppgifter som ska utföras närsamt om flera uppgifter utförs parallellt. Genom att färgmarkera dessa tydliggörs även hur kritiskaalla moment är. [3, s. 119] Via tidsplanen erhöll gruppen en god överblick över alla sprintar, delmål,deadlines samt inbokade kundmöten. Tidsplanen medförde att gruppen enklare kunde planera arbetet.

En produktbacklogg skapades för att planera arbetsgången. Denna bör innehålla alla de krav ochfunktioner som kunden önskar ordnade efter den prioritet de har [12, s. 12-13]. Team Prego estimeradetidsåtgången för utveckling av vardera delfunktion samt hur viktig varje funktion kommer vara för attmjukvaran ska fungera. I och med detta viktades ett index ihop för varje delfuktion för att på så sättprioritera vilka funktioner som måste göras först samt tiden det tar att få de färdiga. Denna låg sedantill grund för sprintbackloggen.

För fortsatt hantering av projektet och för att gruppen på ett smidigt sätt skulle kunna ha tillgångtill alla filer så användes versionhanteringssystemet Git [6] och servern GitHub [7]. Via Git kundeutvecklarna lokalt arbeta i samma fil samtidigt och sedan låta systemet hantera sammanfogningen avkoden som skrivits. Git ser även till att tidigare versioner av filerna arkiveras, vid händelse av förloradinformation finns det därmed möjlighet att återfå en tidigare version.

2.2 Kravhantering

Under sprint 0 utformade Team Prego tillsammans med kunden kravspecifikationen, dokumentet sombeskriver hur systemet ska fungera i ett färdigt stadium [3, s. 180]. Denna användes sedan som guide

Figur 2.1: Team Pregos uppskattade tidsplan

för att producera ett system med hänsyn till kundens önskemål. Vidare användes kravspecifikatio-nen till att göra en prioriteringslista, vilken i sin tur användes till att lägga upp arbetet i sprintar ochtasks. Under arbetetsgången användes kravspecifikationen som kontroll då det uppstod frågor angå-ende vissa problem och hur de var tvungna att lösas samt om/eller vissa delar verkligen skulle ingå islutprodukten.

2.3 Testning

I agila projekt är en målsättning att leverera en produkt som är producerad på ett korrekt sätt genomhela produktionsprocessen, snarare än att göra en stor mängd justeringar i slutet. Det uppkommandesystemet ska matcha de affärskrav som satts och således utförs kontinuerliga testkörningar genom he-la processen [8]. Med detta menas till exempel att de som ansvarar för olika delar i systemarkitekturentestar sin kod på en daglig basis. Till skillnad mot traditionellt projektarbete där det ofta utses granska-re som ansvarar helt för testningen, utför alltså istället alla utvecklare testkörningar [8]. Utöver dessaindividuella kontroller är det även rekommenderat att ha större, mer omfattande kontroller. Dessa kanmed fördel ske i slutet av varje sprint eftersom de avsedda uppgifterna i sprinten då beräknas varaklara. I stora team kan det då vara fördelaktigt att organisera testningsprocessen genom att låta någrapersoner ingå i en testgrupp med extra ansvar. Gruppen arbetar tillsammans med produktägare ochutför testningar på hurvida programmet fungerar enligt planering [8]. Under testningsfasen ämnas detge snabb feedback på systemets beteende. Ofta används uttrycket feedback loops, vilket är tidsperio-den från dess att en programmerare skriver en rad kod tills någon kör koden och ger feedback på dessbeteende [8].

När mer omfattande tester utförs kontrolleras ett flertal olika aspekter som bidrar till systemets pro-gramkonstruktion. Det viktiga är att dessa ska uppfylla kundens behov. Exempel på kontroller är ifallanvändargränssnittet uppnår sina krav, eller att olika funktioner inte överskrider en viss väntetid. Åena sidan hinns det kanske inte med lika mycket utveckling i varje sprint vid kontinuerlig testning, åandra sidan besparas den komplexa testfas som kan uppstå i arbete enligt icke-agila principer. Istäl-let erhålls stabil kod vars funktionalitet uppfyller kundens behov redan från starten. Vidare förebyggsäven den problematik som kan uppstå om programmeringsfel uppstår i ett tidigt skede av utvecklingen[8].

Sannolikheten att ett program innehåller någon slags fel är hög. Felen kan vara allt från att användaren

skriver in felaktiga värden i textfält som gör att programmet slutar fungera till att användare kan kom-ma åt material som bör vara lösenordsskyddat. Produkten bör därför testas ofta under utvecklingstidenoch framförallt innan lansering.

Team Prego arbetade enligt testningsmetoder som föreföll naturligt i olika situationer beroende påvilket typ av problem som uppstod. I vissa fall behövdes feedback av övriga gruppmedlemmar förhur en viss funktionalitet skulle struktureras och kodas. I andra fall behövde gruppen styras i rätt rikt-ning gällande planering av användargränssnittslösningar och nödvändig funktionalitet. En god dialogmed kunden var då viktig, vilket skedde både via mail och genom de möten som var schemalagdavarannan vecka. Återkopplingen som gavs internt i gruppen hanterade i synnerhet konsekventa fel.Konsekventa fel är ett samlingsnamn för fel som i synnerhet orsakas av programmeraren. Detta kantill exempel vara syntaxfel, jämförelse av olika datatyper eller fel variabelnamn (algoritmiska fel) [3,s 429]. Algoritmiska fel kunde vara svåra att upptäcka när programmeringsarbetet utfördes på egenhand. Det var då till stor hjälp att låta en annan gruppmedlem utföra en granskning av den del avkoden som var felaktig. Detta på grund av att en utvecklare ofta har svårt att lokalisera fel i sin egenkod. Utöver nämnda former av feedback erhölls även feedback av kursansvarig genom ett semina-rium. Koden hade vid det stadiet blivit något ostrukturerad och behövde dokumenteras noggrannareför vidare produktion och fortsatt vidareutveckling. Beslut togs då att koden skulle struktureras tillobjektorienterat och delas upp i klasser.

För att kringgå uppkomsten av konsekventa fel applicerades i flera fall parprogrammering, vilket in-nebär att två utvecklare programmerar tillsammans på en dator och alternerar. Detta visade sig varamycket fördelaktigt vid påbörjan av nya uppgifter där båda parter var ungefär lika insatta i det aktu-ella området. Denna metod applicerades exempelvis vid utvecklingen av tävlingssidan, omskrivningtill klasser, startlistsgenerering med mera. En fördel med detta var att paret kunde föra en dialog ochpå så sätt komma fram till bra homogena lösningar, snarare än att programmera olika delar var försig. Utan kommunikation med andra utvecklare är det lätt hänt att kodstrukturen blir oenhetlig och attkommunikationsproblem uppstår mellan programvarans olika delar, i synnerhet då en person använ-der sig av något en annan skrivit. Vidare kunde ofta den ena parten utföra efterforskning och kommamed förslag när problem uppstod vilket medförde att båda blev bättre införstådda i koden och arbetetgick ständigt framåt.

Under det tidiga stadiet av projektarbetet arbetade Team Prego enligt traditionella principer där enutvecklare utsågs till att ansvara för kodgranskning och testkörning. Efter ett fåtal veckor var projektetdock för omfattande för att granskas av endast en ansvarig. Varje enskild utvecklare fick då ansvaraför sin egen testning på daglig basis. De dagliga testerna var ej omfattande utan skulle endast vara ettmedel för att få bra översikt och förståelse för koden.

På grund av tidsbrist kom testning och granskning i andra hand under projektets gång. Leverans avresultat till kunden prioriterades framför förbättring och testning av redan skriven kod. Detta med-förde i många fall att ny kod skrevs istället för att återanvända funktioner. Eftersom det var osäkerthuruvida systemet skulle bli färdigt gjordes inga testkörningar på reaktionstider eller försök till attoptimera kod. Det ansågs vara viktigare att komma en bra bit på vägen med att producera en vidare-utvecklingsbar grund.

För att säkerställa att användargränssnittet uppnådde kundens kognitionsmässiga önskemål lät utveck-lingsteamet kunden testa gränssnittet på Tjalves domän. Vidare testade även tävlande att registrera sigtill tävlingar, vilket visade sig fungera utan problem.

2.4 Dokumentation

För att arbeta strukturerat enligt kravspecifikationen är det bra att dokumentera de beslut som tas.Dokumentationen är viktig för att undvika oklarheter och snabbt tillgängliggöra information gällan-de ändringar vilket under agilt arbete ska uppmuntras. Med en tydlig och tillgänglig dokumentationkommer samtliga parter veta dess uppgifter under arbetets gång. Dokumentationen bör vara konkretoch simpel, men tillräckligt informativ för att uppfylla sitt syfte [9]. Det är även viktigt att informatio-nen är dokumenterad på rätt ställe. Det kan till exempel vara lämpligt att föra dokumentation i formav kommentarer direkt i koden snarare än att ha ett åtskilt dokument avsett för att förklara kodensinnebörd. Vid dokumentering är det viktigt att först fundera på ifall dokumentationen är nödvändig.Har den ett syfte? Det kan hända att delar av kod ser snarlika ut, då kan det vara lämpligt att baradokumentera de funktioner som har påtagliga skillnader. Annars kan dokumentationen bli överflödigoch resultera i att dokumentation överlappar varandra, vilket bör undvikas [9].

Precis som testningarna ändrades även principerna för dokumentation fortlöpande under projektet.Till en början dokumenterades kravspecifikation, planeringsdokument och mötesbeslut genom en de-lad mapp på Google Drive. Kravspecifikationen godkändes av kunden och användes sedan med hjälpav en prioriteringslista som mall för planering av olika sprintar.

Det webbaserade systemet Agilefant [5] användes också som hjälpmedel av Team Prego vid tidspla-nering, tidsrapportering samt för att delegera ansvarsområden och uppdatera status på arbetsgången.Agilefant är uppbyggt för att användas i agila projekt vilket hjälpte projektet att följa en agil process.Dock övergick systemet efter drygt halva arbetstiden till att bli en betaltjänst och Team Prego fick bytatill ett annat hjälpmedel. Systemet Trello fick agera efterträdare, dessa två skilde sig emellertid åt ochfunktioner som fanns med i Agilefant saknades i Trello. Detta medförde att rutiner för användandetav systemen tappades vid övergången.

Koden i sig dokumenterades med versionshanteringssystemet Git som gör det möjligt att se utveck-lingen av koden. Varje ny version av filerna som skickas upp till det globala repositoryt, förvarings-platsen, sparas [6]. I versionerna sparas även information om vilken utvecklare som skrivit varje radav koden. Att använda sig av ett versionshanteringssystem för programmeringskod är förmånligt. Medhjälp av ett sådant kan äldre versioner av filer återskapas. Detta underlättar om koden utvecklats fel-aktig och blivit icke funktionellt i något stadium. Det går även att utveckla systemet i olika riktningarom så önskas. Team Prego använde sig av följande rutiner vad gäller Git:

• Varje arbetsdag inleds med att dra ned de senaste ändringarna från det globala repositoryt

• Vid slutförd uppgift skickas de senaste ändringarna upp till det globala repositoryt

• I slutet på varje arbetsdag skickas de senaste ändringarna upp till det globala repositoryt

• Varje ändring som skickas upp till det globala repositoryt kommenteras kort med informationom de ändringar som gjorts

Bristande insikt rörande vikten av väldokumenterad kod medförde försummelse av beskrivande kom-mentarer. I stadiet vid omskrivning till klasser visade det sig dock vara nödvändigt att ha intern doku-mentation då koden blev för komplex och funktionerna svårförståeliga. Detta resulterade i svårigheteratt återanvända kod. För att underlätta utvecklingen är det en god idé att använda intern dokumentationsom tidigt i dokumentet summerar innehållet och ger nödvändig information såsom datastrukturer ochalgoritmer till den som läser koden [3, s. 413]. Team Prego beslutade att intern dokumentation skulleske på följande sätt:

• Överst i filen nämns alla funktioner filen innehåller

• Innan varje funktion beskrivs dess tillämpning samt definition av eventuell indata och utdata.

• Funktioner som inte använder klassens objekt placeras nederst i filen

• Välorganiserad filstruktur

Kapitel 3

Tävlingsadministration

För att bygga upp ett administrationssystem för friidrottstävlingar krävs kunskap både om friidrottoch systemarkitektur. I ett tidigt skede i projektet undersöktes de verktyg som kunden använde idagsläget samt vad som saknades i dessa. Med större insikt i Tjalves tidigare administrativa arbeteoch verktyg hade Team Prego en bättre grund för att kunna skapa ett mer lättförståligt och komplettsystem. Genom att undersöka de tidigare systemen som kunden använt utformades en sammanfattningom hur Pregosystemet bör designas.

3.1 Befintliga system

Kunden använder för närvarande två system för administration av tävlingar; ett för att ta emot an-mälningar och ett under tävlingen. Det förstnämnda är ett lätthanterligt webbaserat system. Dock ärdet avgiftsbelagt och innehåller inte funktioner för att föra in resultat och skapa resultatlistor. Detandra är utvecklat i ett kalkylprogram och innehåller flera av kundens önskade funktioner, men hartill sin nackdel att det är versionskänsligt och tidskrävande. För att få en bättre förståelse för viktenav ett lättanvänt system ordnades ett studiebesök på en friidrottstävling tidigt i utvecklingsprocessen.Vid detta tillfälle fick Team Prego möjlighet att själva agera funktionärer och då uppleva bristerna ibefintliga system.

3.1.1 friidrottsanmalan.se

Det webbaserade systemet friidrottsanmalan.se är det system som kunden använder för att ta emotanmälningar. Arrangörerna skapar i det administrativa gränssnittet en tävling genom att lägga till deklasser och grenar som ska genomföras. Efter att en tävling skapats kan deltagare anmäla sig självapå sidan och systemet skapar utifrån det en startlista som går att exportera.

Systemet har fördelarna att det är flexibelt och lättnavigerat. Nackdelen med systemet är dock att detär avgiftsbelagt, något som är negativt då kunden har en stram ekonomi. Därtill är systemet hellerinte fullständigt i form av de funktioner kunden önskar då det inte går att föra in resultat eller skaparesultatlistor.

11

3.1.2 Wind Athletics

Systemet Wind Athletics är ett system utvecklat i Microsoft Excel. Detta system är omfattande; härkan man skapa en tävling innehållande grenar och klasser, anmäla deltagare samt skapa start- ochresultatlistor. Kunden använder Wind Athletics för införandet av resultat under tävlingar som kom-plement till systemet beskrivet i 3.1.1. De startlistor som skapas och exporteras i systemet friidrotts-anmalan.se importeras till Wind Athletics där sedan resultat förs in under tävlingens gång.

Under studiebesöket på en av kundens tävlingar fick Team Prego arbeta och få insikt i systemet. Viddetta tillfälle upplevde gruppmedlemmarna själva brister i befintliga system.

Figur 3.1: Startsidan för Wind Athletics

Systemet är komplett på det vis att alla funktioner som kunden önskar finns tillgängliga, men nackde-larna är många. Kunden framförde att de upplevt problem med att systemet är versionskänsligt. I ochmed att systemet är utvecklat i ett externt kalkylprogram finns det risk för inkompatibilitet hos syste-met vid eventuella uppdateringar. För att möjliggöra att filerna ska kunna användas problemfritt påalla datorer krävs det att samtliga filer som exporteras från programmet är sparade i samma filformat,något som inte är underförstått för en novis användare.

Något som erfors under studiebesöket var att systemet inte är helt användarvänligt ens för datorvana.Det saknas i vissa fall indikatorer på att ändringar som förväntas ske då en knapp är klickad ge-nomförs. Ett exempel på detta som upplevdes under studiebesöket var efter införande av resultat, dådeltagarna skulle sorteras efter placering. När systemet ombads sortera tabellen uppdaterades dennamed en ny kolumn där placeringen skrevs in, dock var den förväntade ändringen att ordningen påtabellen skulle ändras i fallande ordning. Systemet innehar flera liknande funktioner som lätt förvirraren ny användare.

Figur 3.2: Införande av resultat i Wind Athletics

Under själva tävlingen pågår flera tävlingsgrenar parallellt, vilket även innebär att införandet av resul-tat sker simultant. Resultatlistor fylls i både analogt och digitalt. Dessa sparas efter slutförd tävlings-gren, det analoga på papper och det digitala på ett usb-minne och levereras sedan av en funktionär tillsekretariatet där all data för hela tävlingen sparas.

Både före, under och efter tävlingen krävs ett omfattande arbete i systemet; startlistor ska importeras,avprickningslistor, startlistor och resultatlistor ska skapas. Allt detta görs manuellt och tar i mångafall längre tid än nödvändigt. Arbetstiden för detta skulle kunna förkortas avsevärt genom att låta allafunktioner finnas i ett och samma system. Flödet i systemet är inte optimerat. I och med alla steg sommåste utföras för att slutligen kunna publicera resultatet blir arbetsbördan större än nödvändigt.

3.2 Utformning av Pregosystemet

Att utforma Pregosystemet med alla de funktioner ett tävlingsarrangemang kräver är komplicerat bådemed avseende på systemarkitektur och design. Efter att ha gjort efterforskningar på de system somkunden använt tidigare fick Team Prego en bra bild över vad som kunde förbättras designmässigt.

Ett flertal frågor dök upp då Team Prego diskuterade uppbyggnaden av det nya systemet. Däriblandvilken funktionalitet som bör finnas med samt hur applikationen ska designas för it-noviser. Frågornadelades upp i två olika kategorier: design och användbarhet samt systemarkitektur.

• Design och användbarhetI artikeln Usability 101: Introduction to Usability[10] beskriver Jakob Nielsen fem punkterav vilka han definierar användbarhet; lärbarhet, effektivitet, minnesvärdhet, fel samt tillfreds-ställelse. Med dessa som grund kan man bland annat fundera kring hur väl samt hur enkeltanvändaren utför nya uppgifter och hur tillfredsställande designen är. Team Prego drog följandeslutsatser för att skapa ett så användarvänligt system som möjligt utifrån Nielsens definition:

– Minimalistisk design för att inte förvirra användaren

– Tabeller och strukturer ska ha samma design.

– Systemet bör anpassas för olika enheter såsom datorer, smartphones och surfplattor.

• SystemarkitekturVad gäller systemarkitekturen ansåg teamet att struktur var ett nyckelord och kom fram tillföljande punkter:

– Skapa klasser för de olika tabellerna i databasen för att möjliggöra återanvändning.

– Skapa lager som sköter tilldelade anrop.

– Strukturerade filer sorterade i mappar.

– Konsekvent namngivande av funktioner och variabler.

Kapitel 4

Systemarkitektur

I takt med den tekniska utvecklingen byggs mer och mer komplexa program. Många komponenter skaofta kommunicera och detta gör systemet än mer komplicerat. Webbutveckling utgör inget undantag.Här finns olika delar av systemet som har vitt skilda funktioner. Detta ställer höga krav på en välgenomtänkt arkitektur. En välbyggd arkitektur för ett program bör ta ett antal punkter i beaktning.Viktiga sådana är följande[2, kapitel 3]:

• SkalbarhetDet är önskvärt att skapa en modell som gör det möjligt att bygga vidare på systemet. Utvecklarekan bygga ett urspungligt program med den viktigaste funktionaliteten. När detta fungerar somdet ska kan teamet sedan addera nya funktioner och utöka vad som redan har skapats.

• AbstraktionDelar i arkitekturen som har olika uppgifter bör abstraheras i största möjliga mån. Detta för-enklar framförallt buggsökande. Om en bugg uppstår är det då enklare att åtgärda denna såvidaman vet vilken typ av bugg det rör sig om.

• UtvecklingsbarhetArkitekturen bör vara möjlig att utveckla ifall nya komponenter skulle läggas till.

Om förändringar i arkitekturen sker, bör dessa föranledas av en analys av hur de kommer påverkasystemet [2, kapitel 3].

Systemarkitekturen för Pregosystemet grundades i ett multilagersystem. Något som stod klart i etttidigt stadium var att webbutveckling genererar en stor mängd filer. Det var därför nödvändigt attskapa en tydlig uppdelning av koden i olika mappar och filer genom en så kallad klient-server-modell.I denna modell separerar man de delar av systemet som hanterar serverkomponenter mot de somhanterar klienten och låter dessa kontakta varandra via protokoll[3, s. 263]. Genom att använda dennamodell erhöll systemet en betydligt tydligare struktur.

I det system som tillämpades utgör klienten det översta lagret i systemet, se figur 4.1. Klienten, somförklaras i kapitel 4.1, skickar sedan ett anrop till servern som ligger i ett lager längre ner. För att dettaanrop ska kunna ske utan att sidan laddas om används ett mellanlager. Detta lager består av en AJAX-fil. AJAX tillåter programmet att skicka data i små delar till klienten utan att det syns för användaren.Detta innebär att en hel sida inte behöver läsas in på nytt för att uppdatera innehåll. Istället uppdaterasden del av sidan som faktiskt ska förändras automatiskt när ett objekt kopplat till AJAX ändras [4].När anropet sedan når servern gör denna en begäran till databasen. I systemet finns många situationerdär det krävs att endast ett fält och inte hela sidan uppdateras. För dessa fall implementerades AJAX.

15

Figur 4.1: Diagram för det implementerade multilagersystemet.

Tillsammans med AJAX användes JSON för att spara och översätta den information som hämtatsför att sedan kunna arbeta med denna i JavaScript. JSON är ett plattformsoberoende syntax för attbeskriva och skicka data som enkelt kan förstås av JavaScript[4]. Utöver detta så användes jQuerysom är ett bibliotek i JavaScript för att enklare kunna utföra standardmässiga aktioner på sidan. jQueryinnehåller funktioner som är vanliga att använda på hemsidor[4]. AJAX i kombination med JSONtillåter de olika delarna i systemarkitekturen att kommunicera utan att göra systemet långsamt medlånga laddningstider. De olika delarna som bygger upp sidan förklaras i kapitel 4.1 samt kapitel 4.2.

4.1 Klient

Klienten är benämningen för en enhet som kopplar upp sig mot hemsidan. Exempel på klienter ärdatorer och surfplattor. Det innehåll som visas är till viss del beroende av vad användaren använderför webbläsare och om man har JavaScript aktiverat. JavaScript, som beskrivs i kapitel 4.1.3, stårför en central del av användandet och det är därför ett krav att användaren har det aktiverat. Sidan ärrelativt oberoende av vilken webbläsare som används men problem med viss funktionalitet kan uppståi vissa situationer. Detta har framförallt visat sig när tester har körts med äldre versioner av InternetExplorer.

4.1.1 HTML

För att definiera standarder på sidan såsom header och footer samt visst innehåll som skapas närsidan laddar används HTML. I HTML skapades exempelvis tabeller innehållande information och

rubriker på olika sidor. Detta är till skillnad från innehåll som skapas i JavaScript, beskrivet i kapitel4.1.3, innehåll som inte kan ändras när sidan väl har laddats. Det kräver en omladdning för att dessakomponenter ska förändras.

4.1.2 CSS

För att skapa den visuella stilen på sidan samt ta fram ett gränssnitt som är lättförståeligt för användareanvänds CSS. CSS används för att separat definiera vad en sida ska ha för utseende och design. Allaolika objekt kan definieras upp i olika element på sidan med CSS[4]. Anledningen till att CSS läggs ien separat fil är att all design kan definieras separat och återanvändas. Detta tillät teamet att skapa enstandard för exempelvis hur knappar och tabeller skulle se ut. Fördelen med detta är att sidan fick enmer enhetlig och personlig design.

4.1.3 JavaScript

För att skapa en interaktiv sida med knappar, listor och formulär användes JavaScript tillsammansmed ett fåtal andra verktyg. JavaScript är ett språk som används för att ändra element på webbsidoroch gör det möjligt att skriva funktioner, if-satser samt koppla knappar till händelser för att nämnanågra funktionaliteter[4].

4.2 Server

Serversidan kan sägas vara den del som sköter kopplingen mellan klienten och webbsidan. Här liggerdatabasen som all information hämtas ifrån. Denna är kopplad till det webbhotell som sidan ligger på.

4.2.1 PHP

PHP är det språk som majoriteten av alla projektets filer skrivits i. PHP-kod är nödvändig för attkunna kommunicera med databasen och hämta informationen som man vill ha. För att göra filernabättre ur utvecklingssynpunkt och därmed mer lättförståeliga togs beslutet att jobba objektorienterat.Detta innebar att koden skulle skrivas med hjälp av klasser, vilka skrevs i PHP. Fördelen med att arbetaobjektorienterat är, förutom att göra systemet mer överskådligt och begripligt, att det är möjligt attåteranvända delar i koden då klasserna generaliseras. Klasserna har som uppgift att hämta informationfrån databasen och spara denna i arrayer eller textsträngar. PHP är ett script-språk som agerar påservern och påminner om många andra språk såsom C++ och JAVA[4]. När data som hämtats skaskickas till databasen används JSON och AJAX, för att Javascript ska kunna hantera det som PHPskickar tillbaka. Detta för att Javascript inte är direkt kompatibelt med PHP-kod.

4.2.2 Databas

En databasserver används när ett system kräver att stora lager av data sparas på ett organiserat sättsom senare är enkelt att hämta och ändra inforamtion ifrån[11, Kaptiel.2]. Det finns många olika sättatt bygga upp en databasserver på, men det vanligaste är att programmeringsspråket PHP används

tillsammans med en MySQL-databasserver. Som tidigare beskrivet ligger PHP på serversidan. Däri-från begärs information från databasservern innan denna information skickas till klientsidan. För attenklare kunna skapa och redigera i databasen kan phpMyAdmin[13] användas. Detta gratisverktygunderlättar utförandet av operationer i databasen. I MySQLservern kan det finnas en eller flera ta-beller som innehåller rader och kolumner, enligt figur 4.2. Som det visas i figuren innehåller varjerad ett specifikt id, en så kallad främmande nyckel. Id:t används sedan för att få tillgång till andralänkade tabeller. Ett exempel kan vara följande; en tabell innehåller information angående en tävlingmedan den andra tabellen innehåller de grenar och ålderklasser som en specifik tävling har. För attlänka samman dessa tabeller används ett tävlingsId som främmande nyckel enligt figur 4.3. Önskasinformation om vilka grenar som ska hållas i en tävling kan man med kodraden i figur 4.4 ta reda pådet.

Figur 4.2: En tabell i databasen för en tävling

Figur 4.3: Sambandet mellan tävlingstabellen och disciplintabellen

Figur 4.4: SQL-kod för att få tillgång till information i båda tabellerna med hjälp av länkade tabeller

I Team Pregos fall kommunicerarade systemet med en enda stor databas som behandlade all data.För att kunna hämta från och manipulera databasen användes SQL vilket är ett språk skapat för attkommunicera med databaser. Språket uttrycks så att frågor ställs till databasen som sedan modifierardata eller skickar tillbaka innehåll[4]. Databasen bestod av åtta olika tabeller vilka i sin tur innehöllönskad information. Databasen var en central del av systemet då sidorna huvudsakligen är inriktadpå just datahantering och presentation. De tabeller som skapades innehöll allt från information omtävlingar och grenar, till inrapporterade resultat och deltagarinformation. Dessa hanteras i klassersom skriver till samt hämtar från databasen. De hämtar från tabellerna beroende på vilken klass somrepresenteras. I vardera tabell finns en främmande nyckel som knyter samman tabellen med andratabell. På det viset är det möjligt att nå data från andra tabeller än den som SQL-frågan skickas till.Exempelvis hade systemet en tabell för deltagare och en tabell för vilka grenar dessa deltar i, medhjälp av en främmande nyckel kunde grenar för en viss deltagare hämtas till startlista och resultatlista,endast genom en SQL-fråga.

Kapitel 5

Resultat och analys

Pregosystemets slutresultat är en tävlingsadministrationssida uppdelad i två kategorier; allmänhetsamt administration. Initialt var tanken att ha en inloggningsfunktion för att kunna få åtkomst tillden senare kategorin. Dessvärre räckte inte tiden till för att utveckla denna betydande funktion, vilketnu innebär en säkerhetsrisk i användandet av systemet. Om en användare vet adressen till administ-rationssidorna kan denne skapa och ändra tävlingar, ta bort deltagare samt bekräfta sent anmäldadeltagare. Detta skulle kunna sabotera och kränka både deltagare och arrangörer. I senare versioner ärdet tänkt att denna inloggningsfunktion ska implementeras.

Hemsidan ligger nu på adressen anmalan.tjalve.nu/page, ägd av kunden, på webhotellet Surftown föranvändartest. Dessvärre har det uppstått problem med domänen då anslutningen från databasen ärlångsam och sidan hinner inte uppdateras i den hastighet som den bör. Detta har gett problem dåanvändare tror att deras information inte har lagrats och genomför processen igen. Det till följd attsamma information lagras dubbelt i databasen och behöver tas bort manuellt. För att reda ut orsakentill vad som ligger till grund för problemet har sidan även lagts upp på en domän tillhörande webhotel-let Binero för att testa databasuppkopplingen. Fördröjningen som upptäcktes hos kunden förekommerinte i testet och konklusionen att det är ett problem som ligger hos webhotellet och inte systemet kandras. Detta har påpekats till kund som själv räknas ta beslut till åtgärd.

Ett antal av funktionerna i backloggen har inte slutförts under projekttiden. I utvecklingen har TeamPrego följt den prioritetslista som tagits fram tillsammans med kunden och just nu finns följandefunktioner levererade till hemsidan:

• Administration

– Skapa tävling

– Redigera tävling

– Redigera deltagarinformation

– Sätta/ändra nummerlapp

– Acceptera sena anmälningar

– Faktureringunderlag

• Allmänheten

– Se aktuella tävlingar

– Anmäla deltagare

19

– Kolla startlistor

Dessa funktioner har delats upp i olika sidor som tillsammans kommer att beskrivas fortlöpande. Enav visionerna för hemsidan var att hålla designen minimalistisk och simpel för att it-noviser ska kunnaanvända sidan utan problem. Detta har åsidosatts tills vidare då fokus lagts på att funktionaliteten skallfungera acceptabelt och korrekt.

Databasen är just nu endast designad för att tillfredsställa de funktioner som är klara och är därförinte fullständig. För att kunna uppfylla de behov som senare funktionalitet kräver måste bland annaten genomtänkt tabell för resultat adderas.

5.1 Allmänhetssidor

Allmänhetssidor syftar på de sidor ämnade för alla användare. Dessa kan vara besökare som vill sestartlistor, resultatlistor eller att som kontaktperson vilja anmäla deltagare från sin klubb till tävling-en. Under kategorin allmänhetssidor finns det för tillfället fyra olika vyer att besöka; Indexsidan,anmälning ett och två samt startlistan. Figur 5.1 illustrerar anknytningen mellan alla de sidor allmän-heten kommer åt. Indexsidan, som är startsidan där alla vyer kan nås från, kan besökas via adressen:anmalan.tjavle.nu/page.

Figur 5.1: En graf över hur allmänhetssidorna är sammankopplade

• IndexsidanIndexsidan är den sida man som användare kommer till först. Både kommande och avslutadetävlingar presenteras enligt figur 5.2. För varje tävling finns det tre olika alternativ att välja på;anmäla till tävling, se startlista samt läs resultat.

Figur 5.2: Startsidan för hemsidan

• Registrering 1När användaren valt alternativen ”Anmäl dig här” på indexsidan skickas denne vidare till förstasidan i registeringsfasen, enligt figur 5.3. Vanligtvis vid friidrottstävlingar är det en personper klubb som anmäler alla klubbens deltagare, denne person kallas kontaktperson. I förstasteget i registreringen förs information om kontaktpersonen in. Här väljs även den klubb mananmäler för, finns inte klubben med i listan är det möjligt att lägga till en ny genom att klicka på”Klicka här”. Man skickas då vidare till Lägg till klubb beskriven nedan. Då alla fält är ifylldaklickas ”Fortsätt”-knappen och användaren skickas vidare till nästa steg i registreringsfasen,Registrering 2.

Figur 5.3: Första anmälningssidan

• Registrering 2På denna sida lägger användaren till deltagare till tävlingen. Enligt figur 5.4 ligger formuläretdär användaren skriver in informationen i vänsterspalten medan de anmälda kommer upp ihögerspalten. Vill användaren lägga till mer än en klass för sin deltagare görs detta genomatt klicka på knappen ”Lägg till klass”. När användaren har anmält alla sina deltagare finnsvalmöjligheterna ”Till startlistan”, ”Tillbaka till startsidan” eller att stänga ner sidan.

Figur 5.4: Andra anmälningssidan

• Lägg till klubbFör att lägga till en klubb skriver användaren in namnet på klubben samt, om denne vill, kontakt-uppgifter till klubben enligt figur 5.5. Endast klubbnamnet är obligatoriskt fält. När användarenklickar på ”Lägg till klubb” skickas denne tillbaka till Registrering 1.

Figur 5.5: Lägg till klubb

• StartlistorFrån början visas alla klasser samt discipliner för vald tävling. Enligt figur 5.6 är det möjligt attfiltrera vad som ska visas genom att välja klass och/eller disciplin i de två olika rullgardinsme-nyerna på sidan.

Figur 5.6: Startlistan för en tävling

5.2 Administrationssidor

Under kategorin Administrationssidor finns för tillfället sex olika vyer att besöka; Indexsidan, skapatävling ett och två, ändra deltagare, ändra nummerlapp, acceptera sena anmälningar samt fakture-ring. De sex vyerna är länkade enligt figur 5.7 där indexsidan kan nås via länken anmalan.tjalve.nu/page/pagesAdmin.

Figur 5.7: En graf över hur administrationssidorna är sammankopplade

Som det gick att läsa tidigare i detta kapitel var det tänkt från början att dessa sidor skulle kräva ett

inlogg. Detta har tyvärr ej hunnits med att implementera. Till följd av detta har alla internetanvändareåtkomst till dessa sidor vilket är en stor säkerhetsrisk för ägarna. Nedan kommer de sex olika vyernaatt presenteras med en bild samt en beskrivande text om funktionaliteten:

• IndexsidanPå indexsidan för administratörerna finns det fem olika alternativ att välja på enligt figur 5.8.

Figur 5.8: Startsidan för administratörer

• Skapa tävling 1I första delen av att skapa tävling kommer användaren hit. Här ska grundläggande informationskrivas in av användaren, enligt figur 5.9. Det går även att välja en logotyp för tävlingen här.När användren klickar på ”Fortsätt” skickas denne vidare till Skapa tävling 2.

Figur 5.9: Första sidan för att skapa tävling

• Skapa tävling 2Nästa steg i att skapa tävling där tävlingsgrenarna läggs till för tävlingen. Användaren väljerförst ålderklass i en rullgardinsmeny och därefter skrivs automatiskt alla discipliner som kaningå i denna ålderklass ut i vänsterspalten. Användaren får då bocka för de discipliner som

ska läggas till tävlingen, dessa kommer då upp i högerspalten. Råkar användaren lägga till endisciplin som inte ska vara med är det enkelt att ta bort denna med hjälp av ”Radera”-knappensom syns i figur 5.10. När användaren är klar kan denne gå tillbaka till startsidan genom attklicka på logotypen i sidhuvudet alternativt stänga ned sidan.

Figur 5.10: Sida nummer två för att skapa tävling

• Redigera tävlingPå denna sida går det att ändra allt innehåll i en tävling. Användaren väljer först den tävlingsom ska redigeras i en rullgardinsmeny. Därefter är det möjligt att lägga till discipliner ochklasser på samma sätt som på Skapa tävling-sidan samt ändra datum. Sidan är uppbyggd enligtfigur 5.11

Figur 5.11: Sidan för att ändra tävlingsinformation

• Redigera tävlandeAnvändaren väljer här vilken tävling som deltagare ska redigeras i och därefter vilken deltagare.Här kan sedan discipliner samt information om deltagaren redigeras, enligt figur 5.12

Figur 5.12: Sidan för att ändra deltagarinformation

• Sen anmälanI vänsterspalten väljer användaren vilken tävling den ska godkänna sena anmälningar för. Ihögerspalten finns information över vilken deltagare det gäller samt vilken gren denne villdeltaga i. Användaren kryssar för de deltagare som får delta i tävlingen sen trycka på knappen’Godkänn’, enligt figur 5.13. Dessa deltagare kommer i databasen att få prioritet två vilket ifaktureringsunderlaget kommer att medföra en extra kostnad för deltagaren.

Figur 5.13: Sidan för att acceptera sena anmälningar

• FaktureringI vänsterspalten kan användaren välja för vilken tävling samt vilken klubb som faktureringsun-derlag ska skapas. Dessa val utförs genom att ändra val i rullgardinsmenyerna, enligt figur 5.14.Faktureringsunderlaget visas i högerspalten där varje deltagare presenteras med den disciplindenne har deltagit i samt kostnad. Längst ner finns en totalsumma för föreningen.

Figur 5.14: Sidan för att få ut faktureringsunderlag för klubbar

• Ändra nummerlappDet finns två olika sätt för användaren att ändra nummerlapp på deltagare. Antingen genom atti vänsterspalten välja ett startnummer och klicka ”Uppdatera” vilket kommer att ge deltagarnai högerspalten ett nummer. Detta kan ses i figur 5.15Ex: Startnummer väljs till 10 kommer att ge följande resultat:

– Deltagare 1 får nummerlapp: 10



– ...

Det andra sättet är att användaren skriver in egna nummer i fälten i högerspalten enligt fi-gur 5.15. När användaren är färdig klickas ”Uppdatera” i högerspalen. Det är inte möjligt attge två deltagare samma nummerlapp, detta kollas innan uppdatering av databasen. Skulle tvåanvändare få samma nummerlapp visas istället ett felmeddelande.

Figur 5.15: Sidan för sätta/ändra nummerlapparna för deltagarna

5.3 Databas

Nuvarande databas ser ut enligt ER-diagrammet i figur 5.16. Som det gick att läsa tidigare i dettakapitel är databasen endast försedd med de tabeller som behövs för att tillfredställa de funktionersom finns just nu. Det som saknas för att göra den fullständig är en eller flera tabeller som sköter omresultaten för de olika grenarna.

Figur 5.16: ER-diagram över databasen

Som kan urskiljas ur figur 5.16 är databasen uppbyggd av åtta olika tabeller som alla är länkade tillvarandra. För att förenkla länkarna skapades ett id, så kallad främmande nyckel, för varje tabell somkan användas i de andra tabellerna. Nedan kommer varje tabell beskrivas mer ingående:

• AllYearClassesAlla ålderklasser som är definerade inom friidrottsvärlden finns inlagda i denna tabell. Ett ex-empel på en ålderklass kan vara F12 (Flickor 12år).

• AllDisciplinesI denna tabell definieras alla grenar som går att tävla i definierade. Tabellen är länkad via ”com-petitiondisciplines”. Då namnen på disciplinerna kan innehålla ett mellanslag är det smidigastatt länka via ett id för att undvika eventuella fel som kan uppstå.

• ClubsHär skall alla friidrottsföreningar vara inlagda. Klubbarna läggs till av kontaktpersoner via sidanLägg till klubb när de anmäler till tävlingar.

• ContactFör varje deltagare finns det en kontaktperson. Detta brukar vara kanslisten i en friidrottsföre-ning som anmäler alla deras deltagare. Tabellen är länkad till Competition samt Club

• CompetitionVarje tävling får en egen kolum i denna tabell där all viktig information sparas.

• CompetitionDisciplinesHär definieras vilka grenar som finns med i en specifik tävling. Den innehåller ålderklass samtgren. Tabellen är länkad till Alldisciplines samt Competition

• ParticipantVarje deltagare ligger som en kolumn i denna tabell. Grundläggande information om personensparas som exempel: namn och födelsår. Tabellen är länkad till Contact

• ParticipantDisciplinesFör varje gren som en tävlande är anmäld till blir det i kolumn i denna tabellen. Här sparasinformation om personbästa, säsongsbästa samt om personen är anmäld i tid eller om det ären sen anmälan(viket måste godkännas av arrangören). Tabellen är länkad till Participant samtCompetitiondisciplines

Kapitel 6

Diskussion och framtida arbete

Tiden med Pregosystemet har varit mycket utvecklande där både motgångar och framgångar har stöttspå. Samtidigt som många beslut som tagits varit helt i linje med vad som bör finns det även utrymmeför förbättringar. Bristen på tid och erfarenhet medförde att projektets alla visioner inte uppfylldes,däremot är målet i stort uppfyllt - att införa ett nytt tävlingsadministrationssystem.

Den agila arbetsmetoden var outforskad mark för samtliga teammedlemmar i projektets inledning.Trots det har den upplevts som ett bra verktyg för att kontinuerligt arbeta sig fram till en slutproduktsom både kund och utvecklare är nöjda med. Rutinerna för scrum följdes inte fullt ut under helaprojektet, något som i efterhand kan konstateras att Team Prego kunde ha gjort bättre för att underlättaarbetet och ge en sammanhängande bild av projektets utveckling.

6.1 Arbetsgången

Då ingen i arbetsteamet hade arbetat med webbutveckling innan var det var det svårt att få en hel-hetsbild över hur en större webbsida skulle struktureras upp. Eftersökningar gjordes, dock med fögaresultat. I detta skede hade det varit bra med en mentor/handledare som kunde vägleda oss och finnastill hands för rådgivning. Detta hade sparat mycket tid och systemet kunde ha utvecklats ytterliga-re. Det var inte endast yttre aspekter som gjorde att vi blev ineffektiva i vårt arbete. Till en börjanbestämdes att för varje enskild sida skulle ett UML-diagram skapas samt ett övergripande diagramsom skulle uppdateras för hela webbsidestrukturen. Detta följdes dessvärre inte och skapade i vissafall missförstånd mellan teammedlemmarna. Därtill borde ett övergripade ER-diagram skapats fördatabasen, då det ofta uppstod kompileringsfel när kod sammanfogades via git då olika variabelnamneller strukturen kunde variera mellan teammedlemmarna.

För att strukturera upp arbetet användes som bekant Agilefant till en början. Tjänsten användes dockinte så flitigt, mycket på grund av lathet men även på grund av att tjänsten var krånglig att använda.Tyvärr blev Agilefant efter halva arbetsperioden en betaltjänst vilket teamet inte ville lägga pengar på.Istället började tjänsten Trello användas. Emellertid tappades rutiner vid övergången. Detta beroddedelvis på grund av att systemen hade olika upplägg men även för att tidsplanering och story- ochtaskhanteringen kom i andra hand i denna del av projektutvecklingen.

Till en början kändes sprint 0 lite onödig och tidskrävande, men det har allt efter tidens gång visatsig att det var ett väldigt bra beslut att genomföra denna sprint. Då team Prego har stött på en hel delproblem under arbetets gång så har planeringen och prioriteringen under sprint 0 gjort att teamet ändåkommer kunna leverera en produkt vid slutdatumet. Även om slutprodukten inte kommer vara helt

30

komplett enligt de visioner som definierades i projektets uppstart så kommer den ändå att fungera ochdetta tack vare prioriteringen och planeringen som gjordes i sprint 0.

GitHub var obekant för samtliga utvecklare, emellertid visade det sig vara ett bra hjälpmedel då fi-ler delats flitigt och tidigare versioner har varit lättåtkomliga. Dock har GitHub inte bara underlättatarbetet, utan även medfört problem vid sammanfogning av filer. Det har ofta genererat sammanfog-ningsproblem där information gått förlorad. Detta har gått att åtgärda dock då Gitub sparar gamlaversioner. I det stora hela har Git underlättat filhanteringen inom teamet.

I och med omstruktureringen av sprinterna då det bestämdes att systemet skulle skrivas ur objektori-enteringssynpunkt blev scrumrutinerna försämrade. Tiden det tog för att strukturera om sidorna skildesig markant mellan utvecklarna vilket resulterade i att uppgifter från olika sprinter utfördes parallellt.För att följa scrumprincipen skulle ej slutförda uppgifter ha flyttats till nästkommande sprint så attsprinterna kunde avslutas korrekt. Tanken med vår strategi var att påskynda utvecklingen då vi kändetidspress, men det resulterade i att vi aldrig kom tillbaka till ett korrekt sprintupplägg igen. Ett bättrebeslut hade varit att lägga mer tid på planering och scrummöten. I efterhand är vi alla överrens om atten korrekt användning av scrummetoden hade varit mer fördelaktig under utvecklingen och i självaverket lett till en effektivare utveckling.

Partnergenomgångar användes som bekant till en början i slutskedet av varje sprint, men ansågs bli enalldeles för stor belastning på grund av att endast en person ansvarade för detta. Det kunde ha fungeratbättre om fler än en person hade ansvarat för granskning. Genomgångar hade varit fördelaktigt, isynnerhet efter implementation av Ajax-kod som visade sig vara svår att förstå. Vidare hade ävenkodinspektion kunnat användas som ett verktyg dels för att stabilisera kod, men även för att utökateammedlemmarnas programmeringskunskaper. Detta hade naturligtvis varit på bekostnad av tid.

Systemets arkitektur blev något ostrukturerad och var något som erhölls väldigt sent in i projektet.Avsaknaden av en ursprunglig plan gjorde att arbetet inte gick framåt i samma stadiga takt som detkunde ha gjort. Detta var som tidigare nämnts i rapporten mycket med anledning av att gruppen intehade tillräcklig kunskap inom projektets inriktning. Därför hade en handledare eller nån slags guideför hur ett liknande system byggts upp, kunnat vara till stor hjälp. Detta hade gjort det möjligt förteamet att införskaffa den kunskap som faktiskt behövdes direkt. Om ett liknande projekt kommeratt startas i framtiden, kommer gruppens medlemmar ha en större möjlighet att planera en vettigarkitektur från starten.

6.2 Slutresultat

På grund av tidsbrist har dessvärre viktig funktionalitet åsidosatts, men grundläggande funktionerär implementerade och stommen är uppbyggd för vidareutveckling. Systemet uppfyller för nuvaran-de inte visionerna angående att designen ska vara minimalistisk och anpassad till olika handhållnaenheter.

6.3 Förbättringspunkter

• Öka funktionalitetenImplementera all funktionalitet som kunden önskar. Exempelvis skriva in reslutat och och visaresultat.

• Förbättra säkerheten för indata

För tillfället är det relativt enkelt att göra intrång på sidan och förstöra databasen genom formu-lären.

• Förbättra säkerhetenJust nu finns inget inlogg för att få åtkomst till administrationssidorna. Denna funktion måsteimplementeras snarast.

• Förbättra designenDesignen har legat långt ner i prioritetslistan och denna behövs jobbas på. Användarna skaenkelt förstå funktionerna och hur dessa ska användas. Just nu funkar sidan bra på datorer mednya versioner av webbläsare installerade samt att datorn ska ha Java installerat och aktiverat.Detta vill vi ändra på så att kraven på mobilanpassning fungerar och att sidan ska fungera utanJavaScript.

• Kontinuerliga uppdateringarUnder utvecklingsarbetet kommer det alltid att finnas småbuggar och småfixar som kundenönskar. Detta bör göras direkt när önskemålen eller buggarna inrapporteras.

Kapitel 7

Slutsatser

Pregosystemet i sin nuvarande form innehar flertalet av de funktioner som kunden önskar och på detstora hela är systemet användbart. Den agila metoden har tillåtit att somliga funktioner som önskasav systemet har sparats för senare implementation. Arbetet med systemet har gett en förståelse förhur viktigt det är med en god systemarkitekur tillsammans med en bättre insikt i webutveckling ochscrum.

7.1 Agilt arbete

Den agila metoden har överlag fungerat bra för både kunden och Team Prego. Metoden ställer krav påatt utvecklingsteamet kontinuerligt ska leverera en uppdaterad produkt till varje inplanerat kundmöte.Detta medför att arbetet kontinuerligt har löpt framåt. Metoden har även gett teamet en överblick förhur projektet fortskrider tillsammans med en förväntad arbetsbörda framöver.

Ur kundens perspektiv har möjligheten att återkoppla till utvecklingsteamet och ändra prioritet påkraven varit en viktig del. I och med detta har missförstånd kunnat redas ut och inga onödiga funk-tioner har utvecklats. Kunden har äve fått chanser att komma med nya önskemål till funktionalitet försystemet.

De riktlinjer som Team Prego satte upp i uppstarten av projektet i projektplanen kunde ha följts myc-ket bättre. Detta uppdagades särskilt i ombyggnaden till ett objektorienterat system då både sprintru-tiner och scrummötesrutinerna försummades. Att gå tillbaka och läsa dokumentet hade kunnat ledaarbetet på rätt väg i det skede där teamet hamnade ur rutin. Anvisningarna för sprint- och mötesrutinervar väl formulerade och hade definitivt underlättat i arbetet om de följts.

7.2 Kundkontakt

Inom alla typer av utveckling är kundkontakt viktig för att slutprodukten ska motsvara beställarensförväntningar. Det är nödvändigt att ha en god kontakt och rekommenderat är att visa även skal ochicke färdig programvara. Undgås detta medför det en risk att teamet lägger dyrbar tid på att utvecklakomponenter som inte ska användas eller som rent av går emot kundens förväntningar. Kundkontaktkan sägas vara ett verktyg för att framställa bästa möjliga produkt och även ett hjälpmedel för attutvecklarna ska arbeta så effektivt som möjligt med rätt inriktning. I projektet hade teamet en konti-nuerlig kontakt med sin kund, vilket ledde till att teamet hela tiden kunde få feedback på produkten

33

och även snabbt göra ändringar. Hur frekventa möten som krävs beror förstås på hur utvecklingen serut och hur lång tid en sprint tar men Team Prego fann att det fungerade bra att ha möten i slutet avvarje sprint.

7.3 Systemarkitektur

För att arbetet ska komma igång snabbt med en stadig progression bör en systemarkitektur tas frami ett tidigt skede. Denna ska enligt den agila läran vara möjlig att förändra under projektets gång. Justörre insikt i det område utvecklingen sker inom, desto mer komplett kan den ursprungliga arkitek-turen vara. Något som är viktigt att tänka på i skapandet av arkitekturen är att den bör vara tydlig ochha som syfte att väva samman de olika delarna i systemet på ett enkelt sätt. Agila metoder förenklaroch lättar på kraven på den ursprungliga arkitekturen. I Team Pregos fall var det essentiellt att kunnaförändra arkitekturen efter hand eftersom insikt och kunskap i ämnet saknades.

Arbetet med Pregosystemet har givit samtliga utvecklare i teamet avsevärt större kunskaper inomområdet webbutveckling, detta kommer att underlätta arbetet i eventuella framtida projekt. Frågorsom tidigt, och kanske flera gånger, bör ställas i ett projekt är vilket språk systemet ska utvecklas ide möjligheter och begränsningar som de ger. Det kan vara värt att ha i åtanke att för mycket tid inteska läggas på arkitekturen om utvecklarna inte är väl invigda i hur utvecklingen för ett sådant projektbrukar fortgå. Med detta sagt så kan det konstateras att utvecklingen för Pregosystemet med säkerhethade gått betydligt snabbare framåt, om teamet hade haft en tydlig plan för hur systemet skulle habyggas upp från början.

7.4 Testning

För att erhålla en buggfri och bättre fungerande kod skulle testning utförts mer kontinuerligt. Ettstabilt system utvinns allt som oftast genom organiserade testkörningar både på kod och användar-gränssnitt. Ambitionerna för testning var inledningsvis höga, men uppnåddes inte då formulering avmånga funktioner tog tid. Detta medförde att det inte var angeläget att utföra testning av funktio-ner som inte var fullständiga. Beslutet att utveckla ett objektorienterat system bidrog också till atttestningen mer eller mindre uteblev på grund av att det var en tidskrävande process.

Det uppdagades i slutskedet av projektet då systemet lades ut publikt för testning att kopplingenmellan databas och klient stundom var bristfällig. Teamet såg allvarligt på detta och utförde ögon-blickligen tester för detta. Orsaken visade sig inte ligga hos systemet utan hos webbhotellet kundenhar sin sida hos. Laddtider är något som är viktigt att testa då det är något som kan försämra använ-darupplevelsen och medföra att användare inte återkommer.

7.5 Design

Vad gäller designen av systemet var det viktigt för kunden att ha det anpassat för it-noviser. Det villsäga att det ska vara intuitivt i användandet och med möjlighet att få guidning av systemet med vadsom ska utföras vid behov. För att försäkra sig om detta hade teamet kunnat utföra tester externt påanvändare för att bekräfta huruvida systemet var användarvänligt eller ej. Att utföra sådana tester ärkostsamt, men hade gett en bra bild över vad som saknas i gränssnittet och vad användare förväntarsig av systemet.

Team Prego valde att från grunden designa det grafiska gränssnittet. Detta var en relativt lågprioriteradpunkt som planerades utföras på allvar i slutskedet av projektet och endast arbetades lätt med undertidigare sprintar. På grund av tidsbrist hanns den stora design-sprinten ej med. En god idé hade varitatt använda sig av grafiska ramverk som hjälp. Med hjälp av dessa hade det gått snabbare och enklareatt ändra designattiraljer.

7.6 Dokumentation

En strukturerad dokumentation gör det enklare för samtliga teammedlemmar att ta del av beslut ochfölja dem. Vidare blir det enklare att prioritera i vilken ordning olika funktionalitet bör produceras,vilket i sin tur underlättar i planeringsarbetet. En väldokumenterad kod leder till att samtliga teamme-dlemmar kan förstå vad som händer och således även återanvända funktioner. Väldokumenterad kodunderlättar även vid vidareutveckling av systemet, ifall produkten inte skulle bli klar i tid, då det germöjlighet att enklare sätta sig in i tidigare skriven kod.

De dokumentationsriktlinjer som definierades i projektplanen följdes väl vad gäller versionshante-ringssystemet och skriftliga dokument såsom kravspecifikationen. Däremot var det bristfälligt preci-serat för kodfilerna, något som upptäcktes en bit in i projektet. I och med uppdagandet formuleradesdessa riktlinjer och förståelsen för koden förbättrades. Att göra detta tidigare är att föredra och enlärdom till kommande projekt.

Litteraturförteckning

[1] Brian Miller, Above the Fold: Understanding the Principles of Successful Web Site Design, HOW2011

[2] Donald G. Firesmith med Peter Capell, Dietrich Falkenthal, Charles B. Hammons, DeWitt Lati-mer och Tom Merendino, The Method Framework for Engineering System Architectures, Auer-bach Publications 2009

[3] Shari Lawrence Pfleeger och Joanne M. Atlee, Software Engineering, Fourth Edition, Internatio-nal Edition, Pearson 2010

[4] w3schools (online) http://www.w3schools.com/

[5] agilefant (online) http://agilefant.com [2014-05-13]

[6] Git (online) http://git-scm.com/ [2014-05-13]

[7] GitHub (online) http://github.com [2014-05-13]

[8] Hendrickson, E. (2008) Agile Testing – Nine Principles and Six Concrete Practices for Testingon Agile teams http://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf[2014-06-14]

[9] Ambler, W.S (2008). Best Practices for Agile/Lean Documentation.http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm [2014-06-14]

[10] Jakob Nielsen. 2012. Usability 101 - Introduction to usability. 4 januari. Nielsen Norman Grouphttp://www.nngroup.com/articles/usability-101-introduction-to-usability/ [2014-04-20]

[11] Kevin Yank, Build Your Own Database-Driven Website Using PHP And MySQL, 4th Edition,SitePoint 2009

[12] Ken Schwaber och Jeff Sutherland. Den definitiva guiden till Scrum: Spelets regler. Ju-li 2013. Scrum.org https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-SE.pdf#zoom=100 [2014-02-17]

[13] phpMyAdmin (online) http://www.phpmyadmin.net/home_page/index.php [2014-06-14]

36

Bilaga A

Bilaga

Kund

• Anna Palmerius

Examinator

• Karljohan Lundin Palmerius

Utvecklingsteam

• Sebastian AlfredssonHuvudansvar: DesignStatistik på Github:

– Antal commits: 23

– Antal tillagda rader: 2,354

– Antal borttaga rader: 1,088

Vilka avslutade punkter i backloggen:

– Som admin vill jag kunna skapa tävling

– Som admin vill jag ha en startsida

– Som kund vill jag ha ett utvecklingsbart system med klasser

– Design av systemet

• Emma EdvardssonHuvudansvar: Projektrapport samt kravspecifikationStatistik på Github:



– Antal borttaga rader: 865


37

– Som admin vill jag kunna redigera anmälan


– Som besökare vill jag kunna anmäla till tävling

– Projektplan

– Kravspecifikation

• Tobias ErlandssonHuvudansvar: PhotoshopsStatistik på Github:





– Som admin vill jag kunna skapa tävling

– Som admin vill jag ha en startsida


– Design av systemet

• Gustav HallströmHuvudansvar: KodgranskningStatistik på Github:



– Antal borttaga rader: 1,843


– Som admin vill jag kunna redigera tävling

– Som besökare vill jag kunna kolla resultat

– Som admin vill jag kunna publicera slutgiltiga resultat (?)


• Hannes IngelhagHuvudansvar: ProjektledareStatistik på Github:


– Antal tillagda rader: 16,105 (ett bibliotek har lagts till = 8,759)

– Antal borttaga rader: 14,846 (ett bibliotek har tagits bort = 8,759)

Vilka avslutade punkter i backloggen har avslutats:

– Som besökare vill jag komma till en startsida

– Som besökare vill jag kunna anmäla till tävling

– Som primär admin vill jag kunna sätta startnummer på alla deltagare

– Som besökare vill jag kunna kolla startlista

– Som primär admin vill jag kunna hämta faktureringsunderlag

– Som primär admin vill jag kunna godkänna efteranmälan


• Therese RambölHuvudansvar: DatabaserStatistik på Github:


– Antal tillagda rader: 137


Vilka avslutade punkter inom backloggen:

– Som admin vill jag kunna skapa avprickningslistor


– Projektplan

– Kravspecifikation

Alla medlemmar har haft liknande arbetsuppgifter under hela processen. Från början var det meruppstrukturerat vilka som gjorde vad men ju längre in i processen flöt arbetsuppgifterna samman,detta på både gott och ont.

Statistiken gör sig inte rättvis i och med att parprogrammering i många fall tillämpades. I detta fallvar det enbart den ena parten som skickade koden till GitHub.