Hedendaagse statische analysetools zoals SonarQube kunnen veel betekenen op het gebied van kwaliteitsverbetering van uw broncode. Bij een juiste inzet van deze tools wordt de introductie van nieuwe technische onderhoudbaarheidsrisico’s voor een belangrijk deel gemitigeerd, wat op lange termijn een grote besparing kan opleveren voor uw organisatie. Een groot nadeel van deze tools is echter dat de geconstateerde risico’s en overtredingen teveel toegespitst zijn op één, dan wel een beperkt aantal, technologie(ën)  en teveel technisch van aard zijn. Uw afdeling Risk Management zal vaak wel weet hebben dat deze tools worden ingezet, maar de toepasbaarheid van de tool voor hun is (waarschijnlijk) nihil. De reden hiervoor is dat de tools geen inzicht bieden in functionele risico’s.

De effectiviteit van zo’n analyse tool zou veel groter kunnen worden als naast de technische risico’s ook de functionele risico’s in kaart worden gebracht.

 

Wat heeft de functionele vraag met de broncode te maken?

 

Wat als je uitgaat dat een stuk technische broncode feitelijk niets anders is dan een implementatie van een functionele vraag? Dan zou je dus mogen concluderen dat functionele risico’s afgeleid kunnen worden op basis van technische risico’s? Het antwoord op deze vraag is: ja, en heel goed ook.

Maar waarom zou je functionele risico’s in kaart willen hebben? De volgende vijf antwoorden zijn ondermeer te geven:

  1. Omdat de gebruiker denkt en praat in functionele termen en niet in technische termen;
  2. Wijzigingsverzoeken zijn bijna altijd functioneel van aard. “De gebruiker wenst…”;
  3. De impactanalyse van een Request For Change (RFC) kan veel beter worden ingeschat als de RFC-behandelaar beschikt over feiten die gerelateerd zijn aan de broncode die geraakt wordt in het wijzigingsverzoek;
  4. De kwaliteit van een technisch aanpassing kan achteraf bij een vervolgmeting worden gecontroleerd door de functionele wijziging te volgen en af te zetten tegen de verwachte impact. Met andere worden, de cirkel is rond: je verwacht een bepaalde impact op een RFC, de RFC wordt geïmplementeerd en je controleert daarna of jouw inschatting al dan terecht is geweest. Hoe lerend kun je zijn als organisatie?
  5. Klanten die het beheer van hun systeem hebben uitbesteed, willen heel graag de kwaliteitsontwikkeling van hun systeem volgen maar hebben de technische kennis niet in huis oftewel: de leverancier geeft geen transparantie en openheid.

Het zou dus mooi zijn als je beschikt over een tool waarin het mogelijk is meerdere technologieën in onder te brengen en de broncode zodanig weet te visualiseren dat ook de eindgebruiker een functionele blik op het systeem krijgt.

 

Hoe helpt dit de kloof tussen eindgebruiker en techneut te dichten?

 

Is zoiets te realiseren en hoe werkt zoiets in de praktijk? Ja: vanuit mijn ervaring kan ik aangeven dat dit zeker te bewerkstelligen is. Hierbij zijn de verschillende partijen betrokken en de volgende stappen kunnen genomen worden:

  • de afdeling Functioneel Beheer stelt een lijst op van alle functionele componenten die in het systeem zijn ondergebracht
  • De afdeling Development stelt een lijst op van alle technische componenten die in het versiebeheer zijn ondergebracht;
  • Beide lijsten worden via een koppeling aan elkaar gerelateerd. Dat is een handmatig proces waarvoor het noodzakelijk is dat beide partijen om de tafel gaan zitten.
  • De uitkomst van de koppeling wordt in de tool ingeregeld en de kwaliteitsmeting wordt uitgevoerd.

Hiermee is het mogelijk om de klassieke kloof tussen eindgebruiker en techneut te overbruggen. Aan de tool wordt wel als eis gesteld dat zij heel veel technologieën moet ondersteunen (van klassieke programmeertalen tot workflow, 4GL’s, document generatoren, etc.) en tot in hoge mate inregelbaar moet zijn.

Dan en slechts dan is deze kloof te overbruggen en kan de som “1 + 1 = 3” worden gemaakt!

Vragen? Neem contact met ons op. 

 

 

Share This