Mätning

För att utföra underhållbarhetsmätningarna användes verktyget Complexity-report [33]. En mätning utfördes på varje projekts respektive kodbas, inklusive Knekts. För att ge ett rättvist resultat vid mätningarna var det viktigt att försäkra sig om att Complexity-report endast analyserade projektspecifik kod, och inte exempelvis källkoden till bibliotek eller ramverk som använts i projekten. Complexity-report är ett kommandoradsverktyg, och följande kom- mando användes för att utföra mätningarna:

Kodexempel A.1: Invokering av Complexity-report.

cr -o <projektnamn>-report.txt <kataloger med projektspecifik kod>

Complexity-report sparade då resultatet av analysen i den specificerade utdatafilen. Ut- datafilen inleddes med en sammanställning av mätningarna, där bland annat det resul- terande MI-värdet kunde utläsas.

A.5

Resultat

I tabell A.1 presenteras de respektive projektens MI-värden.

Tabell A.1: MI-värden för de undersökta projekten.

Projekt MI-värde

Ember.js Dashboard 139,7

FoodMe 135,0

CustomerManagerStandard 129,2

Knekt 115,1

De resultat som presenteras i tabell A.1 är det genomsnittliga MI-värdet över alla moduler i respektive projekt. MI-värdet har avrundats till fyra värdesiffror. Sammanfattningen från Complexity-reports rapportfil för de olika projekten återfinns i bilaga 3.

A.6

Diskussion

Här diskuteras tillvägagångssätt som använts och resultat som erhållits under studien. Eventuella felkällor behandlas också. Värt att notera är att resonemang som förs här bör ap- pliceras med försiktighet på andra projekt där omfattningen skiljer sig mycket jämfört med

A.6. Diskussion

projekten i den här studien. Det kan tänkas att den infrastruktur ramverken tillhandahåller gör ett litet projekt mycket mer komplext är nödvändigt. På samma sätt kan tillvägagångssät- tet utan ramverk bli ohållbart i ett större projekt där tydlig struktur och fasta konventioner krävs.

A.6.1

Metod

Något som bör klargöras när mätningar av den typ som beskrivs i rapporten utförs är att måtten som erhålls inte är absoluta mått på underhållbarhet. Det finns flera andra faktorer som inte tas i beaktande med metoden och måtten som använts i studien, exempelvis kod- kommentarer.

Data som fås genom underhållbarhetsmätningar används kanske lämpligast genom att stud- era om det finns oregelbundna tendenser i denna. Finns moduler som kraftigt avviker till det sämre i mätningarna kan det vara en anledning att manuellt granska modulerna i fråga och undersöka orsaken till de dåliga värdena.

Den data som använts i studien har också hämtats från ett litet antal projekt. Ett större antal hade gett ett resultat som varit statistiskt säkrare, men hade tagit längre tid.

Det går också att ställa sig frågan vad som är mest fördelaktigt av att antingen behöva lära sig ett ramverk för att förstå en ny kodbas, eller enbart sätta sig in i kodbasen givet att utveck- laren i fråga redan är förtrogen med det använda språket. Det kan tänkas att utvecklaren lätt kan sätta sig in i koden när denne väl lärt sig ramverket och dess principer. Det kan å andra sidan också vara lättare för utvecklaren att enbart sätta sig in i en kodbas utan ramverk beroende på ramverkets inlärningskurva. Detta är situationsberoende, och i det hänseendet ger inte MI-måttet någon information. Handlar det om ett åtagande att underhålla kodbasen under en längre tid kan det vara fördelaktigt att först utbilda sig i ramverket, och sedan i gengäld ha en mer trivial kodbas att arbeta med. Handlar underhållsarbetet däremot om min- dre sporadiska åtgärder kan utbildningen bli ett orimligt stort moment relativt åtgärderna.

A.6.2

Felkällor

