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
6.3. Arbetet i ett vidare sammanhang
gruppmedlem är helt insatt i detaljer gällande detta. Inga garantier kan därför ges gällande applikationens säkerhet vid överlämningen till kunden. Kunden bör därför försäkra sig om att applikationen har en tillräcklig säkerhetsnivå innan den släpps till användare.
Det finns även miljöaspekter att ta hänsyn till. Här har fokus legat på att belysa inverkan av utformningen av databasanrop på energiförbrukning. Till stöd finns en studie där inverkan av två olika bästa praxis för energieffektiv mjukvara undersökts[66]. Samtliga beskrivna me- toder och resultat i kommande text är tagna ifrån denna studie om inte annat anges. Praxis nummer ett: ”Use efficient queries” är det som kan vara intressant för detta projekt. I studien undersöktes denna praxis genom att iterera över det fullständiga innehållet i alla engelska sidor på Wikipedia. Detta gjordes med två olika typer av förfrågningar till databasen. Först användes följande förfrågan:
SELECT SQL_NO_CACHE a.old_id FROM text a, revision b WHERE a.old_id = b.rev_text_id ORDER BY a.old_id;
För att kunna utföra jämförelsen utfördes sedan samma uppgift efter att bästa praxis applicerats, vilken gav följande förfrågan:
SELECT SQL_NO_CACHE a.old_id FROM text a, revision b WHERE a.old_id = b.rev_text_id
Skillnaden mellan de båda är alltså att förfrågan efter applicerad praxis inte innehåller OR- DER BY och därmed inte sorterar resultaten. Studien visar resultat på upp till 25% minskad energikonsumtion efter applicerad praxis.
Här övergår texten till att beskriva vad projektgruppen har gjort för att anknyta studien till den utvecklade applikationen Boardeaser Contracts. I Figur 6.1 nedan visas ett urklipp från servern när indexsidan för kontrakt ska laddas in.
Figur 6.1: Utdrag från servern vid inladdning av indexvyn
Det kan observeras att nyckelordet ORDER BY förekommer på tre ställen i urklippet ovan. Figur 6.1 visar inte samtliga förfrågningar vid inladdning av indexsidan utan endast en del av dem. Om samtliga förfrågningar visades hade det kunnat observeras att ORDER BY förekom- mer relativt frekvent. Det gäller för samtliga sidor där innehåll från databasen måste hämtas. Det verkar alltså som att den praxis som studien visade inte används för databasförfrågning- arna i applikationen. Det är således möjligt att det skulle gå att minska energiförbrukningen hos applikationen genom att applicera denna praxis. Innan något definitivt kan sägas gällande detta skulle det dock behöva studeras vilka effekter ORDER BY har i övriga delar av appli- kationen. Projektgruppen har inte själva designat dessa databasförfrågningar, den delen sköts av Rails-ramverket. Om tid och resurser finns tillgängliga i framtiden för att undersöka denna del av applikationen skulle det alltså potentiellt gå att minska applikationens energiförbruk-
6.3. Arbetet i ett vidare sammanhang
ning. Det är dock inget som har varit möjligt med de resurser som funnits tillgängliga i detta projekt.
7
Slutsats
I Kapitel 1 framgår det att motivationen bakom projektet var att utveckla en applikation för att hjälpa styrelser att besvara följande frågor:
• 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?
Applikationen ger användarna en plattform att organisera och hålla koll på sina kontrakt. När kontrakten finns samlade i plattformen kan användarna snabbt få en översikt över vilka kontrakt som finns och med filterfunktionen kan användarna hitta kontrakt som skulle kunna leda till risker för företaget.
För att besvara frågorna Uppfyller vi avtalen? och Är vi berättigade till mer? kan använ- darna föra in och visa metadata om alla kontrakt, vilket hjälper till att besvara frågorna utan att manuellt läsa igenom hela kontraktet.
Nedan följer svaren på frågorna som ställdes i Avsnitt 1.3.
7.1 Hur kan Boardeaser Contracts implementeras så att värde
skapas för kunden?
Projektgruppens implementation av Boardeaser Contracts har gjorts för att maximera produk- tens värde på den tiden som projektet har varat. Detta genom hitta bibliotek med så mycket färdig funktionalitet som möjligt för att snabbt kunna utveckla en snygg och välfungerande webbapplikation.
7.2. Vilka erfarenheter kan dokumenteras från arbetet med Boardeaser Contracts som kan vara intressant för framtida projekt?
7.2 Vilka erfarenheter kan dokumenteras från arbetet med
Boardeaser Contracts som kan vara intressant för framtida
projekt?
En erfarenhet var att jobba efter ett företags riktlinjer och direktiv. I början av projektet var det för projektgruppen en stor inlärningskurva när det gäller ramverket Ruby on Rails samt språken Ruby och CoffeeScript. Det var inget alternativ att byta till exempelvis JavaScript istället för CoffeeScript även om det var lockande under vissa perioder av projektarbetet.
Att använda ett ramverk för webbutveckling var för alla i projektgruppen en helt ny erfa- renhet. En av projektmedlemmarna hade testat på webbutveckling innan projektets start men inte inom ett ramverk. Rails hjälpte definitivt gruppen att få en bra struktur på projektet och ramverkets riktlinjer följdes så långt som det var möjligt.