För att produkten skulle vara användbar att använda skulle det även behövas ett mer stabilt sätt att mäta EEG-data då den utrustning som hittills använts är väldigt känslig för rörelser och användning av muskler. Detta gör att utrustningen blir olämplig för ändamålet. Det sista som kunden skulle behöver åtgärda innan produkten kan användas är att skala upp systemet till att ta emot indata och utföra beräkningar för flera olika personer samti- digt, då systemet är tänkt att övervaka samtliga flygledare inom en organisation. Det som skulle behövas är ett unikt ID för varje individ som skickas med all data och beaktas under beräkningarna. Användargränssnittet skulle även behöva justeras till att stödja flera indivi- der. Eftersom all sensordata som skickas in i NiFi är i JSON-format skulle detta ID kunna implementeras som en extra nyckel i varje JSON-meddelande.
Det går också att skala upp beräkningskraften när antalet flygledare ökar, eftersom beräk- ningarna utförs på ett kluster.
Sammanfattningsvis så har projektgruppen fått uppfattningen att ramverken och verkty- gen som användes genom projektet så som Apache NiFi, Apache Kafka och Apache Spark kommer att kunna behållas när produkten tar sina steg från prototyp till en färdig produkt. Detta då de är konstruerade för att kunna hantera större flöden och upplevs lätta att skala upp till det användningsområde som är planerat för produkten.
6.1.3
Hur skapar projektet ett värde för kunden?
Med den prototyp som presenteras i kapitel 5 har det skapats ett värde för kunden på flera sätt. I och med att prototypen togs fram testades många olika ramverk och verktyg som till exempel Apache NiFi och Apache Spark som visade sig vara väldigt användbara för den här typen av projekt. Framförallt prestandan och skalbarheten hos ramverken har varit ett viktigt resultat av projektet. Eftersom projektet är ett forskningsprojekt betyder detta också att vi kommit ett steg närmre målet vilket skapar ett stort värde för kunden.
Modellerna som tagits fram visade sig också vara användbara även om de skulle behöva finjusteras. De modeller som byggde på en SVR skulle behöva mer och bättre träningsdata för att bli mer pålitliga. Eftersom modellerna baserades på redan publicerade studier har kunden även fått en ökad kunskap om ett par applicerbara studier och en uppsättning studier som direkt kan uteslutas.
Hårdvaran prototypen använde var vanligt förekommande i kundens tidigare projekt och kunden äger därför redan nödvändig hårdvara för att skala upp beräkningsklustret vid be- hov.
6.1.4
Skalbart system
Följande punkter sammanfattar hur ramverken Kafka, Spark och NiFi är skalbara:
• Spark och NiFi är skalbart både horisontellt och vertikalt eftersom att beräkningar går att distribuera på ett kluster samt att mängden resurser som ska allokeras på varje en- skild dator går att bestämma (se kapitel 3.9.3 och 3.9.1).
• Kafka är horisontellt skalbart eftersom att arbete går att distribuera ut på ett kluster, precis som för Spark och NiFi (se kapitel 3.9.2).
Systemet har alltså förutsättningar för att kunna bemöta en ökande arbetsbörda och är därför enligt definition skalbart (se kapitel 3.2).
6.2
Metod
De metoder som valdes för projektet har för det mesta påverkat projektet positivt men det finns även mindre positiva erfarenheter. I det här stycket diskuteras de metoder som specifi- cerades i kapitel 4 och vilka konsekvenser dessa metoderna hade för resultatet.
6.2. Metod
6.2.1
Roller och Specialiseringar
Indelningen av roller tillsammans med specialiseringar i projektet har känts nödvändigt för att få bra struktur. I och med att projektet varat i cirka ett halv år samt att det behandlat en bred mängd områden kan inte alla medlemmar ansvara för allting lika mycket eller besitta exakt lika mycket kunskap om allting som projektet berört. Indelningen av roller har därför hjälp väldigt mycket för att se till att projektgruppen utvecklats effektivare. Även om beslut alltid tagits i grupp, var det alltid en person som hade ansvaret för att det blev gjort eller att projektgruppen faktiskt strävade åt önskat håll. Specialiseringarna hjälpte till att använda tiden effektivare genom att en medlem blev ”expert” på en varsin del av hårdvaran och sedan lärde ut till resterande medlemmar. Nackdelen med specialiseringarna var att det skapades så kallade nyckelpersoner, om någon av experterna var frånvarande ledde detta till att man antingen fick arbeta med något annat eller ta extra tid till att själva sätta sig in i hårdvaran. Detta hade kunnat undvikas genom att alltid ha två personer med samma specialisering.
6.2.2
Möten
Planering och statusmöte har varit det mötet som ägt rum kontinuerligt en gång i veckan. Dessa möten valdes att ske kontinuerligt för att hålla hela gruppen uppdaterat på situatio- nen och få en klar planering över vad som är gjort, ska göras och vad som behöver behöver förbättras eller liknande. Dessa användes på grund av flera medlemmars tidigare erfarenhe- ter och har fungerat bra.
I och med att projektgruppen använt en modifierad variant av Scrum har även ståupp- möten och uppföljning efter sprint genomförts. Ståupp-möten har varit ett utmärkt tillfälle att för samarbeten att bildas och att få hjälp då resterande gruppen får reda på vad som är gjort och vad som är planerat att göras för varje person.
6.2.3
Dokumentation
Dokumenten som har producerats under projektet har alla fyllt viss funktion till projektet. Med tanke på storleken som projektet haft har därför vissa dokument haft större påverkan än andra. Projektplanen har varit mest användbar under arbetet medan resterande doku- mentation varit mest användbart för att sätta riktlinjer, så att respektive ansvarig vet vad som gäller och sedan har informationen oftast hämtats från den ansvariga istället för från do- kumenten. För att underlätta kontakt med kunden under projektet så har kravspecifikation och arkitektursbeskrivning varit användbara. Detta för att se om projektgruppen har samma uppfattning om projektets omfattning som kunden samt delar samma syn på hur mjukvaru- arkitekturen ska se ut.
6.2.4
Arbetsverktyg
Generellt har arbetsverktygen fungerat som planerat. De enda negativa erfarenheter som kan tas med från projektet är med arbetsverktyget ShareLaTeX. Anledningen till att det inte är hållbart till större projekt där stora dokument skall produceras är då det finns brister i ver- sionshanteringen. Det finns också brister i prestandan samt tillförlitligheten när större doku- ment ska kompileras.
Eftersom metoden för att ta fram systemanatomin avslöjar hur funktionalitet och resurser är beroende av varandra så användes den för att se i vilken ordning som systemet borde im- plementeras. Därför var systemanatomin ett bra verktyg vid planeringen av konstruktions- fasen.
PyCharm har varit ett bra verktyg under utvecklingen av projektet. PyCharm har gett många hjälpmedel som har hjälpt till att göra programmeringen effektivare och lättare. En av dessa hjälpmedel var att PyCharm hjälpte till med att hålla kodstandard genom att ge förslag