Contemporary static analysis tools such as SonarQube can be significant in terms of quality improvement of your source code. With the proper use of these tools, the introduction of new technical maintenance risks is largely mitigated, which can yield significant savings for your organisation in the long term. However, a major disadvantage of these tools is that the identified risks and violations are too focused on one, or a limited number of technologies and are too technical in nature. Your Risk Management department will often be aware that these tools are being deployed, but for them the applicability of the tool is (probably) nil. The reason for this is that the tools do not provide insight into functional risks.
The effectiveness of such an analysis tool could be much greater if, in addition to the technical risks, the functional risks are set out.
What has the functional question to do with the source code?
What if you assume that a piece of technical source code is nothing more than an implementation of a functional question? Then you might conclude that functional risks may be derived on the basis of technical risks? The answer to this question is: yes, and quite rightly so too.
But why would you want to map out functional risks? The following five answers may be given:
- Because the user thinks and speaks in functional terms and not in technical terms;
- By nature, change requests are almost always functional. “The user wishes…”;
- The impact analysis of a Request For Change (RFC) may be estimated much better if the person handling the RFC has facts related to the source code affected by the change request;
- The quality of an technical adjustment may be monitored retrospectively with a follow-up measurement by monitoring the functional change and setting it off against the expected impact. In other words, the circle is completed: you expect a certain impact on an RFC, the RFC is implemented and afterwards you check if your estimate has been correct. As an organisation, how learning can you be?
- Customers who have outsourced their systems’ management are keen to monitor the quality development of their system but do not have the in-house technical knowhow i.e: the supplier does not provide transparency and openness.
So it would be nice if you could have a tool in which it is possible to store multiple technologies and to visualize the source code such that the end user also gets a functional look at the system.
How does this help close the gap between the end user and the techie?
Can this be achieved and how does such a thing work in practice? Yes, from my experience, I can say that this is definitely achievable. In doing so, the various parties are involved and the following steps may be taken:
- The Functional Management department draws up a list of all functional components that are stored in the system.
- The Development department draws up a list of all technical components that are stored in the version control.
- Both lists are related to each other via a link. This is a manual process for which it is necessary that both parties get round the table together.
- The result of the link is set into the tool and the quality measurement is conducted.
In this way the classical gap between the end user and the techie is bridged. The tool is required to support many technologies (from classic programming languages to workflow, 4GLs, document generators, etc.) and must be highly adjustable.
Then and only then can this gap be bridged and the sum “1 + 1 = 3” be made!