1. Inleiding

We hebben als groep een opdracht van Regterschot Racing gekregen om een dashboard te maken waar een racecrew de data die van een raceauto komt kan analyseren. Voor ons als groep is de uitbreidbaarheid van hetgeen dat wij gaan maken erg belangrijk, omdat de opdrachtgever nog een aantal jaar door moet met ons product. Daar komt dus bij kijken dat de documentatie die wij leveren bij de producten die wij maken ook goed en coherent is, om het zo makkelijk te maken voor andere of volgende groepen die verder gaan met onze software.

Ons product zal dus door een racecrew gebruikt gaan worden in eerste instantie. Later wil de opdrachtgever graag de mogelijkheid hebben om kijkers mee te laten kijken naar de race via hetzelfde platform. Dit is echter nog ver in de toekomst en dus nog niet van belang voor ons.

Voor mij zal de uitdaging liggen bij het maken van ingewikkelde maar toch makkelijk uit te breiden Java-software. Ik heb de neiging om vaak code te schrijven die ik zelf goed snap maar vervolgens niet erg logisch is. Als de code niet logisch is, kan het niet goed door een ander gebruikt worden en zal dat dus voor een slecht product zorgen. Ik moet er dus goed op gaan letten om mijn code kwalitatief goed te maken. Door te reviewen binnen een groepsverband zal dat vast beter lukken.

Ik wil tijdens dit project mijzelf verbeteren op twee punten, namelijk het beter opletten en actief deelnemen aan gesprekken, omdat ik aan mezelf vaak merk dat ik een passieve rol aanneem. Door meer bij een gesprek betrokken te zijn, kan ik meer zinnige vragen stellen en kan ik de opdracht zelf beter begrijpen.

Daarnaast wil ik aan mijn afwachtende houding werken. Ik ben van nature wat afwachtend, wat vaak resulteert in een terughoudende houding. Ik wil graag actiever zijn en misschien wel het voortouw af en toe nemen.

2. Kwaliteit geleverde deelproducten

Ik had me verheugd op het bouwen van een webapplicatie voor autoraces nadat we de opdracht hadden doorgelezen. Er was na het eerste gesprek met onze opdrachtgever al snel duidelijk wat er van ons verwacht werd. Ik had minder zin in de onderzoeken die we vooraf zouden moeten doen, maar dat hoort er nou eenmaal bij. Na de eerste week van Sprint 1 had ik al wel door dat dit project groter zou zijn dan ik had verwacht. Ik had gedacht de applicatie als geheel binnen een week of twee af te kunnen krijgen met z’n zessen, maar doordat we rekening moeten houden met uitbreidbaarheid, documentatie en het bijhouden van het SRS en SDD, wordt dit toch veel langer.

2.1. Plan van aanpak

Het plan van aanpal dat we opgeleverd hadden leek eerst wel goed te zijn, we hadden alle hoofdstukken ingevuld en dachten het wel redelijk gemaakt te hebben. Toch bleek er bij het assessment van het plan van aanpak toch nog het een en ander te missen waardoor ik al snel het gevoel kreeg dat we het echt vernaggeld hadden. Dit bleek uiteindelijk wel mee te vallen, want het was goed genoeg voor een voldoende. Ik heb tijdens het project niet echt teruggekeken naar het plan van aanpak, wat ik misschien wel had moeten doen. Ik had de gemaakte afspraken dan beter in mijn hoofd gehad en had misschien beter kunnen focussen op hetgeen dat we daadwerkelijk moeten opleveren. Ik zou dan ook graag in een volgend project 'via' het plan van aanpak willen werken. Ik zou dan graag goed willen kijken wat er precies van ons gevraagd wordt en precies daar aan werken en zo weinig mogelijk zelf invullen.

2.2. Onderzoeksverslag

Aan het eind van Sprint 2 hebben we een functionele loginpagina gerealiseerd, een dashboard gemaakt en kunnen we data uit onze database naar de webapplicatie doorsturen. Daarnaast hebben we al onze onderzoeken nu afgerond. Ik heb aan het onderzoek visuele dataweergave gewerkt, samen met Martin. Ik vond dit best een leuk onderzoek om te doen. We hebben gekeken naar de bedrijfswereld en hoe men daar het probleem van Regterschot heeft opgelost. Wat voor een software ze gebruiken en hoe dit gebruikt wordt tijdens de race. Ik heb daarna nog protoypes gemaakt met JFreeChart, wat we uiteindelijk niet zouden gebruiken, maar ons wel meer inzichten gaven in het maken van grafieken a.d.h.v. Java.

2.3. SDD

Ik heb me erg veel bezig gehouden met het SDD. We hebben heel fatsoenlijk bij elke taak die gedaan moest worden en het relevant was de taak 'bijwerken SDD' toegevoegd. Dit was om te zorgen dat het SDD niet achter zou lopen op de huidige code en dat het SDD niet twee weken na het maken van code nog geüpdatet moet worden als de helft alweer vergeten is. We hebben bij de tussentijdse beoordeling te horen gekregen dat het SDD zeer ondermaats was en dat het niet coherent was als document zelf, maar ook niet met het SRS. Dit voelde best vervelend, omdat ik toch wel wat tijd in het document gestopt had en ik dacht dat het er wel redelijk aan toe ging. Ik wist dat het niet af was en dat er gaten zaten in een aantal onderdelen. Toch was het vervelend om te horen dat het document onvoldoende was. Ik heb het toen een beetje op me genomen om zowel het SDD als SRS eens flink op de schop te nemen. Ik ben bij het SRS begonnen en heb daarna het SDD aangepst. Ik heb alles van a tot z nagelopen, gecontroleerd op spelling en taal, coherentie ingebracht en figuren duidelijker gemaakt door concepten en attributen te gebruiken door het hele document, in plaats van steeds weer verschillende termen.

