Auteurs:

Docenten

1. Inleiding

Voor onze eindopdracht zijn we benaderd door Regterschot Racing. Zij zijn momenteel bezig met een zero-emission race auto voor de amateur-autosport. Dit doen zij met behulp van verschillende studenten van de engineering, communicatie en ICT opleidingen. Regterschot Racing is begonnen als scooterservice voor restaurants. In 2020 zijn ze omgedoopt tot het amateur-autobedrijf bedrijf dat we nu kennen. Het doel van Regterschot Racing is om in 2028 een betaalbare zero-emission raceauto op de markt te brengen die gebruikt kan worden in de amateur-motorsport.

Regterschot Racing verwacht een applicatie waarin een gebruiker toegang kan krijgen tot de data die een raceauto in een al bestaande database opslaat. Er wordt geacht dat er een API gebouwd wordt waar de website en database met elkaar kunnen communiceren. Bij deze communicatie is het van belang dat de data die op de website zichtbaar zal zijn betrouwbaar is en dat deze snel geüpdatet wordt. Ook moet het systeem dat gebouwd zal worden makkelijk uit te breiden zijn om in de toekomst nieuwe features te kunnen toevoegen.

In dit document gaan wij beschrijven wat wij gaan doen, hoe wij het gaan aanpakken en wat we uiteindelijk gaan opleveren. In het hoofdstuk "Achtergrond van het project" wordt de achtergrond van het project uitgezocht. Voor wie maken we deze opdracht exact? Wie zijn de stakeholders in het project? Wat is de aanleiding naar het project? In het hoofdstuk "Doelstelling, opdracht en op te leveren resultaten voor het bedrijf en school" wordt de opdracht besproken en worden de op te leveren bestanden verduidelijkt. Daarna geven we in de "Projectgrenzen" aan wat er in het project inbegrepen is en hoelang het duurt.

Verder worden in het hoofdstuk "Randvoorwaarden" de verschillende benodigdheden voor het goed en netjes afwerken van het verslag aangegeven. Daarnaast wordt in het hoofdstuk "Op te leveren producten en kwaliteitseisen" aangegeven wat de producten zijn die we uiteindelijk zullen inleveren en welke eisen daar aan gesteld zijn. Hier kan de opdrachtgever lezen wat hij kan verwachten van de door ons geleverde producten. In het hoofdstuk "Ontwikkelmethode" schrijven wij over de verschillende methodieken die wij zullen toepassen tijdens het project. In het hoofdstuk "Projectorganisatie" geven wij aan wat de frequentie van contacten met school en de opdrachtgever is. In het hoofdstuk "Planning" geven we aan wanneer de oplevering gepland staat voor de gemaakte producten. Tot slot is er het hoofdstuk "Risico's" waarin we kijken wat nog mogelijke problemen kunnen veroorzaken die buiten onze macht liggen.

2. Achtergrond van het project

Regterschot Racing is een bedrijf, eerst begonnen als ScootCar en opgezet door Erik Regterschot. Het bedrijf ScootCar is in 2020 omgedoopt naar Regterschot Racing. Regterschot Racing is toen begonnen als een start-up raceteam en autogarage. Ondertussen is Regterschot Racing begonnen aan hun grootste project. Samen met studenten Engineering, Communicatie en ICT-studenten van de Hogeschool Arnhem en Nijmegen willen ze een endurance auto ontwikkelen met een eigen datalog-systeem voor een DNRT Endurance Championship. Op deze manier willen ze in 2028 een zero-emission raceauto op de markt te brengen.

Regterschot Racing wil de amateur autosport helpen om dezelfde richting op te gaan als de professionele autosport qua duurzaam racen. Met verschillende engineering disciplines en samenwerkingen wil Regterschot Racing de amateur autosport helpen met hun idee van duurzaamheid en hernieuwbare energie. De auto die ze in 2028 willen gaan introduceren zal ook voor de amateur autosport zijn zodat ook deze mee innoveert. 

