Metrics in the software development process: GQM model

“You can’t control what you can’t measure” is a rubber stamp that consultants like to use at expensive trainings. Many people have developed an allergy to various kinds of metrics, because of the manic desire of managers to hang KPI wherever possible. However, without a specific measurement system, it is impossible to talk about the systematic improvement of the quality of a software product and the process of its development. In this article I will talk about the GQM (Goal - Question - Measure) approach, which will help determine truly objective metrics and give a couple of examples.




When developing software, teams regularly encounter problems of process inefficiency and poor product quality. However, projects containing several tens of thousands of lines of code written by hundreds of developers cannot be covered with one glance and any decision can be made. In such cases, special indicators come to the rescue, allowing you to “enlighten” the software product.
')
Making a decision to make changes to a product or process, the team begins an experiment, with the goal of testing some hypothesis. How can you understand that the hypothesis is correct? Teams will be assisted by predefined metrics describing important aspects of the experiment being conducted.

GQM model

Victor Basil proposed the GQM model (Goal - Question - Metric; Aim - Question - Indicator) [1]. The basic idea is described by three basic points:

1. Determine the goal you want to achieve.
2. Formulate questions that characterize important aspects related to the goal.
3. Choose metrics to answer the questions asked.

For clarity, the model is depicted as a three-level hierarchical diagram.

Important aspects when building a GQM model:

1. In formulating a goal, rely on SMART criteria. This will avoid abstract philosophical goals.
2. Choosing the main aspects, pay attention not only to the obvious characteristics, but also to those signs that are indirectly subject to change.
3. In determining the important characteristics, it is necessary to take into account the technologies used, process practices and development tools. All the listed criteria affect which indicator is most relevant in a given context. In addition, it is necessary to choose those metrics that can be collected in automatic or semi-automatic mode, since manual collection of metrics is fraught with invalid results at the output.

Model building examples

Suppose our goal is to reduce the system inactivity time (the time when the system is not available to users). The GQM model for this situation is shown in the figure:


Goals can be both technical and process. A team, for example, can define metrics that will help it improve the quality of labor costing or the effectiveness of various code-writing standards. Below is the GQM model for determining the effectiveness of a standard for writing program code:


In some cases, the goals of the team are too global and require some decomposition. In this case, GQM + approach [2] comes to the rescue, which involves building a tree of goals for a team or an entire company and building a separate model for each goal of the tree. The goal “to reduce the time of delivery of the function to the client (time to market)” is global. It can be decomposed as follows:


Summing up, it is worth noting that this tool is most effective when development teams independently determine their goals for improving the software product and identify suitable metrics. When indicators are imposed from above, the effectiveness of the GQM model decreases dramatically as the team begins to perceive the metrics as a tool of control, and not as an important aspect of the product improvement process.

References:

1. Goal / Metric paradigm. - 1992.
2. Basili V. et al. GQM + Strategies in a Nutshell // Aligning Organizations Through Measurement. - Springer International Publishing, 2014. - p. 9-17.