Voortgangsevaluaties semester 2

Naam: Menno Weerman

Datum voortgangsevaluatie: 27-3-2025

In deze voortgangsevaluatie behandel ik de leeruitkomsten uit semester 2.

Leeruitkomst 1: Software

Je ontwerpt, maakt en test een (web)applicatie met een relationele database op basis van requirements en acceptatiecriteria. Je maakt, volgens geldende standaarden, gebruik van opmaaktalen en programmacode en past daarbij standaardmethodes en algoritmes toe voor het ontwerpen en realiseren van onderhoudbare software. Je werkt in een team, houdt technische documentatie bij en beheert het software-ontwikkelproces in GitLab met behulp van gangbare samenwerkingsafspraken. Je verdeelt de opdracht in haalbare deeltaken en plant deze in de beschikbare tijd en bespreekt de risico's en kansen met belanghebbenden. Je onderzoekt mogelijke oplossingen voor een probleem of behoefte binnen je project. Je gebruikt betrouwbare bronnen om je keuzes te onderbouwen en stemt af met de product owner.

Hoe sta ik ervoor?

Verwacht resultaat: * In Ontwikkeling

Tijdens mijn laatste voorgangsevaluatie ben ik erachter gekomen dat ik vooral “op papier” mijn proces inzichtelijker moet maken. Het zit allemaal wel in mijn hoofd maar dat is voor een ander niet zichtbaar waardoor ik tijdens mijn presentatie geen compleet beeld laat zien. Door het uitgebreider te formuleren heb ik beoogt meer inzicht te geven in mijn proces en waar ik op dit moment sta. Voor mijn gevoel heb ik sinds de laatste voortgangsevaluatie een sterke groei doorgemaakt. Ik ben meer gaan ontwerpen wat uiteindelijk leidde tot meer onderhoudbare code. En door de documentatie tijdens het ontwerpen van de feature uit te breiden/ completer te maken werd het gehele proces voor mij overzichtelijker waardoor de uitvoeting beter verliep.

Wat heb ik gedaan en geleerd?

Bewijs	Toelichting

