scispace - formally typeset
Search or ask a question
Journal ArticleDOI

Adopting GQM based measurement in an industrial environment

01 Jan 1998-IEEE Software (IEEE Computer Society)-Vol. 15, Iss: 1, pp 78-86
TL;DR: The paper discusses the elements of the G QM approach and fitting GQM to a measurement program.
Abstract: Schlumberger RPS (Retail Petroleum Systems) integrated the Goal/Question/Metric approach into their existing measurement programs to improve their program performance. Key to their success was the use of feedback sessions as a forum to analyze and interpret measurement data. The paper discusses the elements of the GQM approach and fitting GQM to a measurement program.

Summary (4 min read)

Motivation and background

  • Schlumberger RPS,the Retail Petroleum Systems division of Schlumberger,manufactures and services systems for self-service petrol stations, such as fuel dispensers, point-of-sale systems, and electronic funds-transfer systems.
  • Since Schlumberger began a software process improvement program in 1989, 1 the RPS division has achieved a level 2 on the SEI's Capability Maturity Model, Version 1.1.
  • It has also introduced reviews and inspections, structured project planning and tracking, defect tracking, and product quality specification and evaluation.
  • In late 1993, the authors began a systematic evaluation of the RPS division's measurement databases to assess the effectiveness of measurement practices.
  • The authors evaluation revealed several weaknesses: Data points were often inconsistent and incomplete.

Elements of the GQM approach

  • The GQM approach 5, 6 is a systematic way to tailor and integrate an organization's objectives into measurement goals and refine them into measurable values.
  • Its aim,therefore,is to create information that will help people understand, monitor, evaluate, predict, control, and improve software development.
  • Users can identify the The GQM approach to goal-oriented measurement.
  • Steve McConnell's most recent book, Software Project Survival Guide, starts with a drawing from Winnie-the-Pooh by A.A. Milne and the following caption: "Here is Edward Bear, coming downstairs now, bump, bump, bump on the back of his head, behind Christopher Robin.
  • Case studies can teach us valuable lessons.

Refinement

  • The GQM refinement steps are documented in a GQM plan, which has three parts: ♦ A goal that describes the measurement's purpose.
  • By stating explicit goals, the measurement program is given a clear context.
  • A GQM goal is described according to a template with five dimensions that express the object to be measured, the purpose of measurement, the measured property of the object (quality focus),the subject of measurement ,and the measurement's context . ♦.
  • A set of questions that refines the goal and reflects the implicit models of the software developers.
  • Questions related to quality models give a more detailed definition of the goal's quality focus.

Data analysis and interpretation

  • The GQM approach also helps analyze and interpret results by describing the measurement data needed to answer the formulated questions.
  • Independent of which analysis technique (statistical analysis, quantitative analysis, decision tree analysis) is applied, the results must be interpreted in close collaboration with the viewpoint team.

Fitting GQM to a measurement program

  • As part of the CEMP project, the authors established goal-oriented measurement programs in Schlumberger RPS,working closely with the teams who were running the projects the measurement programs were to support.
  • The GQM team is embedded in the quality assurance group and includes the quality assurance manager,a GQM coach,and a quality engineer.
  • The project developed both software and hardware for a real-time point-of-sale system.
  • The authors measurement program supported the project from the design phase until a year after its release.
  • Figure 2 shows the sequence of six activities relative to the six steps of the Quality Improvement Paradigm.

Characterize the organization and project

  • The GQM team has developed questionnaires, which either the project team or upper management fills in, depending on the kind of questions.
  • A separate quality assurance department controls the fulfillment of quality requirements.

Define measurement goals

  • Measurement goals can directly reflect business, project, and/or personal goals and must be based on selection criteria, such as priority to project or organization, risk, and time to reach the goal.
  • Goals should take the form of [object to be measured], [purpose of measurement], [quality focus], [viewpoint], [environment].
  • In the sample goal below, the boldface words correspond to these elements:.

Analyze the delivered product to better understand it with respect to reliability and its causes from the viewpoint of the software project team for the Schlumberger RPS Project A.

  • This product-oriented goal definition was the starting point in the process of understanding the product's reliability.
  • The project team could then investigate how to describe that reliability quantitatively and determine what influenced it.
  • Other goals gave us information about the cost and benefits of applying the GQM approach.
  • The authors consulted all project team members in defining their measurement goals and checked their degree of understanding and their motivation to reach them.
  • Without management support and commitment, the measurement program may ultimately fail.

