This page provides an overview of Kiuwan Models and the concept of CQM (Checking Quality Model).
A Kiuwan model is a configuration that defines how quality analyses are conducted on an application. Determines which rules, metrics, and indicators are applied during the static analysis of source code to evaluate its quality.
Kiuwan enables you to manage models associated with the analyses carried out on the applications via the management utility Models Management.
To analyze an application, you must configure a Model—a process that requires some expertise. With hundreds of validation rules available, selecting and fine-tuning the right ones can be challenging. Additionally, configuring other Kiuwan indicators is essential to optimize your analysis. While this may seem complex, Kiuwan provides powerful tools to simplify the process and tailor the configuration to your needs.
Introduction to CQM
CQM (Checking Quality Model) is a software analytics model developed by Kiuwan, designed to provide immediate insights into code quality. It helps users quickly assess their code, using pre-defined rules and metrics. Once familiar with its process, users can adjust or create their models to fit their needs.
Why CQM?
Kiuwan created CQM to solve common software quality issues. Its structured approach saves time and money by speeding up quality checks and reducing risks in long development projects.
CQM and ISO-25000
CQM is based on the ISO-25000 standard, which defines software quality in three key dimensions:
- Internal Quality is the set of characteristics of the software product from an internal view. Internal quality is measured and evaluated against the internal quality requirements. Details of software product quality can be improved during code implementation, reviewing, and testing.
- External Quality is the set of characteristics of the software product from an external view. When the software is executed, quality is measured and evaluated while testing in a simulated environment with simulated data using external metrics.
- Quality in Use is the user's view of the quality of the software product when it is used in a specific environment and a specific context of use.
CQM benefits
CQM provides software analytics that allow:
- Works across different languages and platforms.
- Compare different versions of the same software.
- Compare different applications. It does not matter if they are different kinds of applications or if they are developed in different technologies.
- Evaluate the technical requirements to accept the software from a third-party provider.
Other benefits:
- Supports data aggregation and the continuous improvement process.
The CQM methodology principles
Structured model layer
The CQM methodology extracts evidence from the software's code and configuration. The process continues upward to obtain technology-independent indicators to build evolution, comparators, and aggregations.
Source code indicators layer
This layer is responsible for reading the source code and extracting technical evidence. It has to classify this evidence to analyze it. In this step, you have to prioritize the evidence found, classifying findings by severity (critical, major, etc.)
Technology indicators layer
It can be categorized according to various technologies.
Define technology categories for the evidence found in the previous layer and aggregate it using the priorities based on the severity of the problem.
Software characteristics indicators layer
This layer standardizes the indicators generated in the previous layer to get one normalized indicator for each software characteristic defined by the ISO 25000 standard. CQM proposes the following indicators:
- Security: The capability of the software product to protect information and data so that unauthorized persons or systems cannot read or modify them and authorized persons or systems are not denied access to them.
- Reliability: The capability of the software product to maintain a specified level of performance.
- Efficiency: The capability of the software product to provide appropriate performance relative to the number of resources used under stated conditions.
- Maintainability: The capability of the software product to be modified. Modifications may include corrections, improvements, or adaptability of the software to changes in the environment requirements, and functional specifications.
- Portability: The capability of the software product to be transferred from one environment to another.
Static Analysis in Automated Software Quality Tests
Software quality management solutions function with automated tests that use static analysis processes to generate software quality metrics.
With the ability to parse code in almost every commonly used programming language, static analysis is useful in assessing a key set of five software quality indicators: software system security, code reliability, code memory usage and efficiency, maintainability, and portability.
Security
Static analysis looks for security vulnerabilities in source code by referencing the most common vulnerabilities as defined by OWASP.
A static analysis engine looks at authentication vulnerabilities by checking that the code protects user authentication credentials by hashing or encrypting the stored authentication information. It looks for weak account management functions, such as password recovery processes, for simple password overwriting vulnerabilities. It verifies that the source code hides URL authentication information via URL rewriting algorithms and looks at session timeout procedures that often produce vulnerabilities to session fixation attacks.
When scanning for security vulnerabilities, the static analysis algorithm tags structures that contain sensitive data and verifies that all direct references to these objects require authentication for data to be passed to the caller. Similarly, the parser looks at indirect references to sensitive data objects and the data mapping process to ensure that the call requires user authentication. When the parser locates an instance of potential vulnerability, it will tag and report the instance and include it in a security metrics report. After scanning through all of the most common types of software vulnerabilities, it will generate a report that references all potential vulnerabilities it has identified.
Reliability
Static analysis looks for the reliability of all modules and methods of software.
The source of reliability in code is the ability to produce a predictable outcome given wildly varying inputs. In static analysis, the parser identifies specific methods and isolates them, emulating their behavior when ported into other software modules. Once isolated, the algorithm generates arguments and reads method outputs, expecting the outputs to contain specific information and formatting. It will raise flags for any anomalies in a method.
The algorithm aggregates anomalies and generates a report that points to specific methods that compromise reliability.
Efficiency
The efficiency of code is largely dictated by memory usage and data flow.
A common source of code inefficiency calls for entire data sets to be stored in active memory. The static analysis algorithm looks for any such explicit calls to store data sets in memory and reports them. It will also look for cases of lingering data stored in active memory – any call for data to be stored in active memory will prompt a search for a call to drop that data from memory after working and updating a database.
The report will suggest an iterative alternative approach to carrying out a memory-intensive task, but a knowledgeable developer needs to look at such reports. Some explicit calls to stored data sets in memory are necessary and entirely manageable if, for example, the data set is known to be small (such as metadata).
Static analysis procedures will also identify duplicate code and multiple calls to commit the same data to memory simultaneously.
Maintainability
The maintainability of code is closely related to the complexity of code. If the source code is overly complex, it can be difficult to make changes and incorporate new functions and modules quickly.
Thus, the static analysis protocol looks for sources of code complexity to generate metrics that quantify code maintainability.
A source of program complexity that is easy for a parser to identify is duplicate code in sibling classes. If certain classes share a parent and share explicitly defined methods, the code is overly complicated – the two classes could inherit their shared method from a parent class. A parser can easily identify such cases by looking for duplicate methods.
By quantifying program complexity, a static analysis report helps developers look at the maintainability of their code and improve it by pointing to specific sources of complexity.
Portability
Much as with reliability and maintainability, the portability of code lies in its complexity. The complexity metrics that a static analysis generates help developers quantify the portability of their code.
It’s important to understand the function of static analysis in any automated software quality test. It’s a wonderful tool, but developers should understand its strengths and limitations.
Global indicator layer: CQM indicator
At the end of the quality process, you will get ONE standard and normalized indicator per software unit. Using this indicator helps to evaluate groups of software applications; for example, evaluations of software providers, their areas, and developers teams, etc.
Understanding indicators
An indicator can be defined as something that helps us to understand where we are, where we are going, and how far we are from the goal. CQM indicators are normalized to represent these regions:
- 0-30 region - Poor quality. Improvements are needed.
- 30-70 region - Average. Your next moves will depend on your requirements.
- 70-100 region - Good. This is the zone where all indicators must be. No critical defects were found.
Comparison and evolution
CQM helps you to compare different versions of the same application over time because the meaning of the indicator does not change.