Naast Regterschot Racing, die baat hebben bij het project, heb je ook nog andere partijen die hier baat bij hebben. In 2022-2023 willen ze een raceauto voor het DNRT Endurance-kampioenschap maken. Deze race zal worden gereden met een test auto. Door deze race te rijden leert het team het datalog-systeem te gebruiken naast hoe een raceteam in elkaar zit en wat er nodig is voor een snellere- betere auto. Daarnaast is in principe de gehele amateur racesport een stakeholder. Als de visie van Regterschot Racing later bekend wordt en anderen er op dezelfde manier over denken is het zelfs mogelijk dat ze dezelfde systemen gaan gebruiken.

3. Doelstelling, opdracht en op te leveren resultaten voor het bedrijf en school

In dit hoofdstuk wordt het probleem beschreven, op basis van dit probleem worden vervolgens de doelstelling en opdracht geformuleerd.

3.1. Probleem:

Rechterschot Racing maakt gebruik van sensoren op hun race auto. De informatie van deze sensoren lezen ze af met behulp van node-red maar dit is niet snel genoeg. Ook is dit niet heel toegankelijk en gebruiksvriendelijk voor mensen die hier geen of weinig verstand van hebben. 

3.2. Doelstelling:

Het bedrijf geeft aan dat ze momenteel gebruik maken van node-red, maar dat is niet snel genoeg voor wat ze willen doen. Hierom hebben ze contact genomen met Smalltalk zodat wij kunnen kijken naar een sterk alternatief dat voldoet aan hun eisen. Zij willen namelijk dat wij de data uit de auto in realtime op hun site weergeven. Het doel van ons is het leveren van een product wat uitbreidbaar is voor de volgende groepen.

3.3. Opdracht

Er moet een applicatie gemaakt worden waarmee een gebruiker van Regterschot Racing toegang kan krijgen tot data wat in een al bestaande database word opgeslagen. Wij het team van Smalltalk gaan een API moeten bouwen waar de website en database met elkaar kunnen communiceren. Het gaat hier over de data van de sensoren die in een raceauto zitten. De data wordt gelezen door engineers in de pit, het is dus van belang dat het product snel en betrouwbaar is. Het systeem moet makkelijk uitbreidbaar zijn om in de toekomst features te kunnen bijbouwen

3.4. Resultaat

Regterschot Racing verwacht een webapplicatie waar ingelogde gebruikers een dashboard zien, waar alle informatie van de sensoren terug te vinden is. Dit moet realtime, snel en betrouwbaar zijn. Het belangrijkste is dat de applicatie goed gedocumenteerd is en makkelijk uitbreidbaar is door een nieuwe groep programmeurs zodat zei de applicatie in de toekomst kunnen uitbreiden. Regterschot Racing is bezig met het ontwikkelen van een zero-emissie raceauto, die in 2028 deel moet kunnen nemen aan een race. Bij zo'n race is er een team aan personeel aanwezig die de verschillende sensoren en gegevens die de auto verzamelt en doorstuurt in de gaten houdt. Echter worden de gegevens op het moment alleen naar een database doorgestuurd en niet in een makkelijk overzicht weergegeven. Regterschot Racing wil deze gegevens kunnen zien in een makkelijk overzicht, een soort dashboard om zo snel inzichten in de race en de raceauto te krijgen. Hiervoor moet een API gerealiseerd worden die de verschillende gegevens vanaf de raceauto tot twintig maal toe per seconde kan verwerken en daarbij de betrouwbaarheid van de gegevens kan bewaren. Daarnaast mogen er geen vertragingen zijn bij het verwerken van de gegevens. Wat de opdrachtgever overigens ook heel belangrijk vind is de documentatie waarmee het werk dat wij maken terug te lezen en te snappen is. Dit is heel belangrijk voor het deel dat het allemaal uitbreidbaar moet zijn aangezien wij maar het begin zijn van dit project.

