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

Text File | 1992-12-22 | 9.6 KB | 219 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!gatech!darwin.sura.net!udel!rochester!rocksanne!news
From: [e-mail] (Mike Kirby)
Subject: Re: Debugging the process
Message-ID: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Xerox Corporation, Webster NY
References: <[e-mail]>
Date: Tue, 22 Dec 1992 19:32:38 GMT
Lines: 206

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

Insepction is one way to help improve quality in any software
organization.  It is not the only way, and should be used in concert
with other methods.  Inspections are, by definition, after the fact.
It would be nice if we could produce a product with assurance that the
process was so good that we don't need inspections.

>
>1. It is not necessary to follow the SEI model to benefit from
>statistical quality control in software development. Inspections
>can be done on any product (specs, design, code, test cases,
>documentation). One can start any time. One does not have to wait
>until SEI level 5. Inspections serve two purposes: first, to find
>and fix defects; second, to accumulate data on the kinds of
>defects encountered and then guide management in removing the
>causes of the defects. As Dr. Demming has shown, using inspections
>to remove causes of defects reduces the cost of rejects, reduces
>the cost of rework, and eventually reduces the cost of inspections.
>

I disagree.  If you are doing inspections and they are working, a number
of events have already taken place.  First, management is supporting
you.  This is most likely because a case has been made to them about
how much money they can save, exactly how much time and resources it
will cost.  They have taken this into account in their schedules and
budgets and have provided engineering with the appropriate resources.
Management holds regularly scheduled review meetings to determine the
effect of the inspections and to ensure that the results from
inspections are taking effect.  Management has also provided you with a
development environment where you can control the changes made to the
products by the inspection teams.

If the engineering team has different software products (like specs,
design, code) and it is produced under well documented standards (as
the inspection process requires) then it can be argued that a group has
a defined engineering process.  The results of each stage of the
process are inspected for defects and changes are made to the product
as specified.

Fagan's formal inspection technique demands a significan amount of
metrics.  These metrics are really what make the inspection technique
worth doing.  Without them you cannot tell whether or not all the time
and energy (which is not small) that went into the inspection process
payed off.  Management will want to know what the payback is in
specifics.

What I have just described are a management process, an engineering
process, and a metrics program. (although the metrics program is a
product metrics, not process).  With this type of base an organization
is probabaly a level 3 organization.  With this an organization will be
in continous improvement of product.  With the adition of process
metrics they will be able to predict product quality and identify
process faults.  A Level 5 organization will continously improve
process based on the metrics installed at the previous level.

>
>2. Dr. Humphrey emphasizes in "Managing the Software Process" that
>the SEI model is for the development of large, complex software
>products. One example he uses is a product (an IBM operating
>system, I believe) developed at 13 laboratories spread over 8
>countries. For this kind of project the process should probably be

I don't believe that the SEI model is very complex.  It is quite simple
actually, Common sense probabaly.  And it is flexible enough so that
portions which do not apply to a particular shop can be left out
(sub-contract management for example).

>as complex as the SEI model. But not necessarily. One should start
>with inspections and add management practices from the SEI list as
>required to eliminate the causes of defects.

How are you going to convince management to allow you to spend the
resources on inspection if they don't have a process in which to
allocate and schedule resources.  It is possible to start with
inspections on code and slowly add engineering practices as you slowly
move up the development cycle in your inspections.

>

>
>3. If software workers (are unionized and) object to inspections
>because the findings may be used to substantiate terminations, an
>independent auditor should moderate the inspections and provide a
>periodic impersonal statistical summary of the defects to
>management. These should be posted and employees encouraged to
>offer suggestions on changing the process to eliminate causes of
>defects. Defects arise mostly from problems in the way the work is
>organized, not from the way individuals perform.
>

A Key point.  Note that this is part of the management process.
Management needs to organize and communicate the inspection process.
Engineering needs to implement it effectively.

>
>4.
[ Good Point Deleted]

>>5. After starting inspections, wait until the stats settle down
>before making any management changes. Starting inspections will
>tend to decrease defects without any management changes as workers
>use the feedback to change their individual processing. After they
>have done so take the remaining defects to management for changes
>to the organization of the work. Also, as Dr. Demming points out,
>if the process isn't stable you can't measure the effect of changes.
>

Since this requires (some) process, you must at least be level 2.  It
also seems quite reasonable that if you do not have an engineering
process then it becomes difficult to identify the cause of the
problem.  Is it a known and documented management technique?  Or is it
an unknown and undocumented engineering technique.  Only with a
documented engineering process and a documented management process AND
process measurements can we make changes to the process based on
product failures.

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

NO, NO, NO, NO,  (deep breath...Count to 10)

All the SEI is saying is that you need to have a management process in
place before an engineering process will be able to take hold.  and you
need both processes before you can determine if a product failure is
due to engineering or to management.  AND you need to be able to
measure both.  Once you can do these things then you will be able to
continously improve the processes.

It seems quite reasonable that limited process measures should be
installed as the processes are put in place.  Improvements on the
process can be made prior to the progress to the next step.
Unfortunately if this is followed immediately by a product failure
(late project, poor engineering, etc), does this imply that the process
change was bad? Or was the fact that we have no engineering process the
cause of the blame?  We don't know.  All we can measure is our
managememt process.  We don't know if the engineering process suffered
because we have none.

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

In the SEI's model, this IS the software development process.  From the
establishment of requirements, through the management of each phase in
the lifecycle, to the support of the end product.  All of this has
process elements that are contribute to the overall quality of the
end product.  The SEI is saying the you must document all these
processes and measure them and from the measurements change
the documentation to reach continous PROCESS improvement.  Product
improvement is something else that a good process should do.


>
>
>Would like to hear from those studying cause and effect
>relationships in software defects, and categorizing ways of
>preventing different kinds of defects in different kinds of
>systems.
>
>
>Wm. R. Watt


Sorry for the long winded reply.

Mike Kirby
Xerox Corp
E-mail: [e-mail]