UML Before:	Zoals zichtbaar in het kopje bewijs was bij de eerste versie het idee om een interface te gebruiken als blauwdruk voor de base ability. Zodat de base ability dan weer een basis zou kunnen vormen voor de andere toekomstige abilities. De Ability Manager zou dan de abilities kunnen aanroepen en afhandelen.
UML After:	Toch is gebleken dat dit onvoldoende werkt en de afhandeling hierdoor incompleet is waardoor er aanpassingen noodzakelijk waren. Daarom is ervoor gekozen om de de Ability Manager een child van de speler te geven zodat de continuiteit van het proces beter verloopt en in de toekomst de Ability Manager makkelijk input kan krijgen vanuit de speler. De Base Ability functioneert inmiddels als blauwdruk voor iedere ability. Doordat de Base Ability nu functioneert en kan kijken welke vijand er het dichtste bij de speler is kunnen de cooldowns ook ingeregeld worden. De FireRate ability is zodanig geprogrammeerd dat deze alle abilities regelt die een projectiel afschieten. Maar ook als de cooldown afgelopen is de Fire functie weer aangeroepen worden. Deze functionaliteiten hebben ook een positief effect met als resultaat dat: de code modulairder is geworden en makkelijker uit te breiden. De performance is verbeterd doordat abilities niet meer hun eigen cooldowns en updates/draw beheerden, maar dit nu via een centrale manager doen. Het onderhoud van het systeem is door deze toepassing eenvoudiger geworden hetgeen ook als voordeel heeft dat de abilities minder afhankelijk waren van elkaar.
Gekregen Feedback Lucas:	Ik heb een opsomming gemaakt van de feedback die ik van Lucas heb gekregen, hierdoor is het overzichtelijker geworden waardoor de genomen acties ook zichtbaar zijn; - Optimalisatie van de AbilityManager structuur: Bij de oorspronkelijke AbilityManager had te veel verantwoordelijkheden gekregen waardoor deze te complex was geworden. In de nieuwe versie is de manager eenvoudiger en gespecificeerd, hierdoor is het systeem beter beheersbaar en toepasbaar. - Separation of concerns: In eerste instantie was de AbilityManager ook verantwoordelijk voor de logica van de abilities. Door het aanmaken van verschillende componenten zijn de verantwoordelijkheden beter verdeeld en verloopt het proces nu over de verschillende componenten. - Cooldownbeheer per ability: De cooldowns werden oorspronkelijk beheerd door de AbilityManager, maar na de verkregen feedback heb ik deze verplaatst naar de abilities zelf. Hierdoor is de manager minder complex geworden en kregen abilities meer controle over hun eigen gedrag. - Gebruik van een interface voor Update() en Draw(): oorspronkelijk werd in de AbilityManager expliciet gecontroleerd welke ability werd aangeroepen. Dit proces heb ik vervangen door een generieke aanpak waarbij de abilities nu zelf Update() en Draw() implementeren via een interface. Dit maakt dat de code schoner is en meer uitgebreid kan worden. - Vermijden van "magic numbers": Door het toepassen van een statische klasse voor configuratievariabelen werd de code overzichtelijker en makkelijker te onderhouden.
Gekregen feedback Expert Meeting van Jur:	Tijdens de feedback die ik op de expert meeting heb gekregen is gebleken dat ik erg gegroeid ben in conceptueel werken en dat ik de technische vragen goed kan beargumenteren. Het methodisch werken blijft een punt wat ik mezelf nog meer eigen moet maken. Door het uitschrijven van processen en hierdoor mijn eigen proces inzichtelijk te maken zal mijn methodiek/ structuur zichtbaarder worden.
	Ik heb mijn werkproces met github als volgt vorm gegeven: Ik ben gaan programmeren, en als ik een goed werkend onderdeel van de feature heb dan push ik dit naar github. Dit proces herhaal ik meerdere keren tot dat ik de feature afgerond heb. Na afronding van de feature maak ik een merge request. De opzet van mijn merge request laat ik beoordelen door twee groepsgenoten en vraag om feedback. De ontvangen feedback neem ik mee in mijn verbeterproces. Daarna biedt ik mijn merge request nogmaals aan en als ik twee approvals (goedkeuringen) heb dan wordt de feature gemerged naar develop. (het bijgevoegde bewijs laat een overzicht zien van de commits. Deze commits zijn op datum gezet van nieuw naar oud).
	Op afbeelding 1 is de Ability Manager zichtbaar deze voegt een ability toe en voegt deze daarna lokaal in de array abilities toe. Dit is de enige verantwoordelijkheid van de Ability Manager. Op afbeelding 2 is de Base Ability zichtbaar dit is een soort blauwdruk en beheert de informatie die voor alle abilities nodig zijn. Deze heeft de functie om te kijken of er een enemy dichtbij is en als dat zo is de dichtstbijzijnde enemy teruggeeft, een andere functie heeft de Base Abilitiy niet. Op afbeelding 3 is de Fire Rate Ability zichtbaar, deze neemt de functie over van de Base Ability (afbeelding 2) en regelt alle aanvallen die een projectiel afschieten. Deze Ability heeft dan ook alle functies voor de cooldown, dus zowel voor het schieten maar ook een abstracte functie die aangeroepen wordt als de aanval afgevuurd wordt. En als een aanval een projectiel af gaat schieten kan je hem over laten nemen ( hetgeen zichtbaar is in afbeelding 4) van Fire Rate Ability (afbeelding 3) en dan override je de functie van de Fire om de aanval uniek te maken.
	Om te komen tot een database zijn wij eerst begonnen met het maken van een strokendiagram. Hierin hebben wij de informatie van de vier verschillende tables opgeslagen omdat niet alle informatie relevant is voor de rest van het proces. Zo ontstond ook het idee van de auto increment op de ID bij de Upgrade Stats. Want iedere keer als er nu opgeslagen wordt naar een table met dezelfde sessionID komt er dan automatisch een entry bij. Wat ervoor zorgt dat wij inzichtelijker kunnen maken welke upgrades vaker gekozen worden dan andere. In de ERD heb ik gekeken of de tables 0, 1 of meer dan 1 relatie met elkaar hebben. Ik heb geprobeerd dit inzichtelijker te maken door het met de lijntjes te verbinden.

