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

Text File | 1992-12-22 | 5.7 KB | 121 lines

Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!ukma!cs.widener.edu!dsinc!ub!csn!news.den.mmc.com!thor!jhull
From: [e-mail] (Jeff Hull)
Newsgroups: comp.software-eng
Subject: Re: When do we inspect
Message-ID: <[e-mail]>
Date: 22 Dec 92 16:48:35 GMT
References: <[e-mail]>
Sender: [e-mail] (News)
Reply-To: [e-mail]
Organization: Martin Marietta Astronautics Group
Lines: 107
Nntp-Posting-Host: thor.den.mmc.com

|>In article <[e-mail]>
[e-mail] writes:
|>I suggest ... a "Software
|>>Development Library"
|>
|>>I further suggest ... a "Project Software
|>>Library"


In article [e-mail],
[e-mail] (Mark Shanks) writes:
|>I guess Jeff's description of a "SW Development Library" is
|>less restrictive than a typical CM system. ...
|>Why start that process any sooner than necessary?

I agree with Mark's other comments, but wanted to expand a
little on this one.

The point is that different phases of a project require differing
degrees of CM to function well.

I know from my own experiences as a programmer that it is quite
possible to "get lost" in versions of code that I have designed
myself and am developing by myself.  Most of us develop our own
techniques for dealing with this level of complexity and I
believe that the greatest productivity will result from allowing
people to continue to use their own techniques in this area.  Of
course, when a programmer, usually junior, joins our team who has
not yet developed such techniques, a more senior member of the
team should assist them in developing some (mentoring).

Beyond an individual programmer's efforts, however, more formal
methods are required.  Many companies and projects immediately
jump into full-blown CM at this point, a practice which is *very*
counterproductive.  In the earlier phases of a project (aka the
earlier stages of a product's life cycle), a high degree of
flexibility is required to permit the design team (and later, the
development team) to derive an adequate solution to the problem.
Some design (or development) team members cite this fact as
justifying no controls at all, an equally serious error.  Turning
our common art form (software development) into an engineering
discipline requires a more repeatable approach.  Therefore, my
suggestion of a Software Development Library.

The SDL should probably use the same software tools as the more
formal Project Software Library (about which more below).  The SDL
should include checkout for use, checkout for editing, approval by
the software development lead (or his/her designated representative)
required for checkout for editing, and checkin after editing with
comments on the change.  This should cost much less (in programmer
time to use & support staff time to administer & engineering support
for inspections) because we do not include the degree of review and
documentation required for the PSL.  The approval authority is next
door and requires only the normal design discussions (Is this change
really necessary?  Is this the best way to fix the problem?) with
one's immediate peers rather than a full review board.  There is
little or no value gained from a written software problem reporting
(SPR) and tracking system at this phase.  Proper use of make & RCS
(or your chosen version control system) reduces the programmer cost
to actually use the system.

If your project is large (you define large), it may also be beneficial
to establish a Software Library for the Software Integration Team.
Software turnover from the development team to the integration team
is accomplished by entering the software unit into that library.
There is some disagreement about the value of an SPR system at this
phase.  I tend to avoid them here.

Software turnover from either the development team or the integration
team to the quality assurance team is accomplished by entering the
software, either a unit at a time or all at once, in the Project
Software Library.  The PSL must use the same software tools as will
be used during the Operation & Maintenance (O&M) phase of the product's
life cycle, but, again, the degree of formality is not (quite) as high.
The approval authority for changes is still on the project, i.e., does
not involve the customer or end-user representatives (who may be
involved after the product enters the O&M phase).  There should be an
Engineering Change Board which includes representatives from project
planning & scheduling & from every technical group on the project.
The ECB passes on the need for a change.  There should be a
Configuration Control Board which passes on the quality of a completed
change, i.e., that it has been properly tested, properly documented,
etc.  The PSL should include software problem reports (SPRs) generated
by the testing (aka requirements verification) team & answered by the
development (or integration) team.

Software turnover from the project, i.e. the developing organization,
to the maintaining organization is again accomplished by entering
software into the appropriate library, this one with the full-blown
CM system in all its complexity and formality.

After more than 20 years in this business, working on projects as
small as 1000 SLOC and as large as 1,000,000 SLOC, I am convinced
that multiple, staged software libraries, with increasingly more
formal CM as the project advances, are an essential part of
software engineering.



-- -- -- --  --
       _   _
    /_    / ) / ) 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>