INOM EXAMENSARBETE DATATEKNIK, GRUNDNIVÅ, 15 HP , STOCKHOLM SVERIGE 2019
Implementering av
diagnostiskt verktyg i en
webbapplikation
Hur kan ett verktyg för att analysera diagnostiska
data för felsökning byggas i en React
webbapplikation?
TOBIAS UDD
PHILIP EKBLOM
KTH
Abstract
Sweden produced 215 kilotons of electronic waste in 2016. One way to reduce this amount is to repair electronic devices when they fail instead of replacing them. The company Mavenoid has a troubleshooting service in the form a web application to help troubleshoot machines like for example consumer elec-tronics. The company desired a tool to visualize data about the usage of the troubleshooting models in their web app. The prospect was that the users who build the troubleshooting models would be able to analyse how their models are being used and how well they work with the tool.
To implement the tool, a method with three phases was used. An initial prepa-ration phase with requirements elicitation via a domain analysis and set-up of the development environment, a development phase with iterative develop-ment and requiredevelop-ments managedevelop-ment with weekly meetings and an analysis phase with evaluation of the tool according to the requirements and the status of a pull request.
The product met eight out of ten requirements and was of a sufficiently high quality that it could be integrated into the company’s system. The use of the library C3 resulted in a 21% increase of the web application’s build size.
Keywords
Sammanfattning
Sverige producerade 2016 215 kiloton elektronikavfall. Ett sätt att minska denna mängd är att reparera elektronik när den fallerar istället för att byta ut den. Företaget Mavenoid erbjuder en tjänst i form av en React webapplikation för att underlätta felsökning av maskiner som t.ex. hemelektronik. Företaget eftersökte ett verktyg för att visualisera data om användningen av felsöknings-modellerna i sin webbapplikation. Förhoppningen var att de användare som bygger modellerna via det nya verktyget skulle kunna analysera hur deras mo-deller används och väl de fungerar.
För att utveckla verktyget användes en metod med tre faser. En inledande för-beredelsefas med kravinsamling via en domänundersökning och uppbyggnad av utvecklingsmiljö, en utvecklingsfas med iterativ utveckling och kravhante-ring med veckomöten och en analysfas med utvärdekravhante-ring av verktyget efter kra-ven och status på en pull-request.
Produkten uppfyllde åtta utav tio av de insamlade kraven och var av tillräck-ligt hög kvalitet att integreras i företagets system. Användningen av biblio-teket C3 medförde att webapplikationens transaktionsstorlek ökade med ca 21%
Nyckelord
Innehåll
ORDLISTA ... 1 1 INTRODUKTION ... 3 1.1 Bakgrund ... 3 1.2 Problem ... 3 1.3 Syfte ... 4 1.4 Mål ... 4 1.5 Metodologi / Metoder ... 4 1.6 Avgränsningar ... 4 1.7 Arbetsfördelning ... 5 1.8 Disposition ... 5 2 TEORETISK BAKGRUND ... 7 2.1 React ... 7 2.2 JSX ... 8 2.3 D3 ... 8 2.4 C3... 8 2.5 JSON ... 9 3 KRAVHANTERING ... 113.1 Inledning till kravhantering ... 11
3.2 Kravinsamling ... 12
3.3 Modellering och analys av krav ... 13
3.4 Kommunikation av krav ... 13
3.5 Validering och överenskommelse av krav ... 13
3.6 Utveckling av krav ... 14 4 METOD ... 15 4.1 Översikt ... 15 4.2 Förberedelse ... 15 4.2.1 Litteraturstudie ... 16 4.2.2 Kravhantering ... 16 4.2.3 Uppbyggnad av utvecklingsmiljö ... 17 4.3 Utveckling ... 17 4.3.1 Iterativ utveckling ... 17 4.3.2 Veckomöten ... 17 4.4 Analys ... 17
4.4.2 Utvärdering av resultat ... 18
5 ARBETSPROCESS ... 19
5.1 Vattenfallsmodellen och agila modeller ... 19
5.2 Den valda arbetsprocessen ... 20
5.3 Utvecklingsprocess ... 20
5.4 Utvecklingsverktyg ... 20
6 RESULTAT ... 23
6.1 Produktens utveckling ... 23
6.1.1 Uppbyggnad av utvecklingsmiljö och kravhantering ... 23
6.1.2 Utveckling av första prototypen... 24
6.1.3 Utveckling av andra prototypen... 25
6.1.4 Utveckling av den slutliga produkten ... 26
6.1.5 Pull-request och verifiering ... 27
6.2 Översikt över den slutliga prototypen ... 27
7 UTVÄRDERING AV RESULTAT ... 29
7.1 K1. Produkten skall vara inbyggd i Mavenoids existerande system. ... 29
7.2 K2 & K3. Som användare kan jag se vilka grundorsaker/symptom som är vanligast förekommande i en produkt. ... 29
7.3 K4. Som användare kan jag se vilka komponenter som oftast fallerar i en produkt. ... 29
7.4 K5. & K6. Som användare kan jag se hur grundorsakerna/symptom för en produkt uppträder över tiden. ... 30
7.5 K7. Användare skall kunna filtrera resultaten efter slut-och-startdatum. 30 7.6 K8. Produkten skall följa riktlinjerna i designdokumentet. ... 30
7.7 K9. Produkten skall ha en design som är snarlik den som specificerats. .. 31
7.8 K10. Mätvärden för intervall kan slås ihop i diagrammen ... 31
7.9 Pull-request ... 31
8 DISKUSSION ... 33
8.1 Utvärdering av resultat ... 33
8.2 Svar på arbetets frågeställning ... 33
8.3 Hållbar utveckling och etik ... 33
8.4 Fortsatt arbete ... 34
8.5 Transaktionsstorlek ... 34
1
Ordlista
Front-end - Något som är relaterat till klienten, t.ex kod för
användargräns-snitt som körs hos användaren i dess webbläsare.
Back-end - Något som är relaterat till servern, t.ex kod för API som körs på
servern.
Python - Ett skriptspråk.
Bibliotek - En samling implementationer för en viss funktionalitet med ett
tydligt gränssnitt med vilket denna funktionalitet kan åkallas.
API - Definierat gränssnitt som kan anropas av olika delar av systemet.
Klien-ten kan t.ex göra en förfrågan till serverns API som då levererar det data som klienten behöver.
Transaktionsstorlek - Storleken på de kompilerade filerna som skickas till
klienten.
Dokumentmodell - Ett gränssnitt som behandlar HTML dokument som en
trädstruktur med objekt i trädets löv.
Inline-CSS - Kod för att anpassa en komponents utseende som skrivs direkt i
koden för komponenten istället för i en separat CSS-fil.
Pull-request - Förkortas ofta till PR. Kallas även Merge-request. En
förfrå-gan om att integrera kod i ett versionshanteringssystem. Koden granskas och förfrågan godkänns eller avslås.
CTO - Chief technology officer, högsta ansvarig för teknik. I detta fall är det
3
1 Introduktion
Företaget Mavenoid har en tjänst för felsökning av maskiner i form av en webbapplikation med React. Företaget sökte en ny modul till applikationen för att göra felsökningen effektivare. I denna uppsats ligger fokus på kravhan-teringen och arbetsprocessen bakom framtagandet av denna modul.
1.1 Bakgrund
Europa producerade år 2016 12.3 megaton elektronikavfall [1]. Av dessa stod Sverige för 215 kiloton eller 21,5 kg per capita [1]. Ett sätt att minska mängden elektronikavfall som produceras är att reparera elektronik när den fallerar istället för att byta ut den. Detta ingår i ett av målen i Förenta Nationernas 2030 Agenda for Sustainable Development: “12.5 By 2030, substantially re-duce waste generation through prevention, reduction, recycling and reuse” [2].
Företaget Mavenoid erbjuder en tjänst för att underlätta felsökning av maski-ner som t.ex. hemelektronik. Tjänsten är i form av en webbapplikation där an-vändaren som utför felsökningen besvarar frågor som ställs av applikationen. När användaren svarat på tillräckligt många frågor och applikationen känner sig säker på vad orsaken till felet är får användaren en beskrivning av hur pro-blemet löses.
Det finns även användare som bygger felsökningsmodellen som beskriver ma-skinen som felsöks och bestämmer de frågor som besvaras av felsökaren. För dessa användare finns i webbapplikationen också ett verktyg för att skapa fel-sökningsmodeller för maskinerna. Dessa användare hade inget verktyg för att undersöka de felsökningsmodeller de skapade och det var svårt för dem att hitta brister i sina modeller.
Dessa användare skulle ha nytta av ett verktyg där de kan få det visualiserat för sig t.ex. hur ofta de olika frågorna ställs till användarna och vilka orsaker som är vanligast så att de kan få återkoppling på hur väl deras modeller pre-sterar och vet vad de behöver fokusera på, t.ex. de vanligaste frågorna och or-sakerna.
1.2 Problem
Företaget saknade ett verktyg för att visualisera data om användningen av fel-sökningsmodellerna som de samlar in i sin webbapplikation. Förhoppningen var att de användare som bygger modellerna via det nya verktyget skulle kunna analysera hur deras modeller används och väl de fungerar.
Företaget hade redan tagit fram ett designförslag för hur verktygets vy skulle kunna se ut men ville även ha synpunkter på detta från oss.
4 1.3 Syfte
Syftet med arbetet var att designa och utveckla efterfrågade produkten så att den var av tillräckligt god kvalitet att integreras i företagets webbapplikation och komma till nytta för dess användare.
1.4 Mål
Målet var att implementera den efterfrågade produkten på ett ingenjörsmäss-igt vis med hjälp av designförslaget och den framtagna kravspecifikationen. Effektmålet var ett en produkt som kommer till nytta för tjänstens användare och resulterar i effektivare felsökningsmodeller.
Samhällsnytta, Etik och Hållbarhet
Arbetets potentiella samhällsnytta var att underlätta användarnas arbete med att förbättra sina felsökningsmodeller.
Projektmedlemmarna ingick sekretessavtal i samband med arbetet och måste därmed komma överens med företaget om vad som fick offentliggöras i rap-porten. En av dessa delar var att projektmedlemmarna fick tillgång till en ko-pia av en produktionsdatabas. Denna innehöll information om företagets kun-der som inte fick röjas. Figurer från produkten kommer därmed istället an-vända påhittat data som liknar den som fanns i produktionsdatabasen. Effektivare felsökningsmodeller kunde underlätta felsökningen av de maski-ner som behandlades vilket kunde göra att de fick en längre livslängd och inte behövdes bytas ut vilket skulle leda till mindre avfall och ökad hållbarhet. 1.5 Metodologi / Metoder
Inför och under arbetet genomfördes en litteraturstudie. Sökningen efter rele-vant litteratur skedde i KTH:s divaportal, IEEE:s Xplore databas och på inter-net.
För sökning på internet användes sökmotorn Semantic scholar [3] för att hitta akademiska journalartiklar.
En metod med faserna förberedelse, utveckling och analys med sex delmo-ment användes.
1.6 Avgränsningar
Då en helt ny modul skulle skapas från grunden i systemet begränsades arbe-tet till att skapa ett tidigt stadium av produkten. Produkten fokuserade på data om de två viktigaste delarna i systemet (grundorsaker och symptom). Produk-ten testades inte heller på någon användargrupp utan godkändes endast in-ternt hos företaget.
5
krävdes det kunskap om företagets databasmodeller samt Python. Dessa de-taljer beskrevs inte i rapporten utan fokus låg på implementationen i front-end.
1.7 Arbetsfördelning
Här beskrivs vilka delar av produkten och uppsatsen som gjordes av förfat-tarna Tobias och Philip.
Philip utvecklade diagrammet som visar vilka symptom och grundorsaker som var vanligast, diagrammet till vänster i gränssnittet. Han implementerade även ändpunkter i APIet för att hämta data för detta.
Tobias utvecklade diagrammet som visar hur symptom och grundorsaker upp-träder över tiden i de första iterationerna med D3. Detta var det högra dia-grammet i gränssnittet. I den sista iterationen med C3 var Philip också med och utvecklade detta diagram. Tobias implementerade ändpunkter för dia-grammet. Tobias implementerade gränssnittet för att filtrera resultaten efter datum och såg till att alla ändpunkter var kompatibla med datumfiltrering. Philip skrev de tidiga versionerna av delarna 1.3, 1.4, 1.6, 2.1–2.4, 4.2.1, 5.4 och 8.5 i uppsatsen. Dessa delar fick sedan omfattande kompletteringar av To-bias.
Tobias skrev uppsatsens övriga delar. 1.8 Disposition
Uppsatsen är uppdelad i åtta delar.
Kapitel 1 introducerar arbetet och ger dess bakgrund, det problem som under-söks, arbetets syfte och mål, dess potentiella samhällsnytta, etiska aspekter och inverkan på hållbar utveckling. De metoder som använts och arbetets av-gränsningar beskrivs också.
Kapitel 2 ger den fördjupade teoretiska bakgrund som relaterar till webbappli-kationer i allmänhet.
Kapitel 3 ger den teoretiska bakgrund som relaterar till kravhantering. Kapitel 4 presenterar och motiverar de metoder som använts under arbetet. kapitlet beskriver och motiverar även de utvärderingskriterier som används. Kapitel 5 ger den teoretiska bakgrund som relaterar till arbetsmetoder för mjukvaruutveckling och presenterar och motiverar den metod som valts för arbetet. Kapitlet listar utvecklingsverktyg som använts.
6
Kapitel 7 presenterar utvärderingen av resultatet enligt de utvärderingskrite-rier som beskrivits i kapitel fyra.
7
2 Teoretisk Bakgrund
I detta kapitel förklaras de viktigaste teoretiska begreppen som används i exa-mensarbetet.
2.1 React
React är det kanske viktigaste av de många JavaScript ramverk som används i front-end i webbapplikationen. Därför motiveras en kort introduktion om detta till läsaren.
React strukturerar användargränssnittet i återanvändbara komponenter. I dessa komponenter ligger både funktionalitet med JavaScript men även HTML-kod för att rita vyn. Det är även möjligt att skriva inline-CSS för
HTML-elementen. Med hjälp av detta kan man kombinera all design, struktur och funktionalitet för en komponent i en enda fil.
Komponenterna kan även importeras och återanvändas i andra komponenter. Dessa komponenter kan då skrivas som pseudo-HTML element tack vare JSX som förklaras i 2.2. Det är även möjligt att skicka in egenskaper till kompo-nenten via pseudo-HTML parametrar. I React kallas dessa props. Komponen-terna kan via dessa props ta del av data från andra komponenter.
Figur 2.1: React-komponenter med deras props.
Figur 2.1 visar hur en komponent kan se ut. <FlatButton> och <Options-Menu> är i sin tur React komponenter som importerats till denna komponent. <FlatButton> komponenten får funktionen selectLastYear via en av deras props så att den körs när användaren trycker på knappen.
8
en ny förfrågan till servern varje gång den vill ladda en ny sida. Istället hämtas endast data via HTTP-förfrågningar till ett API. Dessa data laddas sedan in i webbapplikationen.
En viktig del av React är att det använder sig av en virtuell dokumentmodell som representerar den riktiga dokumentmodellen. Detta gör att React kan manipulera dokumentmodellen och rita om vyn på ett effektivt sätt via en dif-ferensalgorithm [4].
2.2 JSX
JSX står för JavaScript eXtension och är ett tillägg i React som gör det möjligt att skriva JavaScript som har liknande syntax som HTML. Denna kod kompi-leras sedan om till Reacts egna funktioner som lägger till elementen till doku-mentmodellen [5]. Till exempel kompileras JSX för en komponent:
<MyButton color=”blue” shadowSize={2}> Click Me
</MyButton>
Till motsvarande JavaScript: React.createElement(
MyButton,
{color: ’blue’, shadowSize: 2}, ‘Click Me’
)
2.3 D3
D3 är ett JavaScript-bibliotek som används för att manipulera dokument ba-serat på data [6]. Biblioteket använder sig av HTML, CSS och SVG element för att visualisera data och är ett kraftfullt verktyg för att bland annat skapa dia-gram. D3 bidrar med de delar som behövs för att skapa diagram och andra vi-sualiseringar, inte färdiga diagram. Därför behöver utvecklaren själv veta hur dessa passar ihop för att skapa diagrammet och ger denne mycket utrymme att själv implementera delar.
D3 manipulerar dokumentmodellen precis som React [7]. Detta kan leda till konflikter och inkonsekvens om de uppdaterar samma del av dokumentmo-dellen samtidigt. I arbetet undveks detta genom att ge D3 ett eget element som inte uppdateras av React.
2.4 C3
C3 är ett diagram-bibliotek implementerat i D3. Det möjliggör att utvecklaren kan generera färdiga diagram och manipulera dessa via den data som matas in [8].
9
C3 genererar grafer via data och en konfigurationsfil skriven i JSON som för-klaras i 2.5. Det krävs därmed minimal kod och går väldigt snabbt att imple-mentera diagram med biblioteket. Det går dessutom att manipulera grafens utseende på många olika sätt via konfigurationsfilen.
2.5 JSON
11
3 Kravhantering
Senare kapitel utgår från tekniker och arbetssätt inom kravhantering. Krav-hantering har använts i utvecklingen av produkten i detta arbete. Därför är det nödvändigt att ge läsaren en översiktlig introduktion till kravhantering.
3.1 Inledning till kravhantering
Kravhantering handlar om att upptäcka, modellera, kommunicera och doku-mentera de krav som finns för det system som skall utvecklas i en kravspecifi-kation. Kraven beskriver vad som skall göras men inte hur det skall imple-menteras. Målet med kravhantering är att alla parter vet vad som skall byggas innan utvecklingen påbörjas för att undvika kostsamma ombyggnationer av systemet. Målet motiveras av två antaganden:
1. Ett misstag som upptäcks senare i processen är dyrare att rätta till än ett som upptäcks tidigt.
2. Det är möjligt att ta fram tillräckligt detaljerade krav innan designen och implementeringen av systemet påbörjat
Att samla in och förstå krav är en utmaning av flera anledningar [10]. 1. Intressenter vet ofta inte vad de eftersöker ifrån systemet i annat än
vaga termer. De kan ha svårigheter att uttrycka vad de vill att systemet skall göra.
2. Intressenter uttrycker naturligt kraven i sina egna termer som utgår från den egna kunskapen i området. Ingenjören som utvecklar systemet kan få svårigheter att förstå kraven utan denna kunskap.
3. Olika intressenter har olika krav som de uttrycker på olika sätt. Ingen-jören behöver bedöma likheter och konflikter i dessa.
Det finns två olika typer av krav. Funktionella krav för ett system beskriver vad det skall kunna göra, hur det skall reagera på olika indata. Funktionella krav beskriver ofta explicit vad systemet skall göra. [10] Ett exempel på ett funktionellt krav som framkommer i arbetet är “systemet skall visa alla symp-tom för en given produkt.”
Icke-funktionella krav handlar om egenskaper för systemet i helhet som pre-standa, pålitlighet, responstid, säkerhet och även egenskaper som lättförstådd kod. Icke-funktionella krav är ofta mer kritiska än de enskilda funktionella kraven [10]. I detta arbete togs endast funktionella krav fram.
Krav kan delas in olika nivåer efter hur viktiga de är. Ett av de vanligaste sät-ten för detta är den så kallade MoSCoW metoden [11]. Den innebär att man delar in kraven i fyra nivåer.
1. Must have eller måste-krav: Absolut nödvändiga krav som måste upp-fyllas i produkten.
12
3. Could have eller kunna-krav: Krav som är önskvärda att uppfylla om de inte medför alltför stora kostnader.
4. Won’t have eller icke-krav: Krav som intressenter önskar men som alla kommer överens om inte kommer att implementeras i denna version av produkten.
Kravhanteringen kan delas upp i fem aktiviteter: kravinsamling, modellering- och analys av krav, kommunikation av krav, validering av krav och utveckling av krav [12]. Dessa aktiviteter beskrivs nu i den generella ordning de förekom-mer i kravhanteringsprocessen.
3.2 Kravinsamling
Kravinsamling handlar om att lära sig och förstå intressenternas behov med det slutliga målet att kommunicera dessa till systemutvecklarna. Kravin-samlingen har ett antal särskilt viktiga mål:
● Att identifiera systemets ramar, vilka kommer att styra de krav som samlas in.
● Att identifiera intressenter, individer eller organisationer som huvud-sakligen påverkas av systemet som skall utvecklas.
● Att identifiera systemets övergripande mål, som kommer att uttryckas i de slutliga kraven på något sätt.
Det finns många tekniker för kravinsamling, tre bland dessa är:
1. Intervjuer
Intervjuer är en av de vanligaste och mest traditionella teknikerna för kravinsamling. Intervjuer kan delas in i två typer, ostrukturerade och strukturerade.
Ostrukturerade intervjuer är mer pratsamma och inte lika strikt kon-trollerade av den som håller intervjun. Det finns en risk att ostrukture-rade intervjuer lägger för mycket fokus på ett visst område och inte till-räckligt mycket på andra viktiga områden. Denna typ av intervju passar bäst vid utforskande av ett område där utvecklarna endast har en be-gränsad förståelse, och kan eventuellt användas som underlag vid framtagande av frågor för en strukturerad intervju [14].
2. Workshop
Workshops som t.ex. möten är en vanligt förekommande teknik för kravinsamling. Grupper är särskilt effektiva för att de involverar intres-senterna direkt och förespråkar samarbete. Workshops kan vara svåra att organisera om det är många intressenter i projektet. Det krävs bra ledning under möten för att se till att intressenter med starka person-ligheter inte dominerar diskussionen. Deltagarnas karaktär och sam-manhållning är viktiga faktorer för effektiva grupparbeten. Det är vik-tigt att deltagarna känner sig bekväma och kan tala öppet och ärligt. Av denna anledning är workshops mindre effektiva i politiska situationer [14].
3. Domänundersökning
13
applikationer undersöks. Denna typ av undersökning är särskilt viktig när projektet handlar om att ersätta eller utöka ett existerande system, vilket är fallet i detta arbete. De dokument som är användbara för krav-insamling är designdokument och instruktionsmanualer.
Denna teknik kombineras ofta med observationer av det existerande systemet där frågor ställs till användarna. Kunskap om domänen i form av beskrivningar och exempel är viktiga för kravinsamling, de hjälper till att skapa en gemensam förståelse mellan utvecklarna och intressen-terna [14].
Med hjälp av en domänundersökning kan den andra utmaningen be-skriven i 3.1 bemästras, eftersom ingenjören med hjälp av domänkun-skapen kan förstå kraven i de termer som intressenterna använder. 3.3 Modellering och analys av krav
När kravhanteringen är påbörjad och t.ex. en domänundersökning är gjord kan det vara relevant att skapa modeller. Det finns många delar av ett projekt som är relevanta att modellera. Det kan vara organisationen där projektet ut-förs, den data som används och genereras av systemet, modellering av syste-met och intressenternas beteende, modellering av domänen med flera. Den typ av modellering som använts under arbetet är modellering av domänen. Detta innebär att en beskrivning av de viktigaste delarna i systemet, och hur de interagerar med sin omgivning, skapas. Denna kan sedan användas som underlag för diskussion med intressenter för att se om systemutvecklarna har en riktig uppfattning om systemet. På så sätt kan modellen justeras tills den är tillräckligt korrekt.
3.4 Kommunikation av krav
Kravhantering handlar också om effektiv kommunikation om de funna kraven mellan olika intressenter. Det är inte särskilt nyttigt att ta fram krav och ut-veckla ett system efter dessa om intressenterna inte får reda på dem eller om de är skrivna på ett sätt som inte är förståeligt. Det dokumentationssätt som används är därför en viktig faktor för att kraven skall kunna begripas, analyse-ras, valideras och utvecklas.
Det finns standarder för hur krav borde dokumenteras, men det kan argumen-teras att strukturen borde anpassas för det problem som skall lösas [12]. 3.5 Validering och överenskommelse av krav
14
alla krav under valideringsprocessen, och det kommer med stor sannolikhet att krävas förändringar i kraven även efter att de är överenskomna [10] 3.6 Utveckling av krav
15
4 Metod
I detta kapitel beskrivs och motiveras de metoder som använts för undersök-ningen och i arbetet med produkten. Först ges en översikt över metoden och dess faser. Därefter beskrivs delmomenten litteraturstudie, kravhantering och uppbyggnad av utvecklingsmiljö för förberedelsefasen,
Iterativ utveckling och veckomöten för utvecklingsfasen och utvärderingskri-terier för resultatet i analysfasen. Det finns även en kort diskussion om hot mot arbetets validitet.
4.1 Översikt
Undersökningen utgick från frågeställningen “Hur kan ett verktyg för att ana-lysera diagnostiska data för felsökning byggas i en React webbapplikation?” För att besvara denna fråga används en kvalitativ metod i form av en fallstu-die. Anledningen till att en kvalitativ metod har valts är att författarna använ-der ingenjörsmässiga metoanvän-der för att utveckla en produkt åt ett företag, vilket en kvalitativ metod typiskt lämpar sig för [13]. Metoden använder ett induk-tivt tillvägagångssätt som utgår från de observationer som görs under utveckl-ingsprocessen som sedan analyseras för att skapa en bättre förståelse och dra slutsatser. Metoden kan delas upp i tre faser: förberedelsefasen, utvecklingsfa-sen och analysfautvecklingsfa-sen. I förberedelsefautvecklingsfa-sen finns momenten litteraturstudie, kravhantering och uppbyggnad av utvecklingsmiljö. I utvecklingsfasen sker iterativ utveckling och veckomöten. I analysfasen sker utvärdering av resulta-tet. Metoden med dess faser och moment illustreras i figur 4.1.
Figur 4.1. Metodens faser och moment [15]. 4.2 Förberedelse
16
behövdes för arbetet. I kravhantering påbörjades kravinsamlingen med en do-mänundersökning. I uppbyggnad av utvecklingsmiljö gjordes de förberedelser som krävdes för att utveckla produkten i det existerande systemet.
4.2.1 Litteraturstudie
Inför och under arbetet skedde sökning av relevant litteratur. Sökningen skedde i KTHs Divaportal och IEEEs databas. Sökmotorn Semantic scholar [3] för att hitta akademiska journalartiklar. KTHs Divaportal ansågs som lämplig då den innehåller många exempel på andra mjukvaruprojekt på lik-nande nivå. IEEEs databas valdes då den inriktar sig på bland annat IT-områ-det. Mycket information och dokumentation om JavaScript ramverk finns i dokumentationen på deras webbsidor. För information om verktyg som t.ex. React och D3 ansågs den information som kommer från ramverkets/verktyget officiella webbsidor som pålitlig.
Kunskap från detta moment utgjorde grunden för valet av metoder till krav-hanteringen och implementeringen av produkten.
4.2.2 Kravhantering
För kravinsamlingen valdes metoderna workshop och domänundersökning. Anledningen till att workshop valdes över intervju var att systemets användare inte fanns lika nära till hands som företagets intressenter. Det fanns även ris-ken att vi skulle företräda företaget på ett olämpligt sätt inför deras kunder och etiska avvägningar som behövs vid utförande av en intervju.
Domänundersökning
En domänundersökning av Mavenoids system genomfördes i början av arbe-tet. En domänundersökning ansågs som en lämplig kravinsamlingsmetod ef-tersom projektet handlar om att utveckla ny funktionalitet i ett system som re-dan existerar och används. En genomgång av systemet genomfördes först med företagets VD, en huvudintressent som har mycket god kunskap om systemet och nära kontakt med kunder. Intressenten bidrog med en modell av systemet och de delar som är viktigast för kunderna och mest relevanta att visualiseras. Under mötet ställdes frågor till intressenten om de koncept som var mindre bekanta. Mötet gav oss en bättre förståelse över vilka krav som hade högst pri-oritet. Vi fick också en modell av systemet som var användbar för steget mo-dellering-och-analys av krav som nämns i 3.3. Genomgången varade i cirka en timme. Endast ett möte av denna typ skedde. Vi hade efter mötet regelbun-den kontakt med intressenten då vi befann oss i samma lokaler, och ställde följdfrågor till denne.
17
Workshop
De veckomöten som skedde för kravhantering beskrivs i 4.3.2 då de inte ingår i förberedelsefasen.
4.2.3 Uppbyggnad av utvecklingsmiljö
Eftersom produkten skulle byggas i ett existerande system var det nödvändigt att installera utvecklingsmiljön för detta på våra datorer. De huvudsakliga de-larna i detta var mjukvaran för virtualisering av miljön och tillgång till syste-met för versionshantering med server för kontinuerlig integration. I detta mo-ment ingick även konfiguration för att se till att utvecklingsdatabaser använ-des och administration av användarkonton.
4.3 Utveckling
I utvecklingsfasen genomfördes utvecklingsarbetet med produkten. I den ite-rativa utvecklingen producerades all kod i arbetet. Momentet veckomöten skedde samtidigt som den iterativa utvecklingen och stod för de löpande de-larna i kravhanteringen.
4.3.1 Iterativ utveckling
Metoderna som används för den iterativa utvecklingen i arbetet beskrivs sepa-rat i kapitel 5.
4.3.2 Veckomöten
Möten med intressenter från företaget genomfördes veckovis och var den hu-vudsakliga metoden för kravhantering. Anledningen till att workshop ansågs som en lämplig metod för kravinsamling var att vi utförde arbetet i företagets lokaler och hade intressenterna tillgängliga. Dessa möten genomfördes i loka-ler som grupprum elloka-ler i soffgrupper och antalet deltagare var 4–6. Detta bi-drog till att alla deltagare kände sig bekväma att tala öppet. Deltagarna var produktens ägare, CTO, en utvecklare och vi. Mötena var av den informella ty-pen beskriven i 3.2 och hade ingen formell struktur. På varje möte redovisades prototyper för intressenterna i en så kallad demo. Prototyperna användes som underlag för diskussion om kraven. Anteckningar från varje möte fördes i mjukvaran Quip och kunde redigeras av samtliga deltagare. Mötena var an-vändbara för många delar av kravhanteringen. Nya krav kunde insamlas un-der ett möte (kravinsamling), mötena var ett bra medium för kommunikation om kraven mellan oss och intressenter (kommunikation av krav). Krav kunde valideras och deltagarna kunde komma överens om det fanns konflikter eller oklarheter (validering av krav). Beslut kunde ske om krav från tidigare möten som inte längre ansågs viktiga kunde tas bort (utveckling av krav).
4.4 Analys
I denna slutliga fas utvärderades resultatet med hjälp av de framtagna kraven. Potentiella hot mot arbetets validitet och hur de hanterats diskuteras.
4.4.1 Hot mot validitet
18
validitet. Detta hot hanterades genom att de huvudintressenter som varit med under domänundersökningen och grupparbeten hade en mycket god förstå-else för slutanvändarnas behov som de kommunicerade till utvecklarna och tog hänsyn till i sina bedömningar.
4.4.2 Utvärdering av resultat
Resultatet av arbetet utvärderades på två sätt. Den slutliga prototypen utvär-derades med hjälp av de framtagna kraven. Kraven listas här för att de var vik-tiga i utvärderingen. Det kommer mer information om kraven som hur och när i arbetet de tagits fram i kapitel 5. Kraven indelades i olika prioritetsnivåer enligt MoSCoW-metoden som nämns i 3.1.
Måste-Kraven var:
• K1. Produkten skall vara inbyggd i Mavenoids existerande system. Bör-kraven var:
• K2. Som användare kan jag se vilka grundorsaker som är vanligast fö-rekommande i en produkt.
• K3. Som användare kan jag se vilka symptom som är vanligast före-kommande i en produkt.
• K4. Som användare kan jag se vilka komponenter som oftast fallerar i en produkt.
• K5. Som användare kan jag se hur grundorsakerna för en produkt upp-träder över tiden.
• K6. Som användare kan jag se hur symptom för en produkt uppträder över tiden.
• K7. Användare skall kunna filtrera resultaten efter slut-och-startdatum. • K8. Produkten skall följa riktlinjerna i designdokumentet.
• K9. Produkten skall ha en design som är snarlik den som specificerats. Kunna-kraven var:
• K10. Mätvärden för intervall kan slås ihop i diagrammen.
Resultatet utvärderades även utifrån om det accepterades och integrerades i systemet vilket skedde den 25 juli 2018.
19
5 Arbetsprocess
I detta kapitel ges en kort introduktion till arbetsmetoder för mjukvaruut-veckling, sedan beskrivs den valda metoden som använts i arbetet. En beskriv-ning av utvecklingsprocessen ges samt en lista över utvecklingsverktyg som användes.
5.1 Vattenfallsmodellen och agila modeller
Två vanliga arbetssätt som ligger på varsin sida i ett spektrum av arbetsme-toder är vattenfallsmodellen och den agila modellen.
Vattenfallsmodellen är linjär och sekventiell, med ett förbestämt antal faser där varje fas måste genomföras helt innan det nästa kan påbörjas. Varje steg utförs av experter på området. Metoden beskrevs först 1970 i Managing the development of large software systems [16].
Vattenfallsmetoden lämpar sig väl för korta projekt där kraven är väldefinie-rade, där teknologin som används är välbekant och stabil [17]. Fördelar med vattenfallsmodellen är att varje steg har tydliga delar som skall levereras och en utvärderingsprocess. Processen och resultat dokumenteras tydligt. Det är lätt att arrangera de aktiviteter som skall göras till ett schema.
Vattenfallsmodellen har ett antal nackdelar. Ingen funktionell kod utvecklas förrän i de senare faserna med denna metod. Det är mycket resurskrävande att göra ändringar i kraven när de tidiga faserna är genomförda, detta leder till problem eftersom kunden vanligen inte vet exakt vilka krav de har. All inte-grering med andra system sker i ett enda stort steg i slutet. Dessa faktorer le-der till att det kan bli stora risker att projektet inte kan genomföras inom givna ramar för tid, kostnad och funktionalitet.
Den andra modellen är den agila modellen. Ett agilt arbetssätt är cykliskt, där varje cykel har ett antal faser som kan liknas en mini-vattenfallsmodell. I Manifesto for agile software development från 2001 så läggs ett antal prin-ciper för agil utveckling fram [18]. Bland dessa är:
● Kundnöjdhet genom tidiga och kontinuerliga leveranser av värdefull mjukvara
● Välkomna förändringar i kraven även i sent i utvecklingen ● Daglig nära kontakt mellan utvecklare och affärsfolk
● Konversationer öga-mot-öga är det bästa kommunikationssättet. (sam-lokalisering)
Produkten testas och fungerande kod levereras i varje iteration, detta gör det lättare att upptäcka problem i god tid. Agila arbetsmetoder gör det lätt att ändra produktens krav under utvecklingen, eftersom dessa är utgångspunkten för varje iteration. Agila metoder är flexibla och tillåter förändringar i pro-jektets ramar för tid, kostnad och funktionalitet. Riskerna i projektet minskar eftersom kod kontinuerligt levereras till kunden.
20
som utvecklas. Det är mycket ansvar på de individuella projektmedlemmarna på grund av minimal dokumentation [19]. Då agila metoder tillåter ändringar av kraven under utvecklingen kan det leda till att projektet tappar fokus om kunden gör stora ändringar i kraven ofta [20]. Det är därför bra att utföra nå-gon typ av kravhantering för att så bra som möjligt förstå kundens behov och minska risken för att detta sker.
5.2 Den valda arbetsprocessen
Arbetet har skett enligt ett agilt arbetssätt. Detta arbetssätt ansågs som lämp-ligt på grund av flera anledningar. Utvecklingen planerades ske i nära sam-band med intressenter i deras lokaler, vilket är gynnsamt för ett agilt arbets-sätt. En fullständig kravspecifikation var ej tillgänglig i början av projektet och det var nödvändigt att genomföra kravinsamling för att skapa en. Utvecklarna förväntade sig att det skulle ske ändringar i kraven genom projektets gång. Prototypen som skapas var tänkt att integreras med en befintlig produkt som är under utveckling. Problemområdet och de verktyg som förväntades använ-das var obekanta och utvecklas kontinuerligt. Ett agilt arbetssätt underlättar att projektet kan anpassa sig efter förändringarna och anses därför som lämp-ligt.
5.3 Utvecklingsprocess
Under utvecklingen av produkten använde vi flera begrepp från Extreme pro-gramming, XP [21]. Ett av dessa var kontinuerlig integration, vilket innebär att koden som skrivs integreras så ofta som möjligt. Vi arbetade med en vers-ion av systemet konfigurerad för utveckling på en egen gren i versvers-ionshante- versionshante-ringssystemet som vi slog ihop koden till flera gånger dagligen.
Vi använde företagets server för kontinuerlig integrering som körde tester vid uppladdning av ändringar. Vi satt bredvid varandra och skrev kod i samma lo-kal som företagets andra utvecklare och diskuterade ofta med dessa.
Ett annat begrepp från XP som användes var parprogrammering vid utveckl-ing av vissa delar. Parprogrammerutveckl-ing innebär att en utvecklare har en övergri-pande fokus om det som utvecklas och hjälper den andra utvecklaren navigera medans denne kan fokusera på att skriva själva koden. Dessa roller varvas emellanåt.
Vi höll koll på arbetsuppgifter med produktivitetsverktyget Quip [22] i vilket vi skapade checklistor med arbetsuppgifter och krav under varje veckomöte. Intressenter från företaget och utvecklare kunde kommentera i dokumenten om vilka krav som borde prioriteras.
I utvecklingens slutskede gjordes en verifiering av pull-request. Företagets in-tressenter och utvecklare kunde lägga kommentarer om önskade förändringar bredvid kodrader.
5.4 Utvecklingsverktyg
Följande utvecklingsverktyg användes under arbetet.
21
● Docker, sköter utvecklingsmiljön, fungerar som en behållare för syste-met så att det kan köras på olika maskiner. Kör startskript för att starta de olika delarna i systemet, t.ex. databas, back-end och front-end [24]. ● NPM, pakethanteringsverktyg för JavaScript [25].
● Webpack + Webpack dev server, används för att packa ihop och kom-primera koden samt för att se resultatet av ändringar i front-end-koden i webbläsare utan omstart [26].
● Quip, dokumentering, används hos företaget för att skriva textdoku-ment, checklistor, m.m. som kan diskuteras tillsammans med kollegor. Detta verktyg användes bland annat för att föra anteckningar under gruppmöten [22].
● Git, versionshanteringsprogram, användes för att undvika konflikter mellan kod, spara historik över sin kod samt sammanfoga kod [27]. ● HipChat, chatprogram, användes för kommunikation med företaget
[28].
23
6 Resultat
I detta kapitel presenteras resultatet av arbetet. Författarna har valt att pre-sentera resultatet utifrån de iterationer som genomförts och sedan ge en över-blick över den slutliga prototypen som levererades till företaget. Anledningen till att resultatet inte presenteras utifrån de specificerade kraven i detta kapitel är att det sker i kapitel 7, där resultatet utvärderas.
6.1 Produktens utveckling
Här ges en beskrivning av de iterationer som genomfördes under arbetet.
6.1.1 Uppbyggnad av utvecklingsmiljö och kravhantering
Innan arbetet med systemet kunde påbörjas var det nödvändigt att sätta upp utvecklingsmiljön. Detta innebar installation av en utvecklingsversion av pro-duktens tre huvuddelar: databasen, back-end-APIet och front-end-klienten samt de utvecklingsverktyg som krävdes för att arbeta med dem. Detta var nödvändigt för att möta kravet “K1. Produkten skall vara inbyggd i Mavenoids existerande system.” All utveckling i projektet skedde i denna utvecklingsvers-ion av Mavenoids system.
Ramverket D3 hade under litteraturstudien uppmärksammats som ett ram-verk som kunde lämpa sig för att skapa diagrammen i produkten, något som intressenterna även höll med om. Ramverket utforskades genom att bygga enkla diagram i systemet och verifiera att det fungerade som väntat.
Som tidigare nämnts i kapitel 3 gjordes som en del av domänundersökningen en genomgång med en huvudintressent från företaget. Intressenten gick ige-nom de begrepp som är viktigast för användarna och tre huvuddelar identifie-rades: Grundorsaker, symptom och komponenter. Systemets användare skulle ha nytta av att få dessa visualiserade för sig.
Mötet resulterade i följande krav:
● K1. Produkten skall vara inbyggd i Mavenoids existerande system. ● K2. Som användare kan jag se vilka grundorsaker som är vanligast
fö-rekommande i en produkt.
● K3. Som användare kan jag se vilka symptom som är vanligast före-kommande i en produkt.
● K4. Som användare kan jag se vilka komponenter som oftast fallerar i en produkt.
● K5. Som användare kan jag se hur grundorsakerna för en produkt upp-träder över tiden.
● K6. Som användare kan jag se hur symptom för en produkt uppträder över tiden.
24
och färger som skall användas och hur användargränssnittelement som knap-par och menyer skall se ut. Det fanns även dokument med ett förslag på hur produktens användargränssnitt kunde se ut, vilket användes som underlag för diskussioner med företaget om hur den slutliga vyn skulle se ut. Dokumentet visas i figur 6.1 så att det kan jämföras med den slutliga designen.
Utifrån dessa dokument och diskussioner specificerades följande krav: • K8. Produkten skall följa riktlinjerna i designdokumentet.
• K9. Produkten skall ha en design som är snarlik den som specificerats.
Figur 6.1: Företagets Designförslag.
6.1.2 Utveckling av första prototypen
I den andra iterationen utvecklades den första prototypen med ramverket D3. Två diagram implementerades. Det ena var en tidslinje över antalet använ-darssessioner per dag för en produkt i systemet med ett underdiagram över hela intervallet som kan användas för att välja ut ett delintervall att visa. Detta diagram var ett första steg till att bemöta kraven “K5. Som användare kan jag se hur grundorsakerna för en produkt uppträder över tiden.”, “K6. Som an-vändare kan jag se hur symptom för en produkt uppträder över tiden.” och “K7. Användare skall kunna filtrera resultaten efter slut-och-startdatum.” då det utforskade ett lämpligt diagram för dessa men med ersättningsdata ef-tersom ändpunkterna för detta inte ännu var implementerade. Diagrammet visas i 6.2 så att det kan jämföras med de slutliga diagrammen.
Det andra diagrammet var ett stapeldiagram över hur ofta de olika sympto-men för en produkt observerades. Detta diagram behandlade kravet “K3. Som användare kan jag se vilka symptom som är vanligast förekommande i en pro-dukt."
25
Figur 6.2: Diagram över användarsessioner.
Under gruppmötet kom det fram att visualisering av grundorsaker var något som borde prioriteras istället för visualisering av användarsessioner. Punk-terna i det diagrammet ansågs inte heller som nödvändiga, det var tillräckligt med staplar.
6.1.3 Utveckling av andra prototypen
I litteraturstudien hade biblioteket C3 uppmärksammats som ett ramverk som ett lämpligt alternativ till D3. C3 bedömdes ha ett antal fördelar mot D3. Med C3 krävs det mindre kod för att implementera diagram. Det uppskattades där-för att det skulle gå snabbare och kräva mindre arbete där-för att skapa diagram-men i C3. React-komponenten blev stor med koden för D3 vilket gav den dålig sammanhållning. Det innebar i detta fall att kod för orelaterad funktionalitet låg i samma komponent. Till exempel definition av beståndsdelarna för ett di-agram och användargränssnittets layout. Detta ansågs också åtgärdas med C3. På grund av dessa fördelar valdes C3 för den andra prototypen i den tredje ite-rationen. Stapeldiagrammet och tidslinjen från första prototypen implemente-rades i C3 för att se ifall de uppnådde de krav som eftersöktes.
En ändpunkt för tidslinjen lades till i APIet för denna prototyp och samtliga ändpunkter som användes utökades så att de skickade data med ett format som kunde användas direkt av C3 och inte behövde bearbetas först. I tidigare iterationer användes redan befintliga ändpunkter för att skicka det data som behövdes. Dessa ändpunkter skickade ett stort JSON objekt med många indi-viduella datum, som sedan räknades ihop i front-end så att de kunde visas i ett diagram. Denna finkornighet ansåg vi inte var nödvändig eftersom vi bara visade datat som minst per dag. Den nya ändpunkten skickade data redan hopräknat per dag och på rätt format. Detta medförde även att mindre data behövde skickas, och att koden för att räkna ihop data i front-end kunde tas bort. Vi blev även av med ett beroende då biblioteket d3-collection användes för detta.
På ett möte i denna iteration kom det fram ett behov av att sammanfoga resul-tatet från flera dagar i till en stapel i diagrammet. Därför tillkom kravet
26
Figur 6.3: Revision av designförslag.
6.1.4 Utveckling av den slutliga produkten
I den sista iterationen implementerades produkten med det valda biblioteket C3. Då användargränssnittet är en viktig del av produktens krav utgick iterat-ionen från den design som tagits fram av företaget. Denna design diskuterades med intressenter från företaget och ett designförslag togs fram av utvecklarna. Ett förslag var till exempel att byta ut show more knappen mot en rullist. De-signförslaget syns i figur 6.3 och kan jämföras med den ursprungliga designen i figur 6.1.
Ytterligare diskussion om designförslaget utmynnade sedan i den slutliga de-sign som användes för att implementera den slutliga prototypen. En punkt från denna diskussion var att underdiagrammet med en översikt över hela tidsperioden var förvirrande och borde tas bort eftersom det redan finns knappar för snabbval av tidsintervall.
För att se hur produkten skulle bete sig i en produktionsmiljö användes en da-tabasdump från produktionsdatabasen med data från verkliga användare un-der utvecklingen i denna iteration. Flera API ändpunkter lades till för att kunna uppfylla kravet “K2. Som användare kan jag se vilka grundorsaker som är vanligast förekommande i en produkt.“ då data om grundorsaker behövdes hämtas ur databasen.
27
6.1.5 Pull-request och verifiering
I slutet av den sista iterationen när produkten var utvecklad gjordes en pull-request till företagets versionshanteringssystem. Att göra en pull-pull-request in-nebär att man skickar in ett kodförslag till deras nuvarande system. Företaget kan då titta igenom förändringarna som skapats i koden och kommentera på saker de tycker ska göras på ett annat sätt, implementeras annorlunda eller de är nöjda med. Detta är en mycket noggrann verifieringsprocess som låter kun-den, i detta fall de intressenter från företaget som deltagit i veckomötena be-kräfta att produkten möter de ställda kraven. När denna pull-request är god-känd kan företaget sammanslå den föreslagna koden med sin egen kod. 6.2 Översikt över den slutliga prototypen
Resultatet var en produkt som var integrerad i företagets system. Produkten har en vy där det går att se olika data om grundorsakerna för en given produkt i systemet. Användargränssnittet är uppdelat i två delar, se figur 6.4. Den vänstra delen innehåller element för att filtrera vilken data användaren vill se. Den högra delen innehåller det diagram som skall visas.
Figur 6.4: Den slutliga designen för vyn.
Inmatningsfältet för början och slutet på tidsintervallet som skall visas imple-menterades med färdigbyggda komponenter från paketet Material-UI [30]. Dessa var datumväljare i form av kalendrar och knappar för snabbval av sen-aste veckan, månaden, kvartal och år.
Listan över vanligast förekommande grundorsaker och symptom implemente-rades med endast JavaScript, HTML och CSS utan C3 eller D3. Användarna kunde välja ett symptom eller en grundorsak för att visa data för just denna i diagrammet till vänster. För att undvika att använda webbläsarens förvalda rullist användes biblioteket react-scrollbar.
28
29
7 Utvärdering av resultat
I detta kapitel utvärderas resultatet enligt de kriterier som beskrivs i 4.4.2. Först ges motiveringar för hur väl produkten möter varje krav i listan, sedan beskrivs status för den pull-request som gjordes till företagets system.
7.1 K1. Produkten skall vara inbyggd i Mavenoids existerande sy-stem.
Uppbyggnad av utvecklingsmiljön så att utveckling av produkten kunde ske i företagets existerande system skedde som beskrivet i 6.1.1 tidigt i projektet. Därefter skedde all utveckling i denna miljö. Detta inkluderar den slutliga pro-dukten. Produktens kod klarade kontinuerlig integration-serverns tester och kunde efter godkännande av en pull-request sammanslås med resten av före-tagets system.
Figur 7.1: Listan över symptom och grundorsaker.
7.2 K2 & K3. Som användare kan jag se vilka grundorsaker/symp-tom som är vanligast förekommande i en produkt.
Användare kan se en lista över alla symptom eller grundorsaker i användar-gränssnittets högra del. Listan visas i figur 7.1. Listan är sorterad efter före-komst, därför kan användarna direkt se vilka grundorsaker och symptom som är vanligast förekommande. Längden på varje stapel i listan är proportionell mot det totala antalet.
7.3 K4. Som användare kan jag se vilka komponenter som oftast fallerar i en produkt.
30
Figur 7.2: Diagram över grundorsaker och symptom. 7.4 K5. & K6. Som användare kan jag se hur grundorsa-kerna/symptom för en produkt uppträder över tiden.
Användaren kan välja en grundorsak eller ett symptom i listan till höger för att visa ett stapeldiagram över hur många gånger den uppträtt per dag. Med detta diagram som syns i figur 6.2 kan de se hur symptomen och grundorsa-kerna beter sig över tiden. Med färgen kan användarna se om stapelns höjd skiljer sig mycket från medelvärdet.
Figur 7.3: Meny för filtrering av datum.
7.5 K7. Användare skall kunna filtrera resultaten efter slut-och-startdatum.
Användaren kan via knappar och inmatningsrutor filtrera vilken tidsperiod de vill se data för. Användaren kan välja start- och slut datum via en datumväl-jare som visas i figur 7.4 men även välja att filtrera efter senaste vecka, månad, kvartal och år med knappar för snabbval som syns i figur 7.3. Datat som visas är data mellan start och slutdatum.
7.6 K8. Produkten skall följa riktlinjerna i designdokumentet.
31
Figur 7.4: Meny för filtrering av datum.
7.7 K9. Produkten skall ha en design som är snarlik den som spe-cificerats.
Den slutliga designen i figur 7.5 är mycket lik företagets ursprungliga förslag som syns i figur 6.1. De delar som ändrats är att en rullgardinsmeny lagts till för att välja mellan grundorsak och symptom samt en rullningslist istället för en show more-knapp.
Företaget önskade även sammanfogning av data från flera dagar till en stapel, men då detta krav valts bort är staplar inte sammanfogade utan en stapel för varje dag visas.
Figur 7.5: Den slutliga designen för vyn.
7.8 K10. Mätvärden för intervall kan slås ihop i diagrammen Kravet på att slå ihop mätvärden från intervall till en stapel togs bort i den sista iterationen, och uppfylldes därför ej.
7.9 Pull-request
32
33
8 Diskussion
I detta kapitel diskuteras resultatet av arbetet med hjälp av utvärderingen i fö-regående kapitel sedan ges ett svar till arbetets frågeställning. Resultatet dis-kuteras även utifrån hållbar utveckling och etiska aspekter. Slutligen ges för-slag på fortsatt arbete.
8.1 Utvärdering av resultat
Produkten uppfyllde åtta av de tio krav som tagits fram. Ett av kraven som inte uppfylldes, K4, handlade om visualisering av komponenter som skulle kunna implementeras utan att göra ändringar i användargränssnittet. Det skulle endast kräva ett ytterligare alternativ i en rullgardinsmeny och änd-ringar i Back-end för att lägga till nya ändpunkter för att hämta data om dem. Komponenter var minst viktiga att visualisera för intressenterna, därför anses borttagandet av detta krav som acceptabelt.
Det andra kravet som inte uppfylldes, K10 som handlade om sammanslagning av data i intervall till en stapel. Tanken var att ge användaren en bättre upp-fattning om medelvärden för t.ex. månader eller veckor, då det kan vara svårt att avgöra detta med de nuvarande diagrammen. Kravet lyftes inte fram som något absolut nödvändigt och var därför ett kunde-krav. På grund av detta an-ses borttagandet av detta krav också som acceptabelt.
Inget av de krav som inte möttes var av prioriteringsnivån måste, och endast ett av kraven var ett bör-krav. Det anses därför att produkten i tillräckligt hög grad uppfyllde de krav som samlats in, och de förhoppningar som intressen-terna hade med arbetet. Denna slutsats styrks framförallt av att den pull-re-quest som skickades in godkändes och integrerades i systemet.
8.2 Svar på arbetets frågeställning
Svaret på arbetets frågeställning: “Hur kan ett verktyg för att analysera dia-gnostiska data för felsökning byggas i en React webbapplikation?” blir efter utvärdering av resultatet “Genom att använda kravhantering, genomföra do-mänundersökning och grupparbete med intressenter i form av möten vecko-vis, och en iterativ agil arbetsmetod.”
8.3 Hållbar utveckling och etik
Under utvecklingen av produkten har utvecklarna haft tillgång till uppgifter tillhörande företagets kunder i form av problemlösningsmodeller och en dump från produktionsdatabasen. För att försäkra företaget om att företags-hemligheter inte röjs har utvecklarna i samband med projektet skrivit på ett sekretessavtal.
34 8.4 Fortsatt arbete
Då en del av kraven valts bort på grund av tidsbrist kan dessa inkluderas i fortsatt arbete. Detta är bland annat sammanfogning av data, detta innebär att utvecklare då implementerar ett sätt att sammanfoga data som är inom
samma tidsspann. Ett exempel på detta kan vara ifall användaren tittar på data över en månad så sammanfogas data i samma vecka till en stapel, det blir då en stapel per vecka istället för sju. Detta medför att det är lättare att se det medelvärdet för varje vecka. Sammanfogning är intressant då man sällan är intresserad av data för en specifik dag utan ofta vill se användningen under en viss period.
Även ytterligare data kan inkluderas i verktyget såsom komponenter. Pro-jektets krav skalades ner till att endast visualisera de två viktigaste delarna i systemet. Det finns många andra delar som kan visualiseras på liknande sätt och nya krav för detta kan därmed samlas in.
Det finns dessutom delar av systemet som kan visualiseras på andra sätt. Un-der projektet testades olika typer av diagram, det diagram som ansågs mest lämpligt för de visualiseringar som behövdes göras var stapeldiagram, däre-mot kan andra typer av visualiseringar vara lämpligare för andra delar av sy-stemet.
Något som också är värt att tänka på är att stapeldiagram kanske inte alltid är det bästa sättet att visualisera data på i alla situationer. Det kan finnas till-fällen man istället vill visualisera data med t.ex. ett linjediagram. Det kan det även vara användbart att implementera ett sätt att byta vilken typ av diagram som ska användas.
8.5 Transaktionsstorlek
Något som noterades under projektet var att projektets totala transaktions-storlek ökade vid användning av D3 och C3. Detta medför att den slutliga filen som skickas till klienten är större.
En enkel undersökning av detta gjordes i slutet av projektet. Undersökningen gick till så att vi använde verktyget för inspektion av nätverksaktivitet i webb-läsaren Google Chrome. Verktyget visar hur mycket data som skickas till webbläsaren. Resultatet blev att den totala storleken för den slutliga prototy-pen ökade med ungefär 21% vilket visas i Figur 8.1.
35
37
Referenser
[1] Baldé, C. P, V. Forti, V. Gray, Kuehr and P. Stegmann, The Global E-waste Monitor – 2017. Bonn/Geneva/Vienna: United Nations University (UNU), In-ternational Telecommunication Union (ITU) & InIn-ternational Solid Waste As-sociation (ISWA), 2017, pp. 78, 107.
[2] 2030 Agenda for Sustainable Development, Sustainabledevelop-ment.un.org, 2015. [Online]. Available:
https://sustainabledevelop- ment.un.org/content/documents/21252030%20Agenda%20for%20Sustaina-ble%20Development%20web.pdf. [Accessed: 20- Jan- 2019]
[3] "Semantic Scholar - An academic search engine for scientific articles", Se-manticscholar.org. [Online]. Available: https://www.seSe-manticscholar.org. [Accessed: 06- Feb- 2019].
[4] A. Lerner, "Fullstack React: What is React?", Fullstack React. [Online]. Available: https://www.fullstackreact.com/30-days-of-react/day-1/. [Ac-cessed: 29- Jan- 2019].
[5] JSX In Depth – React, Reactjs.org. [Online]. Available: https://re-actjs.org/docs/jsx-in-depth.html. [Accessed: 29- Jan- 2019].
[6] M. Bostock, "D3.js - Data-Driven Documents", D3js.org. [Online]. Availa-ble: https://d3js.org/. [Accessed: 29- Jan- 2019].
[7] M. Iglesias, "Bringing Together React, D3, And Their Ecosystem", Smash-ing Magazine, 2018. [Online]. Available: https://www.smashSmash-ingmaga-
https://www.smashingmaga-zine.com/2018/02/react-d3-ecosystem/. [Accessed: 29- Jan- 2019].
[8] D. Iffland, "C3.js Brings Charting Power Without the Learning Curve", In-foQ, 2014. [Online]. Available: https://www.infoq.com/news/2014/09/c3js-d3-charting. [Accessed: 29- Jan- 2019].
[9] P. Dunlu, C. Lidong and X. Wenjie, "Using JSON for Data Exchanging in Web Service Applications", Journal of Computational Information Systems, no. 7, 2011. [Accessed 29 January 2019].
[10] I. Sommerville, Software engineering, 9th ed. Boston: Pearson, 2011, pp. 82-111.
[11] K. Ahmad, N. Ahmad, H. Tahir and S. Khan, "Fuzzy_MoSCoW: A fuzzy based MoSCoW method for the prioritization of software requirements", 2017 International Conference on Intelligent Computing, Instrumentation and Control Technologies (ICICICT), 2017. Available:
10.1109/ici-cict1.2017.8342602 [Accessed 27 February 2019].
38
[13] A. Håkansson, ‘Portal of Research Methods and Methodologies for Re-search Projects and Degree Projects’, in Proceedings of the International Con-ference on Frontiers in Education : Computer Science and Computer Engi-neering FECS’13, 2013, pp. 67–73.
[14] A. Aurum and C. Wohlin, Engineering and Managing Software Require-ments. Berlin: Springer, 2005.
[15, Figur 10] D. Buchberger and K. Sozinov, ‘Visualisering av mjukvaru-system och mjukvaru-systemberoenden’, Dissertation, 2016.
[16] W. W. Royce, Managing the development of large software systems: con-cepts and techniques, Proc. IEEE WESTCON, Los Angeles, pp. 1--9, 1970 [17] SDLC Waterfall Model, www.tutorialspoint.com. [Online]. Available: https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm. [Accessed: 29- Jan- 2019].
[18] K. Beck et al., “Manifesto for Agile Software Development,” Manifesto for Agile Software Development. 2001 [Online]. Available: http://www.agileman-ifesto.org/
[19] "SDLC Agile Model", www.tutorialspoint.com, 2019. [Online]. Available: https://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm. [Accessed: 10- Jun- 2019].
[20] S. Sharma, D. Sarkar and D. Gupta, "Agile processes and methodologies: A conceptual study", International journal on computer science and Engineer-ing, vol. 4, no. 5, p. 892, 2012. [Accessed 13 February 2019].
[21] L. Lindstrom and R. Jeffries, "Extreme Programming and Agile Software Development Methodologies", Information Systems Management, vol. 21, no. 3, pp. 41-52, 2004. Available: 10.1201/1078/44432.21.3.20040601/82476.7 [Accessed 18 April 2019].
[22] "Quip", Quip, 2019. [Online]. Available: https://quip.com/. [Accessed: 11- Jun- 2019].
[23] "WebStorm: The Smartest JavaScript IDE by JetBrains", JetBrains, 2019. [Online]. Available: https://www.jetbrains.com/webstorm/. [Accessed: 11- Jun- 2019].
[24] "Enterprise Container Platform | Docker", Docker, 2019. [Online]. Avail-able: https://www.docker.com/. [Accessed: 11- Jun- 2019].
[25] "npm | build amazing things", Npmjs.com, 2019. [Online]. Available: https://www.npmjs.com/. [Accessed: 11- Jun- 2019].
39
[27] "Git", Git-scm.com, 2019. [Online]. Available: https://git-scm.com/. [Ac-cessed: 11- Jun- 2019].
[28] "Atlassian + Slack | Atlassian", Atlassian, 2019. [Online]. Available: https://www.atlassian.com/partnerships/slack. [Accessed: 11- Jun- 2019]. [29] "Jenkins", Jenkins, 2019. [Online]. Available: https://jenkins.io/. [Ac-cessed: 11- Jun- 2019].
TRITA-EECS-EX-2019:534
