Sprint 5

In sprint 5 zijn we bezig geweest met het schrijven van een adviesrapport waarin we alle testen die zijn uitgevoerd hebben vastgelegd, de observaties die we hebben waargenomen en de conclusies daarvan. Ook staan er instellingen in die aanbevolen worden om de sensor zo goed mogelijk te laten werken. Daarnaast kan de GUI nu ook verbinding maken met de SocketServer en data uit MongoDB lezen en weergeven. Op de GUI kun je terugzien de RPM (het aantal ademhalingen per minuut), Distance (De afstand gemeten tot de dichtstbijzijnde persoon), SignalQuality (De kwaliteit van het signaal), Delay en de Polling Rate (Hoe vaak nieuwe data wordt opgehaald). Ook kun je zien in welke state de sensor zich bevindt, No movement (Geen aanwezigheid gedetecteerd), Movement (Aanwezigheid gedetecteerd, maar geen ademhaling gedetecteerd), Tracking (Aanwezigheid en een mogelijke ademhaling gedecteerd), Breathing (Een valide ademhaling gedetecteerd), Initializing (De sensor past alle instellingen toe en maakt een noise map van de omgeving) en Unknown (De sensor is niet verbonden of de configuratie van de sensor klopt niet). We hebben ook het eindverslag geschreven waarin de leerpunten en het procesconclusie over de gehele duur van het project staan beschreven. Daarnaast zijn de andere documenten afgemaakt/ nagelopen.

Sprint 4

In sprint 4 zijn we bezig geweest met de front-end. Hiervoor hebben we eerst een schets gemaakt en deze aan onze opdrachtgever laten zien voor goedkeuring. Na goedkeuring zijn we aan de slag gegaan met het realiseren van de schets. Naast het realiseren van de front-end, moest er in de back-end ook twee API-calls worden geschreven. Deze zijn noodzakelijk om data te verkrijgen bij het laden van de front-end. Ook zijn we gestart met de testfase, waarin we alle stappen van het testplan hebben doorlopen om de data die we uit de sensor ophalen zo betrouwbaar mogelijk proberen te maken. In sprint 5 willen we met de resultaten een adviesrapport uitbrengen en overige documentatie in orde maken.

Sprint 3

In sprint 3 hebben we ons vooral bezig gehouden met MongoDB en het maken van een testplan. Na het opzetten van de database in sprint 2 is het ons nu ook gelukt om de data die uit de sensor komt, in één keer door te sturen naar de database. In de testplan leggen we alle testscenario’s en criteria vast over waar de test aan moet voldoen. Deze hebben we nodig zodat we alle mogelijkheden die de betrouwbaarheid van de data kan beïnvloeden uitsluiten en om het naar behoren te laten werken. Voor sprint 4 willen we verder werken aan de front-end, zodat we alle data die in de database staan opgeslagen eruit gaan halen en die mooi weergeven én we willen de testfase netjes afronden.

Het vertrek van Riccardo

In de laatste week van september hadden wij een nieuw “teamlid” erbij gekregen. Een vierdejaars BIM student had namelijk een afstudeeropdracht gekregen bij Cinnovate die direct aansluit op onze opdracht. De vierdejaars, Riccardo genaamd, zou namelijk de data uit de sensor analyseren en met deze data proberen te bepalen wanneer er sprake is van onrust.

Dit onderdeel zouden wij in eerste instantie zelf uitvoeren, maar met de komst van Riccardo hadden wij hierdoor meer tijd om ons te focussen op het technische aspect van deze comakership.

Helaas is vorige week bepaald dat de opdracht van Riccardo niet voldoet als afstudeeropdracht, met als resultaat dat Riccardo geen stage meer loopt bij Cinnovate.

In afstemming met de opdrachtgever hebben wij afgesproken dat wij verder zullen gaan met de huidige planning. Indien er tijd over is, zullen wij alsnog een poging wagen om de taken van Riccardo over te nemen.

Sprint 2