2.4. SRS

Ik heb het SRS ook grotendeels omgebouwd, na de feedback die we kregen van de tussentijdse beoordeling. Ik heb het domeinmodel helemaal opnieuw gemaakt waarbij ik de opnames van het gesprek met Erik nog een keer goed heb geluisterd. Ik heb de termen die Erik en Dana ons gaven gebruikt om het model op te bouwen en heb direct uitgelegd waarom dit op deze plek staat in het domeinmodel. Na het domeinmodel geüpdatet te hebben, ben ik doorgegaan met de use-cases en heb deze in een volledig nieuwe use-case diagram gezet en ben daarna eens alle use-cases die we al uitgewerkt hadden na gaan lopen. Daarbij heb ik een aantal use-cases die niet meer relevant waren verwijderd en nieuwe toegevoegd. Ik heb daarbij ook duidelijk gemaakt aan de rest van de groep dat dit onze 'scope' is, oftewel dat dit alle use-cases zijn die we moeten realiseren en we daarbuiten alleen documentatie hoeven te leveren.

2.5. Unit-tests

Ik vond het maken van unit-tests niet zo lastig, maar ik had dan wel het voordeel dat de rest van de groep al unit-tests gemaakt had waardoor ik mijn vragen en onduidelijkheden makkelijk bij hen kwijt kon. Ik had langer gewacht met het maken van unit-tests omdat ik me veel bezighield met de documentatie van onder meer het SRS en SDD. Voor mij zijn de verschillende methodes van Mockito nog altijd een stukje magie, maar met uitleg van onder andere Thomas en Wijnand begon ik het meer en meer te begrijpen. 

2.6. Code

Bij het maken van de verwijder tab functionaliteit heb ik het stuk code hieronder geschreven. Dit stuk code komt uit de TabDAO klasse. Deze methode laat goed zien hoe de code zich aan de SOLID principles houdt. De methode moet een tab verwijderen uit de database, en dat is dan ook het enige wat het het doet. Het is een void methode, omdat de methode niks zal terug sturen naar de DTO klasse waar vanuit deze methode wordt aangeroepen. Daarnaast heeft het heel simpel een query string en een object met de parameters. Deze query wordt gevuld met de parameters die de methode meekrijgt uit de DTO. Daarna wordt de database geüpdatet en zal de meegegeven tabId verwijderd zijn uit de tabel. 

De code voldoet ook aan onze definition of done. De code is gereviewed door twee anderen, de design decisions en sequence diagrams waar deze code in gebruikt wordt staan in het SDD. Daarnaast heb ik zelf later nog tests voor geschreven. Deze tests zijn allemaal goedgekeurd en garanderen dat de code daadwerkelijk functioneert. Er zijn op SonarQube geen code-smells die met deze methode te maken hebben, dus deze methode is helemaal in orde.

public void deleteTab(int tabId) {
        String query = "DELETE FROM Tab WHERE TabId = ?";
        Object[] parameters = {tabId};
        try {
            databaseConnection.executeUpdate(query, parameters);
        } catch (SQLException exception) {
            throw new DatabaseExceptions(exception);
        }
    }

2.7. Testplan + rapport

We hebben als groep aan het einde van het project een testrapport opgesteld. Ik heb hier niet veel aan bijgedragen, alleen de tests die ik gemaakt heb staan er in. Ik vind dit een overzichtelijk document waarin duidelijk al onze tests naar voren komen. Ik vind de kwaliteit van het document wel wat matig. De conclusie had wat mij betreft wat sterker gekund. Daarnaast had de opmaak en de introductie wel wat meer aandacht kunnen gebruiken. Ik heb bij de andere documenten hier op gelet, maar heb dat bij het testrapport niet gedaan, misschien dat het daar aan ligt. Maar het moet niet zo zijn dat één persoon uit de groep de opmaak en introducties van elk document moet bijhouden.

3. Kwaliteit geleverde eindproduct

Voor ons product waren documentatie en uitbreidbaarheid de prioriteiten. We hebben uitendelijk twee producten ontwikkeld en daarbij een boel documentatie geleverd.

Ik vind dat de documentatie die we hebben geschreven bij de producten die we gemaakt hebben best redelijk is. Ik zou het niet perfect noemen, omdat ik vind dat er nog redelijke gebreken zijn. Zo hadden we zowel het SRS als SDD aan het begin van het project zoveel mogelijk moeten maken. Onze aanpak was nu niet goed. We maakten eerst iets en gingen daarna design-decisions vastleggen en schemas maken. We hadden dit beter andersom kunnen doen. Vanuit Astah hadden we de gemaakte UML-diagrammen dan direct kunnen omtoveren tot bruikbare code en hadden we alleen maar de logica binnen de methodes moeten maken, wat waarschijnlijk wel wat werk had gescheeld. Desalniettemin zijn deze twee documenten een goede handleiding voor ons product en met name voor de keuzes die we gemaakt hebben om tot een bepaalde oplossing te komen.

