Kodstruktur

Node.js anv¨ander sig av asynkrona callbacks som beskrivet i figur 3. Majoriteten av deltagarna i enk¨atunders¨okningen tyckte att hanteringen av asynkroniska metoder var annorlundare gentemot det sekvensiella t¨anket, vilket gjorde att inl¨arningskurvan blev l¨angre.

B.3.0.7 Pakethanterare

Enk¨atunders¨okningen visar att majoriteten tyckte att pakethanteraren npm hanterade tredjeparts bibliotek p˚a ett bra s¨att. Det uppskattades att npm hanterar nedladdning, sparandet och filstruk- turen.

B.3.0.8 S¨akerhet

I Assessing the Security of Node.js Platform unders¨oks Node.js plattformen ur ett s¨akerhetsperspektiv d¨ar ett antal s¨akerhetsh˚al unders¨oks. Eftersom Node.js k¨ors p˚a en singeltr˚adad event loop, kan tr˚aden blockeras med processering av stora datam¨angder eller logiska server fel. Dessa fel kan i v¨arsta fall avstanna servern helt d˚a exempelvis ett funktionsanrop fastnar i en o¨andlig loop, vilket i sin tur betyder att server slutar vara responsiv f¨or de andra anslutna klienterna.

Javascript ¨ar ett skriptspr˚ak som l¨ange anv¨ants f¨or webbutveckling d¨ar det inte handlat om att k¨ora l˚anga processer utan att varje skript l¨ankas till en specifik webbsida. Om det uppst˚ar pro- blem i skriptet kan anv¨andaren ladda om sidan f¨or att k¨ora koden igen. Denna funktionalitet ¨ar inte ¨onskv¨ard vid utveckling av servrar utan ist¨allet ska processer k¨oras l¨ange och idealt aldrig beh¨ova laddas om. Att ladda om servern skulle inneb¨ara att hela systemet blir icke funktionellt och anslutna klienter beh¨over v¨anta p˚a att servern startat om.

Felhantering i Node.js ¨ar l¨amnade ˚at anv¨andaren och ¨ar ofta en valfri parameter att definiera i sina callbacks. Detta medg¨or att utvecklaren m˚aste alltid hantera och definiera felen f¨or att undvika m¨ojliga krasher.(Andres Ojamaa & Karl Duuna, 2012)

B.3.0.9 L¨arande

Enk¨atunders¨okningen visar att majoriteten tyckte att det fanns mycket material kring Node.js, men att den korrekta information inte alltid var enkel att hitta.

Enk¨aten visade att Javascript gjorde inl¨arningen gick snabbare och upplevdes som n˚agonting positivt. Samtidigt uppfattades Javascript av vissa som ett problem med bland annat asynkrona callbacks och d˚aligt st¨od f¨or objekt och klasser.

B.4

Diskussion

Node.js har v¨axt och blivit mer popul¨art beroende p˚a ett fletal faktorer d¨ar bland annat prestan- datester visar att den utpresterar vanliga alternativ s˚asom PHP och Python-Web vid sm˚askaliga anv¨andartester. ¨Aven i tester gentemot liknande eventbaserade system visar det sig att Node.js utpresterar, speciellt n¨ar server belastas med ett st¨orre antal samman kopplade klienter. F¨orutom prestandatester har popul¨ariteten v¨axt p˚a grund av att Node.js inneh˚aller en bra fungerande pa- kethanterar f¨or att hantera tredjeparts bibliotek. ¨Aven anv¨andandet av Javascript, vilket ¨ar ett familj¨art skriptspr˚ak g¨or utvecklandet enklare att komma ig˚ang med.

Det finns ¨aven nackdelar med Node.js som visas i enk¨aten d¨ar m˚anga anser att asynkrona funk- tionsanrop (se figur 3) inte alltid k¨anns naturligt. Det kan bli komplicerat att f¨olja en kodstruktur d¨ar ett antal asynkrona funktionsanrop g¨ors tillsammans. Koden kan l¨att bli n¨astlad och kodmo- dul¨ariteten f¨ors¨amras, som visas i figuren nedan.

