Last updated: September 1, 2019
Topic: ArtRadio
Sample donated:

Goal Question Metric and Software






Muhammad Ameer Abdul Rehman


[email protected]


Muhammad Asad


[email protected]


Khurram Khalil


[email protected]






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 expains metrics that should provide the data to answer the
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 determine meaning and
explainingsoftware 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 GQM.

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.




Similarly as
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 someone
uses and how anyone understand dificult in 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 relivant work. Section III. Describes the
detailed meaning 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.


II.    Related

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 GAOL ORIENTED  approaches
because they uses aims, techniques and methods to guide the choice of data to
collect and evaluate in a managed way. One well known goal-oriented approach is
the GQM approach 1.

According to Norton, D. GQM gives
a technique to an association or a work 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 works at all
stages of an organization to the organization’s planing. The “scorecard”
consists of four perspectives: financial, customer, internal business
processes, and learning and growth. BSC does not dictate a fixed set of
activities, but serves as a framework for choosing measures, processes, and
ability to asses that are linked with organizational plans and higher-level
business aims


According to Victor R.Basili Goal
Question Metric (GQM) approach is based upon the thinking that for an
organization to measure in a meaningfull way it must first select the
objectives for itself and its projects, then it must track those goals to the
data that are intended to define those goals on routine bases, and finally
provide a scheme for explaining the data with respect to the specified aims and
objectives . Thus it is important to make clear; at least in simple way, what
information based requirements the organization has, so that these needs for
information can be quantitatively evaluated whenever possible, and the
evaluated information can be checked to whether or not the objectives 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 clear and check aims  for
a particular project in a specific environment, its use has been enlarged to a
larger environment. It is used as the goal setting step in an evolutionary
quality improvement pattern fitted for a software development organization.

According to the US Department of
Defense Practical Software Measurement (PSM) 5 offers very detailed advice on
software measurement, including a list of specific tasks, along with
information on operationaly apply them in an organization. PSM also includes a
process for choosing correct measures based on the problems and aims  related to a software development project.

According to Becker, S.A. in
reference 6 addresses the incorrect arrangemnt between plan at the
organizational and project levels of software organizations caused by project
data that does not address organizational aims and organizational goals that
fail because they are not operationalty related through processes and systems
at the project level. Their approach is the root of a GQM structure within each
of the four BSC perspectives. One advantage of this approach is that it allows
more stability in signs and defining terms 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,  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  structure that encloses
organizational informations. M3P does not allow for goals at different levels
of the organization that are different but clearly linked, to allow analysis of
measurement data to feed back up the chain.



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)

level 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.


Level: (Metrics)

                               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.


GQM Method:



}   They define what the organization wants to


}  They refine each goal to a more
quantifiable way.



}   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.

The same
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

Case Study



              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.



goals and measurement areas identified by the Motorola Quality Policy for
Software Development (QPSD) are listed in the following.


 Goal 1: Improve
project planning.

 Goal 2: Increase
defect containment.

 Goal 3: Increase
software reliability.

 Goal 4: Decrease
software defect density.

 Goal 5: Improve
customer service.

 Goal 6: Increase
software productivity.


Measurement Areas:


}  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.


Goal 1



Improve Project Planning

Question 1.1
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



Goal 2: Increase Defect Containment

Question 2.1:
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


Question 2.2:
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)
PCEi  =
Number of phase errors /
Number of phase errors + Number of phase defects


Goal 3



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)
FR =
Number of failures /
Execution time


Goal 4



Goal 4: Decrease Software Defect

Question 4.1: What is the number of in-process faults, and how
does it
Compare with the number of in-process defects?

Metric 4.1a: In-process Faults (IPF)
In-process faults caused by software development /
source size
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
TRD total
Number of released defects /   source size




Goal 5



Goal 5: Improve Customer Service

Question 5.1 What is the number of new problems opened during
the month?

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
the month


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)


Goal 6



Increase Software Productivity

Question 6.1: What was the productivity of software development
projects (based
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 characters. 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.