Naast deze twee documenten hebben we een installatiedocument, wat met name voor de volgende groepen die aan dezelfde opdracht als wij zullen gaan werken. Het document helpt deze groepen bij het correct installeren van zowel de front- als backend producten die wij gemaakt hebben. Dit is een va nde belangrijkste documenten die wij inleveren, omdat het er voor zorgt dat dit project niet steeds weer vanaf de grond opgebouwd moet worden en volgende groepen niet eerst twee weken nodig hebben om onze producten überhaupt te kunnen gebruiken. 

Onze front- en backend is van prima kwaliteit. Onze website ziet er goed uit en is gebruikersvriendelijk. Ik ben het zelf niet eens met de keuze om de grafieken op de huidige manier toe te voegen, maar de meerderheid van de groep vond dit een goed idee. Ik had zelf liever de grafieken ten alle tijden zichtbaar gehad aan de linkerkant, om deze dan tijdens een race snel toe te kunnen voegen, zonder drie menu's te openen. De broker laat op het moment tweemaal per seconde data zien, omdat de broker lokaal te veel performance vereist van de machine. Ik denk zelf dat dit beter had gekund. Er is van ons gevraagd om twintig maal per seconde data te proberen weer te geven. We laten nu slechts een tiende van dat zien, wat zeer ondermaats is.

De backend zit goed in elkaar. We hebben tijdens het project gebruik gemaakt van een goedkope server om de database op te hosten, waardoor we soms twijfelden of onze methodes wel goed werkten, maar dit bleek aan de servers te liggen. De data die we ophalen uit de database word vrijwel direct geladen en is ook altijd de juiste data, wat betekent dat onze geschreven methodes goed werken. We hebben tijdens het maken van al deze methodes een aantal keer alle klassen moeten verschuiven omdat we liever een andere indeling hadden. Dit ging niet altijd even goed, omdat er steeds weer merge conflicts ontstonden. Deze conflicts zijn uiteindelijk opgelost en hebben daarna niet meer voor problemen gezorgd.

4. Evaluatie gehanteerde projectmethode

4.1. Tussentijdse evaluatie

Ons plan van aanpak vond ik aanvankelijk niet erg goed. Ik had het idee dat we alles goed beschreven hadden en dat alles er duidelijk in stond, maar ik had toch het gevoel dat er iets miste. Bij het assessment voor het plan van aanpak kwamen dan ook enige gebreken aan het plan van aanpak naar voren. We gingen met name bij de randvoorwaarden en kwaliteitseisen voor mijn gevoel onderuit, omdat we niet goed de 5xW, 1xH en de SMART-formulering hadden toegepast. 

Ook zijn onze SCRUM-ceremonies erg ondermaats. Ik ben nog geen SCRUM-master geweest, maar ik krijg langzaam maar zeker steeds meer in de gaten dat er flinke gebreken zijn. Zo hebben we in het begin niet eens over uren gesproken bij DSU's en hadden we het alleen over onze taken. Waar we mee bezig zijn, wat we nog moeten doen en of we ergens tegen aan gaan lopen. We hebben nog niet het jira-planbord open gehad tijdens een DSU, wat er waarschijnlijk ook voor zorgt dat we als groep niet goed weten wat er gaande is binnen het project. Ik had hier zelf ook wat over moeten zeggen, maar volgens mij hadden we het als groep niet door dat dit een vereiste was.

4.2. Definitieve evaluatie

SCRUM is geen slechte manier om een project uit te voeren. Ik vind het zelf niet fantastisch werken, maar het werkt wel effectief. We hebben als groep redelijk ontwikkeld op het gebied van SCRUM. Waar we in sprint 1 een baggere planning hadden gemaakt en eigenlijk helemaal niet zo goed wisten wat we nou aan het doen waren, kwam daar langzaam verandering in.

Mijn grootste probleem lag bij het inschatten van taken. Ik merkte dat onze taken erg krap waren en dat ik vaak nét genoeg tijd had om een taak af te ronden. Daarnaast zit er in een sprint planning géén speling, omdat dat tege nde SCRUM-principes in gaat. Dit was met name voor Bram een probleem, omdat hij steeds weer nieuwe problemen tegen kwam bij het maken van de broker. Dit is dan ook waarom de lijn in de burndown-charts hier en daar plots weer omhoog gaat. Wij hadden dit als groep zelf beter kunnen en moeten opvangen. Wij waren slecht geïnformeerd over de implementatie van de broker. We hadden deze taak beter moeten opdelen en het in behapbare stukken moeten opdelen zodat we niet steeds deze ophogingen hadden. Deze ophogingen waren met name in sprint vier duidelijk. We hadden een goede planning gemaakt en waren allemaal hard aan het werk. In het begin zaten we zelfs onder de trendlijn, maar alle ophogingen zorgden er voor dat we uitendelijk onze sprint toch niet gehaald hadden.

