Product evaluatie Plan van aanpak

Het plan van aanpak is in de eerste weken van het project opgesteld. Ik ben zelf tevreden over het plan van aanpak. De fasering en planning gaven mij houvast in de voortgang van het project. De huidige situatie beschrijving heeft echter nog een herziening nodig gehad. Dit kwam doordat de toegang tot de ISMetadata tool voor nieuwe en duidelijkere inzichten zorgde. Een risico, dat ik over het hoofd heb gezien, was de beschikbaarheid van de

opdrachtgever. Dit risico is tijdens het project wel tot uiting gekomen. Voor een vervolg project zal ik dit risico zeker meenemen. Ook wil ik in het plan van aanpak de contact frequentie vastleggen met de opdrachtgever. Op deze manier is zowel voor mij als de opdrachtgever een duidelijke overeenkomst over de contact uren. Verder heeft het plan van aanpak geholpen om de organisatie omtrent het project vanaf de start duidelijk te hebben. Het plan van aanpak was dus een goede overeenkomst tussen mij en de opdrachtgever.

Onderzoekrapport

Het onderzoek is een document waar ik minder tevreden over ben. Met het onderzoek bracht ik de visualisatie vorm naar voren. Ook heb ik bestaande software en code library’s bekeken. Doordat ik later in het project de afhankelijkheid met ISMetadata ontdekte had ik pas laat toegang had tot de tool en waren de resultaten niet passend bij de metadata in deze tool. Hierom heb ik heb onderzoek moeten aanpassen om wel een passend advies te kunnen geven.

Naar mijn mening had de visualisatie vorm bepaald kunnen worden met een requirements analyse. Door met de stakeholders brainstorm sessies te houden kan de visualisatie vorm worden bepaald. Dit zeker omdat door de toegang tot ISMetadata de mogelijkheden van de metadata duidelijk worden. Ook heeft het uitzoeken van

bestaande software geen resultaat geboden. Tijdens de eerste resultaten had ik gezocht naar software die data flow in een diagram konden plaatsen, dit gaf geen resultaat. Nadat ik de ISMetadata metadata had geanalyseerd was het duidelijk dat het zoeken naar de wijze waarop ETL tools de data flow weergeven een beter idee had geweest. De metadata beschreef op conceptueel niveau de data flow. Later moet het mogelijk zijn om deze conceptuele data flows om te zetten met een tool zodat er een SSIS package wordt gegenereerd. Wel komt er uit het onderzoek duidelijk naar voren dat er geen bestaande oplossing is voor het visualiseren van de ISMetdata metdata. Het uitzoeken van een geschikte code library had zonder onderzoek kunnen worden gedaan. Zodra de requirements duidelijk zijn kan er een overwogen keuze worden gemaakt over bruikbare code library’s.

Mijn conclusie is dat een uitgebreidere requirements analyse had kunnen zorgen voor een bruikbare visualisatie vorm, hierbij had geleerd kunnen worden van bestaande ETL tools en de wijze waarop deze de data flow

visualiseren. Verder had na de requirements op te stellen er een duidelijk beeld geweest van de software waardoor er een overwogen code library keuze had kunnen worden gemaakt.

Requirementsrapport

Het requirementsrapport is een document waar ik tevreden over ben. De requirements zijn verkregen tijdens het onderzoek, de brainstormsessie en de opdracht omschrijving. Hierna zijn de requirements geprioriteerd aan de hand van de MoSCoW methode. Hierdoor ontstaan er duidelijke afspraken over de te maken software. De sessies waarbij de eisen naar voren komen waren goed voorbereid en gaven daarom een nuttig resultaat. Voor een volgend project zou ik enkel meer stakeholders willen spreken over de requirements, zodat er een beeld ontstaat van de applicatie geschetst door meerdere stakeholders.

Functioneel ontwerp

