Inleiding

Voor het OOSE-project ben ik een van de teamleden van het team Smalltalk. Onze opdracht is vanuit het bedrijf Regterschot Racing. Regterschot Racing wil de data van de sensoren die in een raceauto zitten kunnen zien op een, door ons te maken, website. De sensoren in de auto wordt uitgelezen door andere studenten. Door het gebruik van een broker kunnen wij deze data op de website tonen. Naast dat de data op de website wordt getoond wordt er ook geacht dat deze betrouwbaar is. Ook zullen er sensoren zijn die twintig keer per seconde data versturen. Het is van belang dat al deze data zo snel mogelijk op de website getoond wordt. 

In dit document zal ik aan de hand van onder andere competenties mijn vooruitgang laten zien als ICT'er. Ook zal in het document voorkomen welke al bestaande of verkregen kennis en vaardigheden ik heb toegepast. Ook heb ik twee leerdoelen waar ik tijdens het project aan zal werken. 

Mijn eerste leerdoel gaat over het transparant zijn naar mijn teamleden. In vorige projecten heb ik gemerkt dat dit soms nog wel lastig was en kan zorgen voor vragen waar ik mee bezig was. Voor mijn tweede leerdoel wil ik meer het voortouw nemen tijdens overleggen en niet al te snel blij zijn met de oplossing van een ander. Ik wil duidelijk krijgen waarom mijn keuze misschien even goed zo niet beter is. Ook wil ik op deze manier zorgen dat de keuzes die we als team maken de juiste zijn en niet voor meer problemen zorgen.

In het document zal er worden ingegaan op in ieder geval de volgende hoofdstukken. Allereerst de deelproducten. In het tussentijdse verslag zal er in worden gegaan op in ieder geval het Plan van Aanpak, het SRS en over in ieder geval één stuk code. In het hoofdstuk projectmethode wordt er ingegaan op de methode Scrum. Hierin zal ik aangeven wat goed en minder goed werkt. In het hoofdstuk rollen zal ik ingaan op welke rollen ik heb vervuld tijdens het project. In het hoofdstuk competenties ga ik tenminste in op 2 genomen beslissingen. Dit kan gaan over bijvoorbeeld een design decision of implementatie. In het hoofdstuk leerdoelen zal ik verder ingaan op mijn leerdoelen die hierboven kort benoemd zijn. In de conclusie zal ik reflecteren op alle hoofdstukken en het hele project. Dit gaat over het groepswerk maar ook over bijvoorbeeld mijn leerdoelen. Als laatst zal ik een factsheet toevoegen voor alle competenties. Per compententie zal ik facts en toelichtingen toevoegen die deze competentie aantonen.

