Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
Vårterminen 2017 | LIU-IDA/LITH-EX-G--17/049--SE
Utveckling av en webbapplika on
för avtalshantering med
ramverket Ruby on Rails
Development of a web applica on for contract management
using the framework Ruby on Rails
Adam Lindberg
Chris an Thorarensen
Frans Skarman
Johannes Palm Myllylä
Jonathan Bränning
Malcolm Vigren
Rasmus Thuresson
Handledare : Simon Mehari Examinator : Kris an SandahlUpphovsrätt
De a dokument hålls llgängligt på Internet – eller dess fram da ersä are – under 25 år från publice-ringsdatum under förutsä ning a inga extraordinära omständigheter uppstår. Tillgång ll dokumen-tet innebär llstånd för var och en a läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och a an-vända det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrä en vid en senare dpunkt kan inte upphäva de a llstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För a garantera äktheten, säkerheten och llgängligheten finns lös-ningar av teknisk och administra v art. Upphovsmannens ideella rä innefa ar rä a bli nämnd som upphovsman i den omfa ning som god sed kräver vid användning av dokumentet på ovan beskrivna sä samt skydd mot a dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannensli erära eller konstnärliga anseende eller egenart. För y erli-gare informa on om Linköping University Electronic Press se förlagets hemsida h p://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years star ng from the date of publica on barring excep onal circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educa onal purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are condi onal upon the consent of the copyright owner. The publisher has taken technical and administra ve measures to assure authen city, security and accessibility. According to intellectual property law the author has the right to be men oned when his/her work is accessed as described above and to be protected against infringement. For addi onal informa on about the Linköping University Electronic Press and its procedures for publica on and for assurance of document integrity, please refer to its www home page: h p://www.ep.liu.se/.
©
Adam Lindberg Chris an Thorarensen Frans Skarman Johannes Palm Myllylä Jonathan Bränning Malcolm Vigren Rasmus Thuresson
Sammanfattning
Denna rapport behandlar utvecklingen av en webbapplikation för avtalshantering med arbetsnamnet Boardeaser Contracts. Applikationen utvecklades av studenter på Tekniska högskolan vid Linköpings universitet på uppdrag av Boardeaser AB. Rapporten syftar till att ge en överblick gällande utvecklingsarbetet och resultat samt ge svar på uppsatta frågeställningar.
Applikationen har utvecklats med ramverket Ruby on Rails. Rapporten går igenom grundläggande teori gällande ramverket samt de mjukvarupaket som använts för implementationen. Rapporten behandlar också den övergripande utvecklingsmetoden samt metod för erfarenhetsfångst.
Projektets resultat blev en fungerande webbapplikation med önskad funktionalitet. Resultat och metoder diskuteras och kritiseras, det ges även förslag på alternativa metoder. Arbetet sätts i ett vidare sammanhang när bland annat applikationens energiförbrukning diskuteras.
Rapportens slutsatser är kortfattat att den metod som beskrivs i rapporten går att använda för att utveckla en applikation som skapar värde för kunden. Det konstateras också att Ruby on Rails lämpar sig relativt väl för utveckling av webbapplikationer.
Varje medlem i projektgruppen har också skrivit ett individuellt bidrag till rapporten. Där utreds olika områden relaterade till projektet mer detaljerat. Dessa bidrag hittas i slutet på rapporten.
Författarens tack
Tack till Erik Södermark och Jakob Waller på Boardeaser AB för att de varit ständigt tillgängliga för rådgivning gällande utvecklingen av applikationen. Projektgruppen vill även tacka handledare Simon Mehari och kursledningen för kursen TDDD96 vid Linköpings universitet år 2017 för en väl genomförd kurs.
Ordlista
Ord Betydelse
Dynamisk typning Ett kännetecken hos ett programmeringsspråk som innebär bland annat att programmeraren inte specifierar datatypen hos variabler och funktioner.
Front-end Front-end består inom webbutveckling av den del som användare interagerar med på en webbapplikation.
Git Ett versionshanteringsprogram.
Git-repository En datastruktur där Git lagrar information om alla filer i ett pro-jekt.
GitHub En webbsida som tillhandahåller lagring av kod versionshanterad med Git.
Google Hangouts En plattform för kommunikation på nätet.
HTTP HTTP är ett grundläggande protokoll för datakommunikation på webben.
Make Make är ett verktyg som bygger program och tillhörande filer från programkod. Hur byggandet ska gå till specifieras i en eller flera Make-filer (eng. Makefiles)
Migration Migrations är inom Ruby on Rails ett verktyg för att enkelt göra ändringar i en existerande databas. En fil som talar om vilken ändring som ska ske kallas också migration.
Open source Programvara där källkoden finns tillgänglig för allmänheten. Pull Request En funktion i GitHub som möjliggör jämförelse av två
utveck-lingshistoriker innan koden för dessa förs samman. Rails Används i rapporten som förkortning till Ruby on Rails.
Ramverk Inom mjukvaruutveckling tillhandahåller ett ramverk grundfunk-tionalitet som kan utökas av utvecklaren.
Ruby on Rails Ett ramverk som används vid utveckling av webbapplikationer. Trello Trello är ett webbaserat verktyg för att organisera ett
projektar-bete på en anslagstavla. Anslagstavlan talar om vem som jobbar med vad samt vilken status alla aktiviteter har.
Innehåll
Sammanfattning iii Författarnas tack iv Innehåll vi Figurer ix Tabeller x 1 Introduktion 1 1.1 Motivation . . . 1 1.2 Syfte och mål . . . 1 1.3 Frågeställningar . . . 2 1.4 Begränsningar . . . 2 2 Bakgrund 3 3 Teori 4 3.1 Ruby . . . 4 3.2 Ruby on Rails . . . 4 3.3 Rake . . . 5 3.4 Model-View-Controller . . . 5 3.5 RubyGems . . . 6 3.6 AWS S3 . . . 6 3.7 HTML och Slim . . . 7 3.8 Sass . . . 7 3.9 Scrum . . . 7 3.10 CoffeeScript . . . 7 3.11 AJAX . . . 8 3.12 Heroku . . . 8 3.13 Rails ActionMailer . . . 8 3.14 AmCharts . . . 8 3.15 PostgreSQL . . . 8 4 Metod 9 4.1 Utvecklingsmetod . . . 9 4.2 Metod för erfarenhetsfångst . . . 13 5 Resultat 14 5.1 Systembeskrivning . . . 14 5.2 Systemanatomi . . . 18 5.3 Tester . . . 185.4 Gemensamma erfarenheter . . . 19
5.5 Individuella bidrag . . . 20
6 Diskussion 22 6.1 Resultat . . . 22
6.2 Metod . . . 23
6.3 Arbetet i ett vidare sammanhang . . . 24
7 Slutsats 27 7.1 Hur kan Boardeaser Contracts implementeras så att värde skapas för kunden? . 27 7.2 Vilka erfarenheter kan dokumenteras från arbetet med Boardeaser Contracts som kan vara intressant för framtida projekt? . . . 28
7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 28
7.4 Hur väl lämpar sig ramverket Ruby on Rails för utveckling av webbapplikationer? 28 A Adam Lindberg – Arkitektur vid utveckling i Ruby on Rails 29 A.1 Inledning . . . 29 A.2 Bakgrund . . . 30 A.3 Teori . . . 30 A.4 Metod . . . 31 A.5 Resultat . . . 31 A.6 Diskussion . . . 33 A.7 Slutsatser . . . 35
B Christian Thorarensen – En övergripande jämförelse mellan webbutveck-lingsramverken Ruby on Rails och Django 36 B.1 Inledning . . . 36 B.2 Teori . . . 37 B.3 Metod . . . 39 B.4 Resultat . . . 40 B.5 Diskussion . . . 42 B.6 Slutsatser . . . 44
C Frans Skarman – Enhets- och integrationstestning som hjälpmedel vid mjukvaruutveckling 45 C.1 Inledning . . . 45 C.2 Bakgrund . . . 46 C.3 Teori . . . 46 C.4 Metod . . . 46 C.5 Resultat . . . 49 C.6 Diskussion . . . 51 C.7 Slutsatser . . . 52
D Johannes Palm Myllylä – Scrum ur perspektivet studentprojekt 53 D.1 Inledning . . . 53 D.2 Bakgrund . . . 53 D.3 Teori . . . 54 D.4 Metod . . . 54 D.5 Resultat . . . 57 D.6 Diskussion . . . 61 D.7 Slutsats . . . 61
E Jonathan Bränning - Databaser och Ruby on Rails-utveckling 63 E.1 Inledning . . . 63
E.2 Bakgrund . . . 64 E.3 Teori . . . 64 E.4 Metod . . . 65 E.5 Resultat . . . 65 E.6 Diskussion . . . 68 E.7 Slutsatser . . . 69
F Malcolm Vigren – En jämförelse mellan LaTeX och Microsoft Word för dokumentskrivning 70 F.1 Inledning . . . 70 F.2 Teori . . . 71 F.3 Metod . . . 71 F.4 Resultat . . . 73 F.5 Diskussion . . . 75 F.6 Slutsatser . . . 77
G Rasmus Thuresson - Versionshantering i projektet 79 G.1 Inledning . . . 79 G.2 Teori . . . 79 G.3 Metod . . . 81 G.4 Resultat . . . 81 G.5 Diskussion . . . 83 G.6 Slutsatser . . . 84 Litteratur 85
Figurer
3.1 Designmönstret Model-View-Controller. . . 5
5.1 Skärmbild från indexvyn i Boardeaser Contracts . . . 15
5.2 Skärmbild av sökfälten för avancerad filtrering . . . 15
5.3 Gantt-schemats utseende . . . 16
5.4 Systemanatomi över Boardeaser Contracts . . . 19
6.1 Utdrag från servern vid inladdning av indexvyn . . . 25
A.1 Gruppmedlemmarnas svar på fråga 1 . . . 32
A.2 Gruppmedlemmarnas svar på fråga 2 . . . 32
A.3 Gruppmedlemmarnas svar på fråga 3 . . . 32
A.4 Gruppmedlemmarnas svar på fråga 4 . . . 33
E.1 Exempel på relationer i relationsdatabas . . . 67
Tabeller
4.1 Beskrivning av olika integritetsnivåer i projektet . . . 12
B.1 Stöd för front-end-språk . . . 40
B.2 Stöd för databashanterare . . . 40
B.3 IDE-programvara för Rails eller Django . . . 41
B.4 Design och funktionalitet för Rails och Django . . . 41
B.5 Stöd för serverprogramvara . . . 41
B.6 Webbapplikationer med tillhörande ramverk och ranking för webbtrafik[ref:alexa] 42 B.7 Årtal tillgängligt för allänheten . . . 42
C.1 Beskrivning av olika integritetsnivåer i projektet . . . 46
C.2 Lista av fel i backend-delen som klassificerats som buggar . . . 49
C.3 Lista av fel i frontend-delen som klassificerats som buggar . . . 50
C.4 Har du använt projektets tester för att se till att ändringar inte har förstört gammal funktionalitet? . . . 50
C.5 Har du skrivit och använt nya tester medan du har utvecklat en funktion? . . . 51
C.6 Om du inte skrivit tester för projektet, varför inte? . . . 51
C.7 Om du fick göra om projektet, skulle du ändra mängden test som gjorts? . . . 51
E.1 Funktionalitet för olika databaser . . . 67
F.1 Jämförelse av verktygens innehållsmässiga funktioner. . . 73
F.2 Jämförelse av produktivitetsfunktioner. . . 74
1
Introduktion
Denna rapport skrivs i samband med utvecklingen av en webbapplikation vars syfte är att underlätta avtalshantering för styrelser. Gruppen som utvecklat applikationen samt skrivit denna rapport består av sju studenter som studerar civilingenjörsutbildningar inom data- och mjukvaruteknik vid Linköpings universitet.
1.1 Motivation
Projektarbetet gick ut på att utveckla ett avtalshanteringssystem riktat mot företag som har minst en extern styrelseledamot. Projektet beställdes av företaget Boardeaser AB och fick arbetsnamnet Boardeaser Contracts. Styrelsearbete innefattar ofta hantering av många avtal. Det är mycket viktigt för en styrelse att kunna besvara frågor som:
• Vem gör vi affärer med? • Uppfyller vi avtalen? • Är vi berättigade till mer? • Vilka kontrakt är aktiva? • Vilka risker löper vi?
Syftet med Boardeaser Contracts är att hjälpa styrelser besvara dessa frågor.
1.2 Syfte och mål
Syftet med projektet var att utveckla en webbapplikation på beställning av Boardeaser AB. Utvecklingen av applikationen syftade också till att svara på frågeställningarna i Avsnitt 1.3. Denna rapport syftar till att ge en överblick över projektet gällande resultat, arbetssätt, erfarenheter samt vilka slutsatser som kan dras. För att få en bra reflektion av erfarenheter förs diskussioner gällande resultat, metodval, konsekvenser och källor.
1.3. Frågeställningar
1.3 Frågeställningar
Följande frågeställningar behandlas i rapporten:
1. Hur kan Boardeaser Contracts implementeras så att värde skapas för kunden?
2. Vilka erfarenheter kan dokumenteras från arbetet med Boardeaser Contracts som kan vara intressant för framtida projekt?
3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?
4. Hur väl lämpar sig ramverket Ruby on Rails för utveckling av webbapplikationer?
1.4 Begränsningar
Projektarbetet som behandlas i denna rapport hade en begränsad tidsbudget på 400 timmar per gruppmedlem, det vill säga 2800 arbetstimmar totalt. I dessa timmar ingår arbetet med utvecklingen av applikationen och all dokumentskrivning. Rapporten behandlar utveckling med ramverket Ruby on Rails. Alternativa utvecklingsverktyg behandlas endast ytligt.
2
Bakgrund
Projektet beställdes av Boardeaser AB. Företaget ville utveckla Contracts-applikationen för att kunna utöka sin nuvarande produkt Boardeaser. Denna är en webbapplikation vars syfte är att underlätta styrelsearbete. Funktionalitet som den erbjuder är bland annat planera möten, föra mötesprotokoll och dela dokument och kontaktinformation med andra styrelseledamöter via webben. Syftet med Contracts-applikationen är specifikt att hjälpa styrelser med att hålla ordning på sina kontrakt.
Projektgruppen som har utvecklat applikationen består av sju medlemmar som studerar på civilingenjörsutbildningar vid Linköpings universitet. Sex av medlemmarna går på linjen Datateknik och en medlem går på linjen Mjukvaruteknik. Samtliga medlemmar gör projek-tet som examinerande moment i kursen TDDD96 Kandidatprojekt i programvaruutveckling. Medlemmarna har tidigare arbetat med projekt av jämförbar storlek i utbildningssamman-hang. Den största skillnaden mellan detta projekt och de som utförts tidigare är kraven på kvalitet och kvantitet gällande dokumentation. Ingen av gruppmedlemmarna hade i början av projektet någon större erfarenhet av webbprogrammering eller de programmeringsspråk som använts. Samtliga medlemmar har dock via sin utbildning fått en bra grund för att snabbt kunna lära sig de nya tekniker som har krävts under utvecklingen.
3
Teori
I detta kapitel ges teoretisk bakgrund för använda tekniker och metoder. Bland annat de programbibliotek som har använts i projektet, programmeringsspråket Ruby och ramverket Ruby on Rails behandlas.
3.1 Ruby
Ruby är ett objektorienterat programmeringsspråk med dynamisk typning och öppen källkod. Språket beskrivs av Rubys community som enkelt och med fokus på produktivitet. Enligt Rubys skapare Yukihiro ”Matz” Matsumoto, innehåller Ruby blandade delar från hans favo-ritspråk Perl, Smalltalk, Eiffel, Ada, och Lisp[73]. Ruby började utvecklas år 1993 och blev tillgängligt för allmänheten år 1995. Yukihiro ”Matz” Matsumoto fick först lokalt stöd i Japan och år 2000 hade Ruby blivit välkänt bland många av världens programmerare.
I skrivande stund är det tillåtet att använda, kopiera, modifiera och sprida programme-ringsspråket Ruby. Det är med andra ord helt gratis[75].
3.2 Ruby on Rails
Ruby on Rails är ett ramverk för utveckling av webbaserade applikationer och är skrivet med programmeringsspråket Ruby. Rails blev tillgängligt för allmänheten som öppen källkod år 2004. Det är designat för att göra skapandet av applikationer väldigt enkelt, genom flera anta-ganden om vad en webbutvecklare behöver. Detta är kopplat till en av Rails grundprinciper, nämligen Konvention över konfiguration (eng. Convention Over Configuration). Istället för att kräva konfigurering och inställningar för att komma igång med en ny webbapplikation, har Rails förvalda inställningar enligt dess konventioner. Genom detta kan en utvecklare med färre rader kod åstadkomma mer med Rails än med andra programmeringsspråk och ramverk för webbutveckling. Detta förutsätter dock att utvecklaren har följt Rails riktlinjer för vad som är det bästa sättet utveckla webbapplikationer på. I de fall där andra webbutvecklingsramverk hade erbjudit flera likvärdiga lösningar, kan Rails påbjuda en lösning och motverka andra[82]. En annan grundprincip Rails följer är Upprepa dig inte (eng. Don’t Repeat Yourself), för-kortat DRY. Denna princip innebär inte bara att samma rader programkod inte ska dupliceras. Den säger explicit att varje beståndsdel av ett system bör ha en auktoritativ och entydig re-presentation. Det gäller bland annat databasmodeller, testplaner och dokumentation av ett
3.3. Rake
system. Syftet med principen DRY är att göra system flexibla och lätta att underhålla[101, 82].
Ruby on Rails har använts till att bygga hundratusentals webbapplikationer. Några av de största är Basecamp, GitHub, Shopify, Airbnb, Twitch, Soundcloud, Hulu, Zendesk, Square och Highrise[84].
3.3 Rake
Rake är ett för Ruby speciellt utformat program som fungerar på samma sätt som funktionen make för Unix. För en Ruby-applikation utnyttjas den tillhörande Rake-filen tillsammans med .rake-filer till att utföra olika uppgifter, så kallade rake tasks. När en ny Rails-applikation
skapas följer automatiskt vissa nödvändiga rake tasks med, men det går också skapa sina egna för att utföra speciella uppgifter[83].
3.4 Model-View-Controller
Ruby on Rails följer designmönstret Model-View-Controller (MVC). Denna design separerar applikationsdata och koden som används för att visa upp datan. Detta är ett vanligt sätt att designa ett GUI på.
Vid kommunikation mellan en webbläsare och en Rails-applikation, skickar webbläsaren först en begäran. Begäran tas emot av en webbserver som sedan skickar begäran vidare till Rails-applikationens controller, se Figur 3.1. I vissa fall kommer en vy (eng. view) att ren-deras, konverteras till HTML-format och sedan skickas tillbaka till webbläsaren. För Rails-applikationer som behöver datalagring kommunicerar controllern även med en modell (eng. model) för lagring av applikationsdata. Modellen representerar ett visst databasobjekt i Rails, exempelvis användare. Modeller ansvarar således för kommunikationen till applikationens da-tabas. Efter att en eller flera modeller har anropats kommer controllern att rendera en vy och returnera en fullständig hemsida i formatet HTML till webbläsaren[41].
3.5. RubyGems
3.5 RubyGems
RubyGems, eller bara Gems, kan användas för att lägga till funktionalitet i applikationer skrivna i Ruby. Gems är alltså mjukvarupaket som innehåller en applikation eller ett helt bib-liotek med funktioner. Mjukvarupaketen kan importeras och användas av andra Ruby-programmerare[74]. Kommande underrubriker beskriver de viktigaste mjukvarupaketen som använts i projektet.
3.5.1 Zeus
Zeus är ett mjukvarupaket som används för att förladda en Rails-applikation. Detta gör att
vanliga utvecklingsaktiviteter går snabbare än med enbart Rails[51].
3.5.2 Postmark och Griddler
Postmark är en extern tjänst som används för att leverera e-post. Tjänsten inkluderar ett
tillhörande programbibliotek till Ruby on Rails.
För varje Postmark-användarkonto finns en unik e-postadress för inkommande e-post. All e-post som skickas till denna e-postadress kommer Postmark att skicka vidare till en så kallad
webhook. Kort beskrivet är en webhook en publik webbadress till webbapplikationen som är
tillgänglig endast för att ta emot information från andra applikationer via internet[112]. Yt-terligare använder Postmark formatet JSON för alla e-postmeddelanden som skickas vidare.
Postmark har stöd för domänvidarebefordring. Detta innebär att alla e-postadresser som har samma domän kan ställas in att vidarebefordras till en webhook. Exempelvis kan domän-vidarebefordring i Postmark ställas in till:
*@upload.boardeaser.com
Då kommer alla e-postadresser med domänet upload.boardeaser.com att vidarebefordras till den webhook som är inställd i Postmark.
I Postmarks dokumentation rekommenderas programbiblioteket Griddler för att ta emot e-post från Postmark[113]. Griddler inkluderar funktionalitet för att enkelt skapa en webhook, och även en klass som skapar ett e-postobjekt för varje inkommet e-postmeddelande samt kör metoden process, i vilket specifik kod för webbapplikationen ska läggas till av en utvecklare. Koden bestämmer vad som händer med varje mottaget e-postmeddelande.
Kod för att skicka e-post i Rails kan skrivas på samma sätt för Postmark som när en generell e-postserver används. För att Postmark ska skicka e-post åt en Rails-applikation behöver biblioteket postmark-rails installeras enligt beskrivningen på postmark-rails GitHub-webbsida[44].
3.5.3 Ransack
Ransack är ett bibliotek som kan användas för att söka och filtrera data i Rails-applikationer. Genom att specificera vilka fält användaren ska kunna filtrera på kan Ransack skapa ett formulär för sökningen och ge Rails-applikationen en lista på resultaten från sökningar.
3.6 AWS S3
AWS står för Amazon Web Services och S3 för Simple Storage Service, det är en plats för fillag-ring som Amazon erbjuder. Kunder betalar för serverutrymme vilket möjliggör uppladdning av filer. AWS S3 lanserades år 2006 i USA och hade enligt egen utsago två biljoner sparade objekt år 2013[6]. Tjänsten kan smidigt integreras med Rails genom användning av externa programbibliotek.
3.7. HTML och Slim
3.7 HTML och Slim
HTML är en förkortning för HyperText Markup Language och är i nuläget standarden för alla webbsidor på webben och första versionen släpptes i slutet av 1993. Det är uppbyggt för att göra det så lätt som möjligt att formatera sin webbsida och att genom hyperlänkar länka mellan olika webbsidor. Detta görs genom att använda olika så kallade taggar för att definiera bland annat stycken, rubriker och bilder. Dessa taggar kommer vanligtvis parvis med en starttagg och en sluttagg, och kan till exempel se ut som följande: <p>Hello world!</p>. Detta kommer att generera en paragraf där det står ”Hello world!”.
Slim är ett mallspråk som används för att förenkla HTML. Det har åstadkommits genom att ta bort < och > i taggarna och inte ha någon sluttagg. Istället löses det genom att Slim är indenteringskänsligt. Dessutom stöds det av alla de stora ramverken, där Rails är ett av dem. Fördelen med Slim är att det blir mycket mindre kod och samtidigt lättare att läsa med färre överflödiga tecken[7, 89].
3.8 Sass
Sass, Syntactically Awesome StyleSheets, är ett skriptspråk som kompileras till CSS, som i sin tur används för att ändra utseendet på webbsidor. Språket har en äldre indenteringsbaserad syntax och en nyare syntax som använder måsvingar och semikolon för att separera rader och block. Den nya syntaxen liknar syntaxen i CSS. Till skillnad från vanlig CSS stöder Sass variabler, loopar och nästlade CSS-regler[40].
3.9 Scrum
Scrum är ett processramverk som används för utveckling av komplexa produkter. Utveck-lingsprocessen är iterativ och inkrementell för att optimera förutsägbarhet, anpassningsbarhet och hantering av risker. Ett team som arbetar enligt Scrum består av en produktägare, ett utvecklingsteam och en scrummästare. Produktägaren ansvarar för att maximera värdet av produkten och utvecklingsteamets arbete. Utvecklingsteamet utför själva arbetet. Teamet är självorganiserande vilket innebär att ingen kan tala om för teamet hur utvecklingen ska ut-föras. Scrummästaren ser till att Scrum förstås och efterlevs av samtliga teammedlemmar. Scrum innehåller även artefakter som produktbacklogg och sprintbacklogg. Produktbacklog-gen är en lista med all funktionalitet som behövs för den slutgiltiga produkten. Denna lista sorteras efter prioritet där funktionalitet med högst prioritet står högst i backloggen. Det är produktägaren som bestämmer hur backloggen ska prioriteras. Sprintbackloggen är en eller flera poster från produktbackloggen som utvecklingsteamet har tagit på sig att utveckla under en viss sprint[88].
3.10 CoffeeScript
JavaScript är ett programmeringsspråk som är en av kärnorna när det kommer till webb-utveckling. Den mest tillämpade användningen av JavaScript rör front-end-utveckling, men det kan även användas för server-side-utveckling. Kod som skrivs i programmeringsspråket CoffeScript transkompileras till JavaScript-kod. Medan JavaScripts funktionalitet länge har hyllats, har dess syntax och kodstruktur fått genomlida en hel del kritik. CoffeScript utveck-lades just för detta syfte, med en enklare syntax som är inspirerad av bland annat Ruby och programmeringsspråket Python[45].
3.11. AJAX
3.11 AJAX
AJAX står för Asynchronous JavaScript And XML, och används av webbsidor för att hämta
data från en webbserver utan att behöva ladda om sidan. Trots att XML är med i namnet, behöver data som skickas inte ha en XML-struktur.
När JavaScript- eller CoffeeScript-koden som körs på hemsidan behöver information från servern, skapar koden ett objekt som asynkront skickar en förfrågan till servern med eventuella parametrar. Servern behandlar sedan förfrågan och skickar tillbaka datan som förfrågades. Detta anropar en funktion i JavaScript- eller CoffeeScript-koden som behandlar svaret från servern. AJAX kan också användas för att bara skicka data till servern. Det är inget krav att svaret från servern måste behandlas[98].
3.12 Heroku
Heroku är en extern tjänst som har stöd för att ladda upp Rails-applikationer i molnet via
terminalen. Efter en lyckad uppladdning kan en Rails-applikation nås via internet som en vanlig webbsida.
3.13 Rails ActionMailer
Ruby on Rails ActionMailer gör det möjligt att skicka och ta emot e-post med en mailer-modell och tillhörande vyer. En utvecklare behöver först skapa en mailer-modell med kommandot:
rails generate mailer UserMailer
Mailer-modellerna liknar controllers i Rails då de har tillhörande vyer, två per metod. Varje metod motsvarar en mall för e-postmeddelanden. I de flesta e-postklienter (Thunderbird,
Out-look etc.) finns möjlighet att visa mottagna e-postmeddelanden i text- eller HTML-format.
Därför genererar Rails en text- och en HTML-vy för samma e-postmeddelandemall. Metoder i UserMailer svarar med två vyer som skickas via epost, till skillnad från vanliga controllers som svarar via HTTP. Detta förutsätter att metoderna innehåller kod som åtminstone ställer in mottagare till e-postmeddelandet. UserMailer, och alla andra mailers som genereras, ärver från klassen Rails ActionMailer[77].
3.14 AmCharts
AmCharts är ett JavaScript-bibliotek som används för att visualisera data med hjälp av olika
tabeller, diagram och kartor.
3.15 PostgreSQL
PostgreSQL är en databashanterare för relationsdatabaser som förlänger språket SQL
(Structu-red Query Language). Med en relationsdatabas menas en databas där tabeller är sammanlän-kade med så kallade nycklar. Ett exempel kan vara att varje företag relateras till flera kontrakt. I kontrakttabellen ligger det då även med en nyckel, i det här fallet företagets specifika id-nummer, som även ligger i företagstabellen. Detta gör att en utvecklare smidigt kan välja alla kontrakt som tillhör ett visst företag.
4
Metod
Ett antal olika metoder har använts för utförandet av utvecklingsarbetet och för att svara på de uppsatta frågeställningarna. Detta kapitel går igenom samtliga metoder och hur de har använts.
4.1 Utvecklingsmetod
I början av projektet tilldelades varje medlem i projektgruppen en roll med tillhörande ansvars-områden. Förekommande roller var teamledare, analysansvarig, arkitekt, testledare, utveck-lingsledare, dokumentansvarig, kvalitetssamordnare samt konfigurationsansvarig. På grund av att projektgruppen endast bestod av sju medlemmar tilldelades en av medlemmarna två rol-ler i form av dokumentansvarig och kvalitetssamordnare. Rollfördelningen gjordes för att få tydligt definierade ansvarsområden och därmed förenkla organisering av arbete.
4.1.1 Scrum
Själva utvecklingsarbetet har följt en anpassad version av det agila ramverket Scrum. Scrum valdes för att det ger kontinuerliga leveranser av funktionalitet och därmed en naturligt konti-nuerlig kommunikation med kund. Detta underlättade bland annat arbetet med att svara på Frågeställning 1, det vill säga hur värde kan skapas för kunden Boardeaser AB. Teamledaren tilldelades rollen som scrummästare och rollen som produktägare föll på analysansvarig. För att anpassa ramverket efter gruppens utförda arbete följdes inte Scrum till hundra procent. Istället har vissa utvalda delar plockats ut och applicerats på arbetet. Delarna som använts behandlas översiktligt nedan. Bilaga D går in mer på detaljer gällande Scrums roll i projektet. Utvecklingsarbetet delades upp i sprintar med en längd på ungefär 2 veckor. En backlogg med all funktionalitet som applikationen skulle innehålla sattes upp innan påbörjandet av den första sprinten. Varje sprint planerades genom att först välja den funktionalitet som gruppen ville implementera under sprinten, och sedan dela in denna i mindre aktiviteter. Aktiviteterna lades sedan upp på en Trello-anslagstavla där medlemmarna kunde plocka den aktivitet som de ville utföra härnäst. Allmän policy var att varje aktivitet skulle utföras genom sammarbete mellan minst två gruppmedlemmar. Efter varje utförd sprint hölls ett utvärderingsmöte där det reflekterades över vad som hunnits med, vad som inte hunnits med, vad som fungerade bra och förbättringsförslag till framtida sprintar.
4.1. Utvecklingsmetod
4.1.2 Kommunikation med kund
I början av projektet hölls ett möte mellan en representant från kunden Boardeaser AB och två representanter från projektgruppen. Vid mötet presenterade kunden deras vision gällande projektet och vilken funktionalitet de hade tänkt att applikationen skulle erbjuda. Projekt-gruppen gjorde en kravspecifikation utgående ifrån det som kommits fram till vid mötet. Specifikationen fick sedan godkännas av kunden.
Med anledning av att Boardeaser AB har sitt kontor i Stockholm medan projektgruppen befann sig i Linköping, tillät inte logistiken att några fler fysiska möten hölls. Kommunika-tionen mellan projektgruppen och kunden sköttes därför via en kanal på chattprogrammet Slack. Där kunde projektgruppen få hjälp med tekniska frågor samt få förtydliganden gällande exempelvis någon specifik funktionalitet när det behövdes. Analysansvarige försåg också kun-den veckovis med en uppdatering gällande projektgruppens framsteg, framtida planer samt eventuella problem. Denna uppdatering gavs antingen via e-post eller Slack.
När applikationen började ta form och en stor del av funktionaliteten fanns implementerad i en första version, höll projektgruppen en demonstration för kunden. Demonstrationen gjor-des via skärmdelning på Google Hangouts. Vid demonstrationen visade projektgruppen upp applikationen och kunden fick komma med synpunkter och förslag på utökningar.
4.1.3 Utvecklingsmiljö och verktyg
Här redovisas utvecklingsmiljön och de verktyg som har använts i projektet. Se Kapitel 3 för mer ingående förklaringar av specifik teknisk terminologi.
För utveckling av webbapplikationen Boardeaser Contracts användes ramverket Ruby on Rails. På grund av att applikationen utvecklades som en utökning av en redan existerande applikation som var skriven i Ruby on Rails, fanns ingen större valmöjlighet gällande detta. Ruby on Rails är ett ramverk som använder det objektorienterade språket Ruby och är desig-nat för utveckling av webbapplikationer. Ramverket ger utvecklaren ett tydligt designmönster att följa i form av Model-View-Controller. Ruby on Rails hjälper även utvecklaren genom att automatiskt generera en del filer och kod för grundläggande funktionalitet. En klar fördel med Ruby on Rails är att utvecklingen går väldigt fort när en förståelse för ramverket utvecklats. En potentiell nackdel är att denna typ av ramverk ibland kan upplevas vara i vägen för spe-cifika saker som en utvecklare vill göra, då utvecklingen hela tiden måste anpassas efter en viss standard. Utvecklingen av front-end-delen av applikationen gjordes med hjälp av Slim, CoffeeScript och Sass. För versionshantering av koden användes ett privat Git-repository på GitHub som tillhandahölls av Boardeaser AB.
Utveckling av en webbapplikation som denna leder oundvikligen till problem och buggar i applikationen. För att hålla reda på dessa användes issues, som är en funktion på GitHub där kända buggar och problem med applikationen kan rapporteras. Så fort ett problem upptäcktes som ej kunde åtgärdas omgående, rapporterades det som ett issue. Alla medlemmar hade tillgång till den fullständiga listan med rapporterade och olösta issues och kunde via den välja någon att försöka åtgärda. När en issue åtgärdats markerades den som löst och kunde sedan arkiveras.
Varje funktion separat från den fungerande huvudkoden genom användning av grenar (eng. branches) på Git. En gren skapades när en ny funktion som skulle implementeras, där utveck-lingen av funktionen kunde ske utan att påverka koden på master-grenen, där huvudkoden finns. När en funktion ansågs vara färdigutvecklad kunde den läggas samman med huvudkoden, efter en granskning beskriven i Avsnitt 4.1.4.
4.1.3.1 Utveckling med Ruby on Rails
Implementation av ny funktionalitet till applikationen har följt ungefär samma arbetsgång för samtliga funktioner. I det första steget identifieras huruvida några nya filer kommer att behöva genereras. Det en utvecklare oftast kan behöva generera är modeller och controllers. En modell
4.1. Utvecklingsmetod
behövs om den nya funktionaliteten introducerar en ny typ av objekt till applikationen. I detta sammanhang skulle det exempelvis kunna vara att uppladdning av kontrakt ska implementeras när kontrakt är något som inte redan finns definierat i applikationen. En controller behövs när nya typer av förfrågningar ska hanteras. Ett exempel på detta kan vara om en utvecklare vill implementera en sökfunktion i indexvyn för kontrakt. Med hjälp av Rails genereras dessa enkelt med ett kommando från terminalfönstret. Behövs nya poster i databasen genereras en migration på ett liknande sätt. När detta är gjort kan det vara fördelaktigt att fundera på om det finns några färdiga RubyGems som kan underlätta utvecklingen av funktionen. I Kapitel 3 ges beskrivningar av de RubyGems som använts i detta projekt.
I modellerna definieras sedan bland annat relationer och eventuella beroenden till andra objekt. I controllern beskrivs hur applikationen ska svara på händelser som exempelvis an-vändarinteraktion. Front-end-delarna till funktionaliteten skrivs med hjälp av Slim, Sass och CoffeeScript. De grundläggande mallarna för de olika vyerna som behövs skrivs med Slim. Mer avancerad styling skrivs i Sass och mer avancerad interaktion med användaren skrivs i CoffeeScript.
4.1.4 Kodstandard och granskning
Skriven kod följer samma standard som tidigare skriven kod i Boardeaser ABs plattform. Ramverket Ruby on Rails kräver också per automatik att vissa standarder följs.
Kodgranskning utfördes genom att använda kodinspektioner via Pull Requests på GitHub. Detta innebar att när en utvecklare ville lägga koden i sin utvecklingsgren till master-grenen, utsåg denne en inspektör som sedan läste igenom den nya koden. Om inspektören inte hittade några fel slogs koden ihop med huvudkoden på master. Annars fick den som skrivit koden korrigera felen innan detta kunde ske.
4.1.5 Dokumentskrivning
Projektets dokument skrevs i LaTeX. Detta verktyg valdes ut av projektgruppen bland annat för att det stöder kodlistningar och Git enkelt kan användas för versionshantering. Dokumenten versionshanteras därmed i Git i ett privat repository på GitHub. Den dokumentansvarige hade ansvar över att skapa och underhålla LaTeX-mallar för gruppens dokument.
Innan varje utfärdande av ett visst dokument granskades det av minst en projektmed-lem som inte utförde ändringarna, för att kontrollera att innehållet var korrekt. Dokumen-tet inspekterades sedan av minst en annan medlem för att kontrollera att inga stavnings-, grammatik- och formateringsfel förekom i dokumentet.
Följande underrubriker beskriver dokumentationen som ingick i projektet.
4.1.5.1 Kravspecifikation
Kravspecifikationen var en överenskommelse mellan projektgruppen och kunden, som speci-ficerade vilka krav slutprodukten skulle uppfylla. I början av projektet hade en representant från Boardeaser AB ett möte med två projektmedlemmar, där representanten gick igenom ett förslag på en kravspecifikation. Gruppen formulerade detta förslag som en formell specifika-tion med prioritet 1-krav (krav som ska uppfyllas inom den utsatta tiden), och prioritet 2-krav (krav som endast ska uppfyllas om gruppen får tid över). Varje krav numrerades och rörde slutproduktens externa funktioner, kvalitet eller interna struktur.
4.1.5.2 Kvalitetsplan
Kvalitetsplanen var en säkerställning av att hög kvalitet på projektet hölls. Den utfärdades av kvalitetssamordnaren, och baserades på standarden IEEE std 730-2002 för kvalitetsplaner.
4.1. Utvecklingsmetod
4.1.5.3 Projektplan
Projektplanen skrevs för att ha en så god grund för projektets arbetsgång som möjligt. Team-ledaren hade huvudansvaret för projektplanen.
4.1.5.4 Arkitekturdokument
Arkitekturdokumentet skapades för att ge en översiktlig beskrivning om hur systemet är tänkt att konstrueras. Arkitekten hade huvudansvaret för dokumentet.
4.1.5.5 Testplaner
Testplanerna, som utfärdades av den testansvarige, beskrev hur och när tester skulle utföras. En översiktlig huvudtestplan rörande hela projektet skrevs samt en testplan för varje iteration av utveckling. Testplanerna baserades på standarden IEEE std 829-2008.
4.1.5.6 Testrapporter
Testrapporterna utfärdades av den testansvarige och beskrev resultaten av testerna som gjor-des enligt testplanerna. Dessa rapporter baseragjor-des på standarden IEEE std 829-2008.
4.1.6 Testning
I första iterationen av projektet skrevs en testplan som definierade när och hur testning skulle utföras. Testplanen definierade tre nivåer av fel som kunde uppstå där högre nivåer indikerar mer allvarliga konsekvenser om ett sådant fel skulle uppstå. Dessa felnivåer finns beskrivna i Tabell 4.1
För att utvärdera hur testningen fungerade gjordes en enkätundersökning som beskrivs noggrannare i Bilaga C. Delar av datan från undersökningen kommer att användas i denna rapport.
Tabell 4.1: Beskrivning av olika integritetsnivåer i projektet
Nivå Delsystem Konsekvenser
3 Kunduppgiftshantering Fel kan leda till att systemets användares konfiden-tiella information läcks
2 Datahantering Fel kan leda till att kunders data blir förstörd 1 Gränssnitt Fel kan leda till att användarupplevelsen försämras
Eftersom att olika typer av fel har olika konsekvenser beslutades det att enhets- och integ-rationstest krävs för kod där det finns risk för fel på nivå två och tre. Tester uppmuntrades även för övrig kod. Testplanen sade även att tester skulle skrivas för att reproducera eventuella buggar som uppstod och hjälpa till att undvika likande fel i framtiden. För att kod skulle få slås ihop med master-branchen krävdes det att alla projektets tester skulle gå att köra utan problem.
Utöver enhetstesterna skulle även användartester göras efter varje iteration för att verifiera att produkten uppfyllde dess funktionella krav.
Under utvecklingen följdes inte testplanen fullt ut. Användartesterna och enhetstesterna gjordes för det mesta som planerat, men tester skrevs inte för att reproducera alla nyupptäckta fel. Tester skrevs bara för back-end-delen av koden och använde Rails inbyggda testfunktioner.
4.2. Metod för erfarenhetsfångst
Användartesterna utfördes av gruppmedlemmarna på åtta testpersoner som fick utföra två förutbestämda uppgifter i Boardeaser Contracts plattform. Resultatet av testerna sammanfat-tades i en testrapport.
4.2 Metod för erfarenhetsfångst
För att fånga in erfarenheter har utvärderingsmöten hållits efter varje utförd sprint. På dessa möten reflekteras det över vad som har gått bra och vad som går att förbättra till nästa sprint. Teamledaren förde anteckningar vid denna typ av möten så att gruppen kunde applicera nya erfarenheter på kommande sprint. Det underlättar även att aktiviteter utförs av minst två personer. Om arbetet för det mesta sker i par leder det till mer diskussion. På så vis fångas även fler erfarenheter upp då en utvecklare hela tiden har tillgång till någon annans perspektiv. Utöver detta har projektgruppen i så stor utsträckning som möjligt arbetat i grupprum med samtliga medlemmar närvarande. Det har gruppen försökt göra även de gånger som det utförda arbetet hade kunnat göras enskilt, i par eller i mindre grupper. På så vis har möjligheten funnits att diskutera och ta del av erfarenheter från samtliga medlemmar, även de som arbetat på andra delar av projektet.
5
Resultat
I det här kapitlet presenteras en systembeskrivning med några av de viktigaste funktionerna som utvecklats under projektets gång. Här finns även resultatet av systemanatomin, tester, projektgruppens erfarenheter samt en sammanfattning av de individuella bidragen.
5.1 Systembeskrivning
Produkten som tagits fram i detta projekt är ett avtalshanteringssystem som ska underlätta arbetet för styrelseledamöter. Funktionalitet som har implementerats är bland annat uppladd-ning av digitala kontrakt, möjlighet att spara relevant metadata för dessa samt visualisering av kontrakts löptider.
5.1.1 Indexvyn
Indexvyn är den vy som först visas när en användare går in på Boardeaser Contracts. Det är från denna vy som all funktionalitet projektgruppen har implementerat utgår från. En skärmbild av denna vy går att se i Figur 5.1.
Huvuddelen av denna vy är en lista med alla kontrakt som är kopplade till valt företag. I listan syns kontraktens namn, totalvärde, startdatum, slutdatum, namn på personen som laddade upp kontraktet samt datumet då kontraktet senast blev uppdaterat. Högst upp till vänster i vyn finns ett sökfält där användare kan filtrera fram kontrakt via deras namn. Visa
fler sökfält-knappen till höger gör att fler sökfält dyker upp under det första sökfältet. Mer om
detta går att läsa i Avsnitt 5.1.2.
Ytterligare till höger finns två radioknappar, Lista samt Gantt-schema. Med dessa går det att växla mellan listvyn och ett gantt-schema där kontraktens giltighetstider finns visualise-rade. Mer om gantt-schemat går att läsa i Avsnitt 5.1.3. Längst till höger finns knappen Lägg
till kontrakt. Denna knapp tar användaren till en vy där ett nytt kontrakt kan laddas upp.
5.1.2 Sökning och filtrering
I indexvyn för kontrakt, där alla kontrakt listas, kan användare söka efter eller filtrera sina kontrakt. Användaren skriver helt enkelt in namnet på kontraktet som ska sökas fram, och
lis-5.1. Systembeskrivning
Figur 5.1: Skärmbild från indexvyn i Boardeaser Contracts
tan uppdateras automatiskt med de kontrakt vars namn matchar det som skrevs in i sökrutan. Högst upp i vänstra hörnet i Figur 5.1 kan nämnda sökfält observeras.
Om en användare vill sortera efter fler parametrar än namnet görs det genom att klicka på Visa fler sökfält-knappen som finns till höger om sökfältet. Då fås ett formulär där fler alternativ kan matas in för filtrering. När information matas in här uppdateras listan med kontrakt som stämmer med filtreringen, precis som med namnsökningen. Figur 5.2 visar en skärmbild av detta.
5.1. Systembeskrivning
För implementation av sökfunktionalitet som automatisk uppdaterar listan av kontrakt, utan ominläsning av webbsidan, används AJAX för att skicka sökparametrar till servern. När användaren skriver in parametrar för filtrering av kontrakt skickas dessa till servern. Den huvudsakliga controllern för projektet, ContractsController, använder Ransack för att söka i databasen efter kontrakten. ContractsController svarar webbläsaren med HTML-innehållet för att rendera listan med de kontrakt som stämmer överens med sökparametrarna. En liknande process sker också med uppdatering av kontrakten i Gantt-schemat, men då skickas datan tillbaka som JSON.
5.1.3 Gantt-schema
Gantt-schemat skapades med hjälp av AmCharts och visar kontrakten som liggande staplar med olika färger, där kontraktets löptid motsvaras av stapelns längd. Om en användare för musen över en stapel visas en liten ruta där det står kontraktets värde, status och hur länge det gäller. Beskrivningen för färgkodningen och informationsrutan kan båda ses i Figur 5.3. Precis som i listvyn för kontrakten fungerar filtreringen även för Gantt-schemat.
Figur 5.3: Gantt-schemats utseende
5.1.4 E-post
Projektgruppen fick vid projektets start som direktiv från kunden att använda Ruby on Rails
Guides på Ruby on Rails officiella hemsida för att hitta information om hur funktionalitet ska
implementeras i projektet. Projektgruppen hittade där en guide för att skicka och ta emot e-post i en Rails-applikation. Hur implementationen sedan gick till med hjälp av denna guide beskrivs i detta avsnitt. E-post funktionalitetens syfte är bland annat att låta användare begära ett avtal från en ingående part. Detta skulle kunna göras genom att applikationen skickar ett e-postmeddelande som aktuell part sedan kan svara på med en bifogad PDF. Applikationen har då funktionalitet för att ladda upp denna PDF som ett kontrakt till någon av användarens styrelser.
5.1. Systembeskrivning
5.1.4.1 Skicka och ta emot e-post i Ruby on Rails
Huvudfunktionaliteten hos applikationens mailer är att ladda upp kontrakt via e-post. Meto-derna confirmation, failed_save, failed_upload, no_attachment och receive lades till i mailern. Alla metoder förutom receive har funktionalitet som skapar ett e-postmeddelande med tillhörande vyer som innehåll.
Projektgruppen identifierade möjligheten att bädda in Ruby-kod i e-postvyerna för att till exempel göra e-postmeddelandena personliga. I failed_save-vyerna lade projektgruppen till kod så att vissa parametrar skickas tillbaka till användaren vid försök till uppladdning via e-post. Syftet var att användaren ska få reda på vad som eventuellt gått fel och kunna rätta till det till nästa försök att ladda upp ett kontrakt.
Projektgruppen använde Ruby-biblioteket Mail för att hämta parametrar som bifogade filer, till- och från-adresser (e-postadresser) samt innehåll i metoden receive. I metoden finns logik som kollar om adressen tillhör en användare med giltig prenumeration och om från-adressen tillhör ett företag i applikationens databas. För alla misslyckade försök att ladda upp ett kontrakt valde projektgruppen att skriva kod som skapar ett e-postmeddelande och skickar tillbaka information om uppladdningsförsöket till från-adressen. Om receive-metoden hittar flera bifogade filer väljs i första hand en fil i formatet PDF, annars den första filen. Den första filen har index 0 i listan med bifogade filer som hämtas med Ruby-metoden attachments. Projektgruppen återanvände redan existerande kod från Boardeaser AB för att skapa och ladda upp ett kontrakt i receive-metoden.
E-post funktionaliteten testades via ett kommando i terminalen som simulerade ett inkom-mande e-postmeddelande till applikationen. För att göra detta behövdes en lokal fil för att representera meddelandet. Denna fil togs fram genom att:
1. Konfigurera e-postklienten Thunderbird för lokalt bruk
2. Skapa filen “.forward” i en lokal användares hemkatalog på Linux/Ubuntu. Filen ska endast innehålla ett namn, exempelvis “email_file”
3. Skapa ett nytt e-postmeddelande i Thunderbird, fyll i valfria fält och bifoga en eller flera filer
4. Skicka e-postmeddelandet till användare@domän
5. Flytta e-postfilen som skapats från hemkatalogen till valfri plats
De e-postmeddelanden som sedan skickades tillbaka från applikationen kunde projektgruppen granska i en webbläsare med hjälp av Mailcatcher. Mailcatcher är en enkel lokal e-postserver med tillhörande bibliotek till Ruby.
5.1.4.2 Ta emot e-post från internet
För att möjliggöra uppladdning av kontrakt via e-post behövde Boardeaser Contracts webbap-plikation först kunna ta emot och hantera e-post från internet. Boardeaser AB använde sedan innan projektets start redan programbiblioteket Postmark för att skicka e-post och föreslog att projektgruppen skulle använda samma bibliotek för att ta emot e-post från internet.
I Griddlers metod som körs för varje mottaget e-postmeddelande, process, lade projektgrup-pen till kod för att hämta vissa parametrar från e-postmeddelandet och skicka dem vidare till metoden receive i klassen UploadMailer. Projektgruppen skapade också en webhook genom att ange följande kodrad i filen routes.rb (enligt Griddlers dokumentation):
post 'email_processor' => 'griddler/emails#create'
Boardeaser Contracts webhook för e-post behövde projektgruppen göra tillgänglig på inter-net. Det är inte en publik webbadress om den bara kan nås från servern där webbapplikationen
5.2. Systemanatomi
körs. Boardeaser AB föreslog att Heroku skulle användas för att lösa detta. Boardeaser AB hade vid projektets start redan konfigurerat Heroku för Boardeaser Contracts. Projektgruppen gjorde en push av sitt projekt till Heroku, vilket gjorde Boardeaser Contracts webhook till-gänglig på internet så att Postmark kan skicka vidare inkommande e-post till den. Boardeaser Contracts webhook blev då tillgänglig på följande webbadress:
https://appnamn.herokuapp.com/email_processor
5.1.5 Notifikationer
Ett senare krav som lades på produkten var att användare och företag ska bli notifierade vid olika händelser för kontrakt. Framförallt ska notifikation ges när ett visst kontrakt är nära på att löpa ut. Dessa notifikationer ska kunna synas på hemsidan. En av de större frågetecknen för den här funktionen var hur den skulle utformas så att en användare kan ta bort en notifikation, eller märka en notifikation som läst, och då undvika att notifikationen direkt dyker upp på nytt vid nästa kontroll av kontraktet. Detta eftersom kontraktet då fortfarande är nära på att löpa ut. Lösningen blev att ha en egen modellklass för notifikationer som har ett attribut vilket säger om notifikationen i fråga är i bruk (ska visas) eller inte. Det skapas alltså endast en notifikation för utgångstid för varje individuellt kontrakt som aldrig tas bort förrän kontraktet det hör till tas bort. På det här sättet kan det sedan också skapas en ny notifikation en viss tid efter den senaste lästes. Nästa problem var att lyckas få applikationen att kontrollera varje kontrakt för bland annat utgångstid regelbundet och i bakgrunden. Att utföra bakgrundsjobb är inget Rails har stöd för ursprungligen, därmed behövdes en extern tjänst för detta. Eftersom Boardeaser AB sedan innan projektets start använt Heroku Scheduler för att skapa bakgrundsjobb, blev det även det som projektgruppen kom att använda i det här fallet. Det var relativt enkelt att implementera då det enda som behövde göras var att lägga koden i en rake task och sedan säga åt Heroku Scheduler att utföra denna med ett visst intervall.
5.2 Systemanatomi
En systemanatomi skapades i början av projekt och reviderades halvvägs in. Anatomin går att se i Figur 5.4. Den hjälpte projektgruppen att få en överblick om vilken funktionalitet som applikationen skulle behöva. Vid starten av arbetet utgick projektgruppen från den när funktionalitet skulle väljas till nästa sprint genom att jobba med bottom-up, det vill säga att börja med den funktionalitet som finns underst i anatomin och jobba sig uppåt. Allt i anatomin var ej saker som explicit skulle eller kunde utvecklas av projektgruppen. Ett exempel på detta var tidsberäkning som på förhand planerades att vara en egen modul, men som fanns inbyggt i det mjukvarupaket som användes för att skapa gantt-schemat. Gränssnittet är en annan egenskap som systemet skulle inneha. Detta var dock något som varje beroende funktion behövde ha en egen av för att fungera. Till exempel behövde Ladda upp kontrakt ett gränssnitt, eller vy som det heter i Ruby on Rails. Visa Gantt-schema var en annan funktion som var beroende av ett gränssnitt, och den behöver också ha en egen vy. Anatomin som skapades innan projektet var bra gjord med de kunskaper projektgruppen hade vid den tidpunkten. Längre in i projektet då kunskapsnivån var högre gjordes en revidering av den, vilket även kunde ha gjorts i slutskedet av projektet. En ytterligare revidering hade dock inte gjort någon nytta för projektet och gjordes aldrig.
5.3 Tester
Projektets tester utfördes inte helt enligt testplanen. Den mesta av koden hade enhetstester för kodens basfall men saknade tester för specialfall. Ett sådant specialfall som inte testades
5.4. Gemensamma erfarenheter
Figur 5.4: Systemanatomi över Boardeaser Contracts
ledde till en bugg där ett företags data raderades ur databasen när användaren tryckte på radera kontrakt.
Enligt testplanen skulle enhetstester som reproducerar eventuella fel implementeras när fel upptäcktes. Dessa enhetstester skulle verifiera att problemet blir löst och användas för att undvika liknande problem. Denna typen av tester skrevs dock inte för de flesta problem som upptäcktes.
Många av gruppmedlemmarna implementerade inga enhetstester och enligt enkätunder-sökningen som gjordes i Bilaga C för gruppens medlemmar, visade det sig att två av sex medlemmar som svarade inte använde testerna under projektet. För de som använde testerna var de dock en bra hjälp för att verifiera att koden fungerade som den skulle.
Användartestet som gjordes på 8 testanvändare i slutet av iteration 3 gav mycket värdefull återkoppling om produktens användarupplevelse. Bra förslag från användartestet implemen-terades i den efterföljande iterationen.
5.4 Gemensamma erfarenheter
Här dokumenteras de erfarenheter gruppen har fått som kan överföras till framtida projekt.
5.4.1 Webbutveckling
Vid start av projektet var det endast en av gruppmedlemmarna som hade någon egentlig erfa-renhet av webbprogrammering. Ingen hade tidigare programmerat i Ruby on Rails, med Sass, Slim eller CoffeScript. Allt detta är saker som gruppmedlemmarna efter projektet känner sig ganska bekväma med. Då projektgruppen var så pass oerfaren när det gällde både webbpro-grammering och de nya språken som skulle användas, tog det över en månad innan gruppen började få förståelse för hur saker fungerade. Under denna period stod arbetet i princip helt stilla och allt fokus låg på att lära sig språken och ramverken. När projektgruppen kom för-bi denna första tröskel gick arbetet mycket smidigare och inlärning kunde komför-bineras med utveckling av applikationen. I slutskedet av projektet flöt arbetet på väldigt bra och största delen av tiden kunde läggas på utveckling.
5.5. Individuella bidrag
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 ElasticSeElasticSe-arch 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å.
6.2. Metod
Ett annat alternativ hade varit att göra en helt egen implementation så att Gantt-schemat kunde anpassas precis efter kundens önskemål. Det hade dock tagit alldeles för lång tid varvid det valdes bort.
6.1.3 Uppladdning via e-post
Som uppladdningen via post ser ut i skrivande stund, skickar användaren ett e-postmeddelande med en bifogad fil som är kontraktet och där företagets namn skrivs in i ämnesraden. Applikationen verifierar att användaren faktiskt tillhör företaget denne försöker ladda upp till. Här hade det, om det funnits en egen e-postdomän, gått att implementera domänvidarebefordring. Det innebär att varje företag tilldelas en egen e-postadress som kon-trakt kan skickas in till, till exempel företag@contracts.boardeaser.com. Kunden föreslog även att alla kontrakt uppladdade via e-post hade kunnat läggas in i en separat lista. Listan skulle sedan en användare kunna gå igenom manuellt och godkänna varje uppladdning. Då hade användaren samtidigt kunnat lägga till metadata innan själva uppladdningen, och om flera filer bifogades hade denne även kunnat välja vilken av filerna som är kontraktet och vilka som är bilagor.
6.1.4 Notifikationer
Notifikationsdelen är visserligen en relativt viktig del av applikationens helhet. Anledningen till att det ändå blev en del som utvecklades sent under projektet, var att det inte egentligen var några andra funktioner som var beroende av att notifikationsdelen var implementerad. Däremot är det en viktig funktion för användaren att ha, speciellt när det gäller något så känsligt som kontrakt. Det är väsentligt att ha stor kontroll över hur det faktiskt ligger till med ett företags innestående kontrakt. Det tog vidare en betydande del av utvecklingstiden att implementera funktionen, just på grund av att det var utmanande att få bakgrundsaktiviteter att fungera korrekt. Detta berodde på att externa program behövde användas för aktiviteter-na. Andra alternativ utforskades med vissa svårigheter innan kunden kom med förslaget att använda Heroku Scheduler.
6.2 Metod
Här diskuteras och kritiseras metoder som använts för utvecklingsarbetet samt för fångande av erfarenheter. En del alternativa metoder som hade kunnat användas tas också upp.
6.2.1 Utvecklingsmetod
Scrum användes som ramverk för utvecklingsarbetet. Scrum efterlevdes dock inte fullt ut ut-an gruppen valde istället ut de delar som på förhut-and verkade passa bra för projektet. Enligt Scrumguiden [88] riskerar man minskad transparens i arbetet om Scrum inte används fullt ut. Projektgruppen kan därför inte utesluta att metoden hade kunnat förbättras om Scrum efterlevts fullständigt. En aspekt av Scrum som gruppen själv önskar använts mer är dagli-ga scrummöten där det funnits möjlighet att diskutera framsteg, framtida planer, eventuella problem och så vidare. Som alternativ till agila ramverk som Scrum finns den klassiska vat-tenfallsmodellen. Gruppmedlemmarna har dock provat att använda vattenfallsmodellen i ett tidigare projekt och är överens om att de föredrar att arbeta enligt ett agilt ramverk. I indi-viduell del D behandlas Scrum och hur det använts i projektet mer detaljerat.
Av praktiska skäl kunde projektgruppen inte hålla fler än ett fysiskt möte med kunden Boardeaser AB. Kommunikationen fick istället ske via chatt och e-post. När projektgruppen demonstrerade applikationen fick det göras via Google Hangouts. Att kommunicera ansikte mot ansikte oftare hade varit att föredra då det ibland kan vara svårt att kommunicera tydligt via text. Ett fysiskt möte hade också varit att föredra för demonstrationen, bland annat för
6.3. Arbetet i ett vidare sammanhang
att inte behöva förlita sig på en stabil uppkoppling till internet. Om gruppen ansträngt sig något mer gällande detta hade det troligtvis gått att ordna 1-2 ytterligare möten. Mer än så bedöms ha varit orealistiskt på grund av avståndet mellan kunden och projektgruppen.
Ruby on Rails användes som ramverk för utvecklingen av webbapplikationen. Det finns många alternativa ramverk som hade kunnat användas istället. Projektgruppen kan inte göra några större uttalanden gällande andra ramverk då ingen i gruppen hade arbetat med webb-utveckling i någon större utsträckning innan detta projekt. I individuell del B görs en teoretisk jämförelse mellan Ruby on Rails och ramverket Django. Ruby on Rails har kritiserats bland annat för bristande skalbarhet. I en intervju med en utvecklare från Twitter-teamet[49], en av de största webbapplikationerna utvecklad i Rails, nämns att de stötte på skalningsproblem långt tidigare än de troligtvis hade gjort med andra ramverk. Intervjupersonen säger också att Ruby rent objektivt är ett långsammare språk än exempelvis Python, vilket kan leda till sämre prestanda. Det tycks högst osannolikt, men inte omöjligt, att applikationen Boardeaser Contracts skulle stöta på de skalningsproblem som upplevdes av Twitter-teamet. Eftersom att applikationen Boardeaser Contracts utvecklats som en utökning av en redan existerande applikation skriven i Rails, gavs ingen valmöjlighet till projektgruppen gällande val av ram-verk. Om en grupp fått som uppdrag att utveckla en webbapplikation från grunden kan det dock vara fördelaktigt att göra ordentliga jämförelser mellan Rails och andra ramverk innan utvecklingen påbörjas.
Att använda kodinspektioner via Git för kodgranskning har fungerat väldigt bra. Allmän policy var att välja någon som ej arbetat med aktuell kod som granskare för att få nya ögon på koden. Granskningarna har främst lett till att brott från uppsatta kodstandarder har upptäckts samt även onödig kommenterad kod. Om projektgruppen hade haft som policy att alltid ha två granskare där en arbetat med delar av koden, medan den andra inte har det, hade gruppen troligtvis haft ännu mer nytta av granskningarna. Genom att låta en person som är mer bekant med koden och hur den ska fungera läsa igenom den, skulle antagligen fler subtila buggar kunna upptäckas.
6.2.2 Testning
Även om testning inte gjordes till den graden som testplanen krävde, var de flesta av gruppens medlemmar nöjda med hur mycket testning som gjordes. Trots att vissa av medlemmarna hade velat ha fler enhetstester för delar av koden. I sitt nuvarande stadie har projektet bara två tekniska fel och inget av dem gör produkten oanvändbar. Utöver det har den manuella testningen kombinerat med användartestet gjort att det finns en lång lista på förbättrings-förslag till framtida iterationer. Mängden tester anses rätt så lagom för en produkt där fel i största delen av koden endast leder till små störningar för användarna.
6.2.3 Metod för erfarenhetsfångst
När det gäller uppfångande av erfarenheter har det fungerat väldigt bra för gruppen att sitta tillsammans i grupprum och arbeta. Det har gett upphov till diskussion och på så vis kan medlemmarna få insikt i delar av projektet som de inte själva direkt jobbat med. En möjlig förbättring hade kunnat vara att göra utvärderingsmötena något mer omfattande.
6.3 Arbetet i ett vidare sammanhang
Applikationen Boardeaser Contracts huvudfunktion är att hantera avtal mellan styrelser och företag. Det innebär att vissa användare av applikationen sannolikt kommer att lagra känsligt material på applikationen. Därför bör höga krav ställas på applikationens säkerhet för att undvika att obehöriga får tillgång till informationen. Projektgruppen som utvecklat Boardeaser Contracts hade på förhand ingen erfarenhet av Ruby on Rails som använts i utvecklingen. Gruppen har försökt använda Rails inbyggda säkerhetsfunktioner till bästa förmåga, men ingen
