...
Tijdens het maken van het PvA zijn er bij ons al snel een aantal vragen naar bovengekomen. Wat gaan we nou eigenlijk doen en wat is de opdracht eigenlijk precies? We hebben de vragen opgesteld voor een volgend gesprek terwijl we bezig zijn gegaan met andere dingen die ook zeker moesten gebeuren. Doordat we aan verschillende dingen konden werken hebben we daar niet hoeven te wachten op de antwoorden van onze vragen. In eerste instantie denk ik dat wij een goed PvA hebben neergezet. Voor mij was alles duidelijk en konden we ook daadwerkelijk wat met het PvA. In het PvA staat voor ons maar ook voor anderen duidelijk wat wij gaan doen en op welke manier. Ook staat er duidelijk aangegeven welke dingen wij bijvoorbeeld nodig hebben, zoals een lokaal waar we in ieder geval met het hele team kunnen zitten. Wij hadden als team grotendeels duidelijk wat er allemaal in stond en toch waren er een aantal kleine aanpassingen. Dit waren vooral kleine onduidelijkheden waar wij overheen hebben gelezen. Het uiteindelijke PvA (29/11/2022) is een goed product. Alles wat een PvA moet hebben staat er in en ook zijn alle aanpassingen die gedaan moesten worden zijn verwerktHet PvA is na onze oplevering terug gekomen met een paar kleine punten. Deze punten hebben we zo snel en goed mogelijk opgelost om tot het uiteindelijke PvA te komen.
Als ik kijk naar een PvA zijn er een aantal dingen die belangrijk zijn. Zo is het belangrijk om de opdrachtgever duidelijk te maken wat wij zien als opdracht en hoe wij het bedrijf van hen voor ons zien. Als hier fouten in staan kunnen deze zo snel mogelijk worden opgelost om uiteindelijk de opdracht duidelijk te krijgen. Ook is het belangrijk om de opdrachtgever vertrouwen te geven. Als een opdrachtgever bij een bedrijf een goed gevoel heeft dat hij daadwerkelijk krijgt wat hij verwacht dan is hij vaak verzekerd genoeg om met dat bedrijf in zee te gaan. Ook is het belangrijk om aan de opdrachtgever duidelijk te maken wat wij als team nodig hebben. Het kan zijn dat wij bepaalde hard- en software nodig hebben om ons systeem te kunnen testen.
SRS
Het SRS is een belangrijk document bij het maken van een product als hier gestructureerd gewerkt wordt. Tijdens de uitleg deed mij een onderdeel hiervan wel verbazen. Tijdens deze opdracht is het eigenlijk de bedoeling dat tijdens het maken van het product het SRS (en SDD) wordt aangepast. Normaal zou je eerst het SRS (en SDD) maken en daarna aan de hand daarvan gaan programmeren, in plaats van een stukje SRS maken en dat gelijk implementeren. Het is natuurlijk wel zo dat dit soort bestanden tijdens een project veranderen en aangepast worden. De gebruiker kan bijvoorbeeld toch iets er bij willen of wil iets net even wat in elkaar hebben zitten. Dit geeft als resultaat dat er dingen aangepast moeten worden in bijvoorbeeld het SRS. Over de volledigheid van het SRS is momenteel niet veel te zeggen, aangezien deze nooit af zal zijn. Wel is het zo dat de onderdelen die er al zijn goed zijn voor zover ik zie. Als ik bijvoorbeeld kijk naar het domein model en de bijbehorende woordenlijst is deze compleet en is hier goed over nagedacht. Zoals al eerder aangegeven kan het zijn dat deze aan het eind van het project alsnog veranderd. Het maken van een SRS tijdens het programmeren, afwisselend waar je aan werkt kan ook problemen met zich mee brengen doordat je niet weet wat er nog meer moet komen. Het kan zo zijn dat het SRS compleet en goed is voor de eerste tien stukken code, maar dat door stuk elf veel aangepast moet worden. Om dit te voorkomen zou je misschien toch liever een compleet SRS hebben alvorens je gaat programmeren. Het is voor ieder van ons geen favoriet onderdeel, maar nodig.
...