sätta upp en fysisk tavla med lappar på. På fråga 6, om man tror att det hade fungerat bättre med en fysisk tavla istället för den på Trello, svarade fem av sex nej och en person svarade ja, se tabell H.6. Därmed verkar det som även verktyget Trello har fyllt sin funktion i projektet. En faktor som dock inte fångas av metoden och därmed inte heller står att finna i resultatet i enkäten, är det faktum att projektgruppen inte har haft en fast lokal att jobba i, och heller inga fasta timmar där alla alltid samlas. Det gör att det blir praktiskt svårt att använda sig av en fysisk tavla. Tyvärr framgår det inte av undersökningen om det är denna anledning eller något annat som gör att man inte vill se en fysisk tavla. I vilket fall så lämpar sig Trello antagligen bättre för den här typen av projekt, där varken arbetsplats eller arbetstider är fasta. När brädet finns på internet kan man lätt komma åt det oavsett var man är, med den möjliga nackdelen att det är lättare att glömma bort.
E.7
Slutsatser
Här presenteras svaret på de frågeställningar som ställs i rapporten.
E.7.1
Vilka fördelar har projektet dragit av att jobba med ett Kanban-bräde?
Framförallt har det gett projektmedlemmarna en god översikt över vad som händer i pro- jektet. Det har även hjälpt att visa vad som finns kvar att göra i projektet, samt vad som har gjorts. Även om projektet kanske inte har lyckats utnyttja Kanban till dess fulla potential så har det varit till hjälp och givit det stöd projektgruppen hade förväntat sig. Projektmedlem- marna får även med sig användbar kunskap till framtida arbeten i projektform.
E.7.2
Vilka nackdelar och kostnader har det inneburit för projektteamet att
jobba med ett Kanban-bräde?
Kanban har i princip inte inneburit några kostnader för projektet. Lite overhead har funnits i att sköta Kanban-brädet, men det är försvinnande lite i projektets sammanhang. Eventuellt har det kommit i vägen för något annat verktyg som hade kunnat ge bättre resultat. Men med tanke på projektmedlemmarnas tidigare erfarenheter och önskningar, samt projektets omfattning så är det troligtvis ingen större vinst som hade kunnat erhållas med en annan metodik.
E.7.3
Har verktyget Trello varit ett passande verktyg att bedriva Kanban genom?
Trello har varit ett bra verktyg att bedriva Kanban genom. För projektets omständigheter har det varit passande och täckt upp för brister som skulle funnits hos ett fysiskt bräde.
F
Koddelning i webb- och
mobilapplikationer med React av
Oscar Thunberg
F.1
Introduktion
Vid utveckling av mjukvara kan det vara fördelaktigt att dela kod mellan så många delar i projektet som möjligt. Hur mycket som kan delas beror i stor del på vilka verktyg och språk som används vid utvecklingen. I projektet användes Xamarin för att skriva Mobilapplika- tionen medan React användes för att skapa Webbgränssnittet. För att försöka effektivisera framtida arbete undersöktes fördelar och nackdelar med att använda React Native istället för Xamarin.
F.1.1
Syfte
Syftet med rapporten är att undersöka hur projektgruppen skulle kunna förändra och åter- använda kod mellan Webbgränssnittet och Mobilapplikationen i utvecklingen av Kunderbju- dande i molnet. Rapporten kommer fokusera på biblioteken som användes i Webbgränssnittet och hur mycket som måste förändras för att fungera i en mobilapplikation med ramverket React Native samt omdisponeringen av tid där emellan.
F.1.2
Frågeställning
1. Hur stor del av kodbasen i Webbgränssnittet är kompatibel i en React Native- implementation av Mobilapplikationen?
2. Hur mycket tid har vi lagt på att skriva liknande kod i Webbgrässnittet och Mobilappli- kationen, hur mycket skulle kunna besparas med koddelning?
F.2
Bakgrund
Under analysfasen i projektet undersöktes vilket ramverk som skulle användas för mobi- lapplikationer, eftersom kund hade föreslagit Xamarin så föll valet på det. På papper lät det bra: stöd för de stora plattformarna Windows Phone, Android och iOS, ett moget commu- nity, Microsoft som utgivare och samma språk som Molntjänsten. Under utvecklingen av Mobilapplikationen märktes en ökande problematik med ramverket Xamarin, exempelvis
F.3. Teori
krascher av operativsystem, ominstallationer av Windows och svårigheter att dela kod mel- lan Android och iOS.
Vid upptäckten av React Native var utvecklingen för långt gången för att ändra vilka biblio- tek och ramverk Mobilapplikationen skulle byggas av. Då uppstod frågan om hur bra React Native hade kunnat fungera i vårt projekt och hur mycket kod som skulle kunna delats med Webbgränssnittet. I Webbgränssnittet användes React för att skapa en komponentbaserad vy.
F.3
Teori
Här framkommer bakgrund och teorier som ligger till grund för rapporten, utöver denna teoridel förväntas projektteorin vara läst.
F.3.1
React Native
React Native är motsvarigheten till React 3.5.3 på mobila enheter [61] [62]. Precis som React är React Native komponentbaserat i JavaScript och kan i vissa fall använda exakt samma kod som React. Det innebär även att det använder samma trädstruktur som React. React Native stödjer även plattformsspecifik kod med komponenter som definieras olika beroende på operativsystem och importering av bibliotek vilka utvecklats för plattformen. Resultatet är plattformsspecifika applikationer med samma utseende som applikationer skrivna med tillhörande plattforms utvecklingsverktyg.
F.3.2
JavaScriptCore
React Native körs inte i en webbläsare och använder därför en annan körtidsmiljö än React i t.ex. Google Chrome [63]. Detta är en anledning att React Native kan sakna vissa funktioner som annars brukar finnas inbyggt i JavaScript-motorer för webbläsare.
F.3.3
Komponenter i React
Vid design av komponenter i React bör komponenter vara små och centrerade runt en specifik uppgift för att kunna återanvändas i större grad [64] [65]. Dessa komponenter kan vara så simpla som att bara rendera en bild vilken länkar till en annan sida vid klick, eller två knappar som kan göra nätverksanrop för att godkänna eller avslå kvitton.
F.3.4
Grafiska gränssnitt i React och React Native
Den största skillnaden mellan React och React Native ligger i vilken miljö grafiska gränssnitt renderas i [66]. React har sitt ursprung i webbläsare, alltså konverteras till HTML och ren- deras av webbläsarens renderingsmotor. React Native använder istället komponenter som tillhör plattformen den körs på och en motor som är specialanpassad för plattformen. Re- act och React Native har därför väldigt olika komponenter som finns inbyggt, även de mest rudimentära komponenterna som till exempel positionerar innehåll skiljer sig.
F.3.5
Props
För att komponenter ska kunna kommunicera med varandra behövs ett sätt att skicka ner information till en komponents barn. Detta sköter React genom så kallade props, dessa kan liknas vid JavaScript-funktioner som tar in en mängd parametrar som indata. Detta är det enda sättet som en komponent kan få information av andra komponenter [67].
Props är inte skrivbara av komponenten som tar emot dem, vilket underlättar och för- enklar testning. Återsändning av information sker också via en prop. Props kan precis som
F.4. Metod
funktioner i JavaScript skicka med alla typer av parametrar, inklusive andra funktioner, det är genom sådana funktioner en komponent kan signalera till sin förälder när den är klar med en uppgift eller ska uppdatera tillstånd uppåt.
F.4
Metod
Inledningsvis begränsas undersökningen till en viss mängd av vilka delar som är relevanta i Mobilapplikationen. De utvalda delarna blev grafiskt gränssnitt, nätverkskommunikation, tillståndslagring och navigering. De olika delarnas stöd för React Native undersöktes sedan med en jämförelse från Webbgränssnittet. Vilka bibliotek det rör sig om behandlas i tabell F.1.
Jämförelsen baseras på dokumentationen för alla biblioteks respektive delar. Det för att kunna få ett mått på vilken mängd kod som är delbar mellan Webbgränssnittet och Mobilap- plikationen. Oberoende delar ur Webbgränssnittet användes för att jämföra dess biblioteks stöd för React Native. Jämförelsen gjordes genom en kontroll av befintliga implementationer i Webbgränssnittet mot inbyggda komponenter i React Native.
För att bestämma hur mycket tid som skulle kunna ha besparats användes tidsrapporte- ringen för projektet, den innehåller detaljerad information om hur mycket tid som har lagts på de relevanta aktiviteterna. De aktiviteter som var av intresse är implementation för de grafiska gränssnitten, nätverkskommunikation och tillståndslagring samt alla kombinationer av dessa. Aktiviteter av relevans plockas ur tidsrapporteringen för respektive modul. De oli- ka aktiviteterna för Webbgränssnittet adderas till en summa, och de för Mobilapplikationen till en. Dessa jämförs sedan mot varandra för att jämföra tidsåtgång för de olika modulerna. I undersökningen undersöktes tre olika typer av aktiviteter, Layout, Nätverkskommunikation och GUI, vilka aktiviteter som tillhörde vilken kategori framgår i tabell F.2. Uppdelningen gjordes i ett försök att få så jämförelsebara resultat som möjligt. Layout beskriver implemen- tation som ansvarar för navigationsflöde i modulen. Nätverkskommunikation beskriver all form av implementation av delar som ansvarar för kommunikation med Molntjänsten. GUI är den del som beskriver det grafiska gränssnittet som ritas ut på skärmen.
Koden som delas behöver integreras i Mobilapplikationen och kommer lägga på mer tid i utvecklingen. Exakt hur mycket tid som kommer läggas på för integration är svår att förut- se men bör vara proportionell mot mängden kod som ska integreras. Därför undersöktes hur utvecklingstiden för den delade koden hade sett ut med påslagen 20%, 30% och 40%.
Tabell F.1: Lista över vilka bibliotek som undersöks från Webbgränssnittet.
Område Bibliotek
Navigering React Router
Nätverkskommunikation Axios Tillståndslagring Redux
React-Redux Grafiskt gränssnitt
React-Bootstrap
React Notification System Redux Form
F.5. Resultat
Tabell F.2: Lista över hur aktiviteterna kategoriserades.
Område Modul Aktiviteter
Layout MobilapplikationWebbgränssnitt 15. GUI-design31. Sidlayout
Nätverkskommunikation
Mobilapplikation
14. Kommunikation med server 18. Ladda upp kvitto
23. Hämta erbjudanden 24. Hämta kvitton Webbgränssnitt 30. Kommunikation Ajax 32. Login 36. Ta bort erbjudande 39. Godkänna kvitto GUI Mobilapplikation 19. Lista erbjudanden 20. Visa kvitton 21. Detaljer erbjudanden 22. Detaljer kvitton 27. Visa status för kvitton
Webbgränssnitt 33. Lägg till erbjudande 34. Lista kvitton 35. Lista erbjudanden 37. Detalj kvitto 38. Detalj erbjudande
F.5
Resultat
Resultatdelen börjar med att besvara fråga ett: ”Hur stor del av kodbasen i Webbgränssnittet är kompatibel i en React Native-implementation av Mobilapplikationen?”. Sedan besvaras fråga två: ”Hur mycket tid har vi lagt på att skriva liknande kod i Webbgrässnittet och Mobi- lapplikationen, hur mycket skulle kunna besparas med koddelning?”.
F.5.1
Fråga 1
Grafiskt gränssnitt
De grafiska delarna i Webbgränssnittet skulle inte vara möjligt att överföra direkt till en React Native-implementation av Mobilapplikationen då många bibliotek som används inte stöds i React Native. Utöver detta så vill man ha ett utseende på applikationen som matchar platt- formens rekommendationer för utseende och interaktion vilket en befintlig implementation på Webbgränssnittet skulle bryta mot.
Tillståndslagring
Alla tillstånd lagras med hjälp av Redux som är ett generellt JavaScript-bibliotek, vilket bey- der att det kommer vara möjligt att använda. För att integrera React med Redux används biblioteket React-Redux och där utvecklaren själv säger att det ska fungera från och med React Native 0.18, i skrivande stund är version 0.44 senaste [68]. Stöd för samma form av tillståndslagring är alltså tillgänglig i React Native.
Nätverkskommunikation
I Webbgränssnittet användes biblioteket Axios för att utföra nätverkskommunikation. Vid undersökning av dokumentation framkommer det inte vid en första blick om biblioteket stöds i React Native eller inte. Från React Natives hemsida nämns dock att ramverket har
F.6. Diskussion
stöd för XMLHttpRequest API:et som Axios bygger på, utöver detta rekommenderas Axi- os på samma sida [69]. Därför drogs slutsatsen att all nätverkskommunikation som görs i Webbgränssnittet även stöds i React Native.
Navigering
I webbläsare är navigering uppenbar med ett URL fält som indikerar position, mobilapplika- tioner har däremot inte denna ruta. Webbgränssnittet är byggt som en SPA, någonting som är fördelaktigt då Mobilapplikationen även den behöver fungera på liknande sätt. React Router (react-router-dom) är det som sköter navigationen på adminpanelen. Motsvarigheten finns och har bara lite annorlunda bindings för att hantera mobilapplikationer, den heter react- router-native och har fullt stöd för det som används i Webbgränssnittet [70].
F.5.2
Fråga 2
Då alla bibliotek som används för tillståndslagring, nätverkskommunikation och navigering fungerar i React Native går det att estimera hur mycket tid som skulle kunna besparas. Det genom att kolla på tidsrapporteringen som finns i Tabell F.3. Den kod som inte kan delas ligger under GUI. Ur tabell F.4 observeras att totalt 138,5 timmar (layout + kommunikation) har lagts på kod som skulle kunna delas. Vi ser även att besparingen med denna metod ligger mellan 64,7 (20% påslag) och 52,4 (40% påslag) timmar.
Tabell F.3: Tidsåtgång till respektive område
Modul Underdel Tidsåtgång (timmar)
Mobilapplikation Layout 27 Nätverkskommunikation 50 GUI 70,5 Totalt 147,5 Webbgränssnitt Layout 34.5 Nätverkskommunikation 27 GUI 32 Totalt 93,5
Tabell F.4: Beräknad tidsbesparing
Beskrivning Tidsåtgång (timmar)
Total tid utan koddelning 241
Delbar tid 138,5
Estimerad totaltid, koddelning med 20% påslag 176,3
Besparing med 20% påslag 64,7
Estimerad totaltid, koddelning med 30% påslag 182,45
Besparing med 30% påslag 58,55
Estimerad totaltid, koddelning med 40% påslag 188,6
Besparing med 40% påslag 52,4
F.6
Diskussion
F.6.1
Fråga 1
Till en början tänkte vi att det skulle utgöra en fördel att ha Molntjänsten och Mobilapplikatio- nen i samma språk, men eftersom det inte gav några direkta fördelar tycker jag att vi istället
F.7. Slutsatser
att deras syfte faller mer i linje med varande och koddelning skulle ha varit möjligt. Resultatet visar på att användande av React Native skulle kunna ha förenklat vissa delar av utveckling- en i samarbete med React. Exempelvis så är navigation, kommunikation och tillståndslagring applicerbart från React till React Native även om viss modifiering krävs. Det grafiska gräns- snittet är inte direkt överförbart utan bör nog skrivas om specifikt för plattformen. Jag tror att det kunde ha förbättrat uppdelningen av arbetet i och med att andra ansvarsområde hade kunnat vara relevanta. Istället för att medlemmar ska tillhöra antingen Webbgränssnittet eller Mobilapplikationen skulle man kunna dela upp ansvar baserat på uppgifter, till exempel en som ansvarar för layout och navigation, en för nätverkskommunikation och så vidare. På så sätt har man personer som är specialiserade på vissa områden.
F.6.2
Fråga 2
Just med fallet React + React Native skulle gruppen inte behövt dela upp arbetet mellan Webbgränssnittet och Mobilapplikationen i samma grad som vi under projektet gjorde utan man kan istället flyta lite fram och tillbaka då likheterna blir stora. Vi ser från resultaten att vi har lagt många timmar på att göra samma sak två gånger och hade antagligen sparat mycket tid om vi istället delade kod mellan modulerna. Hade man istället lagt denna tid på vidare utveckling skulle slutprodukten kunna bli bättre.
I rapporten används tidsrapporteringen för att skapa ett mått för vilka aktiviteter som tillhör vilket område, det är dock väldigt svårt att exakt säga från den vad som tillhör vilket område. Implementation av att visa saker kräver kanske att man gör nätverkshämtningar och liknande, även om det faller under aktiviteter som ”Visa XXX”. Detta gör att rapporten har en felkälla som ligger i just denna svårighet, vid valet av aktiviteter gjordes ett försök till att minimera detta och välja vissa aktiviteter i vissa områden även om de intuitivt kanske egentligen faller under andra kategorier.
F.7
Slutsatser
F.7.1
Fråga 1
• Stora delar kod skulle kunna delas mellan de två modulerna
• Kanske valde fel när det kommer till server och klient i samma språk, antagligen bättre att ha samma på moduler med liknande uppgifter
F.7.2
Fråga 2
• Många timmar gick åt till att göra samma sak, mycket tid skulle kunna besparas • Felkällor, avgränsning av aktiviteter svårt
F.7.3
Övrigt
• Arbete skulle kunna delas upp bättre, uppgifter istället för modul, nätverk, rendering, navigation
• Webbgränssnitt och Mobilapplikation kanske inte ska ha strikt tilldelade medlemmar utan tillåta flyt mellan dem
G
Tidsbudgetering och estimering
inom projektet av Richard Wigren
G.1
Introduktion
Budgetering för projekt görs i mer eller mindre alla projekt som utförs. I många fall handlar det om pengar, men i vårt fall är det istället tid som budgeteras. Oavsett vilket av dessa bör en plan göras för att få ett bra arbetsflöde. Olika aktiviteter kräver olika mycket tid och det är viktigt att fördela arbetet mellan dessa på ett sätt som leder till att så stor del som möjligt av projektgruppen kan arbeta utan hinder. Aktiviteter som beror på andra kan inte påbörjas innan det de är beroende av är färdigt, vilket kan ställa till med problem.
G.1.1
Syfte
Syftet med den här rapporten är att beskriva och utvärdera tidsestimeringen gjord inom projektet. Rapporten beskriver metoder vi använt för detta och de faktiska tiderna som i slutändan blivit rapporterade. De estimerade tiderna ställs sedan mot de faktiska tiderna som krävdes för respektive aktivitet och estimeringen och metoden utvärderas ifrån detta. Projektmedlemmarnas uppfattning av tidsfördelningen och hur de tyckte att estimeringen fungerade kommer även att inkluderas.
G.1.2
Frågeställningar
1. Var gick tidsbudgeteringen rätt respektive fel? 2. Hur användes buffertiden?
3. Hur väl fungerade metoden vi använde för tidsestimering?
G.2
Bakgrund
Projektet Kunderbjudande i Molnet är utfört i samband med Kandidatarbete i Programvaru- utveckling och går ut på att utveckla ett system åt Byggvarulistan. I projektets tidiga stadie skedde mycket planering och dokumentering. Som en del av planeringen valde gruppen att dela upp utvecklingen i olika aktiviteter. Dessa aktiviteter tidestimerades sedan och tillsam-
G.3. Teori
het. Jag valde att skriva om tidsestimeringen för att få en tydlig inblick i hur väll estimeringen gick och vilka förändringar som kan göras till nästa projekt.
G.3
Teori
Detta kapitel beskriver teori relevant för rapportens innehåll.
G.3.1
Delphi
Delphi är en metod framarbetad för att hjälpa en grupp experter svara på godtyckliga fråge- ställningar. I och med detta kan den användas till mer än endast tidsestimering. Här limiterar vi oss dock till dess applikationer inom tidsestimering och därmed frågan om hur lång tid en uppgift tar. Metoden utförs av en moderator och flera experter. Det hela startas genom att moderatorn delar ut uppgiften som ska estimeras. Experterna får då anonymt estimera tidsåtgång och ge en motivering om så skulle behövas. Moderatorn samlar sedan in dessa och sammanställer estimeringarna och motiveringarna. Om experterna anses vara överens avslutas processen, annars skickas det sammanställda till experterna igen och de har chansen att ändra sitt svar. Detta kan ske i ett antal cykler till dess att experterna anses vara överens. Det går att använda olika brytpunkter. Vanligen är att experterna anses vara överens en brytpunkt, men stopp efter ett visst antal cykler kan exempelvis också vara en brytpunkt. Metodens mål är att få fram den mest pålitliga enigheten av experternas åsikter [71]. Detta framhävs genom den iterativa och anonyma process som hjälper till att både få med alla experters åsikt och finslipa åsikterna levererade. Trots att metoden har använts i stor ut- sträckning finns det få vetenskapliga studier om dess fördelar [72]. K. Molokken och N. Haugen skriver ”Vi har inte hittat någon empirisk forskning om precisionen av Delphi i mjukvaruutvecklingskontext” (Egen översättning) [73]. Trots detta rekommenderas ofta Del- phi i mjukvarusammanhang [73]. Om vi ser till det mer allmänna fallet finns det dock bevis för att metoden presterar bättre än ostrukturerade grupper samt statistiska grupper [72]. Detta kan dock tänkas kontras, i vissa fall, av den tid det tar att genomföra denna metod.
G.3.2
Planning Poker
Planning poker är en metod, skapad för estimering, tänkt att vara diskussionscentrerad och lättviktig. Metoden har två steg. I det första steget visas uppgiften som ska tidbedömmas. Alla som ska estimera har ett antal kort som det står siffror på. Varje person väljer ut ett kort som representerar tiden de tror att uppgiften kommer ta och lägger det nedvänt på bordet. Andra steget sker då alla har valt ett kort. Då vänder alla på sina kort och diskuterar de val de har gjort. Extra regler kan användas efter vad som passar in. Exempelvis används i vissa fall att personen som valt högsta respektive lägsta estimeringen ska motivera sina val. Det