5.4
Översikt över individuella bidrag
Denna del ger en kort översikt över de individuella bidragen i rapporten.
5.4.1
Balans mellan olika testnivåer vid agil systemutveckling av Andreas
Lundquist
Detta bidrag reflekterar över balansen mellan olika testnivåer vid agil systemutveckling och specifikt hur balansen sett ut under detta projekt. Detta för att sedan undersöka potentiella förbättringsmöjligheter och diskutera dessa tillsammans med de erfarenheter som samlades under projektets gång.
5.4.2
Kundinverkan vid agil mjukvaruutveckling av Daniel Herzegh
Detta bidrag undersöker hur de tekniker och strategier som förespråkas av utvecklingsram- verket Scrum kan användas för att producera en slutprodukt som är i linje med kundens förväntningar. Bidraget redovisar detta genom att jämföra det projektarbete som har utförts av projektgruppen med en litterär studie utförd av bidragets författare.
5.4.3
Sårbarhet för Cross site scripting (XSS) i en webbapplikation av David
Hasselquist
Detta bidrag undersöker vilka kategorier av XSS-attacker en webbapplikation kan utsättas för och vad som är utmärkande för dessa kategorier. Därefter ämnar studien sig åt att studera de grundläggande metoder och åtgärder som finns för att skydda sig mot XSS-attacker. Bi- draget redogör även hur webbapplikationen SecTrack kan skyddas genom att tillämpa dessa metoder.
5.4.4
Sårbarhet mot SQL-injektioner i en webbapplikation av Jennifer Lindgren
Detta bidrag undersöker vad som gör en webbapplikation sårbar mot SQL-injektioner och vad utvecklare kan göra för att minska risken för att en webbapplikation utsätts för dem. Bidraget redogör även för eventuella säkerhetsbrister i SecTrack.
5.4.5
Implementation av kontinuerlig leverans av Johan Lind
Detta bidrag undersöker hur processen kontinuerlig leverans kan användas vid utveckling av ett interaktivt system. Bidraget redogör även för vilka delar av teorin om kontinuerlig leverans som saknas från utvecklingsprocessen bakom SecTrack.
5.4.6
Arbetsmiljöers påverkan på grupparbeten av Niklas Nilsson
Detta bidrag undersöker vilken påverkan arbetsmiljöer kan ha på det egna arbetet samt hur en grupp arbetar tillsammans med en gemensam uppgift. Bidraget kommer även att under- söka hur olika saker i arbetsmiljöer kan göra arbetetet lättare eller svårare.
5.4.7
Vikten av kodstandarder och effektiv kod av Philip Bengtsson
Detta bidrag undersöker hur en kodstandard påverkar effektiviteten vid programvaruut- veckling och hur den påverkar underhållbarheten hos programvaran. Dessutom undersöker bidraget vad som påverkar energiförbrukningen hos programvaror.
6
Diskussion
I det här kapitlet diskuteras projektets resultat samt metoder som använts. Dessutom disku- teras hållbar utveckling med avseende på miljöpåverkan, etik och social inverkan.
6.1
Resultat
I den här delen av kapitlet diskuteras alternativa val av ramverk och implementationssätt samt vilket arbete som kvarstår för att kunden ska få ut fullt värde av produkten. Till sist diskuteras vilka egenskaper som har utvecklats sedan tidigare projekt samt vilka lärdomar som kan tas med inför framtiden.
6.1.1
Alternativa implementationssätt
Här tas alternativa implementationssätt som projektgruppen övervägde upp. Dessa inklude- rar alternativa ramverk för front-end och back-end samt val av databasmjukvara.
Front-end ramverk
När ramverk för front-end skulle väljas var det två som övervägdes, React och Angular. Det som gjorde att Angular slutligen valdes över React var att en projektmedlem hade tidiga- re erfarenhet av webbutveckling i Angular medan ingen tidigare erfarenhet av React fanns bland projektmedlemmarna. Ytterligare en anledning till att Angular valdes var att front-end då blir modulär.
Ett alternativ till att använda färdiga komponenter från Bootstrap och Material Design for Angular hade varit att utveckla egna komponenter. Att använda färdiga komponenter var enkelt och sparade tid jämfört med att utveckla egna, det uppstod heller aldrig något behov av någon komponent som inte fanns i varken Bootstraps eller Angulars utbud av komponen- ter. Därför valde gruppen att enbart använda färdiga komponenter i applikationen.
Back-end ramverk
Några exempel på ramverk för back-end-utveckling i en webbapplikation är:
• NodeJS som skrivs i JavaScript eller TypeScript [16, 25]. • Play Framework som skrivs i Java eller Scala [26]. • Django som skrivs i Python [27].
6.1. Resultat
När det hade beslutats att Angular skulle användas som ramverk för front-end resonera- de projektmedlemmarna att ett ramverk som också kan skrivas i TypeScript vore passande för back-end. Då skulle all kod i projektet vara skriven i TypeScript vilket skulle underlätta kodskrivning och kodgranskning. Det enda alternativet som övervägdes då var NodeJS som också valdes.
Databasmjukvara
Ett av kundens krav var att databasmjukvaran skulle ha öppen källkod. Kunden föreslog att vi skulle använda MariaDB som är en känd databasmjukvara som används av stora företag som Google, Wikipedia och Facebook [28]. Alternativ mjukvara som hade kunnat användas var till exempel MySQL. MySQL ägs av företaget Oracle och har i grunden öppen källkod. Dock drivs utvecklingen inte längre av engagerade utvecklare, vilket annars brukar känne- teckna mjukvara med öppen källkod, utan av Oracle själva. I slutändan vägde kundens re- kommendation tyngst. MariaDB är utvecklat av samma personer som utvecklade MySQL och har samma grundfunktionalitet. Säkerhet är dessutom MariaDBs utvecklares främsta priori- tet.
6.1.2
Kvarstående arbete
För att kunden skall få ut fullt värde av produkten återstår att ersätta testdatan i databasen med verklig data. Ett sätt att göra detta är att manuellt lägga till alla kort, handlingar och le- veranser som behöver finnas i databasen. Alla användare, inklusive administratörer, som ska använda applikationen behöver konton för att kunna logga in. Eventuellt kommer kunden att använda sig av en befintlig databas över användare genom att integrera den med SecTrack.
6.1.3
Utveckling sedan tidigare projekt
Vikten av god kommunikation i ett projekt är någonting som togs upp ur flera aspekter i kapitel 2.4 om tidigare erfarenheter. Dålig kommunikation kan både leda till dubbelarbete och till att uppgifter inte blir gjorda. Kommunikationen är dock något som fungerade väldigt bra genom hela projektet. Anledningen till det är att gruppen lade stor vikt vid att allas åsikter skulle bli hörda. Även om mycket arbete skedde enskilt gjordes sprintplanering, fördelning av arbetsuppgifter och framtagning av gränssnittsskisser alltid gemensamt. Det fanns även alltid någon i gruppen att fråga om hjälp när problem uppstod.
Ett annat sätt gruppen har utvecklats på är i hur kod- och designstandarder har använts. Redan när utvecklingen började fanns tydliga riktlinjer. För att all kod skulle följa samma standard uppmanades alla medlemmar använda kodrättningstillägget TSLint. För att appli- kationens design skulle bli konsekvent listades vilka komponenter och ikoner som skulle användas i applikationen. På grund av dessa riktlinjer har gruppen troligtvis sparat tid som annars hade behövts spenderas på att justera kod och designdetaljer i applikationen.
6.1.4
Lärdomar inför framtiden
En viktig lärdom som projektmedlemmarna tog med sig från det här projektet var vikten av att hålla en aktiv dialog med kunden. Genom att regelbundet visa upp vad som hade åstad- kommits kunde kunden komma med feedback och eventuella missförstånd kunde uppmärk- sammas i god tid innan produkten skulle levereras.
En annan lärdom som projektet givit är förståelsen att det kan vara värt att lägga lite extra tid på en implementation om andra delar sedan bygger på den. Flera delar av systemet tänk- tes inte igenom och utvecklades snabbt för att komma igång med resten av projektet. Det