Regterschot Racing heeft vrij weinig inzichten in de werking van een API als deze, dus weten ze niet goed wat ze kunnen verwachten. Ze hebben een aantal eisen opgesteld waaraan de applicatie moet voldoen, maar dit zijn geen specifieke eisen. Ze willen graag een werkend systeem hebben, hoe dit systeem uiteindelijk er uit komt te zien is een bijzaak. Het belangrijkste is dat het systeem uitbreidbaar is. Uiteindelijk wordt er verwacht dat we een API in elkaar zetten die real-time gegevens van de raceauto in grafieken kan laten zien. Wel wil het bedrijf dat de te realiseren API makkelijk uit te breiden is zodat latere uitbreidingen erg gemakkelijk gaan en geen onnodige vertragingen binnen de bouw van de auto creëren.

4. Projectgrenzen

4.1. Tijdsgrenzen

Het project duurt in totaal acht weken en speelt zich af vanaf 09-11-22 tot en met 27-01-23.  Hierna wordt er niet verder gewerkt aan het project en bieden we ook geen ondersteuning meer. Per dag wordt er ongeveer 50% van de tijd productief gewerkt aan de taken in Jira. De overige 50% wordt gebruikt aan individuele verslag, vergaderingen en pauze. Hierbij gaan we uit van een werkweek van veertig uur. Tussen 24-12-22 en 08-01-23 is het kerstvakantie en wordt er niet gewerkt aan het project. Als de opdrachtgever graag extra functionaliteit wilt, dan is dit mogelijk, mits het past binnen onze tijdsgrenzen. 

4.2. Inhoudelijke grenzen

• De SQL-code maken we voor MySQL. We kunnen niet garanderen dat ze ook werken voor andere database-engines.
• We maken de applicatie voor de resolutie 1920x1080 (laptop en pc), dus kunnen we niet garanderen dat het systeem correct werkt op andere formaten.

5. Randvoorwaarden

Binnen dit hoofdstuk wordt beschreven wat er allemaal nodig is om dit project succesvol uit te voeren.

• De HAN biedt ons een beschikbare ruimte met minimaal 8 zitplaatsen.
• De HAN biedt ons een stabiele internetverbinding die in staat is om gebruik te kunnen maken van de tooling en programma's die we nodig hebben om het systeem te kunnen ontwikkelen. 
• De HAN biedt ons de tooling (Bitbucket , JIRA, Confluence, Jenkins , SonarQube) aan die beschikbaar moeten zijn vanaf 09-11-22 tot en met 27-01-23.
• De opdrachtgever en de project en skillsbegeleider zijn minstens een uur per week beschikbaar voor eventueel overleg.

6. Op te leveren producten en kwaliteitseisen

6.1. Producten

Voor dit project zijn er een aantal producten die we moeten opleveren, namelijk: 

• Software Design Description (SDD)
• Software Requirements Specification (SRS)
• Software/Eindproduct
• Onderzoeksverslagen
• Database
• Testrapport
• Projectverslag
• Bijlagen

6.2.  Definition of Done

Zoals de naam al zegt bepaalt de definition of done wanneer een product af is. Als het hier dus niet aan voldoet is het product ook niet af en mag de userstory ook niet als afgerond staan op JIRA. Dit doen we zodat we geen half werk gaan doen en alle producten op het zelfde niveau zijn.

6.2.1. Documentatie

• Alle documentatie voldoet aan de AIM-Controle kaart
• Alle documentatie dat van belang is van de opdrachtgever wordt in het Engels gemaakt
• Alle documentatie wat niet van belang is van de opdrachtgever wordt in het Nederlands gemaakt
• De documentatie is gereviewd en goedgekeurd door twee projectleden die er niet aan gewerkt hebben

6.2.2. Code

• De code moet overeenkomen met het SRS en SDD
• De build op Jenkins moet slagen
• De code moet voldoen aan de eisen van de HAN (geen magic numbers, code smells, etc.)
• De documentatie van de code is up-to-date
• De code is gereviewd en goedgekeurd door minimaal twee projectleden die er niet gewerkt aan hebben.
• Alle unit testen slagen
• Er staat geen code in commentaar
• Er staan geen ongebruikte functies/classes
• De code moet een 80% line coverage hebben
• Alle unit testen moeten slagen