Det finns hj¨alpmoduler som kan installeras i npm som l¨oser dessa problem, exempelvis kan bibli- oteket async anv¨andas f¨or att undvika n¨astlade funktioner.

Figur 24 – N¨astlade funktionsanrop

Det ¨ar inte alltid sj¨alvklart vilka bibliotek som ska anv¨andas, om biblioteken ¨ar stabila eller om biblioteken uppn˚ar den s¨akerhetsstandard som applikation har. Detta ¨ar ett problem i sig, d¨ar Javascriptmotorn var fr˚an grunden t¨ankt att skapa dynamiskt inneh˚all f¨or webbsidor och ¨ar inte anpassade f¨or serversidan.(Questions with Creator Ryan Dahl , u. ˚a.)

Vid besvarandet av fr˚agest¨allningen anv¨andes litteraturstudier av vetenskapliga artiklar, nyhe- ter och intervjuartiklar f¨or att forma en ˚asikt och bakgrund kring Node.js. Dessa k¨allor k¨anns trov¨ardiga och faktam¨assigt r¨att, samt att de dubbelkollades mot andra k¨allor.

N¨ar prestandatester utf¨ors som i kapitel 3.0.5 blir det alltid sv˚art att utf¨ora r¨attvisa tester d¨ar alla delar av ett serversspr˚ak visas upp. Det viktigaste ¨ar att testet visar hur Node.js presterar gentemot andra popul¨ara altenativ n¨ar det g¨aller exempelvis tunga I/O-operationer och select operationer i databaser. D˚a I/O-operationer och select operationer ¨ar fundamentala och mycket vanliga transaktion mellan klient och server, speciellt n¨ar webbutveckling skiftar allt mer mot en datadriven arkitektur.(Kai Lei m. fl., 2014) Det tv˚a testerna som utf¨ordes i Node.js Paradigms and Benchmarks samt Performance Comparison and Evaluation of Web Development Technologies in PHP, Python and Node.js visade h¨og insikt av testmilj¨oerna och valet av tester var v¨al motiverade f¨or det som skulle testas.

Enk¨atunders¨okningen fyller fuktionalitet i att bilda en ˚asikt ¨over faktorer som inte ¨ar lika tekniska s˚asom kodstruktur och inl¨arning. Majoriteten av deltagarna i enk¨aten var studenter som har haft erfarenhet i att programmera i Node.js, detta inneb¨ar att enk¨aten inte t¨acker in alla omr˚aden, ¨

aven om svaren ofta h¨oll sig till normen av vad som tycktes var bra och s¨amre med Node.js.

B.5

Slutsatser

F¨or att besvara fr˚agest¨allningen om varf¨or Node.js har blivit popul¨art s˚a m˚aste ett flertal faktorer analyseras. I resultatdelen visar prestandatesterna att Node.js utpresterar serveralternativen PHP och Python-Web. Att Node.js presterar bra i tester ¨ar en viktig faktorer till att popul¨ariteten v¨axt.

Enk¨atunders¨okningen visar att mycket information och kodexempel p˚averkade inl¨arningen posi- tivt. ¨Aven att Javascript anv¨andes som spr˚ak gjorde att inl¨arningen blev mer familj¨ar och att det var enklare att komma ig˚ang med kodande.

Resultat visade att callbacks funktionalitet k¨andes fr¨ammande, speciellt om man kommer fr˚an ett programmeringst¨ank d¨ar ett sekvensiellt t¨ank ¨ar mer naturligt. ¨Aven att Javascript inte har bra st¨od f¨or klasser och objekt g¨or det sv˚arare att utf¨ora specifika uppgifter.

C. Fredrik - Kvalitetsplan

C.1

Inledning

Jag b¨orjade mitt arbete i detta projekt som kvalitetssamordnare, dock s˚a hoppade en medlem av i mitten av projektet och d˚a f¨orsvann ¨aven v˚ar gruppledare, en roll som jag nu har tagit ¨over. Jag har d¨arf¨or valt att f¨ordjupa mig i min roll som gruppledare och kvalitetssamordnare f¨or att se om anv¨anda en Team Risk Management vore en bra metod att anv¨anda i detta kandidatprojekt. Eftersom vi har st¨ott p˚a ett par problem som skulle kunna hanterats p˚a ett b¨attre s¨att t¨ankte jag ¨

