...
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 gaf gaven in het maken van grafieken a.d.h.v. Java.
...
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.
...
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.
Code
Testplan + rapport
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.
Evaluatie gehanteerde projectmethode
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.
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.
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.
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.
...
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.
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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);
}
} |
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.
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.
Evaluatie gehanteerde projectmethode
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.
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.
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.
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-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 redeleijk 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 databse 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 he btoen 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 eriemand 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.
OOSE P-06. De student past de aangereikte ontwikkeltools om het project te organiseren toe.
...
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 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.
Conclusie
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.
Eindconclusie
Bronnenlijst
Bijlagen
Opnames gesprek Regterschot
...