7. Ontwikkelmethode

Binnen het project gaan we incrementeel én iteratief te werk volgens de SCRUM-methode. SCRUM is een framework waarin verschillende processen en technieken ingezet kunnen worden om effectief te werken. Het maakt de effectiviteit van product management en ontwikkeltechnieken inzichtelijk zodat een teamlid zichzelf kan verbeteren aan de hand van de eigen competenties. De incrementele en iteratieve aanpak van SCRUM zorgt voor een betere en geoptimaliseerde voorspelbaarheid en verlaagt de kans op risico's.

7.1. Rollen

7.1.1. Scrummaster

De projectgroep bestaat uit een team van developers. In dit team is er elke sprint iemand die scrummaster zal zijn.
Het schema ziet er als volgt uit: 

1. Thomas 09-11-22 - > 18-11-22
2. Wijnand 21-11-22 - > 29-11-22
3. Bram 30-11-22 - > 09-12-22
4. Sem 12-12-22 - > 20-12-22
5. Jasper 21-12-22 - > 13-01-23
6. Martin 16-01-23 + 

De scrummaster heeft een aantal taken en verantwoordelijkheden. De rol van de scrummaster:

• is verantwoordelijk voor het oplossen van belemmeringen tijdens het project;
• zorgt dat iedereen begrijpt wat er gedaan moet worden en waarom;
• houdt de daily standup;
• behoudt het overzicht van alle taken die zijn of worden gedaan.

De scrummaster begeleidt het team, maar is geen leider en heeft dus geen autoriteit over het team (Scrum master. 2020).

7.1.2. Product owner by proxy (Martin van Lijden)

In ons team hebben wij een "product owner by proxy" vastgesteld. Dit houdt in dat er een groepslid is die het plannen van afspraken met de product owner regelt.  

7.1.3. Teamleden

In het project zorgen de teamleden uiteindelijk voor het eindproduct. Deze leden gaan aan de slag met het product en zorgen dat alles uiteindelijk in een geheel eindproduct komt. Het team moet door middel van overleg met de product owner, ervoor zorgen dat de opdracht voldoet aan de gestelde eisen.

7.1.4. Product owner (Erik Regterschot)

De product owner verteld het team wat zijn visie is. De product owner krijgt na het project uiteindelijk het product.

7.2. Ceremonies

De ceremonies in scrum zijn bedoeld om het project die goeie kant op te sturen. Deze ceremonies worden geleidt en voorbereid door de scrummaster.

7.2.1. Sprint

Tijdens de sprints wordt er gewerkt aan de taken op JIRA die in de backlog staan. In ons project hebben wij sprints van anderhalve werken. Deze sprints beginnen op maandag of woensdag en eindigen op dinsdag of vrijdag. Tijdens de sprint wordt er een sprint review, planning en retrospective gehouden. Deze worden verder toegelicht in de volgende hoofdstukken. Ook wordt er elke dag een daily stand up gehouden om te controleren of waar iedereen mee bezig is en niemand vastloopt. 

De voortgang van een sprint wordt in kaart gebracht door een burndown chart. Hierin kun je de verhouding van het werk dat nog gedaan moet worden tegenover de tijd zien. Hierdoor kun je in één oogopslag zien of je op schema loopt. In de burndown chart heb je de optimale lijn. Deze lijn laat zien hoever het scrum team moet zijn.  Als het aantal uren boven deze optimale lijn zit loopt het team dus achter.

7.2.2. Sprint review

De sprint review is er om de progressie van het project aan de opdrachtgever te presenteren. Zo weet de opdrachtgever hoe ver we zijn en kunnen we bepalen wat er in de volgende sprint moet gebeuren. Tijdens dit project wordt de review naar de retrospective gehouden wat normaal gesproken niet het geval is.

7.2.3. Sprint planning