Develop the measurement program

  • The major activity here is to refine selected goals into questions and metrics.
  • The refinement itself has two main parts.
  • The first is knowledge acquisition, in which the GQM team tries to capture the project team's current knowledge and represent it in quantitative or qualitative models.
  • The second part is measurement planning, in which the team documents the GQM refinement and corresponding measurement procedures.

Knowledge acquisition

  • The authors conducted structured interviews to make the engineers' implicit knowledge explicit, capturing the project team's definitions, assumptions, and implicit models related to the goal.
  • Authorized licensed use limited to: Eindhoven University of Technology.
  • During each interview,the authors recorded information on an abstraction sheet-a one-page presentation of the main entries,relationships,and related hypotheses for a goal in the GQM plan.
  • Many people find it is hard to distinguish between the quality focus and the variation factors.
  • This approach risks bias from the interviewers who are recording their implicit models,and requires the interviewers to have sufficient knowledge about the goal's context and subject.

Measurement planning

  • The aim of this stage is to produce a well-defined measurement program,documented in the GQM,measurement, and analysis plans.
  • As the authors described earlier, the GQM plan defines top-down what must be measured,moving from goal to question to metric.
  • The authors used several short follow-up interviews and an extensive team review to refine the plan.
  • The measurement plan contains ♦ a name and definition for each unique metric; ♦ the classification for each metric; ♦ an association point in product development that identifies when and how data is to be collected; ♦ definitions of the data collection forms; ♦ the procedures for data reporting,collection,and validation; and ♦ references to the metrics in the GQM plan.
  • There are many ways to analyze measurements, but not all will reflect key issues.

Execute the measurement program

  • The GQM team collects the measurement data according to the procedures defined in the measurement plan and pre-pares the analysis material in line with the analysis plan.
  • Before presenting the measurement data to the project team, the GQM team must thoroughly verify and validate it, checking at a minimum for the data's completeness, timeliness, and accuracy, and conformance to the specified range, and ensuring that each case is classified uniquely.
  • As they did in other steps,the GQM team worked closely with the project team while performing these checks.
  • The project team used an existing defect tracking tool to do most of the data collection.
  • The authors also designed paper forms to record several additional metrics on fault handling, using Microsoft Excel to aggregate the measurement data and represent it in charts and tables.

Analyze and interpret results using feedback sessions

  • Regular and well-prepared feedback sessions have been key to the success of their measurement programs.
  • The session's main objectives are to discuss the measurement program results, have the project team interpret the data,and define actions for the next measurement period.
  • The authors found that this interval is long enough to have new and interesting results for the next session and short enough to keep people's interest and momentum.
  • Because the authors cannot present all measurement results in one session,they usually select a subset of slides to present and distribute hard copies of the full set.
  • All feedback sessions lead to slight or significant updates in the analysis,measurement,and GQM plans.

Package results into reusable models

  • The authors present measurement program results on company bulletin boards and through monthly updates and project legacy reports to management.
  • The authors thus characterized all modules according to their reuse level and attributed every fault to new or reused software.
  • Figure 6 shows the fault density for these categories.
  • The figures helped them quickly identify trends and needed changes.

Results

  • The GQM-based measurement approach has been implemented as part of an organization-wide process improvement program.
  • As a direct result of the measurement program, interest in software reuse has increased and several other projects have renewed their efforts to develop reusable modules.
  • Through regular feedback of the measurement results, the authors avoid misinterpreting data and more synergistically integrate human expertise and formally derived analysis results.
  • Because their project teams met frequently, they could evaluate progress and define improvements to their daily processes-which is what software process improvement is really about.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

