Methods, Tools and Approaches for Source Code Analysis and Quality
Alexander Lipanov, PhD in Computer science, Softarex Technologies, Inc.
Why do we need to keep software on a high quality level?
If you ask any person involved in software development, whether it is important to keep quality of software high, you will get a quite predictable answer: “Yes, certainly.” At the same time, if we take a look at real projects and examine how software is being developed, how the process of finding and fixing bugs is organized, and how concerned the Top Management is with the quality of the development process – we will see a completely different situation. In practice, it turns out that the importance of this issue is often neglected.
Software Quality and its influence on business
What is software quality? When software quality is good, it is invisible. And clearly evident when it’s bad. One of the key components of any company‘s success is the understanding of the importance of software quality. If we take a close look at the processes associated with software development and with software quality in particular, there appears to be an interesting dependency. The more attention a company pays to the software quality management, the greater benefits it receives in business. It should be noted that these benefits are associated with certain software quality characteristics. Actually, there is only one benefit – to increase revenue and profits.
Usually, the following software quality characteristics are defined:
- Functionality: Meet your clients’ expectations
- Security: Keep all customers’ information safe
- Reliability: Maintain your client base and grow your revenue
- Performance: Grow your client base and decrease operating costs
- Support: Decrease maintenance costs, ownership costs, time-to-market
We would like to emphasize that good quality software creates a positive impression on its users, increases clients’ satisfaction and, as a result, gets the competitive advantage. But not always company management prefers to invest time and money into development tools for software quality improvement. Moreover, sometimes the situation is vice versa: companies are trying to save on quality. As a rule, this approach is shortsighted and leads to hidden costs and poor performance.
Creating a proper quality model with measurable and verifiable characteristics as well as implementing a necessary tool for software quality improvement are among the most important management goals.
Quality Target Point Approach
W. Edwards Deming, famous American statistician, once said that “without data (i.e. information) you are just another person with an opinion”. That is why to solve quality control problems we need a special approach that would take into account all the possible quality characteristics and give us a general measurable evaluation of software quality. So that we could use this information for business guidance.
It is obvious that a software product evolves gradually. Furthermore, almost all modern software development methodologies suggest to set special check points for each release or sprint that would meet stated quality characteristics. Typically, it is a specific list of software functions that must be implemented before a certain date. It is obvious that there should exist a certain time point when not only all planed functionality should be implemented, but also certain requirements to source code quality should be fulfilled.
There is a great diversity of approaches towards software quality control. We would like to present you our own internal one called the Quality Target Point approach.
What is QTP? A Quality Target Point is an abstract time point when a complete list of measurable quality characteristics is defined including the set of functions that must be implemented by this date.
Therefore, a Quality Target Point is a set of the following conditions:
- Values of Object Oriented Metrics ∈ [intervals of recommended values]
- Number of CISQ Measures violations → 0
- Source code volume is minimal and provides all necessary functionality. At the very least, the source code does not have duplications
- Number of defects in functionality conforms to planned values that allows customers use the system
- Quality Target Point has exactly defined date
Quality Target Point Parameters and its measures
It is up to developers to set Quality Target Point parameters. The main condition is that all set parameters must describe all functional and structural quality characteristics and be clearly measured. We advise you to include the following groups of characteristics: functional requirements, software source code architecture, source code volume, non-functional requirements. Each of these groups contains a measurable set of parameters.
As you can see, a Quality Target Point contains a large set of parameters, and what is more important, this set can be adjusted to suit a specific project or development team.
Nevertheless, we can offer a common approach to the Quality Target Point representation as an N-dimensional space. Each axis of this graph corresponds to a certain parameter from the table on the right. To make the display on axes easy, we can normalize the metrics values for a certain interval, as a result all parameters will be in the same range of values, for example [0.1] or [1.10].
You should also define a certain area, a range of values for each QTP parameter. When the range of values is achieved, it is sufficient to consider that the required level of software quality for this QTP was reached.
QTP Base parameters
Only measurable parameters that reflect functional and structural quality of the product should be added to QTP. Conventionally, these parameters can be divided into the following groups:
- Statistical Metrics: Number of (application level): packages, namespaces, types, global types, classes, global classes, interfaces, global interfaces, structures, global structures, methods, properties, fields, lines of code, comments, comments density, levels, public data percentage, Halsted complexity, number of parameters in methods, number of functions, overloading
- Object Oriented Metrics: coupling, afferent coupling, efferent coupling, instability, relational cohesion, distance from the main sequence, abstractness, association between classes, cohesion of LCOM, cohesion of LCOM HS, cyclomatic complexity, depth of inheritance tree
- CISQ Measures of reliability, performance efficiency, maintainability, security. The total amount of CISQ Quality Characteristic Measures includes: for reliability – 29, for performance efficiency – 15, for maintainability – 20 and for security – 22.
- Parameters that represent Functional Software Quality: number of realized features vs. total number of features, number of functional defects, number of simultaneously served users, etc.
The easiest parameters are statistical metrics, but not all of them directly reflect the code quality. Please note that without further evaluation or additional parameters, statistical parameters are not effective for software quality evaluation.
Thus, in order to implement the QTP approach in any project, you need to follow the rules below:
- Define the exact list of measurable parameters that can be tracked during software development and testing processes
- Define the optimal list of parameters for the Quality Target Point
- Define exact goals and parameter values for each Quality Target Point
- Define how you will measure each parameter in the Quality Target Point. If you can’t measure some parameters, don’t add them to QTP
- Define how you will monitor parameter values in each Quality Target Point
- Define schedule when you will reach every Quality Target Point
- Explain each parameter in your Quality Target Point to all your team members
Software development process according to Quality Target Points
We have already defined QTP and its parameters. Now let’s check how the QTP approach can be integrated into a software development process based on SCRUM methodology. In SCRUM all processes are divided into several SPRINTs, each having its own set of goals that should be reached.
Therefore, for each SPRINT you need to define its own Quality Target Point with exact set of measurable parameters, source code checking schedule and goals that you need to reach. It is extremely important to identify all parameters that can be measured and reflect different characteristics of software quality. For more than 90% of all cases, it will be enough to use QTP listed above.
Further, during each SPRINT it is necessary to carry out continuous measurement of QTP parameters. At the end of each SPRINT, you need to compare planned and actual QTP values. According to the results of every Quality Target Point you have achieved, you need to make changes to the next Quality Target Point.
Finally, you need to make adjustments to the planned values for the next QTP. You may skip this when it is clearly seen that the next QTP will reach the necessary QTP parameters. Thus, the quality control will be carried out on each SPRINT and you will have clearly defined quality characteristics. Each SPRINT will have its precise QTP quality coefficient.
Integration of the Quality Target Point approach into SCRUM process
Before the start of the project development, you need to:
- Prepare your Quality Target Points and define them for every SPRINT
- Create plan for source code quality improvements based on your needs, abilities and requirements
- Prepare optimal set of source code analysis tools: profilers, code review tools, code style checking tools, code verification tools, security and vulnerability checking tools, architecture checking tools or select some universal tools for code checking, analysis and improvements
- Create implementation plan for these tools usage in the development process
- Teach your engineers/developers how to use all the necessary tools
- Constantly control and measure QTP parameters
- Introduce process procedures for code improvements based on the results of source code analysis
Practical aspects of Quality Target Point usage
As mentioned earlier, before using the QTP approach some preparation steps should be made. The most difficult task is to select the necessary tools for QTP measurement. In general, you can use any tool or even a set of tools. And what about us? At Softarex Technologies, Inc. we’re using codeNforcer. In 2011, we recognized that there was no alternative for us – we needed our own software that would help us maintain our source code on a high quality level. Starting as a tool for internal use, codeNforcer has since grown into a powerful platform delivering its users unique capabilities and strong business results.
codeNforcer is a next generation software product for source code analysis and review based on source code metrics. Remember that the logical chain is quite simple. Keeping software quality on a properly high level is the result of keeping high QTP values. All that leads to a better product performance and the overall business success!