dokument behövde färdigställas och lämnas in. Vid dessa övergångar varierade engage- manget av samtliga gruppmedlemmar då de hade olika ansvarsområden. Vid de senare in- lämningarna behövde handledaren styra upp gruppens struktur gällande dokumentations- skrivning. Totalt sett har alla gruppmedlemmar deltagit i dokumentskrivandet och det blev det få skrivningskonflikter. LaTeX som textredigeringsverktyg har fungerat utmärkt tillsam- mans med versionshanteringsverktyget Git i och med att dokumenten består av ren text. Granskningen och inspektionen av dokumenten har fördelats på ett rättvist sätt.
6.2
Resultat
I detta stycke ges en djupare inblick i vilka bakomliggande orsaker som bidrog till att pro- jektet resulterade i de resultat som presenterades (se rubrik 5). Det presenteras även vad som bidrog till att vissa delar av implementationen av projektet inte färdigställdes. Slutli- gen resoneras kring de erfarenheter som gruppen har haft under projektets gång och då i utsträckningen även vad som kan läras från projektet.
6.2.1
Systemanatomi
Den ursprungliga systemanatomin byggdes tidigt under projektets gång. Trots att det bland gruppmedlemmarna fanns viss kunskap om den valda samlingen av mjukvara saknades dju- pare kunskap om arkitektoniska praxis för de olika miljöerna. Detta ledde till att vissa mindre ändringar behövde göras i anatomins utformning.
Trots detta var en systemanatomi ur många aspekter väldigt användbart. Främst då denna gav en god översikt över beroenden mellan projektets komponenter. Utifrån denna översikt kunde kritiska komponenter prioriteras.
6.2.2
Vyn
Efter att problemen med alfa-vyn identifierats bestämdes att vyn skulle utvecklas mot en simplare modell. Informationen flyttades från en separat sida till att visas direkt på förstasi- dan. För de mobila plattformarna representerades komponenterna utan informationen, den- na blev istället tillgänglig då användaren trycker på komponenten genom att komponenten expanderade nedåt. För de stationära plattformarna visades informationen istället direkt i komponenten, utan att användaren behövde trycka på den. På detta sätt utnyttjades de sta- tionära plattformarnas stora skärmyta samtidigt som mobilplattformarna får en översiktlig vy anpassad för den begränsade skärmyta dessa plattformar har. Gruppen behövde därmed inte utveckla separata vyer för de respektive plattformarna.
Efter återkoppling från kund återgick vyn till att återigen ha en visuellt separat sida för var- je evenemang användaren väljer att läsa mer om. Konceptet vidareutvecklades dock så att överskådlig information om respektive evenemang presenterades på första sidan, så som evenemangsbilden, datum och evenemangets namn. Efter flera iterationer var gruppen nöjd med vyns utseende och funktionalitet.
6.2.3
Systemets funktionalitet
Denna rubrik innehåller en diskussion kring omständigheterna kring varför vissa delar ej blev klara enligt de presenterade resultatet (se rubrik 5).
Avsaknad funktionalitet
Huvudanledningen till att inloggningen inte blivit klar var att säkerhetsaspekterna vid au- tentisering var relativt avancerade och gruppens kunskap inom området begränsad. Utöver detta låg fokus hos gruppen på att få in så mycket grundläggande funktionalitet som möjligt i applikationen snarare än att spendera tid på att färdigställa denna del specifikt.
Det finns primärt två anledningar till att klarna inte blev färdigt. För det första valde pro- jektgruppen att lägga ansvaret för implementationen av Klarna på en enda projektmedlem. För det andra valde projektgruppen att prioritera bort klarna när resurserna började ta slut. Detta val gjordes eftersom projektet som helhet inte är bundet till klarna och tillägg av klar- na eller annan betaltjänst relativt enkelt kan göras i efterhand. Att lägga hela ansvaret för en kritisk del av systemet hos en utvecklare var, i efterhand, ett dumt beslut. Hade man tillsatt ytterligare resurser till denna uppgift hade den troligen slutförts. Dock så hade man behövt prioritera ner en annan del av systemet vilket möjligen hade resulterat i att någonting annat inte blivit klart. Gruppen bedömde att denna del var relativt simpel att implementera, man insåg dock inte att detta var felaktigt förens mycket sent under utvecklingsfasen.
När det gäller användargrupper var en av orsakerna till att det inte slutfördes att gruppen in- te fick den respons de väntat sig från LiU-IT gällande hämtning av information om sektions- och kårtillhörighet. Implementationen av intresseanmälansfunktionaliteten påbörjades men blev inte färdigställt i tid.
Den största anledningen till att kön inte blev färdig var att projektgruppen påbörjade arbetet med denna del under slutet av utvecklingsfasen. Detta resulterade i att tiden inte blev till- räcklig för att slutföra denna del av systemet. En anledning till att arbetet på kön sköts fram var att Klarna inte blev färdigt inom den tänkta tidsramen. Gruppen upplevde att det inte var någon ide att implementera kön förens Klarna fungerade eftersom de som köade annars inte skulle kunna betala i slutet av kön.
6.2.4
Värde för kund
Efter initial kommunikation med kund förhandlades en kravspecifikation fram utgående från kundens behov. Kundens initiala krav förhandlades ner till en mer rimlig nivå givet projekt- gruppens resurser och projektets omfattning. Efter detta påbörjades utvecklingen av systemet som mot slutet av projektet uppfyllde alla grundkrav i kravspecifikationen.
Kunden gjorde det klart att denne prioriterade ett stabilt och fungerande system före ett halv- fungerande system med mycket funktionalitet. Väldokumenterad kod var även av stor vikt då kunden hade för avsikt att vidareutveckla systemet efter projektets avslut. Gruppen fo- kuserade därför på att utveckla färre men fullt fungerade funktioner för applikationen vilket troligen är en anledning till att en del funktionalitet saknades vid projektets slut. Gruppen lade även stort fokus på att bli av med så många buggar som möjligt innan leverans. Genom att göra dessa prioriteringar skapade gruppen därmed värde för kund då ett system med kompletta delsystem kunde levereras vilket underlättar för kund vid vidareutveckling.
6.2.5
Gemensamma erfarenheter
De gemensamma erfarenheter som resulterade av projektet visar på vissa intressanta aspek- ter kring hur projektgruppen fungerade. Att detta projekt var bland de största projekt grupp- medlemmarna har genomfört innebar att många av erfarenheterna kommer ifrån denna oer- farenhet kring att arbeta i större projekt. Problemet som uppstod i projektet när endast en