NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/software/5126

Text File | 1992-12-22 | 6.1 KB | 135 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!thor!jhull
From: [e-mail] (Jeff Hull)
Subject: Re: Debugging the process
Message-ID: <[e-mail]>
Summary: Both process & product quality are important.
Keywords: "sie cmm" "sw engineering" "process improvement" "sw quality"
Sender: [e-mail] (News)
Nntp-Posting-Host: thor.den.mmc.com
Reply-To: [e-mail]
Organization: Martin Marietta Astronautics Group
References: <[e-mail]>
Date: Tue, 22 Dec 1992 20:12:49 GMT
Lines: 119

Bill Watt's excellent article focusses our attention once again on
the real goal:  producing high quality (sw) porducts.  In general,
I agree with what he says.  But to carry the discussion a little
further:

In article [e-mail],
[e-mail] (Bill Watt) writes:
|>
|>Hypothesis:
|>  Software quality improvement should be done by
|>  inspecting products: first, to find and fix defects, and second,
|>  to gather data in order to identify and prevent defects.

I agree that these 2 tasks are (a large) part of the process, but
not all of it.  Efforts to improve the process itself must be
included.  Process improvement, vs. product improvement, is the
focus of SEI's Capability Maturity Model.


|>1. It is not necessary ...
|>2. Dr. Humphrey emphasizes ... One should start
|>with inspections and add management practices from the SEI list as
|>required to eliminate the causes of defects.
|>4. Eliminating defects ...
|>5. After starting inspections, wait ...

I agree with everything Bill says in paragraphs 1, 2, 4 & 5.  The
last sentence of para 2 is included for emphasis.


|>3. ... Defects arise mostly from problems in the way the work is
|>organized, not from the way individuals perform.

I also agree with the idea expressed in para 3, but not with the
last sentence.  I have no data from which to derive "mostly" or
to form the basis for disagreement, but I believe that the way
individuals perform is or can be part of the problem.  Furthermore,
I want to call attention to the fact that "the work is organized"
is part of the software development process (which needs improve-
ment - SEI CMM again).


|>6. The SEI model is the process equivalent of the waterfall model.
|>As such it has limited application. Also, it is the wrong way
|>around in the sense that it leaves process improvement by
|>statistical quality control to the final level. The insistence
|>that the whole process be defined and in place in order to benefit
|>from statistical quality control is in error because the
|>individual worker (the indivisible atomic process) and and every
|>part of a process producing something tangible can benefit from
|>statistical methods.

My understanding of the CMM differs from what I infer is Bill's in
that he seems to believe that the CMM requires (or suggests or even
encourages) delaying the implementation of product quality metrics
and atomic process quality metrics until "the final level" while my
understanding of the model is that a company should make its own
decision about when to implement these metrics, but that the company
cannot be deemed to have achieved Level 4 until after they have been
implemented.  I would agree with Bill that a company would (probably)
be making a serious mistake to defer implementation of such metrics
until after they had done everything else to achieve Level 4.

One issue, that to my mind is still unresolved, is identification of
what specific elements of sw process quality and sw product quality
are important and what metrics are appropriate to measure them.  This
is a different & very involved discussion, of course, but it does
impinge on this one, because the identification of elements & metrics
must be completed before the metrics can be implemented.  Each company
must decide for itself where it will receive the greatest return on
investment.  Some may choose to first address immediate product quality
inprovement while others choose to address process quality first.


|>7. Of the two approaches to quality, a) defined as having
|>desirable properties, b) defined as having no undesirable
|>properties (defects), the second is more promising in that it is
|>measurable and controlable with statistical methods.
|>
|>
|>8. The software development process is not the problem. The
|>quality of the input to the process is the greater problem. More
|>benefit will come from client capability assessment than from
|>software developer capability assessment. Software engineering
|>has been through this before as it was attempted to prove program
|>correctness. It should have been evident then that programmers
|>were not making the mistakes, customers and their systems analysts
|>were making the mistakes in not specifying requirements correctly.
|>One can't build systems for clients who a) don't know what they're
|>doing, b) can't agree among themselves on what they want, and c)
|>don't have any time to devote to the project.

I think there is a cognitive disconnect between these 2 paragraphs.
I suggest that "the quality of the input to the [software development]
process" is the same as or very similar to "defined as having
desirable properties."  While I believe that the software development
process has flaws that make it part of the problem (vs. "not the
problem"), I agree completely & whole-heartedly with Bill that "the
quality of the input to the process is the greater problem."  This
suggests that we should devote a large portion of our efforts to
developing adequate requirements specification methods & techniques.

I suggest that all statistical and metric based methods and techniques
address the 7b type of quality and that we will never achieve an
acceptable level of customer until we address the 7a type of quality,
aka correct requirements specification.

Bill, thanks for a great article.


--- --- --- --- ---
       _   _
    /_    / ) / ) Jeff Hull           [e-mail]
   //_) -/- -/-   1544 S. Vaughn Cir
/_/ \_/ /   /      Aurora, CO 80012    303-977-1061

No matter where you go ... there you are.
#include <standard.disclaimer.h>