...

Ik heb het testrapport in elkaar gezet. Het testrapport bevat alle tests die wij in onze applicatie hebben. Terwijl ik bezig was met dit product, wilde ik eigenlijk graag een tussentijdse review hebben, aangezien ik niet helemaal wist of ik dit op de goede manier aan het aanpakken was. Dit werd helaas niet gedaan tot aan 3 dagen voor het inleveren, waarbij alleen Martin eroverheen had gekeken. Het document herhaalt veel tekst, waardoor het onnodig voelt. De testen zijn kort uitgelegd, maar bevatten wel de basiselementen om te kunnen omschrijven wat de test doet.  Het document mag ook meer introductie bevatten over wat het precies inhoudt. Wel vind ik het fijn dat er nog definitief wordt gezegd dat de test echt geslaagd is, zodat het in een overzicht is te zien. In dit project hebben wij ervoor gekozen om niet een testplan te maken. Hiervoor is gekozen, omdat de testen in het begin van ons project nog te onduidelijk waren en zodra we wisten hoe deze testen werden uitgevoerd, konden we alle testen al vrij snel maken. Het testplan was wel handig geweest als richtlijnen voor welke testen er plaats zouden vinden. 
Het document is in correct Engels geschreven. In het plan van aanpak staat als criteria voor het testrapport dat de database ook getest moet zijn, dit is alleen niet het geval. Hierdoor kan ik dus zeggen dat dit product niet voldoet aan de criteria die ik zelf had opgesteld en schiet het product dus te kort.

Eindproduct

Zoals te zien in In het PvA bij de definition of done en de op te leveren producten en kwaliteitseisen zijn de eisen te zien die we hebben opgesteld voordat het project begon. Deze eisen moeten zorgen voor een goed eindproduct. Voor Regterschot leveren wij de gebouwde applicatie en gerelateerde documenten in. Alle documenten die naar Regterschot Racing gaan zijn in het Engels geschreven. Het proces om deze producten te maken begon traag. In de eerste periodes konden we onze draai niet vinden. Dit zorgde voor veel vertraging en onduidelijkheid over wat de opdracht was. Tijdens de tussentijdse beoordeling was duidelijk te zien dat we het niet goed deden. Dit zagen we gelukkig allemaal in en begonnen met een plan om dit te verbeteren. We hebben het SRS en het SDD geüpdate, zodat het klopt met de wensen van Regterschot. Nadat dit verbeterd was, begonnen we met coderen. Door dit SRS en SDD goed te hebben, hadden we een duidelijke visie over hoe we het coderen moesten aanpakken en wat er in de code moet. Het SDD en SRS bevatten alle benodigde activiteiten om aan het product te komen.. De database was ook vaak veranderd, dit kwam omdat dat deel van het SDD nog niet goed genoeg was. Hierdoor verloren we ook weer tijd. Gelukkig hebben we dit wel opgelost, zodat de code goed werkt met de database. De database mist nog testen om te kijken of alles goed gaat met de database. Hierdoor voldoet de database niet aan de eis in het plan van aanpak. 

Zoals eerder gezegd komt ons project op minimaal 80% code coverage, waardoor we de applicatie reliable kunnen noemen. De front- en backend zien er beide gestuctureerd uit. De frontend kan visueel er nog beter uitzien, maar de stijl van de website maakte onze opdrachtgever niet uit. Daarom hebben we bewust de keuze gemaakt om ons te focussen op een werkende front- en backend. De data die wordt weergegeven van de grafieken komt nu nog te langzaam binnen. Ons originele plan was om dit twintig keer per seconde te doen, maar dit is nu twee keer per seconde geworden. Dit komt doordat de broker veel eist van de prestatie van het systeem. Ik vind het wel jammer dat dit niet sneller is en we hadden als team meer moeten helpen bij dit stukje code om dit opgelost te krijgen. Nou was er wel gezegd door onze opdrachtgever dat dit voor nu niet twintig keer per seconde weergegeven hoeft te worden op de website, maar dit kwam vooral omdat we anders de andere taken niet af zouden krijgen.

De backend code ziet er beter uit dan de frontend code. Dit komt vooral omdat we hier meer verstand van hadden. De backend is wel vaak aangepast, omdat het niet consistent was. Er waren packages met hoofdletters en zonder hoofdletters, functies kregen niet overal dezelfde naamstructuur als in andere klassen en er kwamen vaak klassen terug die verwijderd waren, omdat men in een oudere branch zat te werken. Dit zorgde wel voor wat vertraging, maar gelukkig niet veel vertraging. De backend is compleet en heeft overal op de login functie na, dezelfde structuur. De loginfunctie is hierbij de uitzondering, omdat deze klasse meer logica verreist.

Voor het opzetten van de code is door Martin nog een opzetdocument gemaakt. Het verteld hoe ons programma opgezet kan worden. Wel mis ik in dit document nog een uitleg over hoe IntelliJ gedownload moet worden. Dit is wel belangrijk voor iemand die coderen niet begrijpt. Naast dit punt vind ik de uitleg duidelijk genoeg. Ik heb dit zelf nog gereviewed en na dit reviewen had ik dus alleen nog het punt over IntelliJ kunnen vinden.

De API en de documentatie hierbij vind ik voldoende genoeg. De code is logisch opgebouwd en door unittests veilig gemaakt. De documentatie verteld in een lopend verhaal de werking van de code en de wensen van Regterschot.

Projectmethode

Het werken in een groepje op school via scrum werkt goed, als iedereen er is. In een groep kan er makkelijk een vraag worden gesteld en gelijk beantwoord, waardoor je sneller verder kan werken met waar je mee bezig was.
Door daily standups kan je horen wat andere teamgenoten gaan doen op een dag en hoe lang dat nog gaat duren Tijdens het project hebben we ook bijna elke ochtend een daily standup gehouden. De uitzonderingen hierop waren de begin van de sprints, waarbij er nog geen nieuwe taken waren. Door de daily standups kun je eventueel hulp aanbieden als ze te lang bezig zijn met een taak. Dit hoort allemaal bij de scrum-methode.
De bedoeling van scrum is dat je via iteratief werken (zie figuur 1), langzaam op een optimaal product komt. Voordat een sprint start, is het de bedoeling dat er een backlog wordt gemaakt waar alle mogelijke taken in voort komen. Een paar van deze 
taken worden vervolgens in de sprint planning uitgekozen en gaan mee de sprintbacklog in. Tijdens deze sprint werkt elk individueel teamlid aan een taak, totdat dit klaar is om gereviewed te worden. Als team hebben wij afgesproken om twee
leden te laten reviewen, voordat een taak naar done gaat. Na de sprint houden wij een sprint review met onze opdrachtgever, om hem te vertellen wat we gedaan hebben en wat hij nog zou willen zien. De eerste keer ging deze review nog
redelijk traag en wisten we nog niet goed wat we wilden vertellen. Hierdoor hebben we de afspraak gemaakt om de review 3 dagen van te voren al uit te werken, zodat Regterschot Racing snel en duidelijk kan zien wat er gedaan is.

...