We hadden aan het einde van de sprint ongeveer 20 uur aan taken over. Het aantal uren aan ophogingen kwam uit op 23:15 uur. Dit hadden we met z'n allen kunnen oplossen door bijvoorbeeld een zaterdagmiddag te werken, maar deze taak van Bram was voor ons hocus pocus, dus konden wij niet helpen met deze taak. We hadden dit dus beter op moeten vangen.

Naast het plannen van uren is SCRUM voor mijn gevoel ook niet erg handig qua reviewen. Dit valt een beetje terug op het plannen d.m.v. tijd, want reviewen het verbeteren van producten na een review neemt ook tijd in beslag die of als taak opgenomen zou moeten worden of ope een andere manier ingepland zou moeten worden. Het wordt echter lastig dit als taak in te plannen, want een deeltaak kan some in één keer goed zijn, maar kan soms na vijf reviews nog niet goed zijn. 

5. Beschrijving rollen binnen projectgroep

Ik heb vanaf begin af aan de rol van ‘agendabeheerder’ op me genomen. Ik wilde graag de agenda bijhouden om zo beter boven op de opdracht te zitten en goed in de gaten te hebben wat er te doen staat voor ons team. Deze rol staat niet uitgelegd in het plan van aanpak, maar blijkt toch erg handig voor het team. Er staan geen dubbele afspraken in de agenda en alle afspraken volgen dezelfde regels. Zo staan er geen verwarrende dingen in de agenda en is alles netjes en geordend.

Ik heb over het algemeen de rol van developer gehad. Naast hier en daar een nieuwe afspraak of deadline in de agenda te zetten ben ik verder goed aan het werk gegaan. Ik heb dit redelijk weten te doen. Ik was niet altijd even ijverig aan het werk, omdat ik soms een taak had die me óf minder interesseerde óf omdat deze taak erg lang en/of saai was. Het compleet omgooien van het SRS en SDD leek me erg leuk om mee bezig te zijn. Dit was ook leuk toen ik er mee begon, maar toen ik een paar uur later steeds hetzelfde moest doen en steeds weer zat te klooien met Astah, merkte ik dat mijn aandacht al snel wegzakte. Ik heb hierdoor denk ik ook anderen afgeleid, wat ik juist probeerde te voorkomen. Ik had dit beter kunnen aanpakken door in plaats van een beetje onderuitgezakt op mijn stoel te zitten even op de gang te lopen en even een rondje door het gebouw te doen. Zo zou mijn brein weer fris en fruitig het lokaal binnenkomen en zou ik er weer even tegenaan kunnen.

In Sprint 5 was ik de SCRUM-master, waarbij ik de groep tijdens de DSU's, retrospective en de sprint-planning een beetej begeleidde. Ik heb dit wel redelijk gedaan. Ik had graag iemand voor mij een DSU-formulier laten invullen, maar door ziekte is dat er niet van gekomen. Als ik deze had laten invullen, had ik misschien een beter inzicht kunnen krijgen in dingen die ik anders kon doen of dingen die ik beter kon doen door andere handelingen aan te nemen. 

6. Toelichting Competenties

OOSE P-01. De student voert een project uit op basis van Scrum en een plan van aanpak en evalueert en reflecteert hierop, op individueel en projectniveau.

                We hebben als groep op dag één een scrum-master aangewezen per sprint, zodat we nooit zonder scrum-master zouden zitten. Ik heb in Sprint twee de taak van notulist gekregen. Men verwacht dus dat ik de notulen van belangrijke momenten noteer en dat ik de daily-stand-ups (DSU) bijhoud. Ik had hier wel een goed gevoel bij en had het idee dat ik dit wel kon. Ik had dit immers bij het I-project ook al redelijk uitgevoerd. Ik heb mijn werkwijze met name gebaseerd op voorgaande ervaring met onder meer aantekeningen maken bij hoorcolleges en het I-project. Wanneer we een gesprek, meeting of DSU hadden, pakte ik meteen de notities er bij en begon ik te tikken. Ik denk dat ik dit voor de meetings en gesprekken goed gedaan heb, wat teruggevonden kan worden in de notulen van 21 November 2022 in het mapje Notulen op Confluence. Waar ik meer aandacht aan had moeten geven was het noteren van DSU’s. Ik ben dit vergeten en heb hier de hele sprint niet aan gedacht, wat er voor gezorgde heeft dat we als groep nergens de resultaten van onze DSU’s kunnen teruglezen. Ik ben dus best wel teleurgesteld in hoe ik mezelf heb gedragen als notulist, omdat dit vele malen beter kon. Het had dus echt anders gemoeten dan wat ik heb laten zien. Het kan nu zomaar zijn dat een volgende notulist nu ook niet aan de DSU’s denkt en we nog minder DSU’s kunnen teruglezen. In een volgend gesprek wil ik dus echt beter na gaan denken of het handig is om notities te maken als we in een vorm van overleg zitten. Ik kan beter te veel dan te weinig notities maken.