De externa projekt som mätningarna utfördes på är skrivna av erfarna webbutvecklare, och medlemmarna i det här projektet hade inledningsvis en mycket begränsad erfarenhet av webbutveckling. Det är möjligt att resultatet sett annorlunda ut om medlemmarna hade haft en annan bakgrund.

Projekten har också en relativt begränsad omfattning, det är möjligt att skillnaderna i re- sultatet varit tydligare i större projekt, där den struktur och de mekanismer ramverken tillhandahåller visar sin fulla potential.

I och med att ett antal projekt fick uteslutas då Complexity-report inte kunde hantera den utökade JavaScript-funktionaliteten som använts i dessa projekt blev dataunderlaget mindre än planerat. Resultatet kunde sett annorlunda ut om dessa projekt tagits med. Studien behandlar följaktligen inte heller effekten av funktionaliteten som inte kunde hanteras.

A.6.3

Resultat

I det erhållna resultatet syns att Knekts MI-värde ligger lägre än de andra projekten. Det kan finnas flera orsaker till detta. Exempelvis analyserades enbart projektspecifik kod i de tre externa projekten, vilket innebär att grundläggande funktionalitet som abstraheras

A.7. Slutsatser

bort av ramverken inte tas med i analysen. I analysen av Knekt behandlas sådan kod som projektspecifik vilket kan bidra till det erhållna resultatet.

Det nämndes tidigare under diskussionen om felkällor att projektmedlemmarna hade väldigt begränsad erfarenhet av webbutveckling innan det här projektet. Det kan också vara en bidragande faktor.

För att sammanfatta resultatet så erhöll Knekt komplexitetsmässigt en sämre underhållbarhet än motsvarande externa projekt där ett ramverk använts. Att detta leder till sämre underhåll- barhet är inte helt säkert. Vad resultatet däremot berättar är att system som utvecklas ovanpå ett ramverk får en kodbas som är mindre komplex då ramverken i sig exkluderas. Den kod utvecklare som underhåller systemet behöver bekanta sig med blir mer trivial, förutsatt att utvecklarna känner till ramverket.

Något som dock ska tas i beaktande om ett ramverk väljs på grund av en önskan om långsik- tigt underhåll och vidareutveckling är att ramverk kan sluta underhållas av de utvecklare som står bakom ramverken. Det är en risk som får bedömas utifrån vilket ramverk som väljs, vilken organisation som underhåller det och hur modernt ramverket är.

A.7

Slutsatser

Slutsatserna som kan dras från studien blir att system som utvecklas med hjälp av ett ramverk får en projektspecifik kodbas som blir mindre komplex än kodbasen hos ett motsvarande projekt utvecklat utan ramverk. Det bidrar till kod som har en högre underhållbarhet. Huruvida den totala underhållbarheten påverkas positivt eller negativt är det svårt att göra ett generellt uttalande om. Det beror på hur enkelt en utvecklare som inte är bekant med det använda ramverket kan tillgodogöra sig tillräcklig kunskap för att kunna utföra underhåll på ett tillfredsställande sätt. Om det endast är mindre korrigeringar som ska utföras kan ansträngningen som krävs för att lära sig ett ramverk bli oproportionerligt stor relativt förän- dringarna som ska utföras. Handlar det däremot om långsiktigt underhåll och eventuell vidareutveckling lönar det sig att använda ett ramverk då det i det långa loppet är till fördel för framtida utvecklare. Detta eftersom ramverken ger en komplexitetsmässigt enklare kod- bas att arbeta med, och tiden det tar att lära sig ramverket blir liten i förhållande till den tid som spenderas på utveckling.

Gällande Knekt dras slutsatsen att ett ramverks påverkan på dess underhållbarhet till sist beror på vilken typ av vidareutveckling som utförs av kunden i framtiden. Handlar det om mindre underhållsarbete för att hålla systemet i funktionellt skick är valet att inte använda ett ramverk fördelaktigt. Om däremot omfattande funktionalitet läggs till kan det vara så att ett ramverk hade förenklat det framtida arbetet, dock med en existerande risk att det ramverk som valts idag inte underhålls längre fram i tiden då dessa omfattande tillägg blir aktuella.

