...
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. Het 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. Als ik terug kijk naar wat wij hebben op kunnen leveren als PvA ben ik daar best tevreden over. Er zijn zeker een aantal punten, zoals het kunnen aanscherpen van wat we gaan opleveren in hoofdstuk 6. Daarnaast hadden we ook meer tijd moeten nemen om de afspraken binnen onze groep aan te scherpen.
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.
...