OOSE P-02. De student analyseert de eisen en wensen voor de software van een systeem, en documenteert deze in een Software Requirements Specification (SRS).

                Bij ons eerste gesprek als groep met Erik Regterschot kwamen een hele hoop eisen naar voren. Ik heb aan het begin van Sprint 1 de verantwoordelijkheid op me genomen om de verschillende eisen die in de notulen stonden en de opnames van het gesprek die we hadden te noteren in het SRS. Ik heb eerst de hele opname een keer geluisterd en met pen en papier aantekeningen gemaakt bij opvallende dingen of duidelijke eisen. Daarna heb ik deze aantekeningen samen met de notulen op een rijtje gezet en langzaam omgevormd tot meerdere tabellen, die in het SRS te vinden zijn bij de functionele en non-functionele requirements. Het resultaat was een duidelijke lijst aan eisen die makkelijk aan te vullen is bij eventuele nieuwe esien vanuit de opdrachtgever. Ik zou de volgende keer het luisteren naar de opname anders doen. Ik zat nu bij de rest van de groep aan tafel met oordoppen in te luisteren. De groepsleden praatten nog wel eens of vroegen nog wel eens wat, waardoor ik weer uit het verhaal was en weer een stuk moest terugspoelen. Ik zou in het vervolg dus even ergens apart moeten gaan zitten of duidelijk moeten maken dat ik nu niet gestoord kan en wil worden.

OOSE P-03. De student onderzoekt voor het project relevante (technologie)keuzes en rapporteert hierover gestructureerd.

                Ik heb het onderzoek ‘visuele dataweergave’ gedeeltelijk in elkaar gezet. Dit heb ik samen met Martin gedaan. We hebben al wel eens vaker aan een opdracht samen gewerkt, dus ik had er alle vertrouwen in dat dit goed zou gaan. Ik heb de hoofd- en deelvragen opgesteld en vervolgens de kopjes “5. Hoe wordt de data van een raceauto bij een autorace weergegeven”, “7.1 JfreeChart” en “8. Wat zijn de voor- en nadelen van de verschillende geïmplementeerde API’s?” gemaakt. Ik heb kop 5 gemaakt door veel onderzoek te doen op het internet en dus te lezen over de praktijk. Kopje 7.1 heb ik beantwoord door een prototype te maken, waarbij ik meerdere grafiektypes heb gemaakt en hierbij heb gekeken naar de implementeerbaarheid, documentatie, prestatie, uitbreidbaarheid en de uiteindelijke gemakkelijkheid van het maken van het prototype. Deze resultaten heb ik vervolgens in een grote tabel gegooid om snel een makkelijk overzicht te krijgen van alle voor- en nadelen. Ik ben erg tevreden over dit onderzoek, omdat ik vind dat we een net en strak onderzoek hebben neergezet, waarbij we onze bevindingen goed in woorden hebben kunnen brengen. Door dit onderzoek is het voor anderen duidelijk waarom we voor de Google Charts API hebben gekozen. Dit onderzoek heeft er ook voor gezorgd dat andere groepen die na ons zullen komen niet een nieuw API onderzoek moeten gaan doen, omdat dit onderzoek de keuze al goed verwoord. Ik zou in een volgend project of in het bedrijfsleven wel vaker zo’n onderzoek willen doen, al zou ik dan een uitgebreider onderzoek willen doen, waar meer tijd voor staat, want een onderzoek doen in 3 à 4 dagen is nogal kort en geeft weinig tijd of ruimte om uitgebreidere prototypes te maken.

OOSE P-04. De student ontwerpt de software van een systeem en documenteert deze onder andere met behulp van UML diagrammen en decision templates in een Software Design Description (SDD).

               Voor het verwijderen van een tab was nog geen code geschreven maar dit moest wel gedaan worden. Ik heb deze taak op me genomen en heb deze van begin tot eind uitgevoerd. Ik moest een knop maken in de front-end die een call naar de back-end zou maken. In de backend zou vervolgens de database geüpdatet worden. Ik ben begonnen in de frontend en heb daar relatief snel de knop weten toe te voegen. Ik kon voor de back-end call goed afkijken bij de verschillende knoppen die we al hadden gemaakt die met de back-end communiceerden. Hierdoor was het front-end gedeelte redelijk makkelijk om te maken. Vervolgens moest ik aan de slag met het back-end gedeelte, wat wat moeilijker bleek. Ik had het toevoegen van een tab eens goed bekeken en daarna deels overgenomen, omdat ik dacht dat het ongeveer hetzelfde zou werken. In eerste instantie werkte de knop niet goed. De call naar de back-end werd gemaakt, maar de tab werd vervolgens niet uit de database verwijderd. Ik heb Wijnand gevraagd om mee te kijken nadat ik geen mogelijke oplossing kon vinden. Hij kwam uiteindelijk met een juiste ingeving. Mijn methode gebruikte een verkeerde methode om de database aan te passen. Na de aanpassingen van Wijnand werkte de knop bijna perfect. De knop verwijderde echter de tab links van de tab die gesloten moest worden. Ik heb toen snel in de front-end een variabele aangepast en toen werkte de knop perfect. Daarna heb ik de handeling in de backend vertaald naar een UML sequence diagram. Dit bleek uiteindelijk een kleine moeite, aangezien er alleen een methode een paar keer wordt gedelegeerd. Ik zou graag willen dat het werken zo gaat in de toekomst, waarbij ik snap wat er gedaan moet worden en dat ik een idee heb hoe dit te doen en dit vervolgens goed kan implementeren. Ik vond het ook erg fijn dat er iemand in de groep was die open stond om mee te kijken met mij wanneer iets niet helemaal goed werkte.