B

Kimberley French: Värdet av en

prototyp

B.1

Inledning

Hur går man tillväga vid utformningen av ett nytt grafiskt användargränssnitt? På vilket sätt underlättar en prototyp för utvecklingsarbetet och är det värt den tidsinvestering som krävs? Denna rapport utforskar vilken betydelse prototypning har i framtagandet av ett mjukvarusystem.

B.1.1

Syfte

Syftet med arbetet är att undersöka vilka för- och nackdelar det finns med att göra en proto- typ i samband med utvecklingen av ett mjukvarusystem. Rapporten behandlar de faktorer som har framträtt för denna projektgrupp och andra projektgrupper i kursen TDDD96 Kan- didatprojekt i programvaruutveckling. Även de processer som kan användas för att arbeta fram en prototyp presenteras i korthet.

B.1.2

Frågeställning

Rapporten behandlar frågeställningarna nedan. 1. Vad finns det för värde i att ta fram en prototyp?

2. Vilka nackdelar finns det med att arbeta med prototyper?

3. Vilka processer är lämpliga att använda i framtagandet av en prototyp för mjukvarusys- tem?

B.2

Bakgrund

I och med utvecklingen av ett nytt webbaserat system måste ett grafiskt gränssnitt utfor- mas. Gränssnittet är systemets interagerbara representation som används för att kunna ta del av dess funktionalitet. Därför är det viktigt att systemet är användbart för sin målgrupp och simpelt att lära sig. Till hjälp i beslutstagandet görs ibland prototyper, detta för att ut- forska olika alternativ och få en bild av vad slutresultatet kan bli. Prototyper används ofta till användartester och för tidiga demonstrationer för kund. De underlättar även vid utveck- lingen av systemet. Det finns dock en risk att prototyputvecklingen kräver mycket tid och att kostnaden för den färdiga prototypen är högre än nyttan den bidrar med [38]. Rapporten

B.3. Teori

undersöker om så har varit fallet för projektgrupper i kursen TDDD96 Kandidatprojekt i pro- gramvaruutveckling.

B.3

Teori

Detta kapitel beskriver vad en prototyp är och benämner några olika klasser av prototyper. Processen för hur ett interaktivt system kan arbetas fram behandlas också, där olika faser beskriver arbetet från idé till färdig produkt.

B.3.1

Prototyper

En prototyp är ett till synes fungerande system eller delsystem där endast ett begränsat antal funktioner är implementerade. Prototypen används för att testa de designbeslut som tagits vilket i sin tur avgör ifall vissa delar bör omarbetas innan implementering av systemet sker. Eftersom prototypen inte är tänkt att vara ett färdigt, fungerande system kan man simulera de delar som inte kan eller behöver byggas i detta skede – så länge systemet upplevs vara färdigt på ytan kan variabler och sökresultat vara hårdkodade. [5]

Beroende på vad syftet med prototypen är kan den utformas på olika sätt. Nedan följer en kort beskrivning av olika klasser av prototyper enligt Floyd [38]:

• Utforskande prototypning används för att förtydliga systemkraven och diskutera al- ternativa lösningar.

• Experimentell prototypning presenterar en lösning på ett känt problem och används för att testa funktionaliteten av denna lösning.

• Evolutionär prototypning innebär att utforma prototypen i flera steg där varje version anpassas efter de krav som uppstår allt eftersom utvecklingen sker.

Till skillnad från den evolutionära typen, kastar man ofta bort utforskande och experi- mentella prototyper efter att de byggts och testats. Denna typ av prototyper brukar refer- eras till som temporära. Tanken bakom en temporär prototyp är att de skall göras billiga och utan större ansträngning så att de idéer som testas är enkla att kassera om det skulle visa sig att de inte var bra. Evolutionära prototyper används ofta i projekt med agila arbetsmetoder, exempelvis Scrum [1], där varje version utvecklas under de så kallade sprintarna. [5]