Leeruitkomst 2: Gebruikersinteractie

Je verbetert de gebruikersinteractie van je product door UX-standaarden en best practices te gebruiken. Je doet elke sprint een TMC-cyclus waarbij je je product met de eindgebruiker test. Je stelt eigen user stories op vanuit inzichten uit de test en werkt deze uit in je product. Ondersteunend aan dit proces maak je prototypes en bespreek je ontwerpkeuzes met al je stakeholders. Je houdt documentatie bij van het TMC-proces en zet belangrijke inzichten en beslissingen van het game design en interactie-ontwerp bij in een Game Design document, evenals doelen, aandachtspunten en betrokkenen. Hierbij maak je gebruik van bestaande en actuele standaarden. Het bijhouden wordt gedaan in een iteratief proces, waarbij je geregeld je gemaakte keuzes verantwoordt met betrouwbare bronnen. Je presenteert de verschillende iteraties aan je product owner tijdens de product reviews, evenals welke ethische en/of maatschappelijke normen en waarden van belang zijn bij je keuzes.

Hoe sta ik ervoor?

Verwacht resultaat: * Op niveau

Ik heb de indruk met dit punt op niveau te zitten. Naast dat ik de meeste van de user stories zelf heb geschreven ben ik ook delegated product owner. In deze hoedanigheid heb ik ervoor gezorgd dat er testbare versies van de game waren. Mede door de documentatie die ik heb geschreven en onderhouden is er een duidelijke groei zichtbaar.

Wat heb ik gedaan en geleerd?

Bewijs	Toelichting
	De feedback die wij op TMC 1 gekregen hebben is dat er al een goed onderscheid zichtbaar was tussen de TMC en GDD. De TMC op zich was eigenlijk al compleet en hierdoor behoorlijk duidelijk. De GDD was de Core Concept het onderdeel waar alle informatie van alle onderdelen al in stond. Dus moest de core concept kleiner en meer verdeeld worden over de aparte onderdelen. De link van de TMC 1: https://moojeeyoofaa75-8661a4.dev.hihva.nl/TMC/TMC-1/TMC-1/ De link van de GDD: https://moojeeyoofaa75-8661a4.dev.hihva.nl/GDD/game-design-document/. Wij hebben verder nog geen feedback ontvangen op TMC 2.
	De verschillende testfases zijn uitgevoerd op de laptop, wij hebben eerst de spelers het spel laten spelen en achteraf hebben wij vragen gesteld over de dingen die gezegd werden na acties in de game. Maar wij hebben ook specifiek gevraagd naar dingen die wij wilden weten. De resultaten die wij uit de playtest hebben gehaald zijn zichtbaar onder het kopje bewijs. De meeste punten die wij terug hebben gekregen als feedback waren bij ons al bekend. Wat wel opviel is dat de testers niet wisten wat ze moesten doen. Wij hebben hieruit geconcludeerd dat wij onze bedachte feedback loop implementeren en dat Vijanden collisions met elkaar hebben.
	Nadat wij gezamenlijk het idee van de game hebben uitgewerkt leekt het mij een leuk idee om levels upgrades te laten ontgrendelen waardoor de uitdaging in het spel vergroot wordt. Binnen de groep is toen besloten dat als er een vijand verslagen wordt er dan een experience bij de speler komt en als je een level omhoog gaat je een upgrade krijgt.
	Als upgrade hebben wij het volgende bedacht; als je een level omhoog gaat, krijg je een upgrade en om de 10 levels ontgrendeld een element (als aanval). Al denkend en sparrend kwamen wij erachter dat wij tussen de levels ook upgrades wilden hebben dus toen ontstond het idee over de damage, speed upgrades etc.
	Om dit idee ook visueel te kunnen presenteren hebben wij gezocht naar een stijl die bij ons past. Na de zoekmachine Google te hebben geraadpleegd zijn wij tot een stijl gekomen. De illustraties die het meest aansloot bij onze ideeën hebben wij onder bewijs hiernaast (rechts 2e plaatje onderin) geplaatst. Zo zijn uiteindelijk de levels en upgrades bedacht en gedesigned.

