Na het vastleggen van de processen in het Process Definition Document (PDD)<\/strong> en het goedkeuren van de To-Be<\/em>-situatie, begint de fase waarin visie wordt omgezet in uitvoering: Solution Design, Development en Testing<\/strong>. De Business Analyst waarborgt dat de oplossing blijft aansluiten op de zakelijke doelstellingen en bewaakt de kwaliteit van de requirements tijdens het ontwerp- en ontwikkelproces. Hij of zij:<\/p>\n\n\n\n In deze eerste stap wordt de To-Be<\/em>-situatie vertaald naar een technische oplossing. De Solution Architect maakt hierbij gebruik van het Solution Design Document (SDD)<\/strong>, waarin hij of zij beschrijft hoe de automatisering technisch wordt opgebouwd. Ook wordt in deze fase het Technical Testing Plan<\/strong> opgesteld, waarin testvormen als functionele tests, systeemintegratietests en UAT-scenario\u2019s worden gedefinieerd. In de ontwikkelfase worden de bouwblokken van de automatisering gerealiseerd. Belangrijke testmomenten:<\/strong><\/p>\n\n\n\n De Business Analyst ondersteunt deze fases door:<\/p>\n\n\n\n De output van deze fase omvat:<\/p>\n\n\n\n Veranderingen zijn onvermijdelijk. Voorbeelden van wijzigingsaanleidingen:<\/p>\n\n\n\n De Business Analyst beoordeelt elke wijziging op:<\/p>\n\n\n\n De KRAC-methodiek (Keep, Remove, Add, Change) helpt om wijzigingen te analyseren en te categoriseren. Het onderscheid is essentieel: bugs en defects worden binnen de testfase opgelost; changes kunnen op elk moment ontstaan en vereisen formele goedkeuring.<\/p>\n\n\n\n De Business Analyst speelt een cruciale rol in governance:<\/p>\n\n\n\n In kleine organisaties worden rollen vaak gecombineerd. Aan het einde van de Solution Design, Development en Testing fase liggen de volgende deliverables vast:<\/p>\n\n\n\n Deze output vormt de basis voor de volgende fase: User Acceptance Testing en Project Closure<\/strong>, waar de oplossing wordt overgedragen en geborgd binnen de organisatie.<\/p>\n\n\n\n Kerninzichten:<\/strong><\/p>\n\n\n\n Ontwerp, Ontwikkeling en Testfase Na het vastleggen van de processen in het Process Definition Document (PDD) en het goedkeuren van de To-Be-situatie, begint de fase waarin visie wordt omgezet in uitvoering: Solution Design, Development en Testing.In deze fase wordt het procesontwerp technisch vertaald naar een werkende automatisering, terwijl de Business Analyst de brug blijft tussen […]<\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"class_list":["post-327","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/327","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=327"}],"version-history":[{"count":1,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/327\/revisions"}],"predecessor-version":[{"id":328,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/327\/revisions\/328"}],"wp:attachment":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=327"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
In deze fase wordt het procesontwerp technisch vertaald naar een werkende automatisering, terwijl de Business Analyst de brug blijft tussen business en techniek.<\/p>\n\n\n\n
\n\n\n\nDe rol van de Business Analyst in deze fase<\/strong><\/h4>\n\n\n\n
\n
\n\n\n\n1. Solution Design \u2013 Van proces naar blauwdruk<\/strong><\/h3>\n\n\n\n
De drie belangrijkste rollen zijn:<\/p>\n\n\n\n\n
Daarnaast wordt de Application Access Tracker<\/strong> ingevuld \u2014 een document waarin alle toegangsrechten, testomgevingen en accounts worden vastgelegd die nodig zijn voor ontwikkeling, test en productie.<\/p>\n\n\n\n
De output van deze fase bestaat uit:<\/p>\n\n\n\n\n
\n\n\n\n2. Development & Testing \u2013 Van ontwerp naar realisatie<\/strong><\/h3>\n\n\n\n
De ontwikkelaars gebruiken het PDD en het SDD als leidraad voor de configuratie van de robotmodules.<\/p>\n\n\n\n\n
\n
\n
\n\n\n\n3. Change Management \u2013 Het beheersen van wijzigingen<\/strong><\/h3>\n\n\n\n
Een change<\/strong> is elke aanpassing aan de eerder goedgekeurde requirements in het PDD die niet voortkomt uit een fout (bug<\/em>) of defect.<\/p>\n\n\n\n\n
\n
Na goedkeuring wordt de wijziging gelogd in de Traceability Matrix<\/strong>, en wordt het PDD bijgewerkt met een stap-voor-stap beschrijving van de wijziging.<\/p>\n\n\n\n
\n\n\n\n4. Verschil tussen bugs, defects en changes<\/strong><\/h3>\n\n\n\n
Type<\/th> Beschrijving<\/th> Tijdstip van ontdekking<\/th> Actie<\/th><\/tr><\/thead> Bug<\/strong><\/td> Fout in de code die afwijkend gedrag veroorzaakt<\/td> Tijdens testen<\/td> Developer corrigeert code<\/td><\/tr> Defect<\/strong><\/td> Functionele afwijking van de requirements<\/td> Tijdens testen<\/td> Wordt opgelost via testcyclus<\/td><\/tr> Change<\/strong><\/td> Nieuwe of gewijzigde requirement<\/td> Elk moment in het traject<\/td> BA beoordeelt en logt wijziging<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n5. Governance en communicatie<\/strong><\/h3>\n\n\n\n
\n
Zo kan de Solution Architect ook optreden als Developer en de Business Analyst als Tester.
Wat echter niet mag verdwijnen, is de documentatie \u2014 ook in kleinere teams moeten het PDD, de SDD en de testplannen worden bijgehouden om kwaliteit, herhaalbaarheid en overdraagbaarheid te waarborgen.<\/p>\n\n\n\n
\n\n\n\n6. Resultaat van deze fase<\/strong><\/h3>\n\n\n\n
\n
\n\n\n\n\n