...
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) | 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 zal is het Google Distance Matrix API Onderzoek zijn.
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) | 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 12: 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) | 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) | 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 24: 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.
...
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) | 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
4. Projectmethode
...
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.