...
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
...
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
...
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
...
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
...
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
...
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
...
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
...
| 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 78: kwaliteitsoordeel eindproduct
...
De eerste stap voor het ontwerpen van de database, de datastructuur achter de hele applicatie, was een CDM opstellen. Deze heb ik samen met behulp de hulp van Niels gemaakt. Ik heb vervolgens in het 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 deze niet gelijk volledig gemaakt, de database is meerdere keren aangepastde 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.
...