I detta kapitel diskuteras olika synvinklar på resultatet och mer specifikt vad som kunde ha hanterats annorlunda. Det diskuteras även om projektets vidareutveckling, vilka lärdomar som tagits med till projektet och slutligen vilka lärdomar som tas med från projektet.
6.1.1
Alternativa implementationssätt
Systemet innehåller ett flertal funktioner som är svåra att implementera i SQL. En stor ut- maning var att hämta en hel tävling från databasen eftersom en tävling består av en tabell som har relationer till andra tabeller. De mest komplexa relationerna som en tävling har är till tabellerna tävlingssidor och lag eftersom de i sig också har relationer till andra tabeller. Det blir ett rekursivt problem vilket är svårt att implementera väl i SQL. Det kräver mer avancerade SQL-frågor (eng. query) som join och subqueries för att lösa det rekursiva proble- met. Ett alternativ till SQL är NoSQL, vilket är ett uttryck för databasmodeller där data inte lagras i relationstabeller vilket är hur SQL fungerar. Ett exempel på ett NoSQL-verktyg är MongoDB. Fördelen med att använda en NoSQL-databas är att det går enkelt att spara, re- digera och hämta hela JSON-dokument. Vi gjorde valet med SQL över NoSQL eftersom SQL har en strikt struktur. Till en början blev det svårare med SQL då den strikta strukturen måste skapas och därefter följas. Över tiden underlättades utvecklingen då det blir enkelt att sätta sig in i databasen eftersom den är väl strukturerad. Utöver det finns verktyget SQLAlchemy som underlättar SQL-utveckling i Python.
Det skulle ha underlättat om projektet använde sig av ett enda programspråk istället för två. På frontend är valen begränsade till Javascript och andra relaterade språk som till ex- empel TypeScript, men på backend är det ett helt fritt val av programspråk. Då klienten är implementerad i TypeScript hade en alternativ lösning varit att implementera backend i Ty- peScript. Det skulle ge en homogen struktur över hela projektet och underlätta utvecklings- processen då projektets kod skulle bestå av enbart ett programspråk. I slutändan togs beslutet att frontend och backend ska vara två separata enheter och därmed inte dela någon kod. All kommunikation mellan frontend och backend sker genom ett API och därför har det ingen
6.1. Resultat
större betydelse att de två delarna använder olika programspråk. Att implementera backend och frontend i olika programspråk tvingar även fram den valda strukturen om att inte de- la någon kod mellan delarna. Den avgörande faktorn till varför Python valdes var att alla i gruppen hade goda förkunskaper från tidigare kurser.
Ett alternativ till React är Angular. Huruvida man väljer att använda React över Angular eller tvärtom har ingen större betydelse då båda ramverken har den funktionalitet som krävs för att lösa samma problem. De små skillnaderna mellan React och Angular skulle inte ha påverkat vårt resultat. Eftersom gruppen hade mer kunskap om React än Angular blev valet självklart React.
6.1.2
Återstående arbete
Projektgruppen har hunnit implementera mycket av den funktionalitet som kunden önskade. Det återstår däremot lite arbete innan kunden kan få fullt värde av systemet.
För att kunna använda systemet krävs det först och främst att kunden litar på att det är tillräckligt stabilt så att det inte slutar fungera mitt under en pågående tävling. Från gruppens sida uppnås det med hjälp av automatiska tester på både frontend och backend och integra- tionstester som testar hela systemet. Från kundens sida kommer det även att kräva mycket användartestning för att se till att systemet är lättanvänt och robust. Innan kunden övertygat sig själva om att det är tillräckligt stabilt, säkert och robust kommer de inte att vilja använda systemet.
Systemet saknar också viss funktionalitet som skulle behövas. Bland annat kan inte alla olika efterfrågade frågetyper läggas in vilket gör att kunden potentiellt inte kan använda pro- dukten om några av dessa skulle krävas för en viss tävling. Den prioriteringen gjordes för att få klart all kärnfunktionalitet i systemet. Nu när dessa är på plats kommer det att gå relativt enkelt att lägga till nya frågetyper. Sedan saknas även lite extra funktionalitet som skulle öka användbarheten och göra produkten bättre. Dessa är att kunna automaträtta frågor, som till exempel flervalsfrågor, för att avlasta domarna. Statistik hade varit användbart för att i efter- hand enklare kunna bedöma svårighetsgraden på frågor och tävlingar. Bilder kan läggas in i tävlingar men det bör även gå att lägga in videor och ljud. Att hantera ljud hade avlastat ännu en person då det oftast finns en på plats på en tävling som sköter uppspelning av ljud, men genom att bygga in det direkt i systemet hade operatören kunnat sköta det.
Kundens plan har alltid varit att fortsätta utvecklingen av systemet efter oss. För att un- derlätta detta har gruppen skapat en kort manual som beskriver hur systemet är uppbyggt, hur man använder det och hur det utvecklades. Detta kommer förhoppningsvis att ge ett bra underlag för nästa grupp som kommer ta över projektet. Detta prioriterades eftersom det saknades från den tidigare studentgruppen vilket tvingade gruppen till att börja om från början, och både gruppen och kunden vill ogärna att det händer igen.
6.1.3
Förbättringar från tidigare projekt
Innan projektet började skulle varje gruppmedlem fundera över saker som kunde ha förbätt- rats i deras tidigare projekt. Vid projektets slut diskuterades sedan dessa områden igen, och vi kunde identifiera ett antal saker som vi har gjort bättre i detta projekt jämfört med tidigare. Medlemmarna hade utfört olika projekt och hade därför olika erfarenheter, så vissa personer hade redan utfört några av dessa områden på ett bra sätt i andra projekt. Därför kan dessa områden inte betraktas som förbättringar för varje enskild individ, utan för gruppen som helhet.
6.1.3.1 Möten
Flera i gruppen påpekade att möten hade fungerat bättre i det här projektet. Tidigare projekt hade inte alltid haft regelbundna möten, och de hade inte alltid varit givande. Nu har vi
6.1. Resultat
haft regelbundna möten varje vecka som vi har tyckt att vi har fått ut mycket av. Scrum- mötena har varit särskilt givande. Under mötena har vi gått igenom vad alla har gjort och planerat för veckan tillsammans. Vi har även haft ett möte med gruppens handledare varje vecka vilket har varit bra för att hålla handledaren informerad om arbetets gång och för att fånga upp eventuella problem tidigt. I tidigare projekt hade inte en så hög mötesfrekvens hållits. Ytterligare en förbättring vi har gjort är att alltid boka in nästa handledarmöte som sista punkt på dagordningen, något vi tog till oss efter en kommentar från vår handledare. Vi har även hållit oss till dessa planerade handledarmöten och inte kallat till möten med kort varsel eller utanför ordinarie arbetstid, något som förekom i tidigare projekt.
6.1.3.2 Roller
En gemensam erfarenhet var att grupproller inte hade utnyttjats till fullo i tidigare projekt. I detta område såg vi ett blandat resultat, där vissa medlemmar ansåg att deras roll hade an- vänts mer än tidigare medan andra inte såg någon stor skillnad. En annan skillnad mot tidi- gare projekt var att viss omfördelning av ansvar skedde nära projektets slut. Gruppmedlem- men som hade rollen som arkitekt fick då även ansvar över kodkommenteringen, eftersom arkitekturen var färdigställd och inte behövde mer arbete. Någon sådan omfördelning av rollansvar hade inte gjorts i tidigare projekt.
6.1.3.3 Testning
Detta projekt hade mer omfattande testning än tidigare projekt hade haft. Redan i kvalitets- planen sattes mål för kodtäckning av testerna. Kontinuerligt under projektet har tester skri- vits och förts in i testsviten för att uppfylla dessa mål. Testerna har använts dels lokalt av utvecklarna för att utvärdera sin kod, och dels i en automatiserad CI/CD-pipeline som körs på GitLab varje gång en utvecklare försöker lägga till ny kod projektets huvudgren, för att hu- vudgrenen alltid ska vara körbar. I tidigare projekt hade knappt någon strukturerad testning gjorts alls, så detta var en stor förbättring.
6.1.4
Viktigaste lärdomarna inför framtiden
I början av projektet bokade vi in kundmöten med relativt långa mellanrum, mellan tre och fem veckor. Ungefär halvvägs in projektet föreslog kunden att hålla regelbundna möten med två veckors mellanrum. Detta bidrog till regelbundna diskussioner om projektets alla aspek- ter. Det visade sig vara en bra idé eftersom det är lätt att se många saker på olika sätt. I framtida projekt kan det därför vara fördelaktigt att boka in regelbundna kundmöten från projektets start.
Eftersom projektet även utfördes föregående år kunde vi använda de lärdomar som förra gruppen delat med sig av. Vi gjordes medvetna om att projektet är sådant att mycket funktio- nalitet kan efterfrågas. Med hänsyn till detta kunde vi i ett tidigt stadie sätta ramar om vad som är rimligt och vilka förväntningar kunden kunde tänkas ha. Under projektets förlopp är det dock viktigt att ta i beaktande att saker och ting kan komma att förändras. I vårt fall omprioriterades kraven för att projektet skulle ha en rimligare målbild i förhållande till den tidsram vi befann oss i. Detta kunde som sagt göras tidigt tack vare den föregående gruppens lärdomar.
Med grundliga förberedelser kan det bli en snabb övergång till att komma igång med pro- grammeringen. Vi identifierade att övergången mellan planeringsfasen och utvecklingsfasen skulle bromsa projektet eftersom det kan ta tid för alla gruppmedlemmar att komma igång med projektets konfiguration. Detta löste vi genom att några gruppmedlemmar började ti- digt med att etablera utvecklingsmiljöerna och standarderna för versionshanteringen. Detta gjorde det lätt för resterande medlemmar, av vilka några hade mindre erfarenhet av webb- utveckling, att komma igång med utvecklingen. Även tydliga instruktioner dokumenterades