Leeruitkomst 3: Infrastructuur

Je ontwerpt, realiseert en beheert een nieuwe infrastructuur op basis van de behoeften van de gebruiker. Je beschrijft welke informatie nodig is om deze infrastructuur goed op te zetten, en legt de relevantie hiervan uit. Je hebt de infrastructuur, zowel het geheel, de individuele componenten én de bijbehorende communicatieprotocollen, volledig en correct beschreven in bijbehorende documentatie met betrouwbare bronnen, inclusief testprotocollen. Je hebt de infrastructuur gerealiseerd en getest, zowel op functionaliteit als veiligheid. Je publiceert je game op een bestaande publishing site (zoals itch.io) en stelt daarbij de nodige werkprocedures op voor het publiceren van deze games, alsook voor het onderhouden van deze game door middel van updates.

Hoe sta ik ervoor?

Verwacht resultaat: * In Ontwikkeling

Ik ben bezig geweest met het automatiseren van de releases op itch, aangezien dit nog niet het niveau is waar ik wezen wil denk ik dan ook nog niet dat ik op niveau ben.

Wat heb ik gedaan en geleerd?

Bewijs

Toelichting

https://mennow2004.itch.io/survivor-of-the-spell CI-CD Variables

Als er een tag wordt aangemaakt, dan wordt er ook gekeken naar fouten in de code. Dan wordt er een windows build gemaakt en door butler gepushed naar Itch. Op de foto's (onder bewijs) zijn de variabele te zien. Waarbij de Itch User gelijk staat aan mijn itch username. De Project name gelijk staat aan de naam van het project op Itch. Butler Api key heb ik verkregen door Butler via itch te installeren. Dan in Git Bash de command $ butler login te doen en in te loggen op het account. Als je dat gedaan hebt, dan kan je naar verkenner gaan, %userprofile% invoeren, naar .config gaan, de itch folder ingaan en dan in de folder staat een bestand met butler_creds waar je de Butler Api key kan vinden. De Api Access token heb ik verkregen door op mijn profiel een personal access token aan te maken en de opties api en read_api aan te tikken, dan de token aan te maken. Als dat gedaan is kan je de token kopieëren en invullen in de Api Access token variabele. De build zal drie fases doorlopen om te kijken of deze op itch gezet kan worden, de eerste is om te kijken of de tag bij de release branch hoort, zo ja gaat hij door. Daarna zal er een executable van de game gemaakt worden en zal de build gedeployed worden op itch. De naam van de release staat gelijk aan de naam van de tag.

Leeruitkomst 4: Persoonlijk Leiderschap

Je reflecteert op je gedrag en het effect daarvan op anderen binnen een team. Je neemt verantwoordelijkheid voor je rol in de samenwerking en betrekt je team actief bij je persoonlijke ontwikkeling door open te staan voor feedback. Je herkent en benoemt je sterke punten en ontwikkelpunten. Op basis van deze inzichten ontwikkel je een realistisch beeld van je functioneren als professional ter ondersteuning van je oriëntatie op de arbeidsmarkt.

Hoe sta ik ervoor?

Verwacht resultaat: * Op niveau

Ik heb voor mijzelf de indruk dat ik een enorme groei heb doorgemaakt waardoor ik de indruk heb dat ik op niveau functioneer.

Wat heb ik gedaan en geleerd?