Adopting GQM-based measurement in an industrial
environment
Citation for published version (APA):
Latum, van, F., Solingen, van, D. M., Oivo, M., Hoisl, B., & Rombach, D. (1998). Adopting GQM-based
measurement in an industrial environment.
IEEE Software
,
15
(1), 78-86. https://doi.org/10.1109/52.646887
DOI:
10.1109/52.646887
Document status and date:
Published: 01/01/1998
Document Version:
Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)
Please check the document version of this publication:
• A submitted manuscript is the version of the article upon submission and before peer-review. There can be
important differences between the submitted version and the official published version of record. People
interested in the research are advised to contact the author for the final version of the publication, or visit the
DOI to the publisher's website.
• The final author version and the galley proof are versions of the publication after peer review.
• The final published version features the final layout of the paper including the volume, issue and page
numbers.
Link to publication
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners
and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
• You may not further distribute the material or use it for any profit-making activity or commercial gain
• You may freely distribute the URL identifying the publication in the public portal.
If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please
follow below link for the End User Agreement:
www.tue.nl/taverne
Take down policy
If you believe that this document breaches copyright please contact us at:
openaccess@tue.nl
providing details and we will investigate your claim.
Download date: 10. Aug. 2022

.
78 IEEE Software January–February 1998 0740-7459/98/$10.00 © 1998 IEEE
]
Adopting GQM-Based
Measurement in an
Industrial Environment
lthough software engineers generally agree that software measurement
must be goal oriented,little has been published on the results of shift-
ing to goal-orientation and still less on how to systematically make that
transition.Thus,when we at Schlumberger RPS decided to adopt the
Goal/Question/Metric approach,we resolved to document each step and record
our experiences at each stage of the transition.This article is both a summary of our
experiences and a brief description of how the GQM approach has greatly improved
our measurement programs.
We have tried to describe the activities in our measurement programs in a way
that will help more organizations shift to goal-oriented measurement.We hope
that others will also document their efforts so that the software engineering com-
munity can better understand the benefits of the GQM approach.
A
Schlumberger RPS integrated the Goal/Question/Metric
approach into their existing measurement programs to
improve their program performance.Key to their success
was the use of feedback sessions as a forum to analyze
and interpret measurement data.
Frank van Latum and Rini van Solingen,Schlumberger RPS,The Netherlands
Markku Oivo, Schlumberger SMR,France
Barbara Hoisl,Dieter Rombach,andGünther Ruhe,University of Kaiserslautern,Germany
Authorized licensed use limited to: Eindhoven University of Technology. Downloaded on January 21, 2010 at 10:01 from IEEE Xplore. Restrictions apply.

.
January–February 1998 IEEE Software 79
]
Motivation and background
Schlumberger RPS,the Retail Petroleum Systems divi-
sion of Schlumberger,manufactures and services systems
for self-service petrol stations,such as fuel dispensers,
point-of-sale systems,and electronic funds-transfer sys-
tems.Since Schlumberger began a software process im-
provement program in 1989,
1
the RPS division has
achieved a level 2 on the SEIs Capability Maturity Model,
Version 1.1. It has also introduced reviews and inspec-
tions,structured project planning and tracking,defect
tracking,and product quality specification and evalua-
tion.Processes have been certified to ISO 9001 and TickIT.
In late 1993,we began a systematic evaluation of
the RPS division’s measurement databases to assess
the effectiveness of measurement practices.The data-
bases contained data from most projects from the late
1990s to the time of the evaluation,representing more
than 6,000 data points.Our evaluation revealed sev-
eral weaknesses:Data points were often inconsistent
and incomplete. Because each measurement was
being done in isolation from the others,the measure-
ments tended to lack context and an explicit purpose.
We found that we could not even draw conclusions
about the effectiveness of our practices.
Experiences with goal-oriented measurement in
other organizations
2,3
seemed to offer a solution,so in
1994 Schlumberger RPS joined the Customized
Establishment of Measurement Programs (CEMP) pro-
ject,
4
which was already investigating heuristics and
cost–benefit information on applying goal-oriented
measurement in several European companies (http:/
www.iese.fhg.de/Services/Projects/Public-Projects/
Cemp.html).In this context,we evaluated the feasibil-
ity of implementing the GQM approach.
Elements of the GQM approach
The GQM approach
5,6
is a systematic way to tailor
and integrate an organizations objectives into mea-
surement goals and refine them into measurable val-
ues. As Figure 1 shows, it is characterized by two
processes: a top-down refinement of measurement
goals into questions and then into metrics,and a bot-
tom-up analysis and interpretationof the collected data.
The approach assumes that software development is
still an immature engineering discipline and thus much
is unknown about its characteristics and performance.Its
aim,therefore,is to create information that will help peo-
ple understand,monitor,evaluate,predict,control,and
improve software development.Users can identify the
Q1 Q2 Q3 Q4
Goal (object, purpose, quality focus, viewpoint, environment)
Refinement
Variation
factors
Quality
models
M1 M2 M3 M4 M5 M6 M7 M8
Analysis and interpretation
Implicit
models
Figure 1.The GQM approach to goal-oriented measurement.
Steve McConnell’s most recent book, Software Project Survival Guide, starts with a drawing from Winnie-the-Pooh by A.A. Milne and the
following caption: “Here is Edward Bear, coming downstairs now, bump, bump, bump on the back of his head, behind Christopher Robin. It
is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop
bumping for a moment and think of it.”
This new section, From the Trenches, is about sharing experience stories with colleagues in the software industry. From my perspective,
one of the most effective ways to avoid bumping my own head repeatedly against the same problem is to learn from others. Case studies
can teach us valuable lessons. Whether the outcome is positive or negative, they provide a wealth of practical knowledge representing
years of experience and hard work.
In this section, we offer software professionals a forum to share experiences. Its pages will present practical experiences using some
new methodology or technology, or give update reports about established tools and methodologies. Think about your own war stories. If
you feel that your experiences could benefit others, please submit them.
Your story may just help others from bumping their heads the same way you did.
—Wolfgang Strigel, editor
Wolfgang B. Strigel is president of the Software Productivity Centre Inc., Vancouver, Canada; wstrigel@spc.ca; http://www.spc.ca.
Authorized licensed use limited to: Eindhoven University of Technology. Downloaded on January 21, 2010 at 10:01 from IEEE Xplore. Restrictions apply.