OOSE P-05. De student implementeert een gedistribueerd systeem, evalueert het ontwerp en de realisatie daarvan en zorgt voor traceerbaarheid daartussen en naar de functionele en niet-funcitonele eisen.

               Bij het maken van de popup voor het aanmaken van een nieuwe tab heb ik gebruik gemaakt van de Bootstrap framework. Het aanmaken van een tab wilden we graag verbergen achter een popup scherm, zodat er geen onnodige tekstbalken en knoppen in het scherm stonden die het analyseren van de sensordata alleen maar hinderen. Ik heb het toen tot me genomen om deze popup te maken in Angular, wat ik nog nooit eerder gedaan had. Ik kende al wel het een en ander van Angular en ik kon wel wat overweg met bootstrap na het I-project, maar nu moest ik ze gaan combineren. Ik heb eerst onderzoek gedaan naar de verschillende modals, hoe deze functioneren en wat we er mee kunnen doen. Uiteindelijk heb ik gekozen voor een vrij kleine modal die een tekstbalk en een paar knoppen bevat. Door de popup vrij leeg te houden en niet veel weer te geven is het voor de gebruiker makkelijker om te zien waar de modal voor dient en wat er gedaan moet worden. Ik heb er ook meteen voor gezorgd dat een gebruiker de modal snel weg kan halen door óf naast de modal te klikken óf door op escape te tikken. Wanneer een gebruiker op de knop klikt om een nieuw tab te maken, is de modal er gelijk, zonder enige vertraging. Na de naam en eventuele rondes in te vullen, is de nieuwe tab vrijwel direct toegevoegd en staat deze meteen in de dashboard van de gebruiker. Dit is allemaal in lijn met NFR1, die stelt dat er geen onnodige vertragingen mogen zijn in ons systeem. Ik heb bij het maken van deze modal veel geleerd over hoe Angular samenwerkt met bootstrap en ben er zelfs achtergekomen dat er hele handleidingen zijn die Angular en Bootstrap samen gebruiken om onderdelen van een website te maken.

OOSE P-06. De student past de aangereikte ontwikkeltools om het project te organiseren toe.

                De kalender van Confluence is mijn speeltuin. Tijdens de start van het project heb ik meteen aan de groep gemeld dat ik het leuk zou vinden om de agenda te beheren. De groep vond dit meer dan oké, omdat zij volgens mij wel inzagen dat één beheerder van de agenda makkelijker en efficiënter is dan een hele groep die tegelijkertijd met de agenda bezig is. Wanneer we een afspraak maken als groep of er een deadline, meeting of nutshell-talk gepland wordt of staat, is deze gebeurtenis  meestal binnen vijf minuten in de kalender te vinden. Door dit soort dingen meteen in de agenda te zetten, worden er geen meetings of dergelijken gemist en komen we als groep veel professioneler over. De rest van de groep vindt het erg fijn dat ik deze taak heb opgepakt, omdat ze nu makkelijk in de agenda kunnen zien wat er te doen is op een dag en hebben ze een beter overzicht van de aankomende week. Ik vind dat ik nog wel kan verbeteren in de kalender, omdat de meeste gebeurtenissen geen omschrijving hebben of een hele magere. Door de omschrijving goed en duidelijk te maken, zullen er minder snel vergissingen komen. Zo was er voor een aantal deadlines de vraag of het tijdstip wel klopte, omdat er in de kalender 4 uur stond maar in iSas 5 uur. Door in de omschrijving te zetten dat dit een uur voor de deadline is, vervalt deze verwarring. Ik ga in een volgend project zeker vragen om dit weer te mogen doen, omdat ik dit leuk vindt om te doen en het de groep als geheel enorm helpt.

OOSE P-07. De student bewaakt continu de kwaliteit van de software en het proces door o.a. reviews en gestructureerd testen en stuurt waar nodig bij.

                Bij het onderzoek ‘CSS-framework’ heb ik gereviewed op de spelling. Ik heb met name in de conclusie en de alinea daar voor veel opmerkingen kunnen plaatsen over onder meer zinsopbouw, spelling en taal. Door alle zinnen eens grondig te lezen en daarna alles nog een keer door te nemen, heb ik nagenoeg alle fouten er uit kunnen halen. Door deze spellingscontrole verbeterde de kwaliteit van het onderzoek, waardoor het voor anderen makkelijker te lezen is. Een verbetering voor een volgende keer zou zijn om spellingscontrole en taalhulp pas toe te passen tijdens het reviewen, omdat ik merk dat ik nu nog veel van deze controle/hulp tijdens het maken van de onderzoeken doe. Hierdoor is het moeilijk om te zien wat ik heb gerievewed of waar ik geholpen heb met spelling en taal. Ik denk dat ik door deze controles uit te voeren in volgende projecten gezien kan worden als iemand die betrouwbaar kan schrijven met weinig taalfouten. Daarnaast kan ik ook andere groepsleden goed helpen als zij het niet snappen.