Over het functioneel ontwerp ben ik tevreden. De schermontwerpen zijn gebaseerd op de tekeningen van de brainstormsessie gecombineerd met de gekozen visualisatie vorm. Met deze scherm ontwerpen heb ik voor de opdrachtgever een gebruiksvriendelijke data flow visualisatie kunnen maken. Verder hebben de use case beschrijvingen mij ondersteund in het uitwerken van de requirements. Bovendien hebben de beschrijvingen als goede basis voor de logische en fysieke testcases kunnen bieden.

Technisch ontwerp

Het technisch ontwerp ben ik ook tevreden over. De gemaakte klassendiagrammen hebben mij geholpen tijdens de constructionfasen. Hierbij had ik een duidelijke houvast aan de architectuur, die ik had ontworpen. Ook ben ik blij dat ik de documentatie van de ISMetadata database tot mijn beschikking had. Het ontwerpen van de verschillende query’s was hierdoor versimpeld. Dit kwam omdat de structuur was beschreven in het klassendiagram voor de ISMetadata database. Ik vond het nuttig om deze voor de volledigheid ook op te nemen in het technisch ontwerp. Ik heb hier later veel aan gehad omdat ik hier snel kon bekijken op welke manier de database in elkaar zat. Verder hebben de sequentiediagrammen ervoor gezorgd dat de belangrijke volgordelijkheid van methode duidelijk wordt. Dit was vooral handig tijdens het debuggen in de construction fase. Ook kon ik met de klassendiagrammen en sequentie diagrammen ingewikkelde concepten uitleggen aan de code reviewer.

Data flow visualisatie module

Ik ben gedeeltelijk tevreden over de data flow visualisatie module. Ik ben tevreden over de kwaliteit van de code achter de module. Dit omdat door herhaaldelijk te code reviewen zijn de standaarden toegepast en konden onverwachte uitkomsten worden opgelost, maar ook door een goed ontwerp dat als basis heeft kunnen dienen. Op deze manier heb ik een object georiënteerde applicatie kunnen programmeren. Hierdoor is de code duidelijk leesbaar en onderhoudbaar geworden. Ik vind het jammer dat ik niet meer functionaliteiten heb kunnen toevoegen. Door tijdsgebrek en uitloop, de afhankelijkheid van ISMetadata en tijdsgebrek bij de requirements, in het begin van het project heb ik overeengestemd met de opdrachtgever om minder functionaliteiten te bouwen. Ik had graag een helemaal afgewerkte module achtergelaten. De module is nu nog niet klaar voor gebruik en dit vindt ik jammer. Echter is er in de toekomst misschien nog mogelijkheid tot het uitbouwen van de applicatie, zodat alle gewenste functionaliteiten erin verwerkt zijn.

Testrapport

Over het testrapport ben ik redelijk tevreden. Door het gebruik van een realistische testomgeving geven de resultaten een betrouwbaar beeld van de applicatie. Ook hebben de unit tests eraan bijgedragen dat de kwaliteit van de code gewaarborgd is. Verder heb ik met gebruikersscenario’s de requirements kunnen testen. Ook verwachte in- en uitvoer tests zorgen ervoor dat de data flow visualisatie kloppend is met de achterliggende data. Het verbeterpunt, dat ik zie voor het testen, is het uitvoeren van een FAT en GAT met meerdere stakeholders. Hiermee kunnen de kwaliteitsattributen worden vastgesteld door meerdere stakeholders. Op deze manier kunnen de uitspraken over deze kwaliteitsattributen geldig worden beschouwd voor alle stakeholders. Dit omdat

bijvoorbeeld gebruiksvriendelijkheid door iedereen anders kan worden ervaren. Met de hulp van meerdere stakeholders kan je dan beter vaststellen of de gebruiksvriendelijkheid van de applicatie echt goed werkt.

12. Beroepstaken

In dit hoofdstuk worden de beroepstaken, die ik vooraf aan mijn afstudeeropdracht heb opgesteld om te behalen, beschreven. Hierbij geef ik per beroepstaak aan welke werkzaamheden ervoor hebben gezorgd dat ik deze heb uitgevoerd. Per beroepstaak geef ik aan welk hoofdstuk deze werkzaamheden beschrijven en welke bijlagen de resultaten van deze werkzaamheden bevatten.