information relevant to solve specific problems (goals)
and represent it in a way that others can easily interpret.
The basic ideas of the GQM approach
5,6
have been
adopted in process improvement methods such as the
Quality Improvement Paradigm
7
and AMI.
8
Refinement
The GQM refinement steps are documented in a
GQM plan, which has three parts:
A goal that describes the measurement’s pur-
pose.By stating explicit goals,the measurement pro-
gram is given a clear context.A GQM goal is described
according to a template with five dimensions that ex-
press the object to be measured,the purpose of mea-
surement,the measured property of the object (qual-
ity focus),the subject of measurement (viewpoint),and
the measurement’s context (environment).
A set of questions that refines the goal and reflects
the implicit models of the software developers.
Questions related to quality modelsgive a more detailed
definition of the goal’s quality focus.Questions related
to variation factors describe attributes that are believed
to affect the quality focus in that particular context.
A set of metrics that serves to answer each ques-
tion. Metric data may result from objective or subjective
measurement and can be related to
different scales as long as it is se-
lected carefully.
9
Data analysis and interpretation
The GQM approach also helps
analyze and interpret results by de-
scribing the measurement data
needed to answer the formulated
questions.Independent of which
analysis technique (statistical analy-
sis,quantitative analysis,decision
tree analysis) is applied,the results
must be interpreted in close col-
laboration with the viewpoint
team. Interpretation is generally
done in a feedback session.
Fitting GQM to a
measurement program
As part of the CEMP project,we
established goal-oriented measure-
ment programs in Schlumberger
RPS,working closely with the teams
who were running the projects the
measurement programs were to
support. We organized the GQM
team separate from the project
team to do all activities not directly
related to the project,such as docu-
menting the measurement program
and preparing analysis material.Our aim was to ensure
that project deadlines and stress would not endanger
the continuation of quality activities.In fact,we found
that close and confidential interaction between the pro-
ject and GQM teams was crucial to successfully applying
the GQM approach.
We have retained our initial composition and place-
ment of the GQM team,except that during the first mea-
surement program we had a GQM consultant acting as
the coach.We have since become GQM experts our-
selves so the coach is usually one of us.The GQM team
is embedded in the quality assurance group and in-
cludes the quality assurance manager,a GQM coach,and
a quality engineer.The team’s main activities are to
initiate measurement programs within devel-
opment projects,
carry out interviews and develop GQM deliverables,
check data collection from the project team and
handle available data,
prepare feedback sessions by creating analysis
slides,
moderate feedback sessions,
report progress to the project team and man-
agement,and
disseminate results.
80 IEEE Software January–February 1998
]
.
Package analysis
results into
reusable models
Characterize
organization
and project
GQM
Analyze
and
interpret
data using
feedback
sessions
Define
goals
QIP
Package Characterize
Execute
Choose
process
Analyze Set goals
Execute
measurement
program
Develop
measurement
program
Figure 2. The activities of fitting the Goal/Question/Metric approach into a measurement
program. We integrated the GQM approach into the Quality Improvement Paradigm.
Authorized licensed use limited to: Eindhoven University of Technology. Downloaded on January 21, 2010 at 10:01 from IEEE Xplore. Restrictions apply.