OOSE P-08. De student kan zich zelfstandig verder verdiepen in de beroepstaak.

                Ik heb samen met Martin aan het onderzoek ‘Visuele Dataweergave’ gewerkt. We deden onderzoek naar het weergeven van data binnen applicaties. Hoe wordt dit gedaan en wat zijn de populaire trends hierbij? Bij dit onderzoek hebben we ook gekeken naar de verschillende implementaties van API's die het mogelijk maken om grote hoeveelheden data weer te geven. Ik heb bij dit onderzoek de hoofd- en deelvragen opgesteld die verderop in het onderzoek beantwoord zullen worden. Ik wilde hier graag een goede set vragen opstellen die ons door het onderzoek heen zouden leiden in een logische volgorde, om niet halverwege het onderzoek nieuwe vragen te moeten toevoegen. Bij de deelvraag ‘Hoe wordt de data van een raceauto bij een autorace weergegeven?’ heb ik me veel verdiept in de baan van een race-analyticus, wat voor aardig wat inzichten gezorgd heeft. Zo ben ik veel te weten gekomen over racedashboards bij de Formule 1 en hoe deze dashboards in elkaar steken. Door wat afbeeldingen aan de rest van de groep te laten zien, gekoppeld met wat uitleg, kreeg de rest van de groep snel een idee van het product dat verwacht wordt van ons. Voor mij was dit deel van het onderzoek best belangrijk, omdat ik zo een betere voorstelling had van het op te leveren product. Wat ik de volgende keer wel beter zou kunnen doen is het lezen van meer artikelen of onderzoeken. Ik heb het bij deze deelvraag grotendeels bij één artikel gehouden, wat de betrouwbaarheid van het onderzoek wat minder maakt. Door dit onderzoek ben ik nu zeker in staat om in volgende projecten een goed onderzoek uit te voeren.

7. Leerdoelen

7.1. Leerdoelen

Bij eerdere gesprekken met zowel groepsgenoten als opdrachtgevers, merkte ik zelf op en kreeg ik te horen dat ik vaak wat stil bleef en niet veel vragen stelde. Daarom wil ik beter opletten bij gesprekken zodat ik meer zinnige vragen kan stellen en kan blijven doorvragen over het onderwerp. Ik wil hier aan gaan werken door van tevoren een gesprek goed voor te bereiden zodat ik alvast zinnige vragen kan bedenken om te kunnen stellen. Daarnaast wil ik een actievere rol binnen een gesprek aannemen om zo beter in aan een gesprek deel te kunnen nemen.

Ik ben van nature wat afwachtend, wat kan resulteren in een terughoudende houding in een gesprek of bij een overleg. Ik wil dus graag minder de kat uit de boom kijken en juist direct overgaan tot actie. Ik kan dit doen door actiever deel te nemen aan een gesprek door bijvoorbeeld het gesprek te openen of kritische vragen stellen. Op die manier kan ik beter bijhouden waar we in een gesprek zijn en kan ik de aandacht er beter bij houden.

7.1.1. Tussentijdse Reflectie

Ik merk dat ik mezelf al enigszins heb kunnen ontwikkelen bij het stellen van vragen. Ik stelde tijdens ons gesprek met Erik Regterschot veel vragen en probeerde actief deel te nemen. Er is echter nog veel meer voortgang te boeken binnen dit leerdoel, omdat ik alleen binnen dat gesprek heb kunnen laten zien dat ik het wel in me heb. Ik wil met name in gesprekken met onder meer Erik en andere mensen die bij Regterschot werken meer vragen kunnen stellen en actiever deelnemen met de gesprekken.

Ik merk dat ik qua afwachtende houding nog niet veel verbetering heb laten zien. Ik probeer het voortouw in een gesprek te nemen, maar ik merk al snel dat ik zelf wat naar de achtergrond verplaats als anderen proberen te praten. Ik ben iets te afwachtend met het delen van mijn ideeën of ingeving, waardoor ik soms mijn kans mis om nog inbreng te geven, omdat het gesprek dan al weer verder is gegaan naar een ander onderwerp. Ik zou dus graag nog wat sneller willen reageren en misschien de spotlight van iemand anders stelen om mijn inbreng te kunnen delen met de rest van de groep.

7.1.2. Reflectie eindverslag

Ik stel nu goede vragen bij gespreken met een assessor of opdrachtgever. Ik heb onder meer bij het bespreken van de feedback op de tussentijdse producten effectieve en doelgerichte vragen gesteld over hoe we nu verder moeten werken, zoals: "Is het verstandig om in het SRS een lopen verhaal te maken zodat het niet alleen voor onszelf maar ook voor de opdrachtgever duidelijker is waarom we zo'n document maken en hoe dit doucment in elkaar steekt? We hebben nu namelijk een inleiding die vrij abrupt eindigt en dan zomaar een groot domeinmodel, zonder uitleg, naar voren schuift."

Dit werkte vrij goed op mijn zelfvertrouwen, ik kreeg het idee dat ik best wel goed vragen kon stellen en dat er helemaal geen probleem was met het voortouw te nemen. Deze vraag met name voelde als een soort kantelpunt. Ik kreeg meer zelfvertrouwen en het werdt veel makkelijk om vragen te stellen, ook al dacht ik er niet eens zo lang bij na. In een volgend project zou ik graag op dit punt willen doorontwikkelen, omdat ik merk dat het formuleren van vragen nog een lastig punt is. Het nadenken over de juiste formulering is iets waar ik beter op wil letten, omdat ik mezelf nu nog wel eens verspreek of het naar mijn idee onduidelijk verwoord.