aven unders¨oka om det finns ett bra s¨att att hantera risker med en riktig riskhanteringmetod. N˚agra fr˚agor som jag s¨oker svar p˚a. Hur f¨orbereder man sig p˚a oplanerade risker? Det g˚ar sannolikt att f¨orebereda sig f¨or alla m¨ojliga risker, men ¨ar det konstruktivt att g¨ora det? Var drar man gr¨ansen till vad som faktiskt ¨ar effektivt och konstruktivt?

C.1.1

Syfte

Syftet med denna rapport ¨ar att ta reda p˚a om det g˚ar att f¨orebereda sig f¨or outf¨ors¨agbara h¨andelser, samt att kunna hantera dessa risker p˚a ett effektivt och smart s¨att. Jag hoppas ¨aven f˚a en b¨attre ¨overblick hur man f˚ar en bra kommunikation i gruppen.

C.1.2

Fr˚agest¨allning

• Hur f¨orbereder man sig p˚a oplanerade risker p˚a b¨asta s¨att?

• Hade Team Risk Management varit en bra riskhanteringsmetod i detta projekt?

C.1.3

Avgr¨ansningar

Jag kommer enbart att fokusera p˚a riskhantering och kommunikation som h¨or till projektgrupper som h˚aller p˚a med mjukvaruproduktion.

C.2

Bakgrund

Jag blev tilldelad en projektgrupp under tiden jag var borta i ˚Are. N¨ar jag kom tillbaka s˚a hade min grupp blivit tilldelade projektet Dricksvatten. I detta projekt har vi haft m˚anga ov¨antade h¨andelser som skulle kunna hanterats p˚a ett mer effektivt s¨att. Under den f¨orsta iterationen s˚a var en medlem sjuk i tv˚a veckor. Detta st¨allde inte till med n˚agra j¨atteproblem men det var en ov¨antad risk som vi inte hade t¨ankt p˚a speciellt mycket och som vi inte heller hanterade p˚a ett vettigt s¨att. N˚agra veckor senare valde denna medlem dessutom att hoppa av kursen, detta var n˚agot vi inte var f¨orbereda p˚a. ¨Aven om ¨overg˚angen gick b¨attre ¨an f¨orv¨antat s˚a skulle det vara ¨

onskv¨art att ha skrivit en riskplanering som ocks˚a kunde ha anv¨ants f¨or att hantera h¨andelsen ¨

annu b¨attre.

I b¨orjan av projektet startade vi en SMS-grupp f¨or att ha ett s¨att att f¨ora kommunikationen p˚a, den har dock inte blivit anv¨and s˚a mycket som jag hade hoppats och var egentligen enbart en tempor¨ar l¨osning. Vi f¨ors¨okte under en tid att hitta andra alternativa l¨osningar, till exempel s˚a tittade vi om det fanns ett plugin till Redmine eller om vi skulle anv¨anda Trello. Ett plugin till Redmine verkade inte existera som skulle tillfredsst¨alla v˚ara m˚al. Trello tyckte gruppen k¨andes on¨odigt n¨ar vi redan best¨amt att vi skulle anv¨anda Redmine. En IRC kanal var ocks˚a uppe p˚a diskussion men intresset f¨or detta var ocks˚a v¨aldigt l˚agt. Jag tog ett eget beslut att anv¨anda Skype och har sedan dess f¨ors¨okt att f˚a alla att installera Skype, ett program som till˚ater en att ha b˚ade ha textkonversationer och r¨ostsamtal. Mer ¨an halvv¨ags in i projektet hade fortfarande inte alla

programmet p˚a sin dator och till slut hittades en annan l¨osning i form av en Facebook grupp. Kommunikation har varit ett genomg˚aende problem i projektet.

C.3

Teori

Den definition av risk jag anv¨ander ¨ar definierad av Software Engineering Institute (SEI) som ¨