We have selected the first project for which we es-
tablished a measurement program to illustrate our
transition to a GQM-based measurement program.
The project developed both software and hardware
for a real-time point-of-sale system.The system was a
second release and reused much of the software from
the first release as well as from other projects.At the
end of the project,the product contained more than
70,000 source lines of C code.The project team in-
cluded a project leader,two hardware engineers,and
two software engineers.Our measurement program
supported the project from the design phase until a
year after its release.
Figure 2 shows the sequence of six activities relative
to the six steps of the Quality Improvement Paradigm.
The QIP describes the improvement activities and can
be applied to different tasks within software develop-
ment (project level) and improvement (organization
level).Each step has a corresponding measurement ac-
tivity in the GQM approach,as the figure shows.
Characterize the organization and project
The primary tool for characterization is a question-
naire that includes both quantitative and qualitative
questions,such as:What percentage of software people
are within the organization? What life-cycle model does
the project use? What is the average number of software
product installations?
The GQM team has developed questionnaires,
which either the project team or upper management
fills in,depending on the kind of questions.If there is
any confusion about the answers,the GQM team con-
ducts a short interview to clarify points.We have used
answers to these questions to define,prioritize,and se-
lect goals,as well as to build the GQM models.
For the sample project,results from the ques-
tionnaire showed that the organizations typical
project lasts six months;involves real-time,embed-
ded software products;and is developed using a
waterfall model with five steps:requirements analy-
sis and specification (REQ);high-level design (HLD);
detailed design and implementation (IMP); inte-
gration;and evaluation and release.A separate qual-
ity assurance department controls the fulfillment
of quality requirements.
Define measurement goals
Measurement goals can directly reflect business,
project,and/or personal goals and must be based on
selection criteria,such as priority to project or organi-
zation,risk,and time to reach the goal.Goals should
take the form of [object to be measured],[purpose of
measurement],[quality focus],[viewpoint],[environ-
ment].In the sample goal below,the boldface words
correspond to these elements:
Analyze the delivered product to better under-
stand it with respect to reliability and its
causes from the viewpoint of the software pro-
ject team for the Schlumberger RPS Project A.
This product-oriented goal definition was the start-
ing point in the process of understanding the prod-
ucts reliability.The project team could then investigate
how to describe that reliability quantitatively and de-
termine what influenced it.
Within a brainstorming session,a project team can
define many goals,but they may not know which are
the most critical to their organization’s business re-
quirements.To help us prioritize goals,we devised a
set of seven questions for the project team:
What are your organizations strategic goals?
What forces have affected your strategic goals?
How can you improve your performance?
What are your major concerns (problems)?
What are your improvement goals?
How can you reach your improvement goals?
What are possible measurement goals and their
priorities?
For the sample project,we selected measurement
goals that emphasized reliability (in keeping with the
characterization obtained in step 1) and reuse.The
goal just described,for example,would give us a bet-
ter grasp of reliability issues.Other goals gave us in-
formation about the cost and benefits of applying the
GQM approach.
We consulted all project team members in defin-
ing our measurement goals and checked their degree
of understanding and their motivation to reach them.
We also involved management by explaining how the
measurement goals would support their business ac-
tivities.This involvement is critical.Without manage-
ment support and commitment, the measurement
program may ultimately fail.
Develop the measurement program
The major activity here is to refine selected goals into
questions and metrics.The refinement itself has two
main parts.The first is knowledge acquisition,in which
the GQM team tries to capture the project team’s cur-
rent knowledge and represent it in quantitative or qual-
itative models.The second part is measurement plan-
ning, in which the team documents the GQM refinement
and corresponding measurement procedures.
Knowledge acquisition
We conducted structured interviews to make the
engineers’implicit knowledge explicit,capturing the
project team’s definitions,assumptions,and implicit
models related to the goal.These interviews helped us
January–February 1998 IEEE Software 81
]
.
To help us prioritize goals,
we devised a set of seven
questions for the project team.
Authorized licensed use limited to: Eindhoven University of Technology. Downloaded on January 21, 2010 at 10:01 from IEEE Xplore. Restrictions apply.

Citations
More filters
01 Jan 1998
TL;DR: Data types Sorting and searching parallel and distributed algorithms 3.0 and 4.0 are presented, covering sorting, searching, and distributing in the context of distributed systems.
Abstract: data types Sorting and searching parallel and distributed algorithms 3. [AR] Computer Architecture

833 citations

01 Jan 2000
TL;DR: An abstraction sheet is a one-page summary of a GQM plan that is used for structuring the presentation and interpretation of measurement data during feedback sessions.
Abstract: ion sheets are a powerful tool that can be used during the set-up of the measurement programme: information from interviews can be organised in a structured way and copied from the abstraction sheets into the GQM plan. However, abstraction sheets can also be used for structuring the presentation and interpretation of measurement data during feedback sessions. In fact, an abstraction sheet is a one-page summary of a GQM plan. Not all direct measurements defined in a GQM plan are represented on abstraction sheets, only the basic ones that reflect the most important metrics. An example of an abstraction sheet is shown in Figure 6-4. Deliverable(s) 6.3: Set of interview reports and abstraction sheets. Object Purpose Quality Focus Viewpoint Delivered Understanding Reliability and Project Team Product its causes Quality Focus Number of failures: • by severity • by detection group • number of faults • by module Variation Factors

121 citations

Journal ArticleDOI
TL;DR: It is shown that interrupting this process can significantly reduce a developer's efficiency and can even contribute to project delays.
Abstract: Software development is a highly abstract process that requires intense concentration. The authors show that interrupting this process can significantly reduce a developer's efficiency and can even contribute to project delays.

116 citations

Journal ArticleDOI
TL;DR: An approach is proposed that complements SD modelling with descriptive process modelling and goal-oriented measurement performed according to the principles of the well-established goal/question/metric (GQM) paradigm, called integrated measurement, modelling and simulation (IMMoS).

52 citations


Cites methods from "Adopting GQM based measurement in a..."

  • ...Recent industrial experience of measurement and model building according to GQM has been published by van Latum et al. (1998)....

    [...]

Proceedings ArticleDOI
04 Apr 2001
TL;DR: Two major additions to the GQM (Goals/Questions/Metrics) method are presented based on seven years of experience with goal-oriented measurement programmes, which concern a thorough elaboration of the feedback of measurement data and a conjoined cost/benefit analysis of the G QM project.
Abstract: Two major additions to the GQM (Goals/Questions/Metrics) method are presented based on seven years of experience with goal-oriented measurement programmes. GQM, is a method to organize software measurement programmes. Since the initial ideas of GQM were first published, much industrial experience has been gained and theory has been developed to underpin the approach. Two additions concern a thorough elaboration of the feedback of measurement data and a conjoined cost/benefit analysis of the GQM project. The first addition refers to establishing conditions that are necessary to facilitate learning in software measurement programmes. Learning about software quality is identified as the most important objective of a measurement programme. The second addition refers to identifying whether the measurement programme was actually worthwhile. Through a cost/benefit analysis, the software measurement activity is brought in perspective with other business objectives. Case study research illustrates the importance of both additions. In the past seven years, we have been involved in 15 measurement programmes in five industrial organizations. Successes and failures in these organizations support the importance of both additions. The two additions (feedback sessions and cost/benefit analyses) are described in detail.

50 citations

References
More filters
Journal ArticleDOI
TL;DR: The TAME system is an instantiation of the TAME software engineering process model as an ISEE (integrated software engineering environment) and the first in a series of Tame system prototypes has been developed.
Abstract: Experience from a dozen years of analyzing software engineering processes and products is summarized as a set of software engineering and measurement principles that argue for software engineering process models that integrate sound planning and analysis into the construction process. In the TAME (Tailoring A Measurement Environment) project at the University of Maryland, such an improvement-oriented software engineering process model was developed that uses the goal/question/metric paradigm to integrate the constructive and analytic aspects of software development. The model provides a mechanism for formalizing the characterization and planning tasks, controlling and improving projects based on quantitative analysis, learning in a deeper and more systematic way about the software process and product, and feeding the appropriate experience back into the current and future projects. The TAME system is an instantiation of the TAME software engineering process model as an ISEE (integrated software engineering environment). The first in a series of TAME system prototypes has been developed. An assessment of experience with this first limited prototype is presented including a reassessment of its initial architecture. >

1,351 citations

Journal ArticleDOI
TL;DR: An effective data collection method for evaluating software development methodologies and for studying the software development process is described and results show that data validation is a necessary part of change data collection.
Abstract: An effective data collection method for evaluating software development methodologies and for studying the software development process is described. The method uses goal-directed data collection to evaluate methodologies with respect to the claims made for them. Such claims are used as a basis for defining the goals of the data collection, establishing a list of questions of interest to be answered by data analysis, defining a set of data categorization schemes, and designing a data collection form. The data to be collected are based on the changes made to the software during development, and are obtained when the changes are made. To ensure accuracy of the data, validation is performed concurrently with software development and data collection. Validation is based on interviews with those people supplying the data. Results from using the methodology show that data validation is a necessary part of change data collection. Without it, as much as 50 percent of the data may be erroneous. Feasibility of the data collection methodology was demonstrated by applying it to five different projects in two different environments. The application showed that the methodology was both feasible and useful.

1,172 citations

Book
01 Apr 1991
TL;DR: The book has been comprehensively re-written and re-designed to take account of the fast changing developments in software metrics, most notably their widespread penetration into industrial practice.
Abstract: From the Publisher: This book is the Second Edition of the highly successful Software Metrics: A Rigorous Approach. The book has been comprehensively re-written and re-designed to take account of the fast changing developments in software metrics, most notably their widespread penetration into industrial practice. Thus there are now extensive case studies, worked examples, and exercises. While every section of the book has been improved and updated, there are also entirely new sections dealing with process maturity and measurement, goal-question-metric, metrics plans, experimentation, empirical studies, object-oriented metrics, and metrics tools. The book continues to provide an accessible and comprehensive introduction to software metrics, now an essential component in the software engineering process. Software Metrics, 2/e is ideal for undergraduate and graduates studying a course in software metrics or software quality assurance. It also provides an excellent resource for practitioners in industry.

1,094 citations

Book
01 Feb 1992
TL;DR: In this paper, the authors present a company-wide program with over 70 charts and graphs from real projects that will help project managers to manage software projects and process improvements more effectively.
Abstract: At last! New experiences and lessons from one of the authors who brought you Software Metrics: Establishing a Company-Wide Program. This exciting book has over 70 charts and graphs from real projects that will help you to manage software projects and process improvements more effectively. Project managers: Learn through practical examples what to measure and track, which will help you more effectively manage your projects throughout the life cycle. Learn how to measure and present progress. Most importantly, learn why you need to measure and how important it is for you to tie your measurements to visible, agreed-upon project goals. People responsible for process improvement: Learn a useful model for understanding organizational limitations. Explore the relationship between tools and the potential for achieving improvements. Examine some of the potential problems you might face and see examples of how some of them have been avoided. Finally, discover how metrics can be rolled up into useful, balanced organizational indicators. This book emphasizes proven practices and results.These include: *Which software development "rules" are supported by measured evidence *How measurement should be tightly linked to organizational strategies *How the metrics that engineers find useful help project managers as well *What people feel about metrics and what approaches you can take to gain their support *How metrics are used to achieve continuous process improvement *Which measures are meaningful for a large organization

642 citations

Journal ArticleDOI
H. Wohlwend1, S. Rosenbaum
TL;DR: Improvements in many development areas are seen, including project planning and requirements management, and the catalysts behind these advances include capability assessments, training, and collaboration at Schlumberger.
Abstract: A corporate-wide software process improvement effort has been ongoing at Schlumberger for several years. Through the motivation efforts of a small group, productive changes have occurred across the company. We see improvements in many development areas, including project planning and requirements management. The catalysts behind these advances include capability assessments, training, and collaboration. >

103 citations

Frequently Asked Questions (1)
Q1. What are the contributions in "Adopting gqm-based measurement in an industrial environment" ?

• A submitted manuscript is the version of the article upon submission and before peer-review. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher 's website. The final author version and the galley proof are versions of the publication after peer review. The final published version features the final layout of the paper including the volume, issue and page numbers.