Ik heb de afwachtende houding wat achter me kunnen laten. Na het uitvallen van Helen en het zijn van SCRUM-master merkte ik dat ik het voortouw nam en snel antwoord gaf op vragen. In een tweede gesprek met de nieuwe skills-begeleider gaf ik snel antwoord op de gestelde vragen en reageerde ook goed op de andere groepsleden als deze aan het spreken waren. Ik merkte nog wel dat ik er soms wat moeilijk tussen kwam, omdat ik niet graag door anderen heen praat. Dit is soms wel nodig, omdat het moment om te reageren anders weg is en ik niet meer de gelegenheid heb binnen dat gesprek om mijn mening te delen. Ik zou graag in het volgende project graag daar op willen focussen, het directer 'discussiëren' met anderen. Hoe lief het ook is om de ander uit te laten praten, is het soms simpelweg nodig om er snel tussen te komen.

8. Conclusie

8.1. Tussentijdse conclusie

Ik denk dat ik niet heel sterk aan het project begonnen ben, maar dat zal denk ik voor de hele groep zo zijn. We hebben veel dingen maar half gedaan en we kunnen enorm veel winst boeken op sommige onderdelen. Zo zouden we onze DSU's toch echt moeten verbeteren. We moeten ons Jira bord open hebben en ik wil de feedbackkaart voor de DSU minimaal drie keer per week in gaan vullen. Zo kan ik een beter inzicht krijgen in hoe ik er op dat moment voor sta, maar ook hoe de rest van de groep op het moment bezig is. 

Daarnaast wil ik wat meer aan code gaan werken. Ik heb naast het maken van een prototype en het maken van een Angular workshop alleen een kleine hoeveelheid code geleverd aan het project. Om mijn competenties op dit vlak beter te laten zien, zal het dus van belang zijn om meer code te gaan schrijven. Op die manier kan ik in het eindverslag goed laten zien dat ik ook kwalitatief goede code kan schrijven waar goed over na is gedacht en waar de juiste afwegingen voor gemaakt zijn. De eerste twee sprints bevatte van nature meer onderzoek- en documentatiewerk, dus ik denk dat dit vanzelf goed gaat komen naarmate we verder in het project komen. 

8.2. Eindconclusie

We hebben het project enigszins goed doorlopen als groep. We hebben veel fout gedaan aan het begin wat we later hebben moeten rechttrekken, wat soms makkelijk was, maar soms ook wat moeilijker. De sfeer in de groep was aan het begin veel te gezellig. Het was niet echt serieus. We hebben ons zelf goed weten te herpakken na de tussentijdse beoordeling en zijn hard gaan werken om te zorgen dat we alles nog overeind konden krijgen. Het project ging ook qua sfeer niet altijd even lekker. Soms was het té gezellig en soms was het best gespannen, als twee groepsleden het niet met elkaar eens waren, ging het soms nog best hard tegen elkaar.

Ik begon dit project met het idee dat ik wat zou coderen, wanneer ik wat leuks zou vinden, dat ik wat zou documenteren en dat ik met name bij gesprekken en overleg het voortouw zou nemen. Het bleek al snel dat dit niet het geval zou zijn en dat ik toch echt meer zou gaan moeten doen dan ik in eerste instantie had gedacht. Ik kwam uit een blok met lessen waarbij we vaak al vroeg klaar waren met school. Ik had dus de verwachting dat dit ook tijdens het project zo zou blijven, maar dat bleek alles behalve. Het voortouw nemen bij gesprekken en overleg bleek ook altijd niet even goed naar voren te komen. Dit was een leerdoel waar ik graag aan wilde werken, maar andere groepsleden hadden ook soortgelijke leerdoelen. De mogelijkheid om de leiding te nemen was eigenlijk al meteen weg.

Reflecterend over het gehele project heb ik toch wel wat andere inzichten. Ik ben met een verkeerde mindset het project in gegaan en dat heb ik eerst moeten ontdekken. Ik had veel liever meteen het SCRUM-en gesnapt en meteen begrepen hoe ik taken moest indelen op basis van tijd. In een volgend project gaat dit waarschijnlijk een stuk makkelijker worden, omdat ik nu goed begrijp hoelang een bepaalde taak duurt of wat de verwachte tijdsbesteding er voor zou mogen zijn. In de tweede helft van het project heb ik ook beter het voortouw kunnen nemen. Na de tussentijdse beoordeling ging er een soort knop om en begon ik me meer als 'developer' te gedragen dan als student. Op het gebied van code ben ik ook vooruit gegaan. Door tools als SonarQube te gebruiken krijg je veel meer inzichten in wat de kwaliteit van je geschreven code is. Je komt er dan ook snel achter dat je soms redelijke code schrijft en soms tragische code schrijft. De inzichten hierin helpen wel om een betere developer te worden.

9. Bronnenlijst

10. Bijlagen

10.1. Opnames gesprek Regterschot

Opname van het gesprek met Erik Regterschot op 4 November 2022

AUD-20221108-WA0000.m4a

10.2. Kernkwadranten

10.3. Factsheet