Bewijs	Toelichting
	Userstory 19 heb ik afgerond aangezien ik op basis van de requirements userstories heb gemaakt, deze heb ik ook acceptatiecriteria gegeven en geprioriteerd met MoSCoW. Userstory 21 heb ik afgerond omdat ik onderhoudbare code heb geschreven waar ik ook feedback op heb gehad en deze kan ik beargumenteren/ uitleggen. Userstory 22 heb ik afgerond omdat ik in een repository werk en wij allemaal in aparte branches werken en merge requests oplos. Userstory 25 heb ik ook behaald.
	Om tot een product te komen hanteer ik voor mijn zelf de Plan Do Check Act. . Deze PDCA maakt het voor mij werkbaar en inzichtelijk waar ik ben en sta. Als ik een issue inplan doe ik een korte PDCA voor mijzelf en ga ik eerst kijken welke resultaten ik wil bereiken, deze issue rond ik dan binnen een bepaalde tijd af. Dan ga ik beginnen met het plannen en ontwerpen van de feature waaraan ik ga werken. Mochten er problemen komen of bijzonderheden zijn (de fase van Check) overleg ik dit en zet ik dit in de standup excel(foto 2 in bewijs). Als ik een feature niet haal heb ik het hierover met mijn teamgenoten om de issue van inleverdatum bij te stellen en bij te sturen om alsnog het resultaat te bereiken.
Smart Leerdoel Volledig Uitgeschreven	Uit eerder verkregen feedback is naar voren gekomen dat ik tijdens mijn presentatie moeite heb met het concreet overbrengen van wat ik bedoel. Ik heb het dan wel in mijn hoofd zitten maar heb dan moeite met het duidelijk en kort en bondig overbrengen. Daarom heb ik hier een persoonlijk leerdoel van gemaakt zodat ik hierin kan groeien en mezelf verbeteren (het mij meer eigen maken). De documentatie die ik heb gemaakt heb ik goed weten over te brengen en tot nu toe zijn deze dan ook al goedgekeurd door mijn medestudiegenoten. De feedback die ik ontvang schrijf ik in mijn notitieblokje (zie foto 2, was feedback van Jur op mijn documentatie deelproduct) zodat ik mijn feedback op een centrale plek heb en deze makkelijk kan terug vinden.

Leeruitkomst 5: Doelgericht Interacteren

Je communiceert zowel schriftelijk als mondeling op professionele wijze met belanghebbenden, en stemt behoeften en verwachtingen op elkaar af. Je presenteert verkregen resultaten en je aanbevelingen op professionele wijze volgens de daarvoor geldende kwaliteitsnormen. Je werkt bewust samen met je team, volgens de HvA HBO-ICT Agile/Scrum-methodiek en de daarbij behorende waarden, waarbij je verantwoordelijkheid neemt voor jouw deel in de samenwerking.

Hoe sta ik ervoor?

Verwacht resultaat: * In Ontwikkeling

Ik geloof dat ik goed op weg ben met dit doel, of ik op het gewenste eindniveau ben dat weet ik niet maar heb deze periode mijns inziens goede progressie laten zien.

Wat heb ik gedaan en geleerd?

Bewijs	Toelichting
	De issues tot en met 31 heb ik als product owner allemaal zelfstandig geschreven. Op basis van de te verwachte grote van een issue heb ik een weight ingesteld. Waarbij issue 1 klein is en 3 een grote issue. Omdat onze deadlines op de dinsdagen gepland staan wordt de tijdsplanning ook iedere dinsdag geëvalueerd en zo nodig bijgesteld. Deze dag wordt ook gebruikt om gezamenlijk een PDCA te doorlopen en de voortgang van de issues te bespreken en nieuwe deadlines te stellen voor de bestaande issues maar ook om opgepakte issues toe te wijzen. Onze progressie over of wij op schema lopen is te zien in de Daily standup formulier op teams.
	Als groep hebben wij het proces continue bewaakt, geëvalueerd en zo nodig bijgesteld. Mede door feedback aan elkaar te geven maar ook te ontvangen over de afgelopen sprint. Natuurlijk zijn er dan interne en externe factoren zichtbaar maar ons product is hierdoor alleen maar sterker geworden. De punten die naar voren kwamen schreven wij op. De feedback van de retrospective (2e plaatje bewijs) was dat de retrospective "ok" gemaakt was. Het positieve is dat er geen verbeterpunten waren.
	Op de foto's (bewijs) is de onderlinge communicatie te zien. Op deze manier wil ik mijn werkhouding zichtbaar maken en mijn progressie laten zien/inzichtelijk maken. Maar ook de communicatie over de resultaten van vragen als iemand ziek is. En het kijken naar merge requests, vragen stellen en het krijgen/verwerken van feedback (de PCDA).