Tijdens het project ben nog geen grote uitdagingen tegen gekomen. Het eerste onderdeel waar ik mogelijk problemen zou verwachten was Angular. Angular is het front-end framework wat wij gebruiken voor de website. Angular was ons nog niet bekend. Martin is hier mee begonnen en de rest van het team heeft tijd gestoken in de tutorial op de website van Angular zelf (https://angular.io/start). Naast dat deze tutorial en de extra Tour of Heroes tutorial (https://angular.io/tutorial) enorm veel duidelijke informatie geven is er ook veel over te vinden op verschillende websites. Dit alles maakt dat Angular niet moeilijk te leren was. Wat wel een obstakel kan worden is dat wij dit keer niet een database hebben met alle data. De meeste data die wij zullen gaan krijgen gaat over een broker komen die in C++ is gemaakt. Deze taal is ons niet bekend en wordt ook niet door ons gemaakt. Het is afwachten hoe we met deze broker kunnen communiceren en of de data dan ook goed en snel genoeg binnen komt. Dit is nog iets waar we problemen tegen zullen kunnen komen. Ook heb ik door omstandigheden niet de hele opdracht kunnen maken van DEA. De kennis die ieder zou moeten hebben heb ik grotendeels wel. Ook denk ik dat als het zo mocht zijn dat ik vast loop er genoeg teamleden zijn die mij wel zouden kunnen en willen helpen. Verder zijn er tijdens dit blok niet veel andere obstakels die ik nu kan voorzien. Ik verwacht dat er verder weinig problemen kunnen zijn. 

Deelproducten

Plan van Aanpak

Tijdens het eerste deel van het project is het Plan van Aanpak (PvA) een van de belangrijkste onderdelen om goed en duidelijk te maken. In het PvA zet je een aantal basis dingen op. Dit geeft het team duidelijkheid over wat er moet gebeuren maar ook wat er niet moet gebeuren. Dit geeft ook een terugkoppeling aan de opdrachtgever, Is dit wat de opdrachtgever wil, of hebben we het niet goed begrepen? Snappen we überhaupt voor wie we het maken? Naast deze vragen maak je ook een aantal afspraken voor in je team. Willen we dat we de hele periode 1 scrummaster hebben, of elke week een andere? Willen we altijd dezelfde tijd op school zijn of bepaalt de scrummaster dat? Welke afspraken hebben we en wanneer is iets "klaar". Dat zijn allemaal vragen die je in het PvA tegen gaat komen.

In eerste instantie denk ik dat wij een goed PvA hebben neergezet. Voor mij was alles duidelijk en konden we ook daadwerkelijk wat met het PvA. In het PvA staat voor ons maar ook voor anderen duidelijk wat wij gaan doen en op welke manier. Ook staat er duidelijk aangegeven welke dingen wij bijvoorbeeld nodig hebben, zoals een lokaal waar we in ieder geval met het hele team kunnen zitten. Wij hadden als team grotendeels duidelijk wat er allemaal in stond en toch waren er een aantal kleine aanpassingen. Dit waren vooral kleine onduidelijkheden waar wij overheen hebben gelezen. Het uiteindelijke PvA (29/11/2022) is een goed product. Alles wat een PvA moet hebben staat er in en ook zijn alle aanpassingen die gedaan moesten worden zijn verwerkt.

SRS

Het SRS is een belangrijk document bij het maken van een product als hier gestructureerd gewerkt wordt. Tijdens de uitleg deed mij een onderdeel hiervan wel verbazen. Tijdens deze opdracht is het eigenlijk de bedoeling dat tijdens het maken van het product het SRS (en SDD) wordt aangepast. Normaal zou je eerst het SRS (en SDD) maken en daarna aan de hand daarvan gaan programmeren, in plaats van een stukje SRS maken en dat gelijk implementeren. Het is natuurlijk wel zo dat dit soort bestanden tijdens een project veranderen en aangepast worden. De gebruiker kan bijvoorbeeld toch iets er bij willen of wil iets net even wat in elkaar hebben zitten. Dit geeft als resultaat dat er dingen aangepast moeten worden in bijvoorbeeld het SRS. Over de volledigheid van het SRS is momenteel niet veel te zeggen, aangezien deze nooit af zal zijn. Wel is het zo dat de onderdelen die er al zijn goed zijn voor zover ik zie. Als ik bijvoorbeeld kijk naar het domein model en de bijbehorende woordenlijst is deze compleet en is hier goed over nagedacht. Zoals al eerder aangegeven kan het zijn dat deze aan het eind van het project alsnog veranderd. Het maken van een SRS tijdens het programmeren, afwisselend waar je aan werkt kan ook problemen met zich mee brengen doordat je niet weet wat er nog meer moet komen. Het kan zo zijn dat het SRS compleet en goed is voor de eerste tien stukken code, maar dat door stuk elf veel aangepast moet worden. Om dit te voorkomen zou je misschien toch liever een compleet SRS hebben alvorens je gaat programmeren. Het is voor ieder van ons geen favoriet onderdeel, maar nodig.

Code

De code die voor mij een groot deel van de tijd in beslag heeft genomen en ook nog niet volledig af is is de login. Als we het hebben over de backend van deze code dan gaat het vooral over de code die Thomas geschreven heeft, en later aangepast is door Wijnand. Zelf heb ik hier niet aan gewerkt, maar wel gereviewd. Zelf ben ik bezig geweest met de front-end van de login, de koppeling van de front-end en backend en moet ik nog werken aan de foutafhandeling en het doorgeven van een token. De token is nodig om op elke pagina te kijken of de gebruiker hier mag zijn, en als dit het geval is, wat deze gebruiker mag en kan. Als ik kijk naar de backend is hier veel tijd aan besteed. Er zijn tijdens het maken van de login aanpassingen geweest, grotendeels door meerdere invalshoeken. Iedereen kijkt er toch net wat anders naar. De één vindt het beter om de gebruiker te laten weten of zijn wachtwoord of gebruikersnaam misschien niet klopt, terwijl de ander juist denkt dat er maar één bericht moet komen dat er iets fout is. Dit zijn constant kleine aanpassingen, maar kunnen later op andere stukken weer een grotere impact hebben. Ik durf niet met zekerheid te zeggen of het allemaal veel sneller had gekund omdat mijn focus niet lag op waar Thomas precies mee bezig was. Ik denk echter wel dat het sneller had gekund als we gelijk de uiteindelijke richting hadden gekozen zoals: het wachtwoord moet gehasht in de database staan en er komt 1 foutmelding.
De Backend van de login werkt nu en is klaar, de front-end heb ik met behulp van Angular ook snel in elkaar weten te zetten. Ook door het feit dat er veel over te vinden is het een redelijk snel en makkelijk proces. toch ben ik meerdere obstakels tegen gekomen. Allereerst wou ik een Toastr toevoegen voor foutmeldingen. Toastr's  zijn gekleurde berichten die vaak rechts bovenin een scherm te zien zijn (bijvoorbeeld https://codepen.io/RaiseTheBahr/pen/JOybye). Dit leek ook in Angular makkelijk te kunnen al kreeg ik foutmeldingen waar ik geen raad mee wist en ook na veel onderzoek nog niet uit ben gekomen. Ik heb mij voor nu neergelegd bij het niet kunnen gebruiken van toastrs en ben verder gegaan met de koppeling. De koppeling tussen de twee was er snel en werkte goed. Op het moment dat de login backend af was kon je ook gelijk met de front-end inloggen, al deed deze verder nog niks. De vervolgstap is het doorgeven van een token aan de user. Ook hier heeft al wat tijd ingezeten, al denk ik nu te weten hoe ik dit kan oplossen. Ik denk niet dat hier veel tijd bespaard had kunnen worden. Het gebruik van Toastr's heb ik misschien te graag gewild terwijl een rode tekst voor nu ook genoeg zou zijn geweest. Dit is ook de oplossing die we hier gaan gebruiken. De oplossing voor het meegeven van een token komt uiteindelijk af van Meron Brouwer. Als ik hier eerder de vraag aan had gesteld in plaats van het onderzoek zelf vanaf 0 te doen was misschien de hele login ook al klaar.

Projectmethode

Rollen

Competenties

Leerdoelen

Conclusie

Factsheet