...
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 reiskostenvergoedingen en verlof, zij . 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 haddenhebben, 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.
...
| 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. |
...
| 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. |
...
| 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 softwarestructuur 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 niet 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. |
...
| 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 wordt 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. |
...
| Kwaliteitseis | Beroordeling (goed, neutraal, matig, zwak) | Toelichting |
|---|---|---|
| Code is goed onderhoudbaar | Goed | De hoofdmethode 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, het is maar een unittest maar die loopt alle scenarios door. |
| Geen monster methodes die alles doen | Goed | De methode is opgedeeld in kleinere methodes die elk hun eigen ding doen. |
...
| 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 wil 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, dit zou echter een simpele fix zijn. |
...
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 betekendt 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 ons 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.
...
Tot slot nog het project als geheel. De projectgroep was erg fijn om mee te werken, de sfeer was erg goed en ik denk nog wel het beste van alle groepjes waar ik tot nu toe in heb gezeten. Er was een goede balans tussen serieus werken en ook nog wel wat grappen tussendoor maken. Ook de gezamelijke wandeling naar de Coop en de afsluiter aan het einde va nde van de dag hielpen hier ook wel echt mee. Zo had je een moment dat niet werkgericht was om toch een beetje te bonden. Ook de projectmethode waarmee we hebben gewerkt was erg fijn en paste goed bij het project in mijn ogen. Verder heb ik ditmaal ook mijn verslag wederom optijd af gekregen dus hopelijk ben ik nu wel klaar met het project (op de assessment na).
...