Tijdens Sprint 2 zijn we gaan kijken naar welke programmeertaal we gaan gebruiken om data uit de Sensor te krijgen. We hebben toen een keuze moeten maken tussen Python en C++. De voor- en nadelen van C++ is dat het een voorkeur is van het bedrijf, omdat zij al C++ ontwikkelaars in dienst hebben, sneller is dan Python , maar wel moeilijker aan te leren is. En bij Python is het minder snel vanwege , maar is het wel makkelijker om te leren omdat we al vanuit school de basiskennis hebben opgedaan. Uiteindelijk hebben we in overleg met onze opdrachtgever gekozen om het eerst in C++ te proberen. In dezelfde sprint zijn we ook aan de slag gegaan met opzetten van MongoDB, dit is een open source document oriented database geschreven in C++. De data is opgeslagen als binairy JSON ook bekend als BSON.

Sprint 1

In sprint 1 hebben we een keuze moeten maken tussen een API (Application Programming Interface) en een Web Socket. Het verschil van de twee is dat de API om de x aantal seconden een verzoek naar de server verstuurd om te kijken of er nieuwe data beschikbaar is, terwijl bij de Web Socket je een connectie maar één keer hoeft te openen en deze vervolgens data heen en weer blijft versturen. Uiteindelijk hebben we voor het laatste gekozen, omdat deze gunstiger zou zijn ons opdracht.

Sprint 0

In de eerste sprint zijn we eerst gaan kijken naar wat het bedrijf eigenlijk van ons verwacht en andersom. We zijn daarom eerst begonnen met het duidelijk op kaart krijgen van het probleem, middel en doel. Nadat het allemaal goed gekeurd was zijn we met het technische gedeelte aan de slag gegaan. Hier moesten allemaal projecten voor aangemaakt worden 
voor onze code als Nuxt.js, ASP.NET en C++ . Deze projecten hebben wij aangemaakt, zodat wij in sprint 1 een goede basis hebben om van start te gaan. Ons planning is om een project met structuur aan te maken voor: Nuxt.js, ASP.NET en C++. Deze projecten zijn uiteraard allemaal succesvol opgezet.

Peer reviews feedback

Uit de feedback over de presentatie en het document (uit het gesprek) is gebleken dat het document goed geschreven is en dat de keuzes duidelijk verantwoord zijn. Verbeterpunten voor de presentatie zijn:

  • Er kan meer aandacht worden besteed aan de opmaak van de presentatie. De presentatie was redelijk leeg (geen plaatjes etc.).
  • Er kan minder van het scherm/blaadje worden afgelezen tijdens de presentatie (meer de klas in kijken).
  • In het vervolg zal de internet connectie gecheckt worden voordat de presentatie begint.

Peerreview

Wij zouden graag kritiek krijgen over de technische opbouw van ons eindproduct. Of wij eventueel technisch gezien betere keuzes hebben kunnen maken of dat de gemaakte keuzes, niet logisch of niet onderbouwd zijn op de blog.

Hierna volgt het technische schema van het voor ons op te leveren prototype.

De onderbouwing van de gemaakte keuzes staat in onze technische specificatie, die hier te vinden is in ons menu.

Planning voor elke sprint.

Het team houdt een planning bij om zowel onszelf als de opdrachtgever op de hoogte te houden over wanneer of wat verwacht kan worden en uiteraard of we op planning lopen. Hiervoor maken we gebruik van een aantal scrum-artefacten. Via deze post ga ik de artefacten kort toelichten en de planning daarvan weergeven.

Sprint Planning.
Het werk dat uitgevoerd moet worden tijdens een Sprint wordt gepland tijdens de Sprint Planning.Het maken van dit plan is een gezamenlijke inspanning van het gehele Scrum Team.

De Sprint Planning vindt aan het begin van elke sprint op de woensdag om 11:00 plaats.

Dagelijkse Scrum.
De Dagelijkse Scrum is een 15-minuten-timeboxed gebeurtenis voor het Ontwikkelteam.

De Dagelijkse Scrum vindt elke dinsdag, woensdag en donderdag  plaats van 11:45 – 12:00

Sprint review.
Een Sprint Review wordt gehouden aan het einde van de Sprint om het Increment te inspecteren en indien nodig de Product Backlog aan te passen. Increment is het product dat het Scrum team aan het einde van een sprint oplevert. Het product moet aan de afgesproken Definition of Done voldoen.

De sprint reviews vindt aan het eind van elke sprint op de woensdag plaats om 14:30 

Retrospective.
De Sprint Retrospective is een kans voor het Scrum Team om zichzelf te inspecteren en een plan te maken om zichzelf gedurende de komende Sprint te verbeteren.

De Retrospective vindt aan het eind van elke sprint op de donderdag plaats om 14:30