...
Het gehele plan van aanpak ziet er goed uit, omdat het ons een overzicht laat zien van hoe wij dit project moeten aanpakken en dat is precies waar het plan van aanpak voor is.
Deelproduct SRS
Het SRS was voor het tussentijdse inleverpunt niet goed. Dit komt aangezien er nog bijna niks aan gedaan was, behalve de introductie. Deze introductie vond ik zelf wel goed gemaakt, maar het product als geheel was niet goed. Dit was ook te blijken uit de tussentijdse beoordeling. Nadat dit beoordeeld was en verbeterd, vind ik het product er wel goed uitzien. De feedback van de docenten is verwerkt en we hebben het een lopend verhaal gemaakt voor onze opdrachtgever, zodat hij kan begrijpen hoe zijn visie eruit ziet als dit geprogrammeerd gaat worden. In de laatste sprint hebben we het SRS nog laten zien aan onze product begeleider. Hij had gezegd dat het er goed uitzag en dat het overeenkomt met zijn visie, waardoor dit deel van het project dus geslaagd is.
...
Na mijn idee hebben we al de scrum regels de laatste paar sprints goed toegepast. De sprintplanning ging steeds beter, omdat we doorhadden hoe we dit goed konden doen. We gaven de taken specifieke namen, zodat het duidelijker was wat de taken inhielden. Het aantal uren per sprint werd ook beter ingeschat, dit is te zien door te kijken naar de burndown chart per sprint, zie bijlage burndown charts. Hoewel de eerste drie sprints nog niet goed verliepen, kwam dit vooral door de slechte toepassing van de sprintplanning. Tijdens sprint 4 bleek dat de broker meer tijd zou kosten dan origineel ingeschat, waardoor we de sprint net niet hadden gehaald. De rest van de taken tijdens sprint 4 waren wel goed ingeschat en daarom vind ik het toch een verbetering.
De eerste paar sprints hadden we scrum nog niet goed toegpast. We gingen te vroeg weg van school en werkte nog veel individueel. De daily standups gebeurde wel, maar waren ook niet goed uitgevoerd. Vergeleken met de laatste paar sprints, was dit dus nog een punt waar we aan moesten werken.
Figuur 1: Scrum procesverloop (HAN University of Applied Sciences [HAN], z.d.)
...
Voor het ontwerpen van de code hebben we tijdens DEA geleerd hoe we een API kunnen bouwen door middel van Spotitube. Deze applicatie had ik nog niet helemaal af. Ik miste de unittests en de handling voor de exceptionsexcepties. De theorie achter de code snapte ik ook nog niet, zoals wat een service was of een controller. Tijdens het project heb ik gewerkt aan de backend code voor create tab en login. Hier en daar heb ik ook groepsleden geholpen met coderen wanneer ze ergens niet uitkwamen. Door het maken van de stukken code heb ik de definities geleerd van de applicatieonderdelen. Ik heb geleerd hoe ik excepties op kan vangen en terug kan gooien. Dit is hier te zien. De login functie hielp ook bij het leren van toepassen van compleet onbekende code. De wachtwoord hash die we gebruikt hadden was onbekend voor mij, maar begreep ik snel, omdat ik eerst met een andere hash tool had gewerkt voor het project, die niet toepasbaar was op de code. Door veel test te maken, begreep ik dit stuk ook eindelijk. In het begin van het project kon niemand goed testen. Dit betekende dat we een flinke achterstand in kennis hadden en tijd zouden moeten besteden aan het leren van het testen. Martin had een workshop gehouden, maar achteraf snapte ik het testen alsnog niet helemaal. Ik besloot goed te kijken naar de testcode van Martin en de theorie hierover, erbij te halen. Dit hielp enorm, want door de theorie en de praktijk te vergelijken, snapte ik wat Martin precies had gecodeerd. Hierdoor kon ik ook aan de slag met mijn eigen tests, die tot mijn initiële verbazing, begonnen te werken. Als ik tijdens DEA eerder was begonnen met unittests, terwijl de theorie hierbij werd uitgelegd, had ik de groep wel een hoop tijd bespaart. Voor de volgende keer wil ik dus graag proberen eerder mijn kennis op te bouwen, als ik merk dat niemand in een groep de kennis heeft om iets te doen. Met deze kennis kan ik het dan uitleggen aan de groep en het hopelijk voor hen ook duidelijk maken.
Competentie OOSE P-07: De student bewaakt de kwaliteit van de software door reviews en gestructureerd testen.
Leerdoelen
Voor dit project bedenk ik een aantal leerdoelen waar ik mij aan wil houden. In dit hoofdstuk behandel ik de opgestelde leerdoelen en situatiebeschrijvingen. Als laatst laat ik mijn kernkwadranten zien voor dit project.
Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen.
Dit leerdoel heb ik gekozen, omdat in het vorig I-Project ik te weinig bezig was aan ontwerpen van bijvoorbeeld code.
Hierdoor moest mijn code vaak verbeterd worden, waardoor er te veel tijd verloren ging. Ik zou dit doel graag willen halen, zodat dit minder tijd verspilt voor mij
en de groep.
Dit leerdoel kan ik bereiken door:
- Meer te werken aan het technisch ontwerp, zodat ik van tevoren een duidelijke visie heb op wat ik wil coderen.
- De opdracht beter doorlezen en verdelen in sub-taken, zodat er een overzicht is van de taken.
- Regelmatig anderen mijn code laten reviewen, zodat latere fouten op tijd gezien kunnen worden.
Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.
Dit leerdoel heeft te maken met het realisme kernkwadrant. Dit leerdoel heb ik gekozen, aangezien ik vaak dingen alleen op mijn manier doe en niet op iemand anders manier. Dit maakt het werk meestal wel realistisch, maar niet ideaal.
Om dit leerdoel te halen heb ik een aantal stappen bedacht die ik kan doorlopen.
- Regelmatig vragen voor een 2e blik op mijn werk, wanneer ik denk klaar te zijn met mijn taak.
- Zorgen voor een goed overleg als meningen verschillen, hierbij vragen stellen zoals: "Waarom vind je dit?" of "Hoe sta jij hierin?".
- Als er iets is wat we allemaal moeten doen, dan kan ik vragen hoe een ander dit heeft aangepakt en deze aanpak kan ik dan eventueel opnemen in mijn werk, als dit goed beargumenteerd is.
Conclusie leerdoelen
Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen.
...
Zoals in de vorige competentie ook benoemd is, was ik aan het begin van het project nog niet zo goed in het schrijven van testen. Dit heb ik langzaam ontwikkeld over het project heen. Ik heb de tests geschreven voor de race functionaliteit. Ik heb Wijnand, Jasper en Sem geholpen met het oplossen van problemen die ze tegenkwamen tijdens het maken van de tests. Zo had Sem een probleem dat hij niet wist waarom er een nullpointerexception werd gegooid bij zijn test. Deze error had ik vaker gekregen en liep langzaam door mijn oplossingen heen. Ik dacht eerst dat het lag aan het feit dat de databaseconnection niet gemockt was. Dit bleek niet zo te zijn, aangezien in de setup methode dit wel werd gedaan. Vervolgens heb ik gekeken of hij de antwoorden van de resultset teruggaf. Hiermee bedoel ik de mockito.when functie in de code. Dit bleek nog niet gedaan te zijn, waardoor de code een nullpointer gaf. Toen ik hem had uitgelegd wat het probleem was, had hij het opgelost en kon hij weer verder met testen. Hiermee heb ik laten zien dat ik de code snap en het kan uitleggen aan projectgenoten. Het zoeken naar deze oplossingen in testen is voor mij wel fijn, aangezien ik dan weet of ik de code ook echt snap. Als er weer een probleem zou komen met een soortgelijk geval, weet ik dan ook dat dit waarschijnlijk een van de problemen is en kan ik iemand wat sneller helpen.
Ik heb ook veel code van anderen gereviewd. Vaak waren dit useless imports die er nog instonden, of variabele die niet gebruikt werden. Als ik dit zag, dan zette ik opmerkingen bij de code waar het fout was en legde ik uit wat het probleem precies was. Dit gebeurde niet vaak via KOET, in de praktijk blijkt het toch vaak beter en efficiënter te zijn om te zeggen waar precies het probleem ligt in plaats van elke stap van KOET te doorlopen. Hier wijkt dus de theorie af van de praktijk.
Leerdoelen
Voor dit project bedenk ik een aantal leerdoelen waar ik mij aan wil houden. In dit hoofdstuk behandel ik de opgestelde leerdoelen en situatiebeschrijvingen. Als laatst laat ik mijn kernkwadranten zien voor dit project.
Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen.
Dit leerdoel heb ik gekozen, omdat in het vorig I-Project ik te weinig bezig was aan ontwerpen van bijvoorbeeld code.
Hierdoor moest mijn code vaak verbeterd worden, waardoor er te veel tijd verloren ging. Ik zou dit doel graag willen halen, zodat dit minder tijd verspilt voor mij
en de groep.
Dit leerdoel kan ik bereiken door:
- Meer te werken aan het technisch ontwerp, zodat ik van tevoren een duidelijke visie heb op wat ik wil coderen.
- De opdracht beter doorlezen en verdelen in sub-taken, zodat er een overzicht is van de taken.
- Regelmatig anderen mijn code laten reviewen, zodat latere fouten op tijd gezien kunnen worden.
...
Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.
Ik heb dit leerdoel niet gehaald in de eerste paar sprints sprint. Ik viel nog te vaak in discussies. Het is niet gek dat ik dit toen nog niet heb gehaald, aangezien het de eerste paar sprints waren en vooruitgang in kleine stapjes gaat. In het IPV rapport van sprint 1 is te zien dat ik dit nog niet heb gehaald door te kijken naar de feedback. Voor de laatste paar sprints moet ik dus een scherper beeld hebben op dit leerdoel en moest ik ervoor zorgen dat ik dit doel niet uit het oog verlies.
Helaas kwam er een discussie (zie bijlage discussie login review) nadat mijn groepsleden mij feedback hadden gegeven. Dit wil ik graag verbeteren, door te zorgen dat ik bij frustraties een paar tellen wacht, voordat ik reageer op een antwoord. Ook zal ik proberen mijn frustratie wat meer weg te lachen. Hiermee bedoel ik dat ik mijn frustratie wat minder serieus moet nemen en moet kijken naar wat ik fout doe om deze frustratie te krijgen. Vooral wil ik hiermee zorgen dat ik niet meer boos wordt om deze voorgevallen.
Kernkwadranten
Een kernkwadrant laat in een oogopslag wat iemand zijn: valkuil, uitdaging, allergie en kernkwaliteit is.
Kernkwadrant Bespraaktheid:
...
/\
I
...
I
V
...
Uitdaging
...
Kernkwadrant Realisme
...
/\
I
...
I
V
...
Uitdaging
...
Conclusie
Afgelopen sprints heb ik geleerd om het perspectief van anderen te begrijpen. Ik mag het dan misschien niet eens zijn, maar ik moet anderen toch de kans geven om hun perspectief te leveren en uit te leggen. Ik moet komende sprints vooral werken aan het verdiepen in de beroepstaak. Het testen en bewaken van de software kwaliteit en het ontwerpen van software moet ook meer gebeuren, om zo te voldoen aan de competenties van dit project. Door te werken aan het ontwerpen van software, kan ik mijn leerdoel over het efficiënt werken aan taken ook voltooien.
Factsheet
De factsheet is te vinden op deze pagina.
Bronnenlijst
Documenten die zorgen voor de structuur van het verslag
...
Dit leerdoel heeft te maken met het realisme kernkwadrant. Dit leerdoel heb ik gekozen, aangezien ik vaak dingen alleen op mijn manier doe en niet op iemand anders manier. Dit maakt het werk meestal wel realistisch, maar niet ideaal.
Om dit leerdoel te halen heb ik een aantal stappen bedacht die ik kan doorlopen.
- Regelmatig vragen voor een 2e blik op mijn werk, wanneer ik denk klaar te zijn met mijn taak.
- Zorgen voor een goed overleg als meningen verschillen, hierbij vragen stellen zoals: "Waarom vind je dit?" of "Hoe sta jij hierin?".
- Als er iets is wat we allemaal moeten doen, dan kan ik vragen hoe een ander dit heeft aangepakt en deze aanpak kan ik dan eventueel opnemen in mijn werk, als dit goed beargumenteerd is.
Conclusie leerdoelen
Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen.
Ik heb nog niet veel ontworpen in de eerste sprint, waardoor ik geen tijd heb besteed aan dit leerdoel. Er is ook niet veel code die gemaakt moest worden deze sprint.
De opdrachten van het JIRA bord waren ook nog niet helemaal goed verdeeld, waardoor ik veel werk kwijt was op een sub-taak, dat eigenlijk meerdere taken konden zijn.
Dit leerdoel was in de tweede en derde sprint nog steeds niet gelukt. Ik ben te vroeg begonnen aan het maken van de loginfunctie. Als ik dit wel had gedaan, had dit veel tijd gekost, waardoor ik echt wil opletten dat ik dit goed ga doen. Voor de volgende sprint/code functie, wil ik eerst het SRS maken. Dit ga ik proberen te onthouden door mijn tijd meer te besteden aan het reviewen van het SRS en SDD, zodat ik de prioriteit van deze documenten goed begrijp. Na het SRS ga ik de bijbehorende sequence diagrams maken en laat ik zorgen dat deze zo snel mogelijk gereviewd zijn. Voordat ik ga werken aan de functionaliteit, laat ik mijn sequence diagrams door twee teamleden reviewen, zodat ik zeker weet dat wat ik heb gemaakt, ook echt de bedoeling is van de opdracht.
In de vierde sprint heb ik er aan gedacht om eerst te beginnen aan het maken van alle diagrammen en de beschrijvingen hiervan (zie bijlage diagrams van tevoren maken). Mijn aanpak heeft dus gewerkt en mijn leerdoel is dus eindelijk bereikt.
Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.
Ik heb dit leerdoel niet gehaald in de eerste paar sprints sprint. Ik viel nog te vaak in discussies. Het is niet gek dat ik dit toen nog niet heb gehaald, aangezien het de eerste paar sprints waren en vooruitgang in kleine stapjes gaat. In het IPV rapport van sprint 1 is te zien dat ik dit nog niet heb gehaald door te kijken naar de feedback. Voor de laatste paar sprints moet ik dus een scherper beeld hebben op dit leerdoel en moest ik ervoor zorgen dat ik dit doel niet uit het oog verlies.
Helaas kwam er een discussie (zie bijlage discussie login review) nadat mijn groepsleden mij feedback hadden gegeven. Dit wil ik graag verbeteren, door te zorgen dat ik bij frustraties een paar tellen wacht, voordat ik reageer op een antwoord. Ook zal ik proberen mijn frustratie wat meer weg te lachen. Hiermee bedoel ik dat ik mijn frustratie wat minder serieus moet nemen en moet kijken naar wat ik fout doe om deze frustratie te krijgen. Vooral wil ik hiermee zorgen dat ik niet meer boos wordt om deze voorgevallen.
Helaas is er in de laatste sprint geen IPV opgenomen. Ik heb namelijk het gevoel dat ik de laatste sprints hierop vooruit ben gegaan. Ik ben meer hulp gaan vragen over onderwerpen die ik niet snap. Als ik het gevoel had dat we iets verkeerd deden, dan vroeg ik eerst waarom ze vonden dat het zo moest, in plaats van dat ik gelijk probeer over te halen waarom ik vind dat het anders moet.
De laatste paar sprints ben ik ook niet boos of gefrustreerd geweest. Ik heb groepsgenoten geholpen wanneer ze hulp nodig hadden. Wanneer ik zag dat ze iets hadden gemaakt wat ik niet zo snel had gemaakt, begon ik eerst te vragen hoe ze erop kwamen, in plaats van mijn manier van maken uit te leggen. Zo leer ik namelijk wat de denkwijze van iemand anders is en kan ik daarmee de mening van die persoon meenemen in mijn werk.
Kernkwadranten
Een kernkwadrant laat in een oogopslag wat iemand zijn: valkuil, uitdaging, allergie en kernkwaliteit is.
Kernkwadrant Bespraaktheid:
| Kern kwaliteit | Valkuil | |
|---|---|---|
| Bespraaktheid | -> | Breedvoerigheid |
/\ | I | |
| Allergie | Uitdaging | |
| Kortafheid | <- | Bondigheid |
Kernkwadrant Realisme
| Kern kwaliteit | Valkuil | |
|---|---|---|
| Realisme | -> | Materialisme |
/\ | I | |
| Allergie | Uitdaging | |
| Zweverigheid | <- | Idealisme |
Conclusie
We waren een iets te gezellige groep en konden vaak wat serieuzer werken. Dit zorgde voor een hele moeizame start in het begin. Ondanks dit slechte begin vind ik dat we een goed herstel hebben gemaakt.
Afgelopen sprints heb ik geleerd om het perspectief van anderen te begrijpen. Ik mag het dan misschien niet eens zijn, maar ik moet anderen toch de kans geven om hun perspectief te leveren en uit te leggen. Ik heb geleerd hoe het is om elke dag te moeten werken van 9:00 tot 18:00 in de week. Voor ons was dit in het project 9:15-18:15. Ik heb geleerd minder snel mijn eigen woord aan te nemen als waarheid, maar ook iemand anders de kans geven om zijn waarheid te spreken.
In het vorige project had ik het probleem dat ik mijn taken vaak opnieuw moest doen door slechte voorbereiding. Nu was het dit project wel een gelukt met de create tab functie. Ik hoop dat ik dit kan aanhouden voor de volgende projecten.
In de laatste paar periodes, vooral na de tussentijdse beoordeling, hebben we echt een draai gemaakt en het project serieuzer aangepakt. Het is jammer dat dit niet meteen zo begon, maar wel fijn dat we dit tijdens het project gerealiseerd hadden en er wat aan deden om dit te verbeteren. Hierdoor hebben we uiteindelijk een nuttige bijdrage geleverd voor het Regterschot Racing team en voor school. De API voldoet aan de eisen van het PvA en de documentatie, al niet perfect, is toch na mijn gevoel op hoge standaard.
Het was wel fijn om in een groep samen te werken, omdat je zo kan leren hoe het later in het werkveld ook te werk gaat. Discussies en onderlinge gezelligheid zijn eenmaal niet te voorkomen, maar kunnen wel gereduceerd worden.
Voor het volgende project moet ik proberen mijn leerdoel over discussies vast te houden en te kijken of ik hierin nog meer kan verbeteren. Graag zou ik willen zien dat ik echt compleet een discussie objectief kan beginnen, om zo een ander een echte kans te geven om zijn kant van het verhaal te geven.
Factsheet
De factsheet is te vinden op deze pagina of hieronder.
Nummer | Competentie | Link naar het product (JIRA taak) | Beschrijving eigen bijdrage | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1. | 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. | Product: zie Plan van Aanpak hoofdstuk 5 zie Plan van Aanpak hoofdstuk 7 zie Plan van Aanpak hoofdstuk 8 JIRA: Geen JIRA taak | Gereviewed en hoofdstuk 5, 7 en 8 gemaakt. In hoofdstuk 7 is te zien dat ik een scrummaster was in de eerste periode. Ik heb de daily standups van de eerste sprint gehouden. In het IPV is te zien dat ik deze taken uitgevoerd heb. | ||||||||||||||||||||||||||||||||||||||||||||||||
2. | 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). | Product: JIRA:
| Inleiding gemaakt voor het SRS. De tab en grafiek verwijderen heb ik gereviewed met comments erbij. In issue 159 heb ik het hele SRS doorgenomen, met feedback erbij. Dit was gedaan na aanleiding van de tussentijdse beoordeling. | ||||||||||||||||||||||||||||||||||||||||||||||||
| 3. | OOSE P-03 De student onderzoekt voor het project relevant (technologie)keuzes en rapporteert hierover gestructureerd. | Product: JIRA:
| In het SDD heb ik in login 1.3 genoteerd waarom ik gekozen heb voor Argon2 als | ||||||||||||||||||||||||||||||||||||||||||||||||
| 4. | 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 Specification (SDD). | Product: zie Login 1.3 Sequence diagram
| Voor login heb ik het sequence diagram en system diagram gemaakt. De uitleg hiervan heb ik ook gegeven. Het design class diagram heb ik aangevuld met de login functie en databaseconnectie. Voor het maken van een tab heb ik ook een sequence diagram gemaakt. Na aanleiding van de tussentijdse beoordeling, heb ik het hele SDD nogmaals doorgenomen en comments achter gelaten. Voor issue 136 en 130 heb ik alleen gereviewed. Voor issue 43 heb ik het design class van de toen huidige code gemaakt, waardoor mijn log time over mijn estimate heen ging. In issue 193 is mijn gelogde tijd voor het creëren van de sequence diagram voor create tab genoteerd. | ||||||||||||||||||||||||||||||||||||||||||||||||
| 5. | 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-functionele eisen. | Product:
| Zorgen dat er ingelogd kan worden met de database. De code heb ik voor een deel ook samen met Sem opgezet. Bij deze code heb ik ook gezorgd voor het opzetten van het systeem. (gitignore, beans.xml, injections). Voor issue 194 heb ik de backend implementatie van create tab gemaakt, dit is ook te vinden in de Bitbucket commit. | ||||||||||||||||||||||||||||||||||||||||||||||||
| 6. | OOSE P-06 De student past de aangereikte ontwikkeltools om het project te organiseren toe. | Product: zie Bitbucket zie JIRA zie Confluence | In sonarqube hebben we ervoor gezorgd dat onze codekwaliteit te zien is. Dit duurde wel langer voor ons om op te zetten, maar uiteindelijk hebben we dit opgezet en maken we dit up-to-date elke keer als er iets nieuws op de master komt. Bij deze opzet had ik ook meegeholpen. In Bitbucket heb ik merge requests heb aangemaakt voordat iets op de master branch komt. In JIRA sleep ik mijn taken naar ready to review als ik klaar ben, om te laten weten dat het gecontroleerd kan worden. Als deze door twee personen zijn goedgekeurd, dan sleep ik het naar done. Ook log ik mijn uren op JIRA, waardoor te zien is hoeveel ik per dag heb gewerkt. In confluence is de pagina navigatiestructuur te zien. Hierbij heb ik een aantal mappen toegevoegd en bestanden genoteerd die ingeleverd moeten worden aan Regterschot. | ||||||||||||||||||||||||||||||||||||||||||||||||
| 7. | 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. | Product: zie Bitbucket reviews pull request JIRA:
| Ik had het data transfer verslag verbeter tijdens mijn review, dit is te zien in JIRA taken 54 t/m 61. Door dit te verbeteren, In de Bitbucket link zijn mijn pull request reviews te zien. | ||||||||||||||||||||||||||||||||||||||||||||||||
| 8. | OOSE P-08 De student kan zich zelfstandig verder verdiepen in de beroepstaak. | Product: zie persoonlijk verslag leerdoelen zie persoonlijk verslag conclusie | In de conclusie leg ik uit wat ik heb geleerd van het project en hoe ik dit kan toepassen bij een volgend project. In de leerdoelen leg ik uit hoe ver ik ben ontwikkeld met de doelen die ik heb opgesteld aan het begin van het project. | ||||||||||||||||||||||||||||||||||||||||||||||||
| 9. | |||||||||||||||||||||||||||||||||||||||||||||||||||
| 10. |
Bronnenlijst
Documenten die zorgen voor de structuur van het verslag
| Titel | Auteur(s) | versie | Verwijzing | Publicatiedatum | Uitgever | Raadpleegdatum | |
|---|---|---|---|---|---|---|---|
| 1. | Alle informatie over het schrijven van je Projectverslag | Team professional skills | 2021-2022 | https://han.onderwijsonline.nl/elearning/lesson/ZyMjPlvD | november 2021 | HAN University of Applied Sciences | 28-11-2022 |
| 2. | Slagen voor het OOSE project S1 2022-2023 | Michel Koolwaaij | 1.0 | https://han.onderwijsonline.nl/elearning/lesson/Kqe86W3D | 01-11-2022 | HAN University of Applied Sciences | 01-12-2022 |
Documenten die inhoudelijk gebruikt worden
- Praktijkbureau AIM. (2022). Toelichting plan van aanpak. In Onderwijs Online. HAN University of Applied Sciences. Geraadpleegd op 2 november 2022, van https://han.onderwijsonline.nl/elearning/lesson/Kqe86W3D
- HAN University of Applied Sciences [HAN]. (z.d.). Les 5 wk_5_OOSE_Methode en planning_2022-2023_stud [Presentatieslides; Website]. OnderwijsOnline. https://han.onderwijsonline.nl/elearning/lesson/pNWX2Z9y
- Sonarqube. (2022, 5 december). SonarQube. Geraadpleegd op 13 januari 2023, van https://sonarqube.aimsites.nl/dashboard?id=nl.han.oose.smalltalk
- GmbH, L. (z.d.). IT Architects: Types, Roles, and Skill Sets | LeanIX. LeanIX. Geraadpleegd op 13 januari 2023, van https://www.leanix.net/en/wiki/ea/it-architects?utm_term=it+architect
- Scharwächter, V. (2022, 20 december). Discussie schrijven voor je scriptie | Inclusief voorbeeld. Scribbr. https://www.scribbr.nl/scriptie-structuur/discussie-scriptie/
Bijlagen
IPV rapport sprint 1
IPV rapport sprint 2
IPV rapport sprint 3
Burndown charts
Situatiebeschrijvingen
Situatie: Discussie login review
In sprint 2 was er een discussie begonnen over hoe de loginfunctie veranderd moest worden. Dit gebeurde na het reviewen van mijn taak. Wijnand en Bram waren mijn stukje code aan het reviewen en zagen dat er een aantal aanpassingen gedaan konden worden. In dit geval ontving ik dus feedback en gaven Bram en Wijnand hun feedback. Ik had verwacht dat ik mijn code nog wel wat had moeten aanpassen, want ik zal best een paar dingen over het hoofd hebben gezien. Ik kreeg mijn feedback terug en besloot de aanpassingen die zij hadden toegelicht te implementeren, zodat ik klaar zou zijn met het maken van de login. Mijn frustratie over het maken van deze loginfunctie lag hoog, want ik zat al boven de geschatte tijd in en wilde graag bezig zijn met andere competenties. Na het verbeteren had ik aangegeven dat mijn stukje code verbeterd was en weer klaar was om gereviewed te worden. Dit keer verliep het alleen anders. Veel van wat ik net moest veranderen aan mijn code, moest weer op een andere manier gedaan worden dan bij de vorige review was aangegeven. Dit ging vooral over het geven van tokens en het hashen van een wachtwoord. Ik was hier boos om geworden, omdat ik weer tijd had besteed aan een stukje code, om vervolgens te horen dat het weer anders moest. Aangezien ik deze sprint al vaker problemen had gehad met de loginfunctie, besloot ik dat ik wilde stoppen met het maken van deze code, aangezien ik er niet meer onderuit kwam. Dit deed ik alleen op een best wel boze manier en dit had ik anders kunnen aanpakken. Als ik mijn frustratie had uitgelegd en gevraag om een oplossing, dan was dat een betere optie geweest, dan het werk verschuiven naar iemand anders. Ik dacht dat door mijn werk naar iemand anders te verschuiven, er een teamlid zou zijn die er meer van wist en het dus sneller af zou maken. De groep had aangegeven in het IPV dat dit wel anders gehandeld had kunnen worden, waarbij ik het ook mee-eens ben. Ik had niet boos moeten worden en naar oplossingen moeten zoeken.
Situatie: Diagrams van tevoren maken
Ik had als taak gekozen om de tab aanmaak functie te maken. De vorige keren dat ik een functie ging maken, begon ik met de code en ging ik daarna pas de diagrammen maken. Dit resulteerde in een slordige en onduidelijke login functie, die ik meerdere malen moest verbeteren. Ik begon een branch aan te maken en wilde net gaan coderen, totdat het besef in mij kwam dat ik niet echt goed wist waar ik moest beginnen. Ik besloot mijn code af te sluiten en te beginnen aan het maken van de diagrammen. Door deze diagrammen te maken, kon ik richtlijnen creëren die mij zouden helpen bij het maken van de code. Ik had eerst het SRS gedeelte gemaakt en gevraagd aan Bram en Jasper gevraagd of wat ik had gemaakt, goed was. Na een korte reviewen, was het enige deel feedback dat er nog een paar spellingsfouten inzaten. Deze had ik eruit gehaald en ben toen begonnen aan het sequence diagram. Dit bleek wat moeilijker te zijn dan dat ik had gedacht, omdat er te moeilijk over nadacht. Ik had Wijnand om hulp gevraagd en die gaf wat uitleg over zijn sequence diagram, waardoor ik wist hoe ik mijn sequence diagram kon maken. Nadat ik deze diagrammen afhad met beschrijving erbij, liet ik deze weer reviewen door twee groepsleden. Dit werd nog een keer goedgekeurd en ik ben toen begonnen met coderen. Ondanks de sequence diagram, heb ik nog er nog wel vanaf geweken. De aanpassingen die ik had gemaakt aan de code, heb ik vervolgens ook weer aangepast aan de sequence diagram. De sequence diagram zorgde er wel voor dat het coderen sneller ging, omdat ik wist waar ik naartoe wilde werken. Door een structuur in het codingsproces te krijgen, kan er dus duidelijkheid komen in wat en hoe je gaat coderen. Voor de volgende keer zou ik wel graag willen dat mijn sequence diagram wat beter is en dat het niet aangepast hoeft te worden
Documenten die inhoudelijk gebruikt worden
- Praktijkbureau AIM. (2022). Toelichting plan van aanpak. In Onderwijs Online. HAN University of Applied Sciences. Geraadpleegd op 2 november 2022, van https://han.onderwijsonline.nl/elearning/lesson/Kqe86W3D
- HAN University of Applied Sciences [HAN]. (z.d.). Les 5 wk_5_OOSE_Methode en planning_2022-2023_stud [Presentatieslides; Website]. OnderwijsOnline. https://han.onderwijsonline.nl/elearning/lesson/pNWX2Z9y
- Sonarqube. (2022, 5 december). SonarQube. Geraadpleegd op 13 januari 2023, van https://sonarqube.aimsites.nl/dashboard?id=nl.han.oose.smalltalk
- GmbH, L. (z.d.). IT Architects: Types, Roles, and Skill Sets | LeanIX. LeanIX. Geraadpleegd op 13 januari 2023, van https://www.leanix.net/en/wiki/ea/it-architects?utm_term=it+architect
- Scharwächter, V. (2022, 20 december). Discussie schrijven voor je scriptie | Inclusief voorbeeld. Scribbr. https://www.scribbr.nl/scriptie-structuur/discussie-scriptie/
Bijlagen
IPV rapport sprint 1
IPV rapport sprint 2
IPV rapport sprint 3
Burndown charts
Situatiebeschrijvingen
Situatie: Discussie login review
In sprint 2 was er een discussie begonnen over hoe de loginfunctie veranderd moest worden. Dit gebeurde na het reviewen van mijn taak. Wijnand en Bram waren mijn stukje code aan het reviewen en zagen dat er een aantal aanpassingen gedaan konden worden. In dit geval ontving ik dus feedback en gaven Bram en Wijnand hun feedback. Ik had verwacht dat ik mijn code nog wel wat had moeten aanpassen, want ik zal best een paar dingen over het hoofd hebben gezien. Ik kreeg mijn feedback terug en besloot de aanpassingen die zij hadden toegelicht te implementeren, zodat ik klaar zou zijn met het maken van de login. Mijn frustratie over het maken van deze loginfunctie lag hoog, want ik zat al boven de geschatte tijd in en wilde graag bezig zijn met andere competenties. Na het verbeteren had ik aangegeven dat mijn stukje code verbeterd was en weer klaar was om gereviewed te worden. Dit keer verliep het alleen anders. Veel van wat ik net moest veranderen aan mijn code, moest weer op een andere manier gedaan worden dan bij de vorige review was aangegeven. Dit ging vooral over het geven van tokens en het hashen van een wachtwoord. Ik was hier boos om geworden, omdat ik weer tijd had besteed aan een stukje code, om vervolgens te horen dat het weer anders moest. Aangezien ik deze sprint al vaker problemen had gehad met de loginfunctie, besloot ik dat ik wilde stoppen met het maken van deze code, aangezien ik er niet meer onderuit kwam. Dit deed ik alleen op een best wel boze manier en dit had ik anders kunnen aanpakken. Als ik mijn frustratie had uitgelegd en gevraag om een oplossing, dan was dat een betere optie geweest, dan het werk verschuiven naar iemand anders. Ik dacht dat door mijn werk naar iemand anders te verschuiven, er een teamlid zou zijn die er meer van wist en het dus sneller af zou maken. De groep had aangegeven in het IPV dat dit wel anders gehandeld had kunnen worden, waarbij ik het ook mee-eens ben. Ik had niet boos moeten worden en naar oplossingen moeten zoeken.
Voorbeelen van unittests
...