ar en del av Carnegie Mellon University i Pittsburgh, Pennsylvania. De har definierat risk som chansen att g¨ora en f¨orlust (Higuera, Dorofee, Walker & Williams, 1994). Denna f¨orlust kan vara i form av f¨ordr¨ojd tid, s¨amre kvalit´e p˚a produkten, ¨okad kostnad eller totalt misslyckande. Team Risk Management (TRM) eller gruppdriven riskhantering ¨ar en metod f¨or att hantera pro- jekt med fokus p˚a bra resultat genom att arbeta med riskhantering som en grupp. F¨or att kunna ha en fungerande riskhantering kr¨avs det att alla gruppmedlemmar kommunicerar med varandra. Det g˚ar inte att en person sk¨oter hela riskanalysen, hela gruppen m˚aste jobba tillsammans f¨or att ta fram alla potentiella risker. Samma g¨aller n¨ar det kommer till att l¨osa problemen som uppkom- mit, gruppdriven riskhantering kr¨aver att man inte pekar finger. Alla sorter av kommunikation ¨ar till˚aten och uppmuntras (Higuera & Haimes, 1996).

Det finns det tre stycken faser i riskanalysen (Williams m. fl., 2006). Den f¨orsta fasen ¨ar till f¨or att identifiera de risker som finns. Det kan man g¨ora genom att till exempel brainstorma, skriva enk¨ater och intervjua medlemmar i gruppen.

I den andra fasen skall man prioritera dessa risker. Sannolikheten och konsekvensen ifall risken skulle intr¨affa ger en bra ¨overblick p˚a hur man b¨or prioritera den. ¨Ar det en risk som ¨ar v¨aldigt sannolik att intr¨affa och samtidigt ¨ar v¨aldigt allvarlig ¨ar det uppenbart att den m˚aste prioriteras h¨ogt. Ett bra s¨att att se hur h¨og prioritet en risk har ¨ar att g¨ora en s˚a kallad ’risk impact’ graf. Dessa ¨ar konstruerade med sannolikheten f¨or risken p˚a en axel och hur allvarlig konsekvensen ¨ar p˚a den andra. Denna typ av graf kan g¨oras p˚a flera olika s¨att (Pritchard, 2014).

Figur 25 – Exempel hur en ’risk impact’ graf kan se ut.

Ett effektiv variant ¨ar att gradera hur sannolik det ¨ar att risken intr¨affar p˚a en skala fr˚an 0 till 100 % och bed¨omma konsekvensen ifall den intr¨affar p˚a en skal fr˚an till exempel 0 till 1000 som visas i figur 25. Att sedan placera in dessa i en graf s˚a f˚ar man en tydlig bild av vilka risker som b¨or prioriteras. Dessa typer av grafer kallas f¨or ’risk impact’ eller ’probability charts’.

ett effektivt s¨att.

Ska man implementera en riskhanteringsmetod som TRM i sitt projekt s˚a slutar inte de olika risk- hanteringsmomenten efter en riskanalys har skrivits. F¨or att f˚a full kontroll ska man kontinuerligt uppdatera sin riskplanering och riskanalys. Enligt SEI tar det 18 till 24 m˚anader att l¨ara upp personal samt implementera alla metoder som kr¨avs efter ett beslut har tagits om att byta till TRM. (Higuera m. fl., 1994; Higuera & Haimes, 1996). Figur 26 visar hur denna process ser ut.

Figur 26 – Kontinuerligt arbete kr¨avs f¨or Risk Management.

C.4

Metod

F¨or att ta reda p˚a om TRM skulle vara en bra metod har jag skapat en enk¨at d¨ar jag tar reda p˚a de erfarenheter och ˚asikter de andra gruppmedlemmarna har haft under detta projekt ang˚aende v˚ar riskhantering. Denna enk¨at, som kan ses i bilaga F.1.5, utg˚ar jag fr˚an n¨ar jag diskuterar och analyserar. Jag har dessutom letat upp ett par olika vetenskapliga artiklar som beskriver TRM samt hur man f¨orebygger risker, b˚ade innan de h¨ander, under och efter.

C.5

Resultat

C.5.1

Risker

Ett b¨asta s¨att f¨or att hantera risker finns inte, men ett bra s¨att ¨ar att f¨olja en riskhanterings- metod fullt ut. Att g¨ora en gedigen riskanalys och sedan forts¨atta att kontinuerligt arbeta med riskhanteringen under projektets g˚ang.