A.7 Slutsatser
E.5.1 Kvalitativ j¨ amf¨ orelse av verktyg
Nedan presenteras resultat av den kvalitativa j¨amf¨orelsen av verk- tygen. Installationstiden som syns i tabell 3, 4 och 5 nedan visar att alla tre molnbaserade tj¨anster har l˚ag installationstid och det kan diskuteras huruvida den icke molnbaserade tj¨ansten, dedikerad h˚ardvara som visas i tabell 6, ocks˚a har relativt l˚ag installationstid. Vid j¨amf¨orelse av tids˚atg˚ang vid anv¨andning snarare ¨an installa- tion uppt¨acktes det att varken Heroku eller OpenShift gav n˚agon extra tids˚atg˚ang d˚a dessa verktyg ¨ar automatiserade och integrera- de med ett git-arbetsfl¨ode. Vid anv¨andning av Digital ocean eller dedikerad h˚arvara fanns inga direkta skillnader eftersom b¨agge i praktiken erbjuder samma tj¨anst med skillnaden att en maskin hos Digital ocean ¨ar virtuell. I fallet med gruppens webbapplikation tog det ungef¨ar tv˚a minuter att drifts¨atta applikationen till servern hos Digital ocean eller p˚a den dedikerade h˚ardvaran.
Till gruppens webbapplikation anv¨andes Heroku med gott resultat och gruppmedlemmarna k¨ande sig n¨ojda med tj¨ansten och ans˚ag att den underl¨attade utvecklingsarbetet. Heroku kopplades samman med gruppens git-repo p˚a github och ¨andringar som slogs sam- man med master-grenen driftsattes automatiskt p˚a webben. Heroku kr¨avde inget underh˚allsarbete under projektets g˚ang och upplevdes enkelt att installera. Applikationen k¨ordes utan n˚agra prestandapro- blem via tj¨ansten utan n˚agon erfaren nedtid.
Tids˚atg˚ang f¨or installation av de olika verktygen
Aktivitet Tids˚atg˚ang (minuter)
Skapa applikation hos Heroku 0,5
Koppla applikationen till github-repo 0,5 St¨alla in automatisk drifts¨attning 0,5
Totalt: 1,5
Tabell 3: Tabell ¨over installationstid f¨or Heroku
Aktivitet Tids˚atg˚ang (minuter)
Installtion av Ruby 0,5
Installation av RHC 1
Inst¨allning av RHC 1
Skapa applikation via RHC 2
Uppladdning av kod till OpenShift 0,3
Totalt: 4,8
Tabell 4: Tabell ¨over installationstid f¨or OpenShift
Aktivitet Tids˚atg˚ang (minuter)
Skapa virtuell maskin 2
Logga in via SSH och byta l¨osenord 1
St¨alla in Git 1
H¨amta och starta applikation 1
Totalt: 5
Tabell 5: Tabell ¨over installationstid f¨or virtuell maskin hos Digital Ocean
Aktivitet Tids˚atg˚ang (minuter)
Installation av Ubuntu 10
Installation av Node.js 3
St¨alla in Git 1
H¨amta och starta applikation 1
Totalt: 15
E.5.2 Litteraturstudie
Effektiviteten hos utvecklare ¨okar vid anv¨andning av automatiserad drifts¨attning d˚a tid inte beh¨over sl¨osas p˚a att manuellt uppdate- ra applikationer i produktion. Tiden det tar f¨or en applikation att s¨attas i produktion minskar ocks˚a drastiskt med hj¨alp av dessa verk- tyg. [5] Dessutom minskar riskerna att n˚agot g˚ar fel p˚a grund av den m¨anskliga faktorn n¨ar automatiserad drifts¨attning inf¨ors. [8]
T¨atare uppdateringar g¨or att utvecklarteam f˚ar tillg˚ang till
anv¨andarfeedback snabbare och s˚aledes kan prioritera b¨attre f¨or att i slut¨andan f˚a ut en b¨attre produkt till anv¨andarna. Med manuell drifts¨attning finns risken att utvecklarna l¨agger mycket tid p˚a funk- tionalitet som sedan inte ¨ar anv¨andbar, vilket man f˚ar feedback p˚a f¨or sent. [5]
Anv¨andning av automatiserade verktyg kan hj¨alpa till att minska stress och ¨oka trivseln hos utvecklare p˚a arbetsplatsen d˚a det blir l¨attare att f˚a feedback och bekr¨aftelse att man ¨ar p˚a r¨att sp˚ar med sitt arbete. [8]
Automatiserade drifts¨attningsverktyg l¨ampar sig v¨aldigt bra till t.ex. webbapplikationer eller d¨ar man som utvecklare har kontroll ¨over he- la ekosystemet f¨or applikationen. D¨aremot fungerar det s¨amre vid utveckling av t.ex. applikationer f¨or mobiltelefoner d¨ar man ofta m˚aste f¨orlita sig p˚a tredje part f¨or att n˚a ut med uppdateringar till kund. [4]
E.6 Diskussion
B˚ade i litteraturstudien och den egna unders¨okningen av automati- serade drifts¨attningsverktyg utgicks det ifr˚an att flera personer ar- betade med att programmera en applikation. S˚aledes kan de f¨ordelar som uppt¨ackts m¨ojligen inte g¨alla mindre applikationer som utveck- las av enbart en person.
Vissa av tj¨ansterna och verktygen som tagits upp i unders¨okningen kr¨aver att man litar p˚a tredje part. Vid utveckling av applikationer som hanterar k¨anslig data eller har extrema krav p˚a tillg¨anglighet m˚aste fler parametrar tas i beaktande n¨ar automatiserad drifts¨attning implementeras. Kanske ¨ar det d˚a relevant att utveckla egna verktyg eller k¨ora verktyg som bygger p˚a ¨oppen k¨allkod p˚a egen h˚ardvara f¨or att ha kontroll ¨over hela processen.
E.7 Slutsatser
Slutsatser kan dras kring de tre fr˚agest¨allningarna enligt nedan. 1. Det finns m˚anga f¨ordelar med att implementera automatiserad
drifts¨attning. Effektiviteten hos utvecklare ¨okar, det g˚ar snab- bare att drifts¨atta en produkt och riskerna med att drifts¨atta en applikation minskar. Med automatiserad drifts¨attning n˚ar feedback utvecklarna snabbare och tiden som l¨aggs p˚a on¨odiga funktioner minimeras. Utvecklare som arbetar med en pro- dukt som anv¨ander sig av automatiserad drifts¨attning upplever minskad stress och ¨okad trivsel p˚a arbetsplatsen.
2. Utv¨arderingen av tj¨ansten Heroku visade att den l¨ampar sig bra till sm˚a webbapplikationer. Tj¨ansten upplevdes l¨att att in- stallera och fungerade felfritt under projektets g˚ang.
3. Automatiserad drifts¨attning l¨ampar sig inte till utveckling av mobilapplikationer eller andra applikationer d¨ar man sj¨alv inte har kontroll ¨over distributionen.
F
Gunnar Grimsdal - Webbserver i Node.js
Detta kapitel inneh˚aller det individuella bidraget av projektgrup- pens konfigurationsansvarige. I kapitlet unders¨oks f¨ordelar och nack- delar med att anv¨anda JavaScript och Node.js.F.1 Inledning
Node.js ¨ar en exekveringsmilj¨o f¨or JavaScript som anv¨ander Googles JavaScriptmotor V8. Exekveringsmilj¨on ¨ar open-source och fungerar p˚a de flesta plattformar. Precis som i andra exekveringsmilj¨oer f¨or JavaScript anv¨ands asynkrona funktioner i Node.js.
F.1.1 Syfte
Syftet med denna unders¨okning ¨ar att identifiera f¨or- och nackdelar med att anv¨anda JavaScript i Node.js j¨amtf¨ort med Python och Apache2. [31] Denna kunskap kan i senare projekt bidra till att en utvecklare kan anv¨anda de programspr˚ak och program som passar den specifika uppgiften.
F.1.2 Fr˚agest¨allningar
F¨oljande fr˚agest¨allningar ska besvaras:
1. Vilka f¨or- och nackdelar finns det med att skriva en API-server i JavaScript som exekveras i Node.js j¨amf¨ort med den befintliga webbservern Apache2 som exekverar PHP kod.
2. Vilka f¨or- och nackdelar finns det med att skriva en API-server i JavaScript som exekveras i Node.js j¨amf¨ort med att anv¨anda programspr˚aket Python.
3. Vilka f¨ordelar har asynkrona j¨amf¨ort med synkrona funktioner i en webbserver.
F.2 Bakgrund
Som n¨amnt i inledningen st¨odjer Node.js och JavaScript asynkrona funktioner. Att en funktion ¨ar asynkron betyder att funktioner som tar l˚ang tid, till exempel I/O, v¨antar tills det inte finns n˚agot p˚a
funktionsstacken. Asynkrona funktioner ¨ar en v¨aldigt viktigt egen- skap hos JavaScript d˚a den kod som k¨ors i webbl¨asaren ¨ar singel- tr˚adad och d¨armed inte kan exekvera olika delar av koden samtidigt. Om JavaScriptet i webbl¨asaren ska kommunicera med n˚agon webb- server, vilket ¨ar en l˚angsam operation, kommer denna uppgift v¨anta tills det inte finns andra uppgifter, som att l˚ata anv¨andaren tryc- ka p˚a knappar. Detta leder till att webbsidan inte ”fryser” medan l˚angsamma operationer utf¨ors. En webbserver skriven i JavaScript kan anv¨anda dessa asynkrona funktioner genom att till exempel ta emot nya f¨orfr˚agningar ”samtidigt” som webbservern h¨amtar data fr˚an en databas. Apache2 hanterar detta problem genom att skapa nya tr˚adar f¨or alla nya f¨orfr˚agningar och l˚ater d¨ar med operativsy- stemet hantera vad som ska exekveras.
Ett exempel p˚a skillnaden mellan en asynkron och en synkron funk- tion kan ses i exempelkoden nedan. Om man k¨or JavaScript-koden i kodexempel 6 kommer detta program skicka tillbaka 1 4 2 3 till terminalen medan Python-koden i exempel 7 kommer returnera 1 2 3 4 till terminalen. Det som ocks˚a skiljer dessa tv˚a exempel ¨ar att JavaScript-exemplet kommer att exekveras p˚a cirka 2 sekunder medan Python-exemplet kommer att exekveras p˚a cirka 4 sekunder.
var fun = f u n c t i o n( t e x t ) { c o n s o l e . log ( t e x t ) ; }; c o n s o l e . log (" 1 ") ; s e t T i m e o u t (f u n c t i o n() { fun (" 2 ") } , 2 0 0 0 ) ; s e t T i m e o u t (f u n c t i o n() { fun (" 3 ") } , 2 0 0 0 ) ; c o n s o l e . log (" 4 ") ;
Kodexempel 6: JavaScript med asynkron funktion
f r o m t i m e i m p o r t s l e e p def fun ( t e x t ) : s l e e p (2) p r i n t( t e x t ) p r i n t(" 1 ") fun (" 2 ") fun (" 3 ") p r i n t(" 4 ")
F.3 Metod
F¨or att svara p˚a fr˚agest¨allningarna studerades tidigare skrivna rap- porter samt tre unders¨okningar, beskrivna nedan, utf¨ordes.
F.3.1 Unders¨okning 1
Den f¨orsta unders¨okningen som gjordes var att skapa tv˚a webb- servrar som hanterade HTTP-f¨orfr˚agningar och som b˚ada var en- keltr˚adade. Kodexempel 8 visar den f¨orsta webbserver skriven i Ja- vaScript som exekveras i Node.js. Detta exempel anv¨ander sig av ramverket Express. Kodexempel 9 visar den andra webbservern skri- ven i Python 3, detta exempel anv¨ander modulen http.server. B˚ada dessa exempel startar en webbserver p˚a port 8082 respektive 8081. N¨ar dessa webbserverar f˚ar en HTTP-f¨orfr˚agan exekverar program- men bash-kommandot ”sleep 1”, detta ska simulera en l˚angsam I/O- operation.
var e x p r e s s = r e q u i r e (’ e x p r e s s ’) ;
var app = e x p r e s s () ;
var e x e c = r e q u i r e (’ c h i l d _ p r o c e s s ’) . e x e c ;
// Do I / O o p e r a t i o n
app . get (’ / ’, f u n c t i o n ( req , res ) {
e x e c (" s l e e p 1 ", f u n c t i o n( err , stdout , s t d e r r ) { res . s e n d (’ H e l l o ’) }) ; }) ; app . l i s t e n (8082 , ’ 1 9 2 . 1 6 8 . 0 . 1 2 ’, f u n c t i o n () { c o n s o l e . log (’ s t a r t i n g s e r v e r ... ’) })
f r o m h t t p . s e r v e r i m p o r t B a s e H T T P R e q u e s t H a n d l e r f r o m h t t p . s e r v e r i m p o r t H T T P S e r v e r f r o m os i m p o r t s y s t e m c l a s s M y H a n d l e r ( B a s e H T T P R e q u e s t H a n d l e r ) : def d o _ G E T ( s e l f ) : s e l f . s e n d _ r e s p o n s e ( 2 0 0 ) s e l f . s e n d _ h e a d e r (’ Content - t y p e ’,’ t e x t / h t m l ’) s e l f . e n d _ h e a d e r s () # Do I / O o p e r a t i o n s y s t e m (’ s l e e p 1 ’) s e l f . w f i l e . w r i t e ( b y t e s (" H e l l o ", " u t f 8 ") ) r e t u r n p r i n t(’ s t a r t i n g s e r v e r ... ’) s e r v e r _ a d d r e s s = (’ 1 9 2 . 1 6 8 . 0 . 1 2 ’, 8 0 8 1 ) h t t p d = H T T P S e r v e r ( s e r v e r _ a d d r e s s , M y H a n d l e r ) h t t p d . s e r v e _ f o r e v e r ()
Kodexempel 9: Webbserver i Python 3. [29]
P˚a en virtuell maskin installerades Ubuntu server 16.10 och p˚a den- na maskin installerats sedan versionerna 4.2.6 av Node.js och 3.5.2 av Python. De b˚ada webbservrarna flyttades till den virtuella ma- skinen och startades d¨ar. Efter detta anv¨andes tv˚a Python-skript f¨or att analysera tiden det tog f¨or de olika webbservrarna att svara p˚a ett visst antal HTTP-f¨orfr˚agningar. Python-skriptet som visas i ex- empelkod 10 tar emot tv˚a v¨arden fr˚an konsolen vid start. Den f¨orsta v¨ardet ¨ar vilken port som webbservern k¨ors p˚a och den andra ¨ar hur m˚anga HTTP-f¨orfr˚agningar programmet ska skicka. Med hj¨alp av detta skript kan man analysera tiden det tar f¨or olika webbservrar att svara p˚a ett visst antal HTTP-f¨orfr˚agningar.
i m p o r t u r l l i b . r e q u e s t i m p o r t t h r e a d i n g i m p o r t sys c l a s s m y T h r e a d ( t h r e a d i n g . T h r e a d ) : def _ _ i n i t _ _ ( self , p o r t ) : t h r e a d i n g . T h r e a d . _ _ i n i t _ _ ( s e l f ) s e l f . p o r t = p o r t def run ( s e l f ) : i p _ p o r t = ’ h t t p : / / 1 9 2 . 1 6 8 . 0 . 1 2 : ’+ s e l f . p o r t u r l l i b . r e q u e s t . u r l o p e n ( ip_port , t i m e o u t = 3 0 0 0 ) . r e a d () i = int( sys . a r g v [ 1 ] ) w h i l e i : l o c a l s() [" t h r e a d "+str( i ) ] = m y T h r e a d ( sys . a r g v [2] ,) l o c a l s() [" t h r e a d "+str( i ) ]. s t a r t () i -= 1 i = int( sys . a r g v [ 1 ] ) w h i l e i : l o c a l s() [" t h r e a d "+str( i ) ]. j o i n () i -= 1
Kodexempel 10: Client simulering i Python 3
Python-skriptet som visas i kodexempel 11 tar tiden f¨or att exekvera kodexempel 10 sex g˚anger och skriver sedan ut ett medelv¨arde f¨or tiderna. Genom att k¨ora detta skript p˚a en annan dator i samma n¨atverk som webbservrarna som ska unders¨okas kan tiden det tar f¨or webbservrarna att svara p˚a alla f¨orfr˚agningar analyseras.
i m p o r t os i m p o r t t i m e p o r t = 8 0 8 1 i = 0 f = 0 w h i l e i < 10: v a l u e s = [] w h i l e f < 6: s t a r t = t i m e . t i m e () os . s y s t e m (" p y t h o n 3 c l i e n t . py " + str( i ) + " " + str( p o r t ) ) end = t i m e . t i m e () v a l u e s . a p p e n d ( end - s t a r t ) t i m e . s l e e p (1) f += 1 a l l V a l u e s . a p p e n d ( v a l u e s ) p r i n t(str( i ) +" \ t "+ str(sum( v a l u e s ) /len( v a l u e s ) ) ) i += 1 f = 0
F.3.2 Unders¨okning 2
I unders¨okning 2 testades hur snabb webbservern skriven i Java- Script var j¨amf¨ort med en multitr˚adad webbserver ¨annu en g˚ang skriven i Python 3. Webbservern skriven i Python 3 som anv¨ande multipla tr˚adar ses i kodexempel 12. De tv˚a webbservrarna laddades ¨
annu en g˚ang upp p˚a den virtuella maskinen och startades. Som i f¨orra unders¨okningen anv¨andes Python-skriptet som visas i kodex- empel 11, med ¨andringen att den f¨orsta while-loopen stoppades vid i ≥ 50 ist¨allet f¨or i ≥ 10 samt att i-v¨ardet summerades med tv˚a ist¨allet f¨or ett varje loop.
f r o m h t t p . s e r v e r i m p o r t H T T P S e r v e r f r o m h t t p . s e r v e r i m p o r t B a s e H T T P R e q u e s t H a n d l e r f r o m s o c k e t s e r v e r i m p o r t T h r e a d i n g M i x I n i m p o r t t h r e a d i n g f r o m os i m p o r t s y s t e m c l a s s H a n d l e r ( B a s e H T T P R e q u e s t H a n d l e r ) : def d o _ G E T ( s e l f ) : s e l f . s e n d _ r e s p o n s e ( 2 0 0 ) s e l f . e n d _ h e a d e r s () # Do I / O o p e r a t i o n s y s t e m (’ s l e e p 1 ’) s e l f . w f i l e . w r i t e ( b y t e s (" H e l l o ", " u t f 8 ") ) r e t u r n c l a s s T h r e a d e d H T T P S e r v e r ( T h r e a d i n g M i x I n , H T T P S e r v e r ) : """ H a n d l e r e q u e s t s in a s e p a r a t e t h r e a d . """ i p _ a n d _ p o r t = (’ 1 9 2 . 1 6 8 . 0 . 1 2 ’, 8 0 8 1 ) s e r v e r = T h r e a d e d H T T P S e r v e r ( i p _ a n d _ p o r t , H a n d l e r ) p r i n t (’ S t a r t i n g s e r v e r . . . ’) s e r v e r . s e r v e _ f o r e v e r ()
F.3.3 Unders¨okning 3
Den sista unders¨okningen analyserade hastigheten hos Apache2 som exekverade PHP-kod och den tidigare n¨amnda webbservern skriven i JavaScript. F¨or denna unders¨okning installerades Apache2, PHP5.6 och libapache2-mod-php5.6 p˚a den virtuella maskinen. Webbservern skriven i JavaScript startades p˚a den virtuella maskinen. Ett PHP- program som visas i kodexempel 13 skrevs och flyttades till mappen /var/www/ f¨or att kunna exekveras av Apache2. Utan att ¨andra konfigurationen av Apache2 startades webbservern. Den virtuella maskinen som Apache2 k¨ordes p˚a konfigurerades till att anv¨anda 4 processork¨arnor. Efter detta exekverades samma Pyhton-skript som i unders¨okning 2, kodexempel 11, f¨or att analysera hastigheten hos webbservrarna.
<? php
s h e l l _ e x e x (’ s l e e p 1 ’) ;
e c h o " h e l l o "; ? >
F.4 Resultat
Resultatet f¨or de olika unders¨okningarna visas nedan.
F.4.1 Unders¨okning 1
Resultatet, det vill s¨aga utdata fr˚an Python-skriptet som visas i kodexempel 11, framst¨alls av diagrammet som syns i figur 15.
Figur 15: Diagram ¨over svarstid f¨or ett vist antal f¨orfr˚agningar.
Resultatet ¨ar inte ov¨antat. D˚a webbservern skriven i Python 3 var- ken ¨ar multitr˚adad eller anv¨ander asynkrona funktioner m˚aste ser- vern v¨anta en sekund mellan varje HTTP-f¨orfr˚agan. Svarstiden blir d¨armed linj¨ar med antal f¨orfr˚agningar.
F.4.2 Unders¨okning 2
Tiden det tog att exekvera simuleringsskriptet, se kodexempel 6, med olika m˚anga f¨orfr˚agningar visas i figur 16. Det man kan se i fi- guren ¨ar att webbservern skriven i JavaScript var snabbare, speciellt n¨ar antal f¨orfr˚agningar gick mot 30. Anledningen till detta ¨ar troli- gen att Python-skriptet som skapar en ny tr˚ad f¨or varje f¨orfr˚agning f˚ar mycket st¨orre overhead. Det ska dock noteras att webbservrar- na k¨ordes p˚a en dator med en fyrk¨arnig CPU. Fler k¨arnor i CPU:n skulle bidra till att fler tr˚adar skulle kunna k¨oras samtidigt och d¨ar med skulle Python-skriptet f˚a en b¨attre prestanda.
Figur 16: Diagram ¨over svarstid f¨or ett vist antal f¨orfr˚agningar. F.4.3 Unders¨okning 3
Samma unders¨okning gjordes igen men denna g˚ang med Apache2 och PHP5.6 ist¨allet f¨or webbservern skriven i Python. Resultatet av denna unders¨okning visas i figur 17. Som i de tidigare fallen klarar JavaScript-exemplet att beh˚alla en svarstid p˚a cirka 1 sekund f¨or alla olika antal f¨orfr˚agningar, Apache2 exemplet planar ut vid 2 sekunder.
F.5 Diskussion
Enligt resultatet fr˚an unders¨okningarna ser det ut som att en webb- server skriven i JavaScript och exekverad i Node.js ¨ar betydligt snab- bare ¨an ”motst˚andet” n¨ar det k¨ors p˚a en processor med f˚a k¨arnor. Nimesh Chhetri har publicerat liknande unders¨okningar och resultat i sin rapport A Comparative Analysis of Node.js (Server-Side Java- Script). [7] Nimesh testade precis som vi att s¨atta upp en webbserver exekverad i Node.js och en webbserver med Apache2 som exekverade PHP-kod. Resultatet fr˚an Chhetris tester liknar resultatet fr˚an den- na analys, det vill s¨aga Node.js hade snabbare svarstid. Chhetri tar dock upp CPU-anv¨andning f¨or de olika unders¨okningarna. Fr˚an hans resultat kan man konstatera att Node.js-exemplet anv¨ander 100 % av en CPU-k¨arna medan unders¨okningarna p˚agick och Apache2 anv¨ande 75 % p˚a tv˚a CPU-k¨arnor. En tv˚ak¨arnig CPU anv¨ands i unders¨okningarna.
F.6 Slutsatser
Alla mina unders¨okningar samt unders¨okningarna som Chhetri skrev om visar att webbservarar skrivna i JavaScript som exekveras i No- de.js har snabbare svarstid ¨an en webbserver skriven i Python och Apache2 som exekverar PHP kod. Unders¨okningarna visar dock ba- ra resultatet f¨or exekvering p˚a datorer med f˚a k¨arnor. Med fler k¨arnor hade troligtvis l¨osningarna med multitr˚adning presterat b¨attre. Med detta sagt pekar resultatet mot att asynkrona funktioner pre- sterar v¨aldigt bra i den milj¨o d¨ar testerna utf¨ordes.
G
Johan Nilsson - Utecklingsmetodik och Sc-
rum
Detta kapitel behandlar den individuella delen av kandidatrapporten av projektgruppens utvecklingsledare.
G.1 Inledning
Numera finns det en stor m¨angd olika utvecklingsmetodiker inom systemutveckling. Dessa brukar normalt klassas som antingen tradi- tionella eller agila. Tidigare var metodiker s˚asom vattenfallsmodel- len vanlig, men den och andra liknande traditionella metodiker f¨orde ofta med sig problem inom systemutveckling d˚a dessa inte hade st¨od f¨or att produkten ¨andras under utvecklingen. Dessutom h¨avdas det att det finns st¨orre risk f¨or f¨orsenad leveranstid och ¨okade kostna- der med dessa metoder. [34] Den h¨ar rapporten kommer att f¨ors¨oka avg¨ora om den agila metodiken Scrum passar f¨or ett mindre utveck- lingsprojekt, samt reda ut vad dess f¨or- och nackdelar ¨ar.
G.1.1 Syfte
Syftet med rapporten ¨ar att f¨ors¨oka avg¨ora om Scrum ¨ar en bra utvecklingsmetodik f¨or mindre projekt, samt att unders¨oka om det finns n˚agon annan metodik som passar mindre projekt b¨attre.
G.1.2 Fr˚agest¨allningar
F¨oljande fr˚agest¨allningar ska besvaras:
1. Passar Scrum som utvecklingsmetodik f¨or mindre projekt? 2. Finns det n˚agon annan etablerad utvecklingsmetodik som pas-
G.2 Bakgrund
Programvaruutveckling har nu funnits i ¨over 60 ˚ar, och en m¨angd olika utvecklingsmetodiker har funnits och anv¨ants genom ˚aren. Till en b¨orjan s˚a h¨arstammade dessa utvecklingsmetodiker fr˚an tillverk- ningsindustrin och utmynnade i metodiker s˚asom vattenfallsmodel- len.
Vattenfallsmodellen ¨ar ett typiskt exempel p˚a en s˚a kallad tradi- tionell utvecklingsmetodik. [43] Modellen ¨ar strikt sekventiellt och f¨oreskriver att man ska vara f¨ardig med ett steg innan man forts¨atter till n¨asta del. Modellen har genom ˚aren f˚att en stor kritik f¨or att inte fungera tillr¨ackligt bra, en av nackdelarna med modellen ¨ar att den inte har tillr¨ackligt bra st¨od f¨or f¨or¨andring under utvecklingen. Under 90-talet f¨oddes en rad olika nya utvecklingsmetodiker s˚asom RAD (rapid application development), Scrum och XP (extreme pro- gramming). Dessa metoder har kommit att kallas f¨or agil systemut- veckling. Till skillnad fr˚an de traditionella sekventiella metoderna s˚a s˚a sker agil systemutveckling iterativt, n˚agot som inneb¨ar att arbetet delas upp i olika delleveranser av funktionalitet och att ut- vecklingen av produkten ofta f¨oljs upp genom regelbundna m¨oten mellan utvecklare och best¨allare.
I dagsl¨aget har m˚anga f¨oretag och projektgrupper ¨overg˚att till agila utvecklingsmetoder, men hur v¨al fungerar de j¨amf¨ort med de tra- ditionella metoderna? De agila metoderna ¨ar starkt marknadsf¨orda av The Agile Alliance vilket ¨ar en ideell organisation vars m˚al ¨ar att sprida den agila l¨aran. [12] Den h˚arda marknadsf¨oringen fr˚an The Agile Alliance kan ha gett en onyanserad bild av de traditio- nella metoderna d˚a man p˚ast˚ar att dessa ¨ar i princip ¨ar v¨ardel¨osa. M˚anga f¨oretag har specialiserat sig p˚a utbildning inom agil utveck- ling, n˚agot som ocks˚a kan ha lett till svartm˚alningen av de traditio- nella metoderna. Hur v¨al fungerar d˚a egentligen de agila metoderna gentemot de traditionella?
G.3 Teori
G.3.1 Agil systemutveckling
Agil systemutveckling ¨ar ett samlingsnamn f¨or en rad utvecklings- metodiker som f¨oljer den filosofi och de principer som formulerats i Manifesto for Agile Software Development fr˚an ˚ar 2001. [13] Bak- grunden till manifestet var en rad fallerande IT-projekt, vars miss- lyckande h¨arleds ur orealistiska projektplaner, vikten av dokumenta- tionen framf¨or det faktiska resultatet och kontraktskrivning framf¨or en bra kommunikation mellan kund och projektgrupp.
Grundtanken bakom agil utveckling ¨ar att arbetet ska delas in i iterationer, vilket inneb¨ar att arbetet delas in i flera delar, d¨ar man planerar varje del, utf¨or varje del, och slutligen utv¨arderar varje del. Enligt manifestet s˚a anses det vara m¨anniskorna och kommuni- kationen mellan dem som l¨oser problemen, inte verktygen och den formella dokumentationen. Nedan listas de tolv grundprinciperna f¨or agil utveckling, direkt tagna ur manifestet:
• V˚ar h¨ogsta prioritet ¨ar att tillfredsst¨alla kunden genom tidig och kontinuerlig leverans av v¨ardefull programvara.
• V¨alkomna f¨or¨andrade krav, ¨aven sent under utvecklingen. Agila metoder utnytt- jar f¨or¨andring till kundens konkurrensf¨ordel.
• Leverera fungerande programvara ofta, med ett par veckors till ett par m˚anaders mellanrum, ju oftare desto b¨attre.
• Verksamhetskunniga och utvecklare m˚aste arbeta tillsammans dagligen under hela projektet.
• Bygg projekt kring motiverade individer. Ge dem den milj¨o och det st¨od de beh¨over, och lita p˚a att de f˚ar jobbet gjort.
• Kommunikation ansikte mot ansikte ¨ar det b¨asta och effektivaste s¨attet att f¨ormedla information, b˚ade till och inom utvecklingsteamet.
• Fungerande programvara ¨ar fr¨amsta m˚attet p˚a framsteg.
• Agila metoder verkar f¨or uth˚allighet. Sponsorer, utvecklare och anv¨andare skall kunna h˚alla j¨amn utvecklingstakt under obegr¨ansad tid.
• Kontinuerlig uppm¨arksamhet p˚a f¨orstklassig teknik och bra design st¨arker an- passningsf¨orm˚agan.
• Enkelhet – konsten att maximera m¨angden arbete som inte g¨ors – ¨ar grundl¨aggande. • B¨ast arkitektur, krav och design v¨axer fram med sj¨alvorganiserande team. • Med j¨amna mellanrum reflekterar teamet ¨over hur det kan bli mer effektivt och
G.3.2 Scrum
Scrum ¨ar en metodik f¨or systemutveckling som b¨orjade att imple- menteras under b¨orjan av 1990-talet och formaliserades 1995. Enligt