Analyseren
AN1
Beschrijving
Ik kan een analyse van een opdracht uitvoeren gebaseerd op een praktische onderzoeksvraag en maak hierbij gebruik van bestaande methoden en technieken.
Bewijs volgens Stageplan
De uitgevoerde analyse van de vergelijking tussen twee oplossingen voor AIS receivers verwerkt in een testverslag, waarin de verschillen, voor- en nadelen en andere gegevens zoals bijvoorbeeld performance terugkomen.
Bewijs
Inleiding
De onderzoeksvraag voor de analyse om twee oplossing voor AIS receivers te vergelijken is:
Is het rPiAIS project van AISHub beter om te gebruiken als AIS dispatcher in vergelijking met de oplossing die al ontwikkeld is binnen Teqplay.
Dit onderzoek is van toepassing op de AIS Dispatcher voor Raspberry Pi met 3G Netwerk
De reden om deze mobiele AIS ontvanger te maken was om het plaatsje Izegem van meer dekking te voorzien, aangezien daar enkele tot geen scheepsberichten werden ontvangen. Door het maken van een mobiele ontvanger kon deze ingezet worden in Izegem maar ook voor andere locaties als op een later moment ook mobiele ontvangers ontwikkeld moeten worden.
Richard, de product owner, had aan Joost en mij gevraagd om het rPiAIS project van AISHub uit te proberen en te kijken of deze goed werkt om te gebruiken voor het project. Mocht deze niet goed werken dan konden we de 'home'-folder gebruiken die al eerder gemaakt was om zo de Raspberry Pi scheepsberichten op te laten halen.
rPiAIS
Om de Raspberry Pi op te zetten heb ik het stappenplan gevolgd op de pagina van AISHub. Hiervoor heb ik eerst de SD-kaartafbeelding gedownload en vervolgens op de SD-kaart van de Raspberry Pi geflashed. Hierna heb ik de stappen gevolgd om onder andere de WiFi en SSH configuratie op te zetten.
Na het opzetten en aansluiten van de Raspberry Pi is de volgende interface te zien binnen hetzelfde netwerk.
Binnen deze interface moeten nog enkele configuraties worden ingesteld voordat de Raspberry Pi daadwerkelijk de scheepsberichten kan ontvangen en versturen.
Problemen bij de interface
Het instellen en bekijken van de Raspberry Pi was vrij gemakkelijk door het simpelweg volgen van de stappen. Echter was de interface voor de AIS Dispatcher meerdere keren niet beschikbaar en bleek dat de Raspberry Pi niet meer werkte. De daadwerkelijke reden hierachter is niet bekend, maar op dat moment had ik als conclusie getrokken dat het binnenhalen van de scheepsberichten en het runnende houden van de interface te zwaar was voor de Raspberry Pi.
Voorlopig is deze oplossing dus niet te gebruiken als AIS Dispatcher, aangezien de interface te zwaar is voor de Raspberry Pi om draaiende te blijven.
Teqplay homedirectory
Een andere optie was de homedirectory van het vorige project, die al eerder gewerkt heeft. Hieraan moesten enkele aanpassingen gedaan worden zoals aan de monitor en het automatisch laten opstarten en werken van de applicatie.
Om deze te laten werken heb ik in eerste instantie de homedirectory overschreven van de rPiAIS om zo deze versie te kunnen testen op de Raspberry Pi. In principe stonden alle onderdelen hiervoor ook al ingesteld, het enige wat hier moest gebeuren was ervoor zorgen dat alle scripts uitvoerbaar waren en dat de Raspberry Pi na het opstarten zichzelf gelijk initialiseert.
Bij deze opstelling waren echter nog een aantal speerpunten die bijgewerkt moesten worden, zodat de Raspberry Pi daadwerkelijk klaar was voor het inzetten ervan.
Netwerkproblemen
Een probleem wat in de opstelling voorkwam is dat deze geen DNS resolution kon doen. Dit probleem zorgde ervoor dat er geen normale webadressen gebruikt konden worden om informatie te verkrijgen en versturen. Hierdoor moesten er IP-adressen ingevuld worden bij verschillende onderdelen zoals de monitor en de dispatcher van de gegevens naar AISHub en het platform van Teqplay.
Om dit probleem op te lossen kunnen alle addressen uiteraard vervangen worden door de IP-adressen. Een punt van aandacht hierbij is echter wel dat alle IP-adressen dan wel statisch moesten zijn, dus dat deze niet zouden veranderen in de looptijd dat de Raspberry Pi online moest staan.
Hierbij werd de overweging gemaakt dat het IP-adres van AISHub al jaren hetzelfde is en ik dus samen met de Product Owner kon concluderen dat deze statisch was. Daarnaast gingen we ervan uit dat het IP-adres van het platform ook hetzelfde zou blijven aangezien Teqplay hier invloed op heeft. Voor de uiteindelijke versie van de Raspberry Pi is dus gebruik gemaakt van statische IP-adressen om het netwerkprobleem op te lossen.
AISMonitor
Een ander probleem was dat de AISMonitor die al geïmplementeerd was verouderd was, waardoor de status van de Raspberry Pi niet bepaald kon worden. De monitor is namelijk verantwoordelijk om onderdelen te herstarten op het moment dat er geen berichten meer worden verstuurd. Om dit te kunnen doen controleert de Raspberry Pi bij AISHub wat de status is van het station, als de status hiervan niet op online staat gaat de monitor hierop verschillende acties uitvoeren. Deze acties verschillen van bepaalde onderdelen herstarten tot het volledig herstarten van de Raspberry Pi.
Na het opnieuw implementeren van de check of de status online is, kon deze nieuwe versie van de software op de Raspberry Pi gezet worden om te testen.
Conclusie
Voor- en nadelen
Optie | Voordelen | Nadelen |
---|---|---|
rPiAIS | - startklaar-oplossing - interface - configuratie via interface - direct inzage in schepen via map | - interface is niet beschikbaar buiten lokaal netwerk (zonder verder werk) - interface werkt niet stabiel - beveiliging van login voor interface (credentials) - monitor is nog te implementeren |
Homedirectory | - al ingezette oplossing - bijna geen overhead - heeft al een geïmplementeerde monitor - gemakkelijker uit te breiden | - geen interface/alles gaat via command line - enkele aanpassingen moeten nog gemaakt worden - meer uit te voeren tests |
Verschillen
De voornaamste verschillen tussen de rPiAIS en de homedirectory zijn dus:
- de rPiAIS is startklaar en biedt een interface, maar heeft nog een monitor nodig
- de homedirectory is uitbreidbaar, al ingezet en heeft enkele aanpassingen nodig
Het grootste verschil tussen de twee opties is dat de homedirectory al ingezet is en stabieler draait in tegenstelling tot de rPiAIS. Dit verschil zorgt ook voor een verschil in performance, zo kan de homedirectory langer draaien zonder te crashen. Terwijl de rPiAIS door de overhead van de interface instabieler werkt.
Een ander punt van aandacht is een belangrijk onderdeel in het project, namelijk de monitor. Bij de rPiAIS moet deze nog geïmplementeerd worden, terwijl deze alleen aangepast hoeft te worden in de homedirectory.
Keuze en resultaat
De gemaakte keuzes en het resultaat hiervan staat beschreven bij Adviseren 1.
Feedback
Aan de hand van deze analyse heb ik een advies gegeven over welke van de twee oplossingen voor AIS receivers ingezet moest worden in Izegem. Om hierover een goed advies te geven moest de analyse goed zijn uitgedacht en uitgewerkt. Feedback op het proces tot en met adviseren staat bij Adviseren 1.
Reflectie
In de loop van het project heb ik geleerd hoe een 'screen' werkt en ik heb dit later ook toe kunnen passen bij het deployen van de routeplanner (RiverScout). Daarnaast heb ik ook kunnen werken met hardware, namelijk de AIS-antenne en ontvanger, een moelijkheid heirin was dat ik nog nooit aan een project gewerkt had waarin zoveel verschillende hardware-componenten samenkomen. Ik ben dan ook erg blij dat het project tot een erg goed resultaat geleid heeft.
AN2
Beschrijving
Ik kan een requirementanalyse uitvoeren voor een (deel van een) softwaresysteem met verschillende belanghebbenden en ik houd hierbij rekening met de kwaliteitsstandaarden die gelden bij het bedrijf.
Bewijs volgens Stageplan
Requirementanalyse uitgevoerd voor eisen rondom het project, bijvoorbeeld benodigde features en codestandaarden, en deze in samenspraak met de product owner verwerkt op het scrumbord.
Bewijs
Proces
Toen Joost en ik hadden gekozen om aan de routeplanner te gaan werken hebben we hiervoor samen met de product owner en begeleiders besproken hoe de routeplanner binnen Teqplay zou moeten gaan passen en wat de wensen ervan waren.
Hierna hebben we de initiële requirements opgesteld in samenspraak met de product owner en hebben vervolgens na elke sprint gekeken welke requirements en taken vervolgens opgepakt of opgesteld zouden worden.
Naarmate het project vorderde werden uitbreidingen gedaan aan de requirements van RiverScout, doordat er een samenwerking kwam met de frontend die Joost ging ontwikkelen.
Requirements
Binnen de routeplanner voor schepen (Riverscout) zijn er verschillende requirements.
De originele requirements voor het project:
- Het aanmaken van de grafiek door middel van bronnen van onder andere Rijkswaterstaat
- De volledige grafiek beschikbaar stellen via een API
- Het beschikbaar stellen van het opvragen van routes door middel van een API
- De aanvraag voor routes snel afhandelen en routes teruggeven, rekening houdend met bijvoorbeeld de dimensies van een schip
- Soortgelijke (of betere) resultaten krijgen in vergelijking met de huidige routeplanner
En later ook extra requirements voor samenwerking met de frontend:
- Het openstellen van alle routes in de grafiek
- Het ingeven van zelfgemaakte routes
- Het aanpassen van routes
- Het kunnen testen van zojuist aangemaakte routes
Kwaliteitsstandaarden
De kwaliteitsstandaarden van Teqplay zijn gedeeltelijk verwerkt in de requirements van het project, zo zijn 'De aanvraag voor routes snel afhandelen en routes teruggeven, rekening houdend met bijvoorbeeld de dimensies van een schip' en 'Soortgelijke (of betere) resultaten krijgen in vergelijking met de huidige routeplanner' hier voorbeelden van.
Andere kwaliteitsstandaarden zoals de keuze van technology stack en de codestandaarden zijn respectievelijk verwerkt in Analyseren 3 en Realiseren 1.
Verwerking op het scrumbord
Samen met de product owner en de begeleiders hebben Joost en ik voor het project requirements opgesteld en deze vervolgens op het scrumbord verwerkt.
Het volledige scrumbord
Een aantal kaartjes die geplaatst zijn op het scrumbord met daarbij bij welke requirement het hoort.
Het aanmaken van de grafiek door middel van bronnen van onder andere Rijkswaterstaat | De volledige grafiek beschikbaar stellen via een API |
Het beschikbaar stellen van het opvragen van routes door middel van een API | De aanvraag voor routes snel afhandelen en routes teruggeven, rekening houdend met bijvoorbeeld de dimensies van een schip |
Soortgelijke (of betere) resultaten krijgen in vergelijking met de huidige routeplanner | Het openstellen van alle routes in de grafiek |
Het ingeven van zelfgemaakte routes | Het aanpassen van routes |
Het kunnen testen van zojuist aangemaakte routes |
Feedback
Ik heb bij het opzetten van requirements voldoende bijdragen geleverd, dit gebeurd tijdens de demo's. Voordat deze demo's beginnen denk ik na over welke vervolgstappen er gemaakt moeten worden in het project en welke requirements hierbij horen.
Reflectie
Ik was erg betrokken bij het opstellen van de requirements en hoe deze geïmplementeerd zouden worden. Tijdens de demo's nam ik een actieve houding om deze requirements aan te dragen en over de implementatie te discussiëren.
AN3
Beschrijving
Ik kan een specificatie opstellen aan de hand van een analyse.
Bewijs volgens Stageplan
Gemaakt overzicht waarin beslissingen rondom high en low level worden gegeven, zoals de keuze van technology stack.
Bewijs
Aan de hand van de voorgaande requirementanalyse zijn de volgende high en low level beslissingen gemaakt.
High level
Voor Riverscout zijn er verschillende onderdelen betrokken die samen aan de requirements bij Analyseren 2 moeten voldoen.
RiverScout zal uit verschillende modules bestaan om zo logica te kunnen scheiden van elkaar, wat de onderhoudbaarheid ook makkelijker maakt. De verschillende modules waaruit RiverScout minimaal zal bestaan is: een core, een API en een route engine. Zowel de API als de route engine delen de logica van de core om toegang te krijgen tot onderdelen zoals het opslaan en verwerken van grafieken. De API zal verantwoordelijk zijn voor het openstellen van data en de route engine voor het daadwerkelijk genereren van routes.
Context diagram van de verschillende onderdelen in en buiten RiverScout
RiverScout
Dit is de plek waar de implementatie van de routeplanner komt te staan. Dit onderdeel is verantwoordelijk voor de grafieken en routering van het systeem.
Database
In de database moeten de verschillende gegevens over grafieken en andere informatie worden opgeslagen. Bijvoorbeeld alle nodes en edges van alle grafieken, inclusief managementinformatie die aangeeft welke informatie over een grafiek beschikbaar is en welke instellingen hiervoor zijn aangemaakt.
User
De mogelijkheden voor een gebruiker wordt bepaald door de frontend van RiverScout. Hierin moet de gebruiker routes kunnen inzien en veranderen, daarnaast moeten ook routes gegeven kunnen worden tussen verschillende locaties.
External Party
Via de API van RiverScout moeten verschillende aanvragen gedaan kunnen worden, dit is ook waar de frontend op aangesloten wordt. Daarnaast moeten er ook grafieken verstuurd kunnen worden naar de API, zo kunnen de standaardgrafieken van RiverScout ook verrijkt worden met nieuwe data van andere bronnen.
Low level
De technology stack van RiverScout is: Kotlin, Java, Spring Boot, MongoDB en Maven. Deze technologieën worden ook gebruikt binnen Teqplay en worden onder andere daardoor gebruikt binnen het project.
Zoals benoemd bij high level zal RiverScout uit verschillende modules bestaan. In ieder geval zijn de core en API modules geïmplementeerd in Kotlin. De taal waarin de route engine wordt geprogrammeerd is afhankelijk van welke route engine gekozen wordt voor dit project.
Hieronder staat beschreven welke taken de modules moeten vervullen en hoe ze afhankelijk van elkaar zijn.
De afhankelijkheid van verschillende modules in RiverScout
Context diagram met opsplitsing van RiverScout modules
Core
De core wordt de belangrijkste module, alle andere modules zijn afhankelijk van de implementatie hiervan. In deze module moeten verschillende onderdelen geïmplementeerd worden, zoals interactie met de database, logica om grafieken op te bouwen vanuit verschillende bronnen en deze samen te voegen tot één grafiek en informatieverwerking en opslag van gegevens over routes.
API
De API wordt verantwoordelijk voor het openstellen van data uit de core module. Hier komt de implementatie van onderdelen zoals het opvragen van routes, gegevens over objecten en lijnen in verschillende grafieken en beheergegevens.
Route engine
De route engine is de module waarin de daadwerkelijke implementatie van de route engine komt. De API module moet routes op kunnen vragen uit deze module.
Feedback
Aan de hand van de requirements is een overzicht gemaakt van de beslissingen voor het project. Hiervoor is het oorspronkelijke idee vertaald naar een prototype.
Dit prototype werd heel snel gerealiseerd en hierdoor konden al snel routes gepland worden, daarnaast had ik ook visualisaties gemaakt van de resultaten.
Reflectie
Voor het maken van het prototype heb ik eerst gekeken naar het vertalen van de requirements, hiervoor heb ik de werking van de routeplanner beschreven. Voor de kwaliteit van de grafieken en de routeplanner zelf heb ik een visualisatie-tool gemaakt die mij erg geholpen heeft bij het ontwikkelen van de routeplanner en het visualiseren van de inhoud.
AN4
Beschrijving
Ik kan een acceptatietest opstellen aan de hand van kwaliteitseigenschappen die gelden bij het bedrijf.
Bewijs volgens Stageplan
Het opgestelde testplan met de kwaliteitseigenschappen van het bedrijf en de acceptatiecriteria verwerkt in een document.
Bewijs
In de hieronder beschreven hoofdstukken volgt waardoor RiverScout voldoet aan de kwaliteitseigenschappen van Teqplay.
Functionaliteit
De functionaliteiten van het RiverScout project zijn besproken met de product owner en voldoen aan de opgestelde requirements voor het ontwerp (Ontwerpen 2) en voor de implementatie (Realiseren 2).
Robuustheid
De mate waarin RiverScout zinvol reageert op foute invoer wordt bepaald door de context. Bij het opvragen van routes wordt foute invoer aangegeven door een bericht terug te geven met de reden waardoor het misging, bijvoorbeeld door verkeerde locaties voor de start- en eindpunten. Voor operaties op een sandbox wordt bijvoorbeeld aangegeven of deze wel of niet aangemaakt of geupdate kon worden.
Conversieprocedure
Om RiverScout uiteindelijk over te kunnen zetten als de huidige routeplanner worden voorlopig de resultaten van de huidige routeplanner nageaapt, hierdoor kunnen de resultaten van RiverScout al ingezien worden zonder grote veranderingen te maken.
Voor het overzetten naar de 'echte' resultaten moeten eerst nieuwe modellen aangemaakt worden om dit resultaat op te slaan. Hierna hoeft alleen de logica gedeeltelijk aangepast te worden om de onderdelen van het nieuwe model te gebruiken. Door het volgen van deze 'simpele' stappen wordt de routeplanner overgezet, de resultaten zijn altijd hetzelfde maar worden in een andere vorm teruggegeven.
Koppelingen
RiverScout heeft geen externe koppelingen om te kunnen functioneren als routeplanner zelf. Echter is het opstellen van de grafieken wel afhankelijk van de bronnen opengesteld door externe partijen zoals Rijkswaterstaat.
Performance
RiverScout heeft geen zware operaties op het opvragen van routes en het maken van grafieken na. Om toch een goede performance te leveren is bij deze onderdelen meer gelet op efficiëntie, snelheid en geheugengebruik. Door te letten op de werking van deze onderdelen heeft RiverScout een hele goede performance en kan deze heel snel routes teruggeven.
Documentatie
De documentatie van RiverScout staat voornamelijk in de Swagger-pagina, op deze pagina staat documentatie over de volledige API van RiverScout. Daarnaast is heel het project gedocumenteerd op code-niveau en is er een README waarin onder andere uitgelegd staat hoe het project te installeren, updaten en deployen is.
Testplan
De volgende onderdelen moeten getest worden voor RiverScout.
Voor unit-tests en integratietests wordt gebruik gemaakt van het testing framework JUnit.
Unit-tests:
- Operaties op grafieken
- Verwijderen van dubbele objecten en lijnen
- Klaarmaken van de grafiek
- Simplificeren van de grafiek
- Verbeteren van de grafiek
- Samenvoegen van 'manual' met 'saved' grafieken
- Volledige werking van het samenvoegen van routes
- Standaardbronnen en optionele bronnen
- Bronnen die dienen als lagen
- Routes waar afstand tussen zit
- Volgorde van de routes
- Routes gecombineerd met route-punten
- Routes die alleen bestaan uit punten
Integratietests:
- Binnenhalen van bronnen van de FIS van Rijkswaterstaat
- Verbinding met Rijkswaterstaat
- Inladen van alle gegevens in de modellen
- Omvorming naar het RiverScout-format
Systeemtesten:
Het systeem moet voldoen aan alle opgestelde requirements bij Analyseren 2.
Acceptatietest
De testen zijn succesvol op het moment dat alle unit-tests en integratietests succesvol uitgevoerd zijn en het systeem voldoet aan de systeemtesten.
De resultaten van deze acceptatietest zijn aangegeven bij Realiseren 2.
Feedback
De applicatie voldoet aan de kwaliteitseigenschappen van Teqplay.
De routeplanner draait al een tijd stabiel en werkt naar de verwachtingen van de product owner.
Reflectie
Al vanaf het begin van het project heb ik rekening gehouden met de gewenste kwaliteit van de routeplanner, waar nodig heb ik in de loop van het project ook gewerkt aan het verbeteren van de efficiëntie en performance ervan. Hierdoor was het mogelijk om dit zo stabiel mogelijk te kunnen laten draaien. Ik ben erg trots dat het volledige proces van het maken van de routeplanner ertoe geleid heeft dat de product owner hier ook erg tevreden mee is en de routeplanner daadwerkelijk gebruikt wordt in productie.