You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Models and CQM

One of the most interesting features that Kiuwan offers is its ability to manage Models associated with the analyses carried out on the applications, quite detailed and accurate through a management utility: Models Manager, which is accessed through the settings menu on the top right and is described in this chapter.
 

 
To analyze an application, it is necessary to have and configure a Model. This is not an easy task. It requires a minimum knowledge of the repository of hundreds of rules that help you validate the code and how to select and parametrize them. Configuring details for other Kiuwan indicators is also needed to fine tune your analysis. Although these are complex tasks, Kiuwan helps you all the way with useful tools to narrow your needs.

What is CQM?

CQM is a model for extracting analytics of a software product, designed by Optimyth and available 'out-of-the-box' in Kiuwan, so that users can begin to analyze their code immediately. Once the methodology behind code certification is well known, users will be able to "calibrate" their own models, creating them from scratch or from other existing models. Before using it, let's introduce the concepts and methodology behind CQM and, then, go into the details of the elements that compose a model in Kiuwan: Indicators, Rules and Metrics.

Why CQM?

Optimyth has a deep experience advising its costumers to get better in software development.  Optimyth has noticed that its customers have common troubles and interests, so there was the need of defining a methodology that was supported by tools, products and solutions. This methodology must guarantee that the solution adopted will provide the target benefits and will resolve the most common troubles. Having a defined methodology saves time and money in the software development process of these companies. When you cut time in implantation, you get extra benefits because you minimize the risks that surround this kind of projects: Long projects are risked ones.

ISO-9126 based

CQM is ISO-9126 based. It defines us the internal quality scope and characteristics. This standard provides a set of concepts in order to build a common language about quality.
ISO-9126 defines three techniques of validation:

  • 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 the characteristics of the software product from an external view. It is the quality when the software is executed, which is typically 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. It measures the extent to which users can achieve their goals in a particular environment.

CQM benefits

You will get software analytics that allows you to:

  • Abstract from technical layer. Your information will be independent from program languages and platforms.
  • Compare different versions of the same software. This answers the most important question: has my software improved?
  • Compare different applications. It does not matter if they are different kinds of applications or they are developed in different technologies.
  • Evaluate the technical requirements in order to accept the software from a third party provider.

But also other benefits:

  • Aggregation of data. You can aggregate the information from different applications in order to get an evaluation of the software produced by a provider, a country or IT area compared to others.
  • Continuous improvement process. You can apply a control methodology in your software lifecycle process.

The CQM methodology principles

Layer structured model

CQM methodology extracts evidences from the software's code and configuration. The process continues upwards in order 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 in order to analyse it. In this step you have to prioritise the evidence found, to distinguish what is critical, major, low or informative. It will define the required level.

Technology indicators layer

It can be based on different categories according to the technology, for example, you are not going to get usability defects in PL/SQL source code, because this language does not concern itself with the user layer nor the presentation layer.
So you have to define technology categories for the evidence found in the previous layer and aggregate it using the priorities based on the severity of the problem. These categories must be defined by thinking about the software characteristics of the next layer. For example, the group of evidence related to threads or parallelisation references to software efficiency.
The output of this layer will be technical indicators that allow you to compare software based on the same technology.

Software characteristics indicators layer

This layer standardises the indicators generated in the previous layer in order to get one normalised indicator for each software characteristics defined by ISO 9126 standard. CQM improves ISO 9126 focusing on internal quality. In order to provide indicators that correlate with the software characteristic, CQM proposes the next indicators:

  • Security. The capability of the software product to protect information and data so that unauthorised persons or systems cannot read or modify them and authorised 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 amount 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 environment and in requirements and functional specifications.
  • Portability. The capability of the software product to be transferred from one environment to another.

At this point you will have technology independent software indicators that allow you to analyze your application; even if you do not have specific technology knowledge.

Global indicator layer: CQM indicator

At the end of the quality process you will get ONE standard and normalised indicator per software unit. Using this indicator you can extrapolate to evaluate groups of software applications; for example, evaluations of software providers, its 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. Therefore, it can be a sign, a number or a graphic and so on. It must be a clue or a pointer to something that is changing. Indicators are presentations of measurements. They are bits of information that summarise the characteristics of systems or highlight what is happening in a system.
CQM indicators are normalised to represent these regions:

  • 0-30 region. The characteristic pointed to by the indicator is in the RED zone. Improvements are needed.
  • 30-70 region. Represented by YELLOW and means that you have to keep your mind on this indicator. Your next moves will depend on your requirements.
  • 70-100 region. The GREEN zone. This is the zone where all indicators must be. No critical defects found. 

Comparison and evolution

This normalisation allows the comparison of different characteristics between them; this means that you can say if the software is more maintainable than it is efficient or reliable. You are going to compare different versions of the same application over time because the meaning of the indicator does not change.

  • No labels