Goal Question Metric and Software
Muhammad Ameer Abdul Rehman
INSTITUE OF INFORMATION AND TECHNOLOGY
Abstract— Goal Question metric is designed for the improvement of Software
Development process. GQM defines a certain goals and then refines these goals
into questions and defines metrics that should provide the information to
answer these questions. The Goal Question Metric (GQM) approach has exhibited
itself accommodating in an assortment of mechanical settings to help
quantitative programming venture administration. This paper talks
about the utilization of the Goal Question Metric as a system for defining and
interpreting software measurement. In software concentrated affiliations, a hierarchical
organization won’t guarantee definitive accomplishment unless the business
technique can be changed over into an arrangement of operational programming
objectives. And this paper discuss about the issues on identifying the problems
faced in the development of software and how to resolve them properly using
Question Matric,Software Quality, Software Measurement, Goal Oriented, Defect
Goal-Question-Metric (GQM) has been proposed by Basils and Weiss. The rule
behind the GQM technique is that estimation ought to be objective oriented.GQM
characterizes a specific objective, refines this objective into questions, and
characterizes measurements that ought to give the data to answer these
inquiries. Whereas software quality refers to two related however particular
ideas that exist wherever quality is characterized in a business setting.
Programming utilitarian quality reflects how well it follows or complies with a
given plan, in light of practical prerequisites or details.
with any designing control, software improvement requires an estimation
component for criticism and assessment. Estimation is a component for making a
corporate memory and a guide in noting an assortment of inquiries related with
the establishment of any product procedure. This implies estimation must be
characterized in a best down manner. It must be engaged, in view of objectives
and models. A base up approach won’t work in light of the fact that there are
numerous discernible qualities in programming yet which measurements one uses
and how one deciphers them it isn’t clear without the fitting models and
objectives to characterize the unique circumstance.
This paper is organized as
follow: Section II describes the related work. Section III. Describes the Discussion
on the GQM. Section IV describes the case study. Section V Describes the
Conclusion. In the last section references are provided which helped in the
completion of this research paper.
According to Victor R.Basili
there are few organized ways to deal with software measurement have been
produced and are utilized as a part of associations. These approaches are
referred to as “GOAL ORIENTED” approaches because they use goals, objectives,
strategies, or other mechanisms to guide the choice of data to collect and
analyze in a systematic way. One well known goal-oriented approach is the GQM
According to Norton, D. GQM gives
a technique to an association or a task to characterize objectives, refine
those objectives down to determinations of information to be gathered, and
after that dissect and translate the subsequent information as for the first
objectives. Balanced Scorecard (BSC) 2 is an approach to linking measurement
at all levels of an organization to the organization’s strategy. The
“scorecard” consists of four perspectives: financial, customer, internal
business processes, and learning and growth. BSC does not dictate a static set
of measures, but serves as a framework for choosing measures, processes, and
initiatives that are aligned with organizational strategy and higher-level
According to Victor R.Basili Goal
Question Metric (GQM) approach is based upon the assumption that for an
organization to measure in a purposeful way it must first specify the goals for
itself and its projects, then it must trace those goals to the data that are
intended to define those goals operationally, and finally provide a framework
for interpreting the data with respect to the stated goals. Thus it is
important to make clear; at least in general terms, what informational needs
the organization has, so that these needs for information can be quantified
whenever possible, and the quantified information can be analyzed to whether or
not the goals are achieved. The approach was originally defined for evaluating
defects for a set of projects in the NASA Goddard Space Flight Center
environment. The application involved a set of case study experiments 4 and
was expanded to include various types of experimental approaches 3. Although
the approach was originally used to define and evaluate goals for a particular
project in a particular environment, its use has been expanded to a larger
context. It is used as the goal setting step in an evolutionary quality
improvement paradigm tailored for a software development organization.
According to the US Department of
Defense Practical Software Measurement (PSM) 5 offers very detailed guidance
on software measurement, including a catalogue of specific measures, along with
information on operationalizing them in an organization. PSM also includes a
process for choosing appropriate measures based on the issues and objectives
relevant to a software development project.
According to Becker, S.A. in
reference 6 addresses the misalignment between strategy at the organizational
and project levels of software organizations caused by project data that does
not address organizational goals and organizational goals that fail because
they are not operationalized through processes and metrics at the project
level. Their approach is to embed a GQM structure within each of the four BSC
perspectives. One advantage of this approach is that it allows more consistency
in notation and terminology surrounding goals and measures at all levels.
However, the approach does not recognize or support truly different goals at
different levels of the organization case, italic) in addition to the style
provided by the drop down menu to differentiate the head from the text.
According to Offen, R.J. and
Jefferey, R. The M3P – Model, Measure, Manage Paradigm – is an extension of the
QIP and GQM 7. M3P embeds GQM as a measurement definition technique within a
larger framework that encompasses organizational concerns. M3P does not allow
for goals at different levels of the organization that are different but
explicitly linked, to allow analysis of measurement data to feed back up the
GQM is the approach to software matrices which is promoted by the
Victor Basili from the University of Maryland College Park.GQM defines a
measurement model on three different levels which are mentioned as follow:
Conceptual Level: (Goal)
defines the goals in which we decide that what we want to accomplish about the
desired project and what are the main problems that we can face in the project.
Operational Level: (Question)
This level defines the set of
questions is used to characterize the way the assessment/achievement of a
specific goal is going to be performed based on some characterizing model.
This Level defines the set of data associated with every question
in order to answer it in a quantitative way. That data can be possibly in two
ways that are mentioned below:
If they depend only on the object that is
being measured and not on the viewpoint from which they are taken; e.g., number
of versions of a document, staff hours spent on a task, size of a program.
If they depend on both the object
that is being measured and the viewpoint from which they are taken; E.g.,
readability of a text, level of user satisfaction.
} They define what the organization wants to
} They refine each goal to a more
} They indicate the metrics required to answer each question
A GQM model is a hierarchical structure,
starting with a goal that is specifying the purpose of the measurement, the
object to be measured, the issue to be measured, and the viewpoint from which
the measure is taken.
The goal is
then refined into several questions, which usually break down the issue into
its major components. Each question is then refined into metrics — some of them
objective, some of them subjective.
metric can be used to answer different questions under the same goal. Several
GQM models can also have questions and metrics in common. Here’s an example of
the GQM approach. As the Project Manager, I would like to know the functional
quality of the current version in the production.
In above example, the goal is to know the quality of the
software. In order to satisfy this goal, two questions are asked. One looks for
the number of defects in the production, which is answered by having a metric
called “defect leakage.” The other question is to identify if there has been
any improvement in the quality compared to the last release, which is answered
by having defect leakage trend and severity trend metrics. These metrics look
like logical extensions of a Project Manager’s goal.
Advantages and Disadvantages:
Directing and monitoring process in
GQM become difficult to apply where
the impacts of methodology are not clear.
It accesses the software engineering
technologies which are new.
Technological support for GQM is still
Certifying and judging the improvement
Detailed guidelines for establishment
of GQM program in industrial environment are still limited.
It helps in achieving improvement
GQM has been criticized for lack of
structure and guidance.
It generates only those measures which
are useful for goal attainment.
is no final numerous or quantitative result, which could be used for
comparing two or more GIS software
Motorola was set up in 1928 by brothers Paul and Joseph
Galvin. The company was originally incorporated as the Galvin Manufacturing
Corporation (GMC), and was headquartered in Chicago. GMC’s first product was a
‘battery eliminator’, which allowed radios to operate on standard household
electric current instead of batteries.
The competition in the battery eliminator business was
intense, with manufacturers aggressively undercutting each other. Because of
this, GMC diversified into making automobile radios, which was a relatively
unexplored business at that time. GMC’s first car radio was launched in 1930
under the name MOTOROLA.
The goals and measurement areas identified by the
Motorola Quality Policy for Software Development (QPSD) are listed in the
Goal 1: Improve
Goal 2: Increase
Goal 3: Increase
Goal 4: Decrease
software defect density.
Goal 5: Improve
Goal 6: Increase
} Delivered defects and delivered defects per size
} Total effectiveness throughout the process
} Number of open customer problems
} Software reliability
For each goal the questions to
be asked and the corresponding metrics were also formulated. And following are
the list of the questions and matrices for each goal.
Improve Project Planning
What was the accuracy of estimating the actual value of project
Metric 1.1 : Schedule Estimation Accuracy (SEA)
SEA=Actual project duration / Estimated project duration
Question 1.2: What was the accuracy of estimating the actual
value of project
Metric 1.2 : Effort Estimation Accuracy (EEA)
Actual project effort /
Estimated project effort
Goal 2: Increase Defect Containment
What is the currently known effectiveness of the defect
detection process prior to release?
Metric 2.1: Total Defect Containment Effectiveness (TDCE)
Number of prerelease defects / Number of prerelease defects
+ Number of post release defects
What is the currently known containment effectiveness of faults
introduced during each constructive phase of software development for a
particular software product?
Metric 2.2: Phase Containment Effectiveness for phase i (PCEi)
Number of phase errors /
Number of phase errors + Number of phase defects
Goal 3: Increase Software Reliability
Question 3.1: What is the rate of software failures, and how
does it change over time?
Metric 3.1: Failure Rate (FR)
Number of failures /
Goal 4: Decrease Software Defect
Question 4.1: What is the number of in-process faults, and how
Compare with the number of in-process defects?
Metric 4.1a: In-process Faults (IPF)
In-process faults caused by software development /
Metric 4.1b: In-process Defects (IPD)
In-process defects caused by software development/ source size
Goal 4: Decrease Software Defect
Question 4.2: What is the currently known defect content of
software delivered to customers?
Metric 4.2: Total Released Defects (TRD) total
Number of released defects / source size
Goal 5: Improve Customer Service
Question 5.1 What is the number of new problems opened during
Metric 5.1: New Open Problems (NOP)
NOP = Total new post release problems opened during the month
Question 5.2 What is the total number of open problems at the
end of the month?
Metric 5.2: Total Open Problems (TOP)
TOP = Total post release problems that remain open at the end of
Question 5.3: What is the mean age of the problems that were
closed during the month?
Metric 5.4: Mean Age of Closed Problems (ACP)
ACP = (Total time post release problems closed within the month
were open) / (Number of open post release problems closed within the month)
Increase Software Productivity
Question 6.1: What was the productivity of software development
on source size)?
Metric 7.1: Software Productivity total (SP total)
SP total =
total source size /
Software development effort
Software process improvement should be
based regarding quantitative evolution of products and process characteristics.
The application of GQM into various projects with same organization that allows
to reuse the parts of GQM planning such as goals, sheets, abstraction, question
and metrics. The reusing of these parts may save effort and time of
organization. The growth of GQM and its measurement plans must be based on wide
knowledge on process details. Goal setting should be based on simple
representations and intuitive of the known difficulties of the process that are
being studied.GQM must have clear knowledge of organization that being studied
at various levels of management.
1 Basili, V., Caldiera, G., and Rombach D. “Goal,
Question Metric Paradigm”, Encyclopedia of Software Engineering, vol. 1, John
Wiley and Sons, 1994a.
2 Kaplan, R. and Norton, D. “The Balanced Scorecard –
Measures That Drive Performance”, Harvard Business Review, January-February
1992, p. 71.
3 V.R. Basili, R.W. Selby, “Data Collection and Analysis
in Software Research and Management”, Proceedings of the American Statistical
Association and Biomesure Society, Joint Statistical Meetings, Philadelphia,
PA, August 1984.
4 R Basili, D.
M.”A Methodology for Collecting Valid Software Engineering.” IEEE Transaction
on Software Engineering, SE-10(6), 728-738(Nov. 1984b)
5 US Department of Defense and US Army (DoD), Practical
Software and Systems Measurement: A Foundation for Objective Project
6 v. 4.0c, March 2003, from www.psmsc.com, visited in
7 Becker, S.A. and Bostelman, M.L. “Aligning Strategic
and Project Measurement Systems”, IEEE Software, May/June 1999, pp. 46-51.
8 Offen, R.J. and Jefferey, R. “Establishing Software
Measurement Programs”, IEEE Software, Mar/Apr 1997.
9 Boehm J. R. Brown, and M Lipow,”Quantitative
Evaluation of software Quality.”Proceedings of the Second International
conference on Software Engineering, pp 592-605, 1976.