In de sprint planning wordt er bepaald wat er allemaal gemaakt gaat worden in de aankomende sprint. Hiervoor wordt een sprintdoel vastgesteld waar tijdens de sprint naar toe gewerkt wordt. Deze sprintplanning wordt gehouden net voor dat de sprint gestart word. Per sprint plannen we 170 uur in. Op dit getal zijn we gekomen door de volgende berekening: 6 personen x 8 uur = 48uur per dag. 48 x 7 dagen = 336uren. 50% van 336 = ~170 uur per sprint.

7.2.4. Sprint retrospective

De sprint retrospective is om de effectiviteit van het team te verhogen. Elk teamlid  alles schrijft alles op wat er goed ging en alles wat slecht ging. Hierdoor kun je de dingen die fout gingen oplossen zodat het niet nog een keer gebeurd en alles wat goed ging zo voortzetten. De sprint retrospective vindt plaats aan het einde van elke sprint.

7.2.5.  daily stand up

Met de daily stand up vertelt iedereen waar mee hij bezig is geweest en waarmee hij verder gaat werken en of hij nog obstakels verwacht of is tegen gekomen. Dit doen we zodat niemand gaat vastlopen en iedereen weet wie waar mee bezig is. De daily stand up wordt gehouden aan het begin van elke ochtend.

8. Projectorganisatie en communicatie

8.1.  Leden project

Dit team bestaat uit tweedejaars HBO ICT studenten van de HAN Arnhem.

Auteurs:

Docenten

8.2. Gespreksoverleg

Voor elke sprint zal er een gesprek plaatsvinden tussen de opdrachtgever en het team. Dit gesprek is er zodat er aan de opdrachtgever doorgegeven kan worden hoeveel taken er zijn afgerond en welke taken er in de planning staan voor de volgende sprint. In dit gesprek kan de opdrachtgever nog eventuele wensen aan bod brengen. Om dit gesprek te kunnen plannen zullen we een aantal dingen meegeven, namelijk hoe lang wij verwachten dat het gesprek duurt, waar het gesprek plaatsvindt en een aantal onderwerpen waar we het over gaan hebben.

Er zullen ook gesprekken plaatsvinden met de procesbegeleider. De procesbegeleider zal onder andere bij de retrospecitve aanwezig zijn. De retrospective is een gesprek waarin het team een terugblik werpt naar de vorige periode. In dit gesprek wordt er besproken wat goed en fout ging in de afgelopen sprint en hoe hierop verbeterd kan worden.

De skills begeleider zal de professional skills lessen houden die wordt gegeven tijdens het project. Deze skills lessen zijn er, om de benodigde vaardigheden aan te leren die in de praktijk te hanteren zijn.

8.3. Afspraken

• Iedere werkdag wordt er van 9:15 tot 16:45 gewerkt.
• Iedere werkdag wordt er een daily standup gehouden om 9:25.
• Iedere werkdag worden er minstens vier volledige werkuren besteed aan taken.
• Ieder groepslid heeft 45 minuten pauze.
• Voor elk issue wordt er een aparte feature branch aangemaakt.
• De sprints duren zeven werkdagen.
• Aan het eind van elke sprint wordt er een retrospective gehouden.
• Documentatie van de code die voor belang is van de opdrachtgever wordt in het Engels gemaakt.
• In het geval dat het niet mogelijk is om op locatie te werken, wordt er gebruik gemaakt van Discord en Teams.

9. Planning

Planning

10. Risico’s

In het tabel hieronder staan risico's beschreven die wij van te voren niet kunnen beïnvloeden. We geven van het benoemde risico de grootte van de kans en impact mee. De tegenmaatregel geeft aan wat er moet gebeuren om probleem dit op te lossen. Tot slot wordt een uitwijkstrategie meegegeven, dit geeft aan wat er moet gebeuren als het toch mis gaat en niet opgelost kon worden.

11. Literatuurlijst

Scrum Master: tips en uitleg bij de taken en verantwoordelijkheden (+ animatie). (2020, December 19). Scrumguide. ht