From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
Subject: Re: When do we inspect
Reply-To: jhull@vulcan-gw.den.mmc.com
Organization: Martin Marietta Astronautics Group
Date: Mon, 21 Dec 1992 18:42:24 GMT

In article <1992Dec18.145952.26062@saifr00.cfsat.honeywell.com> shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
ms>WHEN should software be inspected? ...
ms>Should software be inspected and put into
ms>a configuration management system months before design is
ms>complete and months before scheduled delivery ...


In article 6r0@NeoSoft.com, 
claird@NeoSoft.com (Cameron Laird) writes:
cl>I assert:  source code should go into the CM system
cl>from its first day.  ...  Some ob-
cl>ject that checking in source is too much overhead; for
cl>me, that's only a symptom that the check-in process
cl>isn't yet adequate.  Coders should *want* the benefits
cl>of even the most rudimentary CM:  automated regression
cl>testing, static semantic analysis, validation of
cl>porting considerations, ...

Au contraire.  Since we are not yet, and may never be, at a
point where we all think alike and work alike, I suggest that
each programmer should be allowed to do his or her own work 
in whatever manner allows them to be most productive.  If
that involves some form of CM, fine.  But if not, so what.

I suggest that a unit of code should enter a "Software
Development Library" at the time when the individual team
member has finished coding and unit testing it.  At that 
time, some or all of the team should review it to ensure
that it meets the team's internal quality standards (what
ever they are).  The SDL should be controlled by the team
lead (or his/her designated representative) and any
changes to code entered into the SDL require the team lead's
signature.  The team lead, in conference with the team,
should decide how much or little formality and checking
is required for such changes.

Suppose Team A is responsible for developing software Unit 
A and Team B for Unit B and that Unit B must use some
service of Unit A.  

I further suggest that there should be a "Project Software
Library" controlled and managed by a Software Quality
Assurance group/team/organization, and that Unit A must be
entered in the PSL prior to being released for use by Team
B.  The SQA team, in conference with all other development
teams, should develop an appropriate set of quality checks
and procedures for entering such software into the PSL and
for changing/enhancing it as the project moves through the
development cycle.  These checks and procedures should 
include notification of all teams "registered" as users of 
a given unit that the unit has been changed, notification
to the developing team that an error has been found, etc
and should focus on being flexible enough that they do not
impede the development process.  These procedures should be
designed to make things easier for developers; they are
*not* intended to ensure the quality of the final product
(i.e., if there is any conflict between facilitating the
development process and ensuring that the final product
meets spec, it should be resolved in favor of facilitating
the development process).

The SQA team, in conference with all other development teams 
and personnel from the corporate staff, should also develop 
an appropriate set of quality checks and procedures for 
verifying the function and performance of the software prior
to delivery to the customer.  This set of checks and pro-
cedures should be quite different from the set suggested
above (i.e., if there is any conflict between facilitating 
the development process and ensuring that the final product
meets spec, it should be resolved in favor of ensuring the
quality of the final product).




-- -- -- --  --
	   _   _
    /_    / ) / ) Jeff Hull           j.hull@vulcan-gw.den.mmc.com
   //_) -/- -/-   1544 S. Vaughn Cir  
/_/ \_/ /   /	  Aurora, CO 80012    303-977-1061

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

Newsgroups: comp.software-eng,alt.sources.d,comp.sources.d