Guide to Approaches for Measuring Software Quality
Top managers always need to rely on some metrics to guide them through the decision process. With continuous development of technologies and methodologies, metrics evolve as well. Traditionally, defect tracking was used for software quality measurement throughout the entire lifecycle. But now the situation has changed, and it's possible to predict and prevent defects before they become features.
The main questions to answer here are: Is defect tracking really important and needed? Which metrics to use for quality measurements? When is it needed to implement a quality metrics program?
We've created a short overview of gears we use in codeNforcer that answer the questions above.
What Is Software Quality?
Usually definitions of Software Quality include the following aspects:
- Software functional quality reflects how good it complies with the given design according to functional requirements or specifications.
- Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements.
Standards for Structural Software Quality
- ISO 9126-3 and ISO 25000:2005 contain metrics which can be used for measurement of structural quality. ISO 25000:2005 is also known as SQuaRE quality model (Systems and software Quality Requirements and Evaluation).
- According to SQuaRE model, Consortium for IT Software Quality (CISQ, http://it-cisq.org/) has defined the five most important goals, or desired structural characteristics, which should be provided by software for covering each user's business needs. These goals and related to them measurable attributes are shown in the figure below.
Main directions for source code analysis in codeNforcer
Using this approach, developers can write the code that adheres to a coding standard including finding class design problems, method design problems, etc.
Total number of supported code validation rules: 231
Total number of supported code сonvention rules: 73
With the wide possibilities for source code analysis, users can customize checking directions out of predefined and defined set of rules.
CISQ Measures of Reliability, Performance Efficiency, Maintainability and Security
IT organizations can use code quality standards to detect critical violations of good coding and architectural practice in software. Measure software against code quality standards at every release, e.g. measure code compliance to secure architectures, and put CISQ software quality measures into contracts with outside developers or software vendors to track to established outcomes.
Total number of supported CISQ Measures: 44
- Reliability measures (rules) – 18
- Performance Efficiency (rules) – 6
- Maintainability (rules) – 14
- Security (rules) – 6
Today codeNforcer provides a set of metrics for programming languages. We are constantly expanding the list of these metrics and conducting our own research to carry forward the theory about source code metrics.
Total number of supported object-oriented metrics: 11
In most cases, the above metrics help to estimate the scale and complexity of the project being developed. Quantitative metrics indicate the number of classes, methods, structures, interfaces, lines of code, number of comments, etc. Complexity metrics are calculated using special formulas, including various algorithms for complexity evaluations.
Total number of supported statistical parameters: 21
Quality Target Points
Approach towards source code analysis based on Quality Target Point is an internal development of Softarex Technologies, Inc. that combines complex math calculations and development processes. Quality Target Point is an abstract time point when a complete list of measurable quality characteristics is defined including Architecture measures, Reliability, Performance Efficiency, Maintainability and Security measures. 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 before a specific date. This kind of approach is based on ideas described in Test Maturity Model Integration (TMMI). Its aim is to provide a framework for assessing the maturity of the test processes in an organization, and so to provide targets on improving maturity.