GQM
GQM
Goal-Question-Metric — A Goal-Driven Software Measurement Framework
1. Overview of GQM: A Software Quality Measurement Framework That Derives Questions and Metrics Backward from a Goal
flowchart LR
A["Collecting arbitrary metrics<br/>with an unclear measurement purpose<br/>makes the data unusable"] --"Design in reverse:<br/>Goal → Question → Metric"--> B["A goal-aligned,<br/>meaningful metric system"] --"Data-driven<br/>quality decisions"--> C["Continuous quality improvement<br/>based on measurement"]
style A fill:#FFEBEE,stroke:#D32F2F,color:#000
style B fill:#E3F2FD,stroke:#1976D2,color:#000
style C fill:#E8F5E9,stroke:#388E3C,color:#000
Definition: A software measurement framework developed by Victor Basili that uses a three-tier, top-down approach — Goal → Question → Metric — to derive meaningful quality metrics that are directly tied to the measurement purpose, then interprets the collected data backward to assess whether the goal has been achieved.
Characteristics: (Top-down design) Rather than choosing metrics first, it defines the measurement goal first and derives the necessary metrics in reverse. (Context-dependent) The same metric can be interpreted differently depending on the measurement goal, viewpoint, and environment — context must always be made explicit. (Linked to standards) Connected with ISO/IEC 15939 (the software measurement standard), CMMI, and the Measure phase of Six Sigma DMAIC.
2. Core Structure of GQM
a. The Three-Tier Goal-Question-Metric Structure
flowchart TD
subgraph GOAL["Goal Layer"]
G["Goal<br/>Defines the measurement object, purpose,<br/>viewpoint, and environment along 4 dimensions<br/>e.g., Evaluate the development process<br/>in order to reduce defects"]
end
subgraph QUES["Question Layer"]
direction LR
Q1["Question 1<br/>What is the<br/>current defect rate?"]
Q2["Question 2<br/>When are<br/>defects found?"]
Q3["Question 3<br/>What are the main<br/>causes of defects?"]
end
subgraph MET["Metric Layer"]
direction LR
M1["Metric 1<br/>Defects per unit of function<br/>Defect Density"]
M2["Metric 2<br/>Defect detection rate by phase<br/>Phase Containment"]
M3["Metric 3<br/>Distribution of defect causes<br/>Defect Causal Analysis"]
end
GOAL --> QUES
Q1 --> M1
Q2 --> M2
Q3 --> M3
style GOAL fill:#1E3A5F,stroke:#1E3A5F,color:#fff
style QUES fill:#E3F2FD,stroke:#1976D2,color:#1E3A5F
style MET fill:#E8F5E9,stroke:#388E3C,color:#1B5E20
The Four Dimensions for Defining a Goal
| Dimension | Description | Example |
|---|---|---|
| Object | What is being measured | Software development process, product, or resource |
| Purpose | Why it is being measured | Understand, improve, predict, control, or change |
| Quality Focus | Which quality attribute is examined | Defects, productivity, cost, reliability, maintainability |
| Viewpoint | Whose perspective it is | Developer, manager, user, or QA staff |
b. Procedure for Designing and Measuring SW Quality Metrics
flowchart LR
S1["1. Define goal<br/>Write the 4-dimension Goal<br/>reach stakeholder agreement<br/>fix measurement scope"]
S2["2. Derive questions<br/>List questions that<br/>confirm goal achievement<br/>review measurability"]
S3["3. Design metrics<br/>Define quantitative/qualitative<br/>metrics that answer each question<br/>decide methods & tools"]
S4["4. Collect data<br/>Establish measurement plan<br/>automated/manual collection<br/>verify data quality"]
S5["5. Interpret & feed back<br/>Interpret backward toward the Goal<br/>judge goal achievement<br/>establish corrective action"]
S1 --> S2 --> S3 --> S4 --> S5
S5 -->|"Revisit the goal"| S1
style S1 fill:#1E3A5F,stroke:#1E3A5F,color:#fff
style S2 fill:#E3F2FD,stroke:#1976D2,color:#000
style S3 fill:#F3E5F5,stroke:#7B1FA2,color:#000
style S4 fill:#FFF3E0,stroke:#F57C00,color:#000
style S5 fill:#E8F5E9,stroke:#388E3C,color:#000
Example of GQM Applied to Software Quality
| Goal | Question | Metric |
|---|---|---|
| Evaluate code quality to reduce defects | What is the code’s complexity level? | Cyclomatic Complexity |
| What is the code review coverage? | Percentage of PRs with completed reviews | |
| How many static analysis violations are there? | SAST warnings per 1,000 LOC | |
| Analyze the development process to improve productivity | How much time does development take per feature? | Effort per function point |
| How frequent are deployments? | Deployment frequency (per week) | |
| What is the rework rate? | Rework effort / total effort (%) |
3. Expected Benefits and Application of GQM
| Category | Expected Benefits | Application and Practical Use |
|---|---|---|
| Goal-aligned measurement | Collects and analyzes only metrics meaningfully tied to organizational goals | Eliminates unnecessary metrics — select metrics that are “needed,” not merely “collectible” |
| Quality visibility | Objectively represents software quality status through data | Use GQM metric dashboards in sprint reviews and QBRs |
| Linked to CMMI | A core implementation method for the Measurement and Analysis (MA) process area | Establish a quantitative measurement system to achieve CMMI Level 4 |
| DevOps metrics | Structures the four DORA metrics within the GQM framework | Define measurement goals for deployment frequency, lead time, change failure rate, and MTTR |