5.4.2 Versionshantering och dokumentation
Alla gruppens medlemmar hade sedan tidigare använt grundläggande versionshantering. Det som har varit nytt för de flesta har varit användandet av grenar och pull requests, vilka är mer avancerade funktioner i Git och GitHub. Med mer avancerade funktioner ökade dock risken för mänskliga fel, vilka gruppen fick lära sig att lösa. Exempelvis togs fel kod bort vid en manuell sammanslagning av två versioner av en fil.
För dokumentationen har LaTeX använts. Då inte alla gruppmedlemmar använt det innan gick det även åt tid att lära in grundläggande kunskaper om det.
5.4.3 Grupparbete mot kund
Samtliga medlemmar i gruppen hade vid projektets början tidigare erfarenhet av att arbeta i en projektgrupp. Det här projektet skiljer sig dock från den erfarenheten på grund av att det i det här projektet är en verklig kund som gruppen arbetar mot. Det blir då en större mängd ansvar för samtliga involverande. Detta ansvar har blivit en stor erfarenhet. Att våga säga till andra gruppmedlemmar och se till att alla faktiskt gör det de ska är en stor lärdom. Vidare när gruppen jobbar med en faktisk kund är det väldigt viktigt att lyckas upprätthålla en bra kommunikationslinje mellan båda parter, vilket absolut är något där det är tydligt att projektgruppen utvecklades under projektets gång. Under inledningen av projektet hade gruppen utöver ett personligt möte endast väldigt flyktig e-postkommunikation med kunden. Med tiden utvecklades detta dock till kontinuerlig kommunikation över applikationen Slack, vilket skapade klart bättre möjligheter till effektiva lösningar på problem.
5.5 Individuella bidrag
Detta avsnitt beskriver översiktligt de individuella bidragen som gjorts av projektmedlemmar- na. Bidragen finns i detta dokument som bilagor.
5.5.1 Arkitektur vid utveckling i Ruby on Rails
Denna utredning av Adam Lindberg utreder vilket behov det finns för att göra en arkitektur vid utveckling av en webbapplikation i Ruby on Rails. Eftersom ramverket använder design- mönstret Model-View-Controller väcker det frågan om huruvida en utveckling av arkitektur blir överflödig. Se Bilaga A för vidare läsning.
5.5.2 En övergripande jämförelse mellan webbutvecklingsramverken
Ruby on Rails och Django
I denna utredning gör Christian Thorarensen en jämförelse mellan webbramverken Ruby on Rails och Django, ett Python-baserat ramverk. Syftet är att bättre förstå varför företag eller privatpersoner skulle välja Rails framför andra ramverk, i detta fall Django. Se Bilaga B för vidare läsning.
5.5.3 Enhets- och integrationstestning som hjälpmedel vid
mjukvaruutveckling
Frans Skarman undersöker hur automatiserade tester kan hjälpa till i mjukvaruprojekt. Hur mycket resurser som bör läggas på testning utreds också. Se Bilaga C för vidare läsning.
5.5.4 Scrum ur perspektivet studentprojekt
I denna utredning av Johannes Palm Myllylä görs en analys av Scrum som projektramverk för studentprojekt. Se Bilaga D för vidare läsning.
5.5. Individuella bidrag
5.5.5 Databaser och Ruby on Rails utveckling
Denna utredning av Jonathan Bränning handlar om databaser. Utredningen tar bland annat upp vilka alternativ för databashantering som finns för projektet, hur väl PostgreSQL passar för detta projekt och hur väl Ruby on Rails samverkar med databasen. Se Bilaga E för vidare läsning.
5.5.6 En jämförelse mellan LaTeX och Microsoft Word för
dokumentskrivning
I denna del gör Malcolm Vigren en jämförelse mellan det verktyg som använts för dokumenten i detta projekt, LaTeX, och Microsoft Word. I utredningen ingår en jämförelse mellan verktygens funktioner samt hur produktiv en användare kan förväntas vara i respektive program. Se Bilaga F för vidare läsning.
5.5.7 Versionshantering i projektet
Denna utredning av Rasmus undersöker hur versionshantering påverkat detta projekt samt gör en jämförelse mellan två olika versionshanteringsverktyg, Git och Subversion. Se Bilaga G för vidare läsning.
6
Diskussion
Detta kapitel innehåller diskussioner om rapportens resultat, metod samt arbetet i ett vidare sammanhang.
6.1 Resultat
Överlag har både projektgruppen och kunden varit nöjda med hur projektet gått. Gruppen anser att arbetet varit mycket lärorikt och även de delar som hade kunnat utvecklats mer kan vara av värde för kundens fortsatta arbete med projektet. Som alltid finns det dock områden som hade kunnat förbättras.
6.1.1 Sökning och filtrering
Sökfunktionaliteten fungerar så att användaren i sökrutan just nu endast kan söka fram kon- trakt genom dess namn. Detta hade kunnat utökas till en så kallad fuzzy search. Fuzzy search innebär att om en användare skriver in ett sökord i sökrutan, listas alla resultat där något av kontraktens metadata eller övriga fält innehåller sökordet.
För implementationen av sökfunktionaliteten valde gruppen att använda biblioteket Ran- sack. Det stod mellan det och ElasticSearch, och Ransack valdes för att det var betydligt smidigare att sätta sig in i. Om det funnits mer tid till utveckling hade antagligen ElasticSe- arch använts istället, då det är betydligt kraftfullare. Det är med ElasticSearch bland annat möjligt att få automatiska textförslag medan användaren skriver, och skulle en felstavning ske kan applikationen fråga om det är rättstavat eller inte.
6.1.2 Gantt-schema
Med tanke på att AmCharts användes för att implementera Gantt-schemat är det inte jätte- mycket som hade kunnat göras annorlunda. Projektgruppen hittade många inställningar för hur data ska presenteras, men det fanns också en funktion som skapade frustration. Vid in- zoomning, om en stapels högra kant ligger utanför det inzoomade fönstret, dyker inte inforutan upp om musen förs över stapeln. Det är dock något som gruppen inte kunde lösa på grund av att det är ett problem med AmCharts. Då biblioteket är väldigt smidigt i övrigt, och det redan användes av Boardeaser AB vid projektets start, gjordes valet att använda det ändå.