Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!agate!ucbvax!ucsd!nosc!manta!norton
From: norton@manta.NOSC.MIL (Scott Norton)
Newsgroups: comp.software-eng
Subject: Re: Software Quality
Summary: ~(Us vs Them)
Keywords: Quality, Metrics, Process Improvement Team, TQM
Message-ID: <1853@manta.NOSC.MIL>
Date: 27 Mar 91 02:10:17 GMT
References: <SBANG.91Mar13155652@empty4.iesd.auc.dk> <36650001@hpopd.pwd.hp.com> <3955.27ee3172@iccgcc.decnet.ab.com>
Organization: Space & Naval Warfare Systems Command
Lines: 55

In article <3955.27ee3172@iccgcc.decnet.ab.com> kambic@iccgcc.decnet.ab.com writes:
>In article <36650001@hpopd.pwd.hp.com>, daves@hpopd.pwd.hp.com (Dave Straker) writes:
>[...SLIGHTLY EDITED...]
>>>  To attach metrics to this fundamental activity of
>>> process quality improvement--"let's see, last month THE CODE WAS 7.2 on our
>>> quality index, this month THE CODE 8.1: good CODE!"--is ... well, I
>>> don't have the words to describe it.
>> 
>> "Process data must not be used to compare projects or individuals. Its
>>  purpose is to illuminate the product being developed and to provide an
>>  informed basis for improving the process. When such data is used by
>>  management to evaluate individuals or teams, the reliability of the 
>>  data itself will deteriorate."
>> 
>>      --- Watts Humphrey, "Managing the Software Process", Addison Wesley 1989
>No question about the statement.  Now, even with all of the good words, how do
>we get Humphrey's principle into a useful paradigm.  If x produces buggy code
>from month to month to month, does management let it continue or do they get
>this person into a bug reducing class.  Or do they continue to rework the code
>because the "data must not be used.." to evaluate x.  Tough problem.  This may
>be taking the problem to an extreme but if data indicates that the problem may
>be in a person's techniques or style, what do you do if you are management or a
>member of a team?

You have to "embrace the new philosophy" and "Drive out fear."

The TQM way of using the metric is that the metric that quantifies the
buggyness of the code was developed in the first place by people
who were part of the code writing process: maybe a spec writer, a
coder, and a tester.  _They_ are the ones who decided that
mistakes in the code-writing process might be causing poor quality
in their product (internal product, such as the modules they write).
So, they establish the metrics and apply them.  They notice that coder
"X" has a higher bug rate, and ask management to get "X" more training.

In the jargon of TQM, the group that tries the metric and evaluates
its result is a "Process Action Team."  It is composed of the experts
on the process: the people who do it.  It can be augmented by outside
specialists.  The classic example is a statistician, but here an expert
in software metrics could be called to give his advice, but the Process
Action Team will apply the metrics, evaluate the results, and recommend
options to improve the process.

Finally, the team will continue to monitor the process, and see that
sending coder "X" to school actually helped.

I'm not trying to minimize the difficulty of choosing good metrics
and applying them properly.  In this example, I might look at counting
modules that failed unit test, and maybe group them by some causes
like "Ambiguous spec", "Math error", "Typo", "Control Flow Error",
and "All Others", and then if it turns out that All Others has
the only significant data, break it down again.  But I'm not in the
process; I don't know it the way those programmers do.

LT Scott A. Norton, USN  <norton@NOSC.MIL>