1. Inleiding
1.1 Opdracht
Wij hebben van het bedrijf JDI de opdracht gekregen om voor hen een HR-portaal te bouwen. Zelf gebruikte zij telkens excelsheets om veel dingen bij te houden zoals reiskosten vergoedingen en verlof, zij wouden dit makkelijker maken door een groot deel ervan te automatiseren en het op een centraal punt te kunnen doen. In ons portaal zouden wij verschillende dingen opnemen zoals; het reserveren van een werkplek, reiskosten declaraties aan kunnen maken op basis van je thuis locatie en het kantoor of twee zelf ingevulde locaties, automatisch declaraties aanmaken voor mensen die die dag een plek gereserveerd hadden, verlof aanvragen kunnen doen en deze goedkeuren als je de juiste rechten hebt en wat algemene CRUD mogelijkheden voor het aanmaken, aanpassen en verwijderen van dingen zoals medewerkers, locaties en werkplekken.
1.2 Inhoudelijke uitdagingen
Voor mij is het een aardige tijd geleden dat ik heb geprogrameerd in de talen die we zouden gebruiken in dit project, als herkanser heb ik niet veel lessen gevolgt, dit was dus een beetje opfrissen weer. Verder is een grote uitdaging voor mij dit verslag schrijven en optijd af krijgen, ik heb al meerdere malen het ISE en OOSE project gedaan en echter alleen vorig semester het ISE project ook daadwerkelijk afgerond.
1.3 Leerdoelen
Leerdoel 1: Duidelijker aangeven aan de groep waar ik aan werk.
Bij het vorige ISE project werd er door de andere leden aangegeven dat het niet altijd duidelijk was waar ik aan werkte, dit kwam ook een deel doordat we veel vanuit huis werkte. In dit project wil ik dus duidelijker maken wat ik aan het doen ben op de dag.
Acties die ik ga ondernemen om dit te behalen:
- Elke dag bij de daily stand-up aanwezig zijn en duidelijk aangeven wat ik ga doen.
- In de middag na de pauze nog een keer laten weten wat ik de rest van de dag ga doen.
- Bij het online werken na de daily stand-up vragen of het duidelijk is wat ik ga doen.
Mijn leerdoel zal behaald zijn als ik gemiddeld minder dan 1x per week een vraag krijg over wat ik aan het doen ben (buiten de daily stand-up om natuurlijk).
Leerdoel 2: Optijd aanwezig zijn op locatie.
Bij de eerste sprint review was er een feedback puntje naar voren gekomen, dit was minder te laat zijn. Dit was niet alleen op mij gericht maar meer een iedereen in de groep moet dit doen maar ik merkte van mezelf wel dat dit bij mij inderdaad wel regelmatig voor kwam. Door de bus die ik neem ben ik altijd of 5 minuten te laat of ik moet de bus een half uur eerder nemen, vandaar dat ik vaak net iets later aan kwam.
Acties die ik ga ondernemen om dit te behalen:
- De bus eerder pakken zodat ik altijd optijd ben.
- Als er iets is waardoor ik wat later ben, dit optijd en duidelijk aangeven.
Mijn leerdoel zal behaald zijn als ik gemiddeld minder dan 1x per week later kom dan de afgesproken tijd.
2. Deelproducten
2.1 PvA
Het Plan van Aanpak (PvA) dient duidelijke te maken wat het plan is voor de duur van het project en duidelijke regels opstellen voor zowel de groep als de opdrachtgever.
Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:
| Kwaliteitseis | Beroordeling (goed, neutraal, matig, zwak) | Toelichting |
|---|---|---|
| Voldoet aan de AIM-controlekaart (zie bijlage 10.2) | Goed | Het document is voorzien van alle punten die betrekking hebben tot het document en de vereisten van werken op confluence. Het bevat een inhoudsopgave en is opgebouwd uit hoofdstukken, paragrafen en alinea’s. Het document is doelgericht geschreven, woorden en werkwoorden zijn correct gespeld en het is geschreven in de lijdende vorm. Echter zijn alleen de tabellen en afbeeldingen niet genummerd. |
| Verwerking feedback | Goed | Er is tussentijds niet erg veel feedback ontvangen over het PvA, de enige punten gingen over wat tijden die waren aangepast die nog niet verwerkt waren in het PvA, dat is nu wel gedaan. |
| Eisen van de opdrachtgever zijn duidelijk terug te zien | Goed | In hoofdstuk 3 is duidelijk aangegeven wat de opdrachtgever van groep verwacht en wat er uiteindelijk opgeleverd wordt. |
| Het document laat geen ruimte voor uitendelijke duscussie met de opdrachtgever | Goed | De opgenomen projectgrenzen en randvoorwaarden dekken alle mogelijke verwarring af en zorgen ervoor dat er voor de opdrachtgever geen valse verwachtingen heeft en de projectgroep niet meer hoeft te maken dan al is afgesproken. |
| Het document bevat duidelijke en goed opgestelde kwaliteitseisen | Neutraal | De opgenomen kwaliteitseisen zijn erg schaars en gaan bij productkwaliteit vooral over of ze voldoen aan de documentatie richtlijnen, bij de proceskwaliteit gaat het bijna alleen om het goedkeuren door 2 groepsleden en de tevredenheid van de opdrachtgever en begeleider. |
Tabel 1: kwaliteitsoordeel PvA
Ik vind dat de kwaliteit van het PvA goed is, alle belangrijke punten worden aangetikt en zijn van voldoende of hogere kwaliteit. Ook is het doel van het document behaald.
2.2 Onderzoeksverslag
Het onderzoek dient verdieping te tonen over de API en een conclusie te trekken die betrekking heeft tot het project. Het onderzoel dat ik zal beoordelen is het Google Distance Matrix API Onderzoek.
Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:
| Kwaliteitseis | Beroordeling (goed, neutraal, matig, zwak) | Toelichting |
|---|---|---|
| Voldoet aan de APA-richtlijnen | Neutraal | Er zijn bronnen gebruikt bij het schrijven van het onderzoek, deze zijn echter niet in de tekst zelf vermeld en ook staat de bronnenlijst niet op de APA manier vermeld. Dit laatste punt zal echter vooral komen doordat het allemaal links zijn van de documentatie over de API van google zelf, veel informatie zoals de auteur, datum etc zijn niet beschikbaar. |
| Voldoet aan de AIM-controlekaart (zie bijlage 10.2) | Goed | Het document is voorzien van alle punten die betrekking hebben tot het document en de vereisten van werken op confluence. Het bevat een inhoudsopgave en is opgebouwd uit hoofdstukken, paragrafen en alinea’s. Er is sprake een bronnenlijst. Het document is doelgericht geschreven, woorden en werkwoorden zijn correct gespeld en het is geschreven in de lijdende vorm. Echter zijn alleen de tabellen niet genummerd. |
| Verwerking feedback | Goed | Voor dit onderzoek was er eerst een erg kleinschalig document opgezet waarbij veel onderdelen die het een echt onderzoek zouden maken ontbraken, hier is dus redelijk wat feedback over gekomen. Vervolgens heb ik voor dit onderzoek alle feedback zo goed mogelijk toegepast en aangevuld waar nodig. |
| Doel van het onderzoek is duidelijk en behaald | Goed | Er is een duidelijke doelstelling vermeld en met de conclusie die getrokken wordt, wordt dit doel ook behaald. |
| Het onderzoek bestaat uit duidelijke deel en hoofd vragen | Goed | Het onderzoek is duidelijk verdeeld over 1 hoofdvraag en 3 deelvragen, de deelvragen samen geven genoeg informatie om de hoofdvraag te kunnen beantwoorden. |
| De aanpak voor het onderzoek is duidelijk | Neutraal | Er is een duidelijke methode opgesteld over hoe het onderzoek uitgevoerd zal worden. Dit zou echter misschien wel iets uitgebreid kunnen worden. |
| Er is een duidelijke conclusie getrokken | Goed | In de conclusie worden kort alle antwoorden op de deelvragen samengevat en hiermee wordt de hoofdvraag beantwoord. Hiermee wordt ook het doel van het document behaald. |
Tabel 2: kwaliteitsoordeel onderzoeksverslag
Ik vind dat de kwaliteit van het onderzoek dus goed is, alle belangrijke punten zijn aangetikt en zijn van voldoende of hogere kwaliteit. Ook is het doel van document behaald.
2.3 SRS
Het Software Requirements Specification (SRS) dient als een soort van plattegrond en plan voor het bouwen van de software, het moet duidelijk maken welke functionaliteit er wordt geimplementeerd en hoe het eruit zal gaan zien zonder te technish te worden.
Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:
| Kwaliteitseis | Beroordeling (goed, neutraal, matig, zwak) | Toelichting |
|---|---|---|
| Voldoet aan de AIM-controlekaart (zie bijlage 10.2) | Goed | Het document is voorzien van alle punten die betrekking hebben tot het document en de vereisten van werken op confluence. Het bevat een inhoudsopgave en is opgebouwd uit hoofdstukken, paragrafen en alinea’s. Er is sprake een bronnenlijst. Het document is doelgericht geschreven, woorden en werkwoorden zijn correct gespeld en het is geschreven in de lijdende vorm. Echter zijn alleen de tabellen en afbeeldingen niet genummerd. |
| Verwerking feedback | Goed | Over dit document was veel feedback ontvangen tussentijds, een groot deel waren kleine dingen zoals dat de NFR's in een appart hoofdstuk moesten, dit was verkeerd gegaan doordat er geen H1 bovenaan de pagina stond, dit soort dingen en alle andere feedback punten zijn verwerkt in het document. |
| Er is een duidelijk domein model | Goed | Er is een duidelijk domein model opgesteld dat het domein waarmee gewerkt wordt goed in kaart brengt. Ook is er een duidelijke glosary opgesteld die het domein verduidelijkt. |
| Er is een duidelijk use case model | Neutraal | Er is een duidelijk use case model opgesteld die duidelijk maakt welke use cases er zijn en welke actoren hierbij horen. Er is echter wel iets veranderd aan hoe het verlof systeem werkt dat hier niet in is verwerkt. |
| Er zijn fully dressed use case descriptions uitgewerkt | Goed | Alle use cases die niet alleen over CRUD operaties gaan zijn uitgewerkt in fully dressed use case descriptions, deze bevatten alle benodigde informatie en ook een alternative flow waar dit toepasselijk is. |
| Er zijn functional requirements opgesteld | Goed | Er zijn zowel other functional requirements als non functional requirements omschreven die alles omvatten dat buiten de usecases valt, de non functional zijn ook opgedeeld door middel van de FURPS+ methode. |
| Er zijn user interface sketches | Goed | Er zijn user interface sketches die duidelijk maken hoe de applicatie er uiteindelijk uit gaat zien, hierin zijn alle schermen die de gebruiker te zien krijgt verwerkt. |
Tabel 3: kwaliteitsoordeel SRS
Ik vind dat de kwaliteit van het SRS goed is, alle punten zijn aangetikt en zijn van voldoende of hogere kwaliteit. Ook is het doel van het document behaald.
2.4 SDD
Het Software Design Description (SDD) dient het te verduidelijken van het ontwerp van de software structuur en alle sub systemen die deel uit maken van de applicatie.
Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:
| Kwaliteitseis | Beroordeling (goed, neutraal, matig, zwak) | Toelichting |
|---|---|---|
| Voldoet aan de APA-richtlijnen | Goed | Er is een bron gebruikt bij het opstellen van het SDD, deze staat vermeld in de bronnenlijst in de APA-stijl. Dit is echter wel maar 1 bron, dit komt vooral doordat dit document gaat over onze software structuur en bronnen dus niet echt nodig zijn. |
| Voldoet aan de AIM-controlekaart (zie bijlage 10.2) | Goed | Het document is voorzien van alle punten die betrekking hebben tot het document en de vereisten van werken op confluence. Het bevat een inhoudsopgave en is opgebouwd uit hoofdstukken, paragrafen en alinea’s. Er is sprake een bronnenlijst. Het document is doelgericht geschreven, woorden en werkwoorden zijn correct gespeld en het is geschreven in de lijdende vorm. Echter zijn alleen de tabellen en afbeeldingen niet genummerd. |
| Verwerking feedback | Goed | Over dit document was veel feedback ontvangen tussentijds, dit kwam grotendeels doordat het nog niet helemaal af was en een groot deel verkeerd begrepen was en dus verkeerd was neergezet. De feedback is vervolgens allemaal toegepast en het document is aangevult tot volledigheid. |
| Er is een duidelijk achitectueel overview | Goed | Er is een duidelijk diagram aanwezig met daarin een schets van de architectuur van onze applicatie. |
| Er is een duidelijk deployment diagram | Goed | Er is een duidelijk deployment diagram aanwezig met daarin een schets van de uiteindelijke deployment van onze applicatie. |
| Bevat alle sub systemen en deze zijn goed uitgewerkt | Matig | Het sub systeem van de backend is goed uitgewerkt en volledig, het bevat een volledig klassen diagram met daarin alle klasses van de backend. Ook zijn er sequence diagrammen aanwezig van use cases die de interactie tussen klassen laten zien. Echter ontbreekt op het moment van schrijven nog wel een sub systeem uitwerking voor de frontend, dit is dus wel een heel onderdeel dat nog mist. |
| Er zijn design desicions vermeld | Neutraal | Er zijn meerdere design decisions opgesteld voor de backend, deze zijn echter wel aan het einde pas opgesteld dus het kan zo zijn dat er beslissingen zijn genomen die we vergeten zijn te vermelden. Ook ontbreekt dus het gedeelte van de frontend op moment van schrijven, hier zijn dus ook geen design decisions over opgenomen. |
| Er is een duidelijk database design met een PDM, tabelbeschrijvingen en design decisions | Goed | Het database design is goed en volledig uitgewerkt, er is een PDM aanwezig welke is gegenereerd uit een CDM en aangepast waar nodig, er zijn tabelbeschrijvingen aanwezig voor elke tabel en kolom en er zijn design decisions opgenomen. |
Tabel 4: kwaliteitsoordeel SDD
Ik vind dat de kwaliteit van het onderzoek neutraal is, de onderdelen die erin zitten zijn goed uitgewerkt en voldoen aan de eisen, maar er ontbreekt nog een cruciaal onderdeel. Hierdoor is ook het doel niet helemaal behaald, het dient het ontwerp te verduidelijken en dat doet het ook voor de backend en de database maar niet over het geheel.
2.5 Unittests
De unittests dienen aan te tonen dat de geschreven code goed werkt en ook tijdens het project door blijft werken.
Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:
| Kwaliteitseis | Beroordeling (goed, neutraal, matig, zwak) | Toelichting |
|---|---|---|
| Er zijn unittests geschreven voor alle methodes waarbij dit van belang is | Neutraal | Er zijn unittests geschreven voor alle methodes in de service laag, de rest van de klasses worden niet getest door unittests. De recource laag en DAO van de backend en de methodes van de frontend worden wel getest door flow tests. In zowel de frontend als backend hadden er nog wel meer unittests geschreven kunnen worden. |
| Er is een 80% of hoger line coverage over de klassen waarbij dit van belang is | Goed | Als er gekeken word naar de line coverage van de services laag is er een line coverage van 85% (433/507). |
| Alle unittests zijn nuttig | Goed | Alle unittests die geschreven zijn testen ook daadwerkelijk de uitkomst van de functie, er zijn geen 1=1 unittests geschreven. |
| Alle unittests slagen | Goed | Van de 91 unittests slagen er 91, dit is een 100% slagings percentage. |
Tabel 5: kwaliteitsoordeel unittests
Ik vind dat de kwaliteit van de unittests goed is, alle unittests slagen, ze zijn allemaal nuttig en er is een line coverage van 85% over de onderdelen waar het toe doet.
2.6 Stuk code
De code dient als functionaliteit van de applicatie, het is een uitwerking van de use cases en/of non/other functional requirements. Het stukje code dat ik zal beoordelen is DeclaratieAuto.java.
Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:
| Kwaliteitseis | Beroordeling (goed, neutraal, matig, zwak) | Toelichting |
|---|---|---|
| Code is goed onderhoudbaar | Goed | De hoofd methode is opgedeeld in meerdere methodes die elk hun eigen ding doen. Ook zijn er geen magic numbers of strings gebruikt, deze zijn allemaal aangemaakt als variabelen dus als deze aangepast moeten worden kan dit op 1 plek en is het gelijk duidelijk wat het is. |
| Code maakt gebruik van dependency injection | Zwak | In het stukje code wordt geen dependency injection gebruikt, er wordt een nieuwe instantie aangemaakt van alle DAO's die gebruikt worden. |
| Er zijn unittests geschreven voor de code | Goed | Er zijn voldoende unittests geschreven voor de code. |
| Geen monster methodes die alles doen | Goed | De methode is opgedeeld in kleinere methodes die elk hun eigen ding doen. |
Tabel 6: kwaliteitsoordeel stuk code
Ik vind dat de kwaliteit van de code voldoende is, als er gebruik gemaakt wordt van dependency injection zou het naar een goed gaan, de rest is namelijk wel meer dan voldoende.
2.7 Testrapport
Het Testrapport dient aan te tonen hoe het testen verlopen is en of er ergens nog problemen zijn.
Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:
| Kwaliteitseis | Beroordeling (goed, neutraal, matig, zwak) | Toelichting |
|---|---|---|
| Voldoet aan de AIM-controlekaart (zie bijlage 10.2) | Goed | Het document is voorzien van alle punten die betrekking hebben tot het document en de vereisten van werken op confluence. Het bevat een inhoudsopgave en is opgebouwd uit hoofdstukken, paragrafen en alinea’s. Er is sprake een bronnenlijst. Het document is doelgericht geschreven, woorden en werkwoorden zijn correct gespeld en het is geschreven in de lijdende vorm. Echter zijn alleen de tabellen en afbeeldingen niet genummerd. |
| Er is duidelijk hoe is getest en welke tools hiervoor worden gebruikt | Goed | Er staat duidelijk aangegeven dat er getest wordt met unittests en flow tests, ook staat er aangegeven welke tooling zowel de frontend als backend hiervoor gebruiken. |
| Er zijn bekende errors/bugs opgesteld als deze aanwezig zijn | Goed | Er zijn bugs bekend bij het team en deze zijn ook verwerkt in het testrapport met duidelijk aangegeven wanneer dit gebeurd en hoe dit opgelost zou kunnen worden. |
| Alle tests zijn aanwezig | Matig | Voor de backend zijn alle unittests opgenomen, ook zijn flowtests opgenomen die de frontend, backend en database testen. Er zijn op het moment van schrijven echter nog geen frontend unittests opgenomen in het document. |
| Er is een 100% slagings percentage | Goed | Alle tests die zijn opgenomen in het testrapport slagen. |
Tabel 7: kwaliteitsoordeel testrapport
Ik vind dat de kwaliteit van het testrapport nog net voldoende is, voor de frontend ontbreken wel de unittests maar de frontend is niet helemaal niet getest, deze wordt ook meegenomen in de flow tests. Echter is het wel een belangrijk deel dat ontbreekt.
3. Eindproduct
Het doel van het eindproduct was de werkzaamheden van JDI versimpelen door te automatiseren wat kan en er een centraal portaal voor te maken waardoor de excel sheets en persoonlijke aanvragen niet meer nodig zijn.
Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:
| Kwaliteitseis | Beroordeling (goed, neutraal, matig, zwak) | Toelichting |
|---|---|---|
| Er is de mogelijkheid om in te loggen | Goed | Er is een gebruikers systeem waardoor gebruikers moeten inloggen op het portaal om het te kunnen gebruiken. |
| Er is de mogelijkheid om gebruikers te beheren | Goed | Voor beheerders is er de mogelijkheid om gebruikers en alle toepasselijke gegevens aan te passen, te verwijderen of aan te maken. |
| Er is de mogelijkheid om een werkplek te reserveren en ook weer uit te schrijven | Goed | Gebruikers van het portaal kunnen in het werkplek overzicht een werkplek aankliken om hier op ingeschreven te worden als hier plek voor is. Als een werknemer toch niet op de werkplek wilt werken kunnen zij of een andere plek aan klikken of de thuis plek kiezen om zo uitgeschreven te worden. |
| Er is de mogelijkheid om werkplekken te beheren | Goed | Voor beheerders is er de mogelijkheid om werkplekken en alle toepasselijke gegevens aan te passen, te verwijderen of aan te maken. |
| Er is de mogelijkheid om locaties te beheren | Goed | Voor beheerders is er de mogelijkheid om locatiesen alle toepasselijke gegevens aan te passen, te verwijderen of aan te maken. |
| Er is de mogelijkheid om reiskosten te declareren | Goed | Gebruikers van het portaal kunnen op de declaratie pagina een overzicht zien van hun huidige declaraties en hier ook een nieuwe declaratie aanmaken op basis van of ze thuis hebben gewerkt, op locatie of naar een klant zijn geweest. Hierbij wordt bij woon-werk automatisch de afstand berekend tussen de thuislocatie en het kantoor, ook heeft de gebruiker de mogelijkheid om zelf 2 locaties in te vullen, deze worden dan via een google API opgehaald om ervoor te zorgen dat het legitieme locaties zijn. |
| Reiskosten worden elke dag automatisch gedeclareerd | Goed | Voor alle gebruikers in het systeem wordt er elke dag automatisch een declaratie aangemaakt, als zij dit zelf niet al hadden gedaan, deze wordt vervolgens aangemaakt op basis van de invulling van het werkplek schema. Dus als ze niks hadden ingevuld en op thuis stonden werd dit automatisch in de declaratie verwerkt en zo ook voor als ze stonden ingeschreven op een werkplek. |
| Er is de mogelijkheid om declaraties te beheren | Goed | Voor beheerders is er de mogelijkheid om declaraties en alle toepasselijke gegevens aan te passen, te verwijderen of aan te maken. |
| Er is de mogelijkheid verlof aan te vragen | Goed | Gebruikers van het portaal kunnen op de verlof pagina een overzicht zien van van hun huidige verlof aanvragen en hier ook een nieuwe aanvraag doen. Hierbij wordt er automatisch uitgerekend hoeveel verlofuren ze dit zou kosten. |
| Er is de mogelijkheid verlof aanvragen goed/af te keuren | Neutraal | Gebruikers met de rol Product owner of Lead link kunnen in het portaal verlof aanvragen goed keuren op dezelfde manier en volgoorde die JDI ook gebruikt op moment. Bij een aanvraag moet deze eerst goedgekeurd worden door een PO en vervolgens door een LL en dan is deze geaccepteerd, als een PO of LL een aanvraag doet hoeft alleen een LL dit goed te keuren. Op moment is er alleen een bekende bug waardoor het menu waarin ze deze aanvragen kunnen zien en goedkeuren verborgen is voor alle niet beheerders en dus ook PO's en LL's, de functionaliteit is er echter wel. |
| Het product bevat geen bugs | Neutraal | De enige bug die op moment bekend is, is het verborgen menu voor niet beheerders waardoor verlof aanvragen niet goedgekeurd kunnen worden tenzij de PO's en LL's ook beheerders zijn. |
Tabel 8: kwaliteitsoordeel eindproduct
Ik vind dat de kwaliteit van het eindproduct erg goed is, alle bovengenoemde punten zijn voldoende of beter. Alle wensen van de opdrachtgever zijn behandeld op een slack koppeling toevoegen na, hier had de opdrachtgever zelf al vroeg over aangegeven dat dit een heel erg optioneel deel was en meer een extra als er tijd zou zijn. Verder is de enige bug die functionaliteit breek die van het verlof keuren, deze kan echter heel simpel opgelost worden als hier wat tijd voor zou zijn.
4. Projectmethode
De projectmethode die wij hanteerde was Scrum, Scrum is een agile softwareontwikkelmethode, dat wil zeggen dat er in sprints gewerkt zal worden. Bij Scrum wordt er ook incrementeel gewerkt, dit betekend dat elke sprint een onderdeel volledig wordt uitgewerkt met documentatie, tests en functionaliteit. Hierdoor krijg je bij elke sprint een opleverbaar product dat elke sprint groeit. Per sprint zijn er een paar use cases gepakt en uitgewerkt, zo heeft de opdrachtgever ook een duidelijk beeld van wat ze die sprint kunnen verwachten. Ook maakte we gebruik van bepaalde Scrum ceremonies zoals; de daily standup, deze deden we elke dag om 9:30, soms is er ook gekozen in de middag nog een kleine standup te doen. Ook hebben we gebruik gemaakt van sprint planningen om de volgende sprint in te delen op basis van de tijden die uit onze planningspoker kwam. Verder hebben we ook een sprint retrospective gehouden na elke sprint om terug te kijken naar wat goed ging, wat beter kon en waar we mee moesten stoppen. Tot slot hebben we ook nog gebruik gemaakt van sprint reviews waarbij we de opdrachtgever lieten zien wat we die sprint af hebben gekregen, wat niet af was en wat we de volgende sprint wouden gaan doen.
Ik vind dat dit project goed gebruik hebben gemaakt van wat Scrum ons aanbood, de daily standups waren handig om iedereen op een lijn te krijgen over wat iedereen aan het doen was. De sprint planningen zorgde ervoor dat de sprints goed ingepland konden worden, het kwam natuurlijk wel voor dat we soms net iets te veel taken hadden opgenomen maar het is ook lastig schatten. De sprint retrospectives hielpen erg om te leren van wat goed ging en wat niet zodat we dit de volgende sprint konden aanpassen en hierdoor beter konden werken. Tot slot de sprint reviews waren goed om aan de opdrachtgever aan te tonen wat er gedaan was en wat het plan was voor de volgende sprint. Doordat het incrementeel was hadden we ook elke sprint iets om te laten zien aan de opdrachtgever wat voor hun ook een stuk fijner is dan hoe het werkte bij de RUP methode van ISE-P.
5. Rol
Tijdens het project had ik samen met Connor de rol kwaliteitsmanager dit is uiteindelijk erg goed uitgekomen aangezien ik vooral aan de backend en database werkte en Connor aan de frontend, zo had elk sub systeem zijn eigen kwaliteitsmanager. Tijdens het project heb ik mij buiten mijn eigen bijdrage aan het programeren en documenteren ook bezig gehouden met het zorgen dat alles van goede kwaliteit was. Ik heb veel documenten doorgelopen om deze te controleren en heb ook aardig wat pull requests gereviewed, ik kan natuurlijk niet alles nakijken dus als iemand anders dit deed zouden zij zich houden aan de kwaliteitseisen en definition of done die ik heb geschreven en zijn opgenomen in het PvA. Ook heb ik me bezig gehouden met wat feedback toepassen die we tussentijds onvangen hadden van onze procesbegeleider.
Situatiebeschrijvingen:
In week 1 had ik in het PvA het hoofdstuk 'Op te leveren producten en kwaliteitseisen' geschreven als kwaliteitsmanager, hier hadden we na het assessment van het PvA feedback op gekregen van de procesbegeleider. Vervolgens ben ik deze aan gaan passen om ervoor te zorgen dat deze beter geformuleert, meer concreet en meer toepasselijk en meetbaar zouden zijn. Na het aanpassen liet ik andere team leden het zien om te vragen of het zo beter was en ze waren hier tevreden mee, dit was fijn want nu wist ik dat ik ze goed verbeterd had. Nu hadden we dus beter opgestelde proces en kwaliteitseisen en was het voor de rest duidelijk waar iets aan moest voldoen als zij dit zouden reviewen.
Tijdens sprint sprint 3 had Thijmen een pull request aangemaakt voor de functionaliteit gebruikers lijst ophalen. Ik ben deze pull request gaan nakijken om te bepalen of hij van voldoende kwaliteit was. Omdat er een paar stukjes code in stonden die terwijl hij aan het programeren was veranderd waren moesten die delen ook aangepast worden in zijn pull request om ervoor te zorgen dat er geen niet werkende code op de develop kwam. Ook werd er in een van de functies het wachtwoord mee opgehaald, deze was voor deze functie niet van belang dus ook daar liet ik een comment over achter. Thijmen zag dat ik de comments had achter gelaten en was aan de slag gegaan met het aanpassen, toen dit gedaan was keek ik er weer overheen en vond ik een verandering die bestaande functionaliteit in de knoop zou kunnen brengen dus ook hier liet ik een comment over achter. Hier kreeg ik vervolgens een reactie op die mij gerust stelde en vervolgens kon het dus gemerged worden. Nu hadden we dus een voldoende stuk code die goede functionaliteit toevoegde en niks anders in de problemen bracht.
Tijdens het uitvoeren van mijn rol heb ik geleerd om soms iets zorgvuldiger te kijken na het werk dat ik na kijk en ook niet te vergeten de code ook zelf te runnen om te kijken of het bij mij ook goed gaat, dit deed ik soms wel soms niet. Voor een volgende keer kan ik hier dus beter op letten.
Deze rol past best goed bij mij vind ik zelf, ik vind het vaak wel leuk om werk na te kijken en ben er ook wel redelijk zorgvuldig in. Ook ben ik zelf soms wel een beetje een perfectionist als het gaat om dingen gelijk en consistent krijgen dus dit kan soms ook hiermee helpen.
6. Competenties
6.1 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).
De eerste stap voor het ontwerpen van de database, de datastructuur achter de hele applicatie, was een CDM opstellen. Deze heb ik samen met de hulp van Niels gemaakt. Ik heb vervolgens in het SDD het data ontwerp voor de database gemaakt, hierin is het PDM opgenomen met tabel beschrijvingen en per kolom een omschrijving. Ook zijn hierin de design decision opgenomen die ik heb gemaakt bij het opstellen van de uiteindelijke versie van de database. Omdat we incrementeel werkte is de database niet in een keer volledig afgerond, deze is door de loop van het project meerdere malen aangepast (PDM op 29-04-22, PDM op 09-06-22).
6.2 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.
6.3 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.
7. Leerdoelen
7.1 Leerdoel 1: Duidelijker aangeven aan de groep waar ik aan werk.
7.2 Leerdoel 2: Optijd aanwezig zijn op locatie.
8. Conclusie
9. Bronnenlijst
https://specials.han.nl/sites/studiecentra/auteursrechten/bronnen-vermelden/apa-normen/
10. Bijlage
10.1 Factsheet
10.2 AIM controlekaart
CONTROLEKAART DOCUMENTEN_
Een document dient aan alle onderstaande criteria te voldoen.
Algemeen
1. Het document is op tijd en op de juiste plek en wijze ingeleverd.
2. Het document oogt netjes (geen verspringend lettertype, geen rommelige vormgeving en geen
onleesbare stukken tekst).
3. Het document is voorzien van een titel, studentnaam of -namen (alfabetisch geordend),
studentnummers, klas, groepsnummer, docentnaam of -namen, datum, course/semestergegevens en
versienummer.
4. Het document is voorzien van een inhoudsopgave en paginanummers.
Opbouw
5. Het stuk is opgebouwd uit hoofdstukken, paragrafen en alinea’s. Het document bevat in ieder geval
een inleiding, kerntekst en conclusie.
6. Bijlagen, plaatjes en tabellen hebben een naam en een nummer en zijn een zinvolle aanvulling op de
hoofdtekst.
7. Er is sprake van APA-bronvermelding en er is een APA-literatuurlijst aanwezig.
Stijl, spelling en grammatica
8. Het document is doelgericht geschreven en in de schrijfstijl is rekening gehouden met de doelgroep.
9. Vervoegingen van werkwoorden zijn correct gespeld. Er staan maximaal drie foutief gespelde
werkwoorden op een willekeurige pagina.
10. Woorden zijn correct gespeld. Er staan maximaal drie foutief gespelde woorden op een willekeurige
pagina.
11. Het document is in de actieve vorm geschreven. Het bevat nagenoeg geen lijdende zinnen.