Definition of Done

Een Definition of Done is een checklist aan eisen die gesteld worden voordat een user story als “done” kan worden gemarkeerd. Het development team en de Product Owner gebruiken de DoD, omdat het een scrum-artifact is.

Checklist:

  • Alle geschreven UNIT-tests moeten slagen
  • Mits er extra eisen zijn voor het uitvoeren van de code moet hier een stapsgewijze gids voor zijn op de Wiki in Gitlab
  • Bibliotheken moeten voorzien zijn van documentatie met voorbeelden op de Wiki in Gitlab
  • Naamgeving van variabelen moet duidelijk zijn
  • Structuur moet overzichtelijk zijn
  • Er moet een goedkeuring zijn van een ander teamlid binnen het developmentteam (Joey en Jeffrey)
  • De aparte branch in Gitlab moet gemerged zijn met de “master”-branch
  • De Product Owner moet het resultaat accepteren tijdens de sprint demo

Sprint verlengen

Het team heeft afgelopen maandag 15 oktober een consultmoment gehad met Edwin Hennipman en Wouter Leenards (begeleiders vanuit Windesheim). Daar hebben we het over de voortgang van het project gehad, de belemmeringen waar we tegen aan lopen en hoe we daarmee om gaan.

Ook hebben we het over de sprint reviews gehad, deze eindigen bij ons altijd op donderdag, maar de vrije dag van onze Product Owner is altijd op de donderdag. In overleg met de begeleiders zijn we tot de oplossing gekomen om de sprint waarin we nu zitten te verlengen tot woensdag en dit dan aan te houden.

GitLab

Wij hebben ervoor gekozen om GitLab te gebruiken als hulpmiddel voor Scrum en het project in het algemeen. Wij hebben voor GitLab gekozen, omdat dit een handig all-in-one pakket is waarin user stories gekoppeld kunnen worden aan issues binnen de repositores.

In gitLab hebben wij een project aangemaakt genaamd Cinnovate, dit project is onderverdeeld in onze 3 repositories:

  • GUI (nuxt project)
  • Sensor (C++ project)
  • Socket Server (C# project)

In gitLab is het mogelijk om een Product Backlog aan te maken met user stories. Deze user stories zijn inzichtelijk per repository, maar kunnen ook als geheel bekeken worden in het Cinnovate project. Bij het toewijzen van een user story kan er automatisch een nieuwe branch worden aangemaakt. Na het voltooien van een user story kan de branch, na controle en goedkeuring van de code, gemerged worden met de hoofdbranch.

Scrum

Wij hebben ervoor gekozen om scrum te gebruiken als projectmethodiek. Wij hebben hiervoor gekozen omdat wij deze methodiek op school hebben geleerd en gedurende het tweede schooljaar al gebruik hebben gemaakt van Scrum tijdens het comakership. Daarnaast wordt binnen Cinnovate ook gebruik gemaakt van Scrum.

De voordelen van scrum ten opzichte van een methode zoals Prince2 is dat je in korte sprints werkt. Hierdoor heb je regelmatig oplevermomenten waardoor de product owner altijd op de hoogte is van de voortgang. Dankzij de vele contactmomenten met de product owner is het makkelijker om een product op te leveren waar de product owner achter staat. Aan het eind van elke sprint zullen wij een retrospective houden waarin wij binnen het team zullen bespreken hoe de sprint is verlopen. Wij zullen hierin bespreken waarom user stories niet behaald zijn, zodat deze problemen in volgende sprints verbeterd/voorkomen kunnen worden.

Hierbij zal onze opdrachtgever, Sander Kolkman de rol van Product Owner innemen, Ken Cheung zal de Scrum Master zijn en zal de rest van het team de rol van Development Team op zich nemen.


C++

Om gegevens uit de sensor te halen heeft Xethru een Module Connector beschikbaar gesteld. Helaas is hiervoor alleen een binaire C++ library voor beschikbaar. Deze C++ library kan alleen worden gebruikt in combinatie met de GNU C++ Compiler. Dat betekent dat we geen gebruik kunnen maken van Microsoft Visual C++ of Visual Studio. In plaats daarvan moeten we gebruik maken van MinGW, een ontwikkelomgeving voor de GNU Compiler Collection voor Windows.

We hebben besloten JetBrains CLion te gebruiken als onze IDE, onder andere omdat deze MinGW ondersteunt en we al gebruik maken van de andere IDE’s van JetBrains voor onze backend (Rider) en frontend (WebStorm).



Sensor Development Kit vs Respiration Sensor

Bij de aanvang van de comaker hadden we de Xethru Sensor Development Kit tot onze beschikking. Wij zijn ermee begonnen door deze kit aan te sluiten en de bijbehorende Xethru Explorer software op onze laptops te installeren. Daaruit bleek dat deze sensor kit alleen ruwe (radar)gegevens naar de laptop stuurt.

Wij hebben op het internet, via zoekmachines en de Xethru website, gezocht over hoe we zelf een ademhalingsritme kunnen detecteren. We hebben toen ontdekt dat deze sensor kit bedoelt is om zelf een sensor te ontwikkelen aan de hand van de teruggestuurde radio impulsen, door zelf eigen algoritmes te programmeren op de sensor zelf. Hiervoor is grondige kennis van natuurkunde en digitale signaalverwerking voor nodig. Voor ons doel zouden we ook nog kennis moeten hebben over hoe we uit deze ruwe gegevens een ademhalingsritme kunnen halen.

Xethru blijkt ook een kant-en-klare variant te hebben, de Respiration Sensor. Deze kan zonder zelfontwikkelde algoritmes een ademhalingsritme detecteren.

We hebben eerst nog geprobeerd de firmware voor de 
Xethru Respiration Sensor op de Sensor Development Kit te programmeren. Dit blijkt niet mogelijk te zijn, onder andere omdat de firmware controleert of er een bepaalde sleutel aanwezig is op de sensor, die de Respiration (en de Presence) Sensor vanuit de fabriek meekrijgen.

Dit hebben we aangekaart bij onze product owner, Sander. We hebben hierna de Respiration Sensor besteld bij Xethru.

2 weken later was de Respiration Sensor binnen. Toen we deze aan onze laptops hadden verbonden konden we met het programma Xethru Explorer wel al een ademhalingsritme detecteren.

We gaan dus gebruik maken van deze Respiration Sensor voor de rest van het project.

Technische specificatie

Naar aanleiding van een gesprek tussen de Product Owner en het team is naar voren gekomen dat bepaalde onderdelen uit de business case te technisch waren. Toch vond de Product Owner dat er goed over nagedacht was en er goede verantwoording van de keuzen waren. Om deze reden, alsmede met het vastleggen van technische eisen, besloot het team om dit deel uit de Business Case te verwijderen en een apart document te maken.

In dit document staat beschreven de visie van het team over de technische opbouw van het prototype. Tezamen met de verantwoording van de gemaakte beslissingen. De visie is meerdere malen met de Product Owner overlegd en hij toont begrip voor de verantwoording bij de beslissingen.

SocketServer V.S. API

Tijdens het bepalen van de technische specificaties van het onrust prototype liepen we tegen het probleem aan hoe de data te versturen van de sensor naar de grafiek. Hiervoor is een server nodig die alle data coördineert. Uiteindelijk zijn wij op twee mogelijke oplossingen gekomen: een Websocket of een API.

Websocket

Een Websocket is een connectie die open blijft. Vervolgens kunnen beide  partijen berichten naar elkaar sturen. Bijvoorbeeld de server ontvangt nieuwe gegevens, dan kan de server tegen de andere clients melden dat er nieuwe data beschikbaar is.

API

Een API is een gesloten verbinding. De client vraagt gegevens op waarna de verbinding verbroken word.

Besluit

De gegevens die wij moeten versturen zijn: onrust, werking van vitale organen en mobiliteit. Bij een API ontstaat er vertraging i.p.v. realtime, omdat de nieuwe gegevens iedere x aantal seconden weer opnieuw opgevraagd moeten worden.  Dit lijkt ons niet wijs bij het monitoren van vitale organen. Om deze reden hebben wij besloten om de gegevens te ontvangen/ versturen via één of meerdere Websockets.

Business Case

Naar aanleiding van het eerste experimenteren van het team is er met de product owner overlegd om een aantal punten zoals: probleem, doel, middel, proces en risico’s vast te leggen in een document. Dit document heeft als doel dat alle betrokken partijen in overeenstemming zijn met het doel van het project en op de hoogte is van de werkwijze. Dit document hebben wij de Business Case genoemd. De inhoud van dit document is meermaals verbeterd en aangescherpt, zodat nu het developmenten team en de product owner op één en dezelfde lijn zitten als het gaat om de risico’s die op kunnen treden, het doet dat het project dient en welke weg bewandeld wordt naar het behalen van het doel.