Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!ut-emx!tivoli!alan
From: alan@tivoli.UUCP (Alan R. Weiss)
Newsgroups: comp.software-eng
Subject: Re: Code inspections
Message-ID: <370@tivoli.UUCP>
Date: 12 Feb 91 00:16:12 GMT
References: <14964@megatest.UUCP> <40530@genrad.UUCP> <7362@tekchips.LABS.TEK.COM> <29653@mimsy.umd.edu> <349@tivoli.UUCP> <3108.27aeae3b@iccgcc.decnet.ab.com>
Reply-To: alan@tivoli.UUCP (Alan R. Weiss)
Organization: Tivoli Systems Inc., Austin, TX
Lines: 59

In article <3108.27aeae3b@iccgcc.decnet.ab.com> kambic@iccgcc.decnet.ab.com writes:
>In article <349@tivoli.UUCP>, alan@tivoli.UUCP (Alan R. Weiss) writes:
>> In article <29653@mimsy.umd.edu> cml@tove.cs.umd.edu (Christopher Lott) writes:
>>>In article <40530@genrad.UUCP>, mas@genrad.com (Mark A. Swanson) writes:
>[...]
>> I absolutely agree.  Still, as people get better at inspections,
>> the name of the game really IS getting those defect Finds during
>> inspections way up.  The trick is to not make it personal, but acknowledge
>> that software engineering is iterative and social in nature (see Weinberg,
>> Boehm, et. al).
>> 
>[...]
>There seems to have been little discussion in this thread on the training 
>required for doing inspections.  Creating the atmosphere for, and then 
>running proper inspections takes time, money, training, schedule impact,
>and potentially changes in either the psychology and/or staff of  the 
>organization.  Are they valuable?  Absolutely.  Are they free?  Not initially.
>The resultant value for some organizations has been measured as is part of the 
>literature.  IMHO most organizations have to go through some type of 
>justification of the value, and should continue to measure the value in
>terms of $ and time.
>
>GXKambic
>Allen-Bradley
>Standard disclaimers.


Inspections DO take training.  Distinguished from "code walkthroughs"
and "code reviews", inspection methodology can be (and SHOULD be)
applied to all deliverables, especially specifications.

We have found that training takes about a day, with reinforcement
during actual inspections by the Lead Moderator.  We learn by doing.
We decided to absorb the day's "cost" because of the high return on
investment.  The schedule "impact" is all positive, IMHO.  We believe
that inspections bring to light design issues faster than by using (endless,
unstructured) meetings by forcing people to do their homework *before*
the inspection meeting.   There undoubtedly is more up-front time devoted
to specification generation, but we're firmly convinced that this will yield
a MUCH cleaner and MUCH faster back-end (Integration, Functional, and System
Test/Beta Test) process resulting in schedule AND design achievement.



	.-------------------------------------------------------.
	|  Alan R. Weiss                                        |
	|  Manager, QA and Mfg.  _______________________________|
	|  Tivoli Systems, Inc.	| These thoughts are yours for  |
	|  Austin, Texas, US	| the taking, being generated   |
	|  512-794-9070		| by a program that has failed  |
	|  alan@tivoli.com	| the Turing Test. *value!=null;|
	|_______________________________________________________|
	|#include "std.disclaimer" --- Your mileage may vary!   |
	.-------------------------------------------------------.

"Quality is never an accident.  It is always the result of high intention,
sincere effort, intelligent direction, and skillful execution.  It represents
the wise choice of many alternatives."