Mendix Best Practices on Github: Omnext calls upon the Mendix community

Mendix Best Practices on Github: Omnext calls upon the Mendix community

02-05-2017 – VEENENDAAL – In order to be of even better service to the Mendix community and to also make better use of their expertise, Mendix Best Practices have been published on GitHub by Omnext. A complete list (constantly supplemented by users themselves) provides a fully up-to-date platform for quality analysis: the Fit Test 4 Mendix.

Source code analyst Omnext has spent the past year on the Fit Test 4 Mendix: the analysis platform that analyses and preserves the quality of Mendix applications. A large part of this quality is the ISO guideline for software quality, but because of the modelling properties of Mendix, the Best Practices play at least as big a role in this.

In this way, GitHub is used for its intended purpose: deploying the widely acclaimed close community (of Mendix) for product improvement and innovation. The members of the Mendix community indeed know best what is going on within their development environment. By making Best Practices accessible through GitHub, the Fit Test can be improved and the results are even better applied.

Omnext aims to contribute to improving the quality and maintainability of all Mendix applications and realizes that this can only be done by calling on the community. Everyday violations should be easily detected and prevented. Through the collection and qualification of the Best Practices by our Mendix partners, the Fit Test 4 Mendix can provide the most added value. You can find the link to GitHub here: https://github.com/Omnext/omnext.github.io

Will you support the community to improve quality in Mendix applications?

Look on www.omnext.com or https://github.com/Omnext/omnext.github.io contact Bryan de Vries (Omnext), mobile +31(0) 6 34 735 375 for more information.

 

 

1+1=3!

1+1=3!

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:

  1. Because the user thinks and speaks in functional terms and not in technical terms;
  2. By nature, change requests are almost always functional. “The user wishes…”;
  3. 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;
  4. 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?
  5. 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!

 

Frans van den Berg

Frans van den Berg

Principal Consultant

Frans is Principal Consultant at Omnext, specialising in source code analysis of software applications using Fit Testing and Stay Fit programs. Frans has extensive experience in evaluating the quality of software systems including applications of government agencies and financial institutions.

Any questions? Then please contact Frans.