March 31, 2020

The Goal/Question/Metric (GQM) Paradigm

  —A look at a framework for creating well-aligned software metrics.

In McCall’s Software Quality Model, I discussed a paper tying quality factors to quality criteria. That model takes quality criteria coupled with metrics collected throughout the lifecycle to provide feedback on quality. What’s missing from this model is a discussion on how to arrive at good metrics.

The Goal/Question/Metric (GQM) Paradigm provides a framework published in 1994 for arriving at good measures.

Measurement is a mechanism for creating a corporate memory and an aid in answering a variety of questions associated with the enactment of any software process.

Measurement also helps, during the course of a project, to assess its progress, to take corrective action based on this assessment, and to evaluate the impact of such action.

I like this framework when its coupled with the quality criteria in McCall’s model. What follows is a brief description of GQM and how I think it complements McCall’s model.

GQM must be applied top-down and focus on goals and models. An organization must identify goals and trace those goals to data intended support to those goals operationally. Then provide a framework for interpreting the data with respect to its goals.

An object is the focus of measurement. Objects can be resources, processes or projects.

• Goals are defined for an object that is to be the focus of measurement. A goal is characterized by a purpose, issue and viewpoint (or perspective). An object is a product (something that is produced), process (an activity) or resource (something consumed).

• Questions connect the object of measurement to a quality issue. They determine the quality from the viewpoint.

• Metrics are associated with every question. Metrics are objective if they are the same regardless of viewpoint and are subjective if they depend upon the viewpoint.

A GQM model is developed by identifying a set of quality or productivity goals. Questions are derived for object of measurement to define the goal as completely as possible. Metrics are developed to answer those questions.

Goals are developed from policy and strategy, process and product descriptions and viewpoint to develop the measurement.

Quality factors in McCall’s model affect product operation (fufills specification), translation (ability to adapt software) or revision (ability to change software). These are similar to architectural quality attributes–a measurable or testable property of a system used to indicate how well the system satisfies the needs of its stakeholders. Basili’s GQM cites McCall’s model and identifies it as another means of defining Software Quality Metrics.

The chief contribution of GQM over McCall’s model is the explicit introduction of goals coordinates based upon viewpoint, purpose, issue and object. The explicitness of the goal coordinates creates a wider perspective for goals.

I like the complement between architectural quality attributes, McCall’s quality model, where criteria is identified to measure attributes, and the GQM idea of tying viewpoint to metric.

The Goal/Question/Metric Paradigm overlaps and refines McCall’s Software Quality Model as follows.

Here, goals create quality factors, an extension of the original concept to explicitly include a wider varienty of objects.

I don’t differentiate between the current notion of software architecture quality attributes and quality factors. I see GQM’s notion of goal as a superset because a goal might include resource, time, defects, etc. I view quality attributes as non-behavioural requirements.

Questions aided by goal coordinates motivate quality criterion that connect goals to metrics.

Metrics are an extension over quality measures because they explicitly include subjective and objective measures. Not necessarily missing from McCall’s model but not explicitly called out either.