Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!ut-emx!tivoli!alan
From: alan@tivoli.UUCP (Alan R. Weiss)
Newsgroups: comp.software-eng
Subject: Re: Accepted Practices
Message-ID: <814@tivoli.UUCP>
Date: 10 Jun 91 22:12:08 GMT
References: <1991Jun6.125833.18549@dec254.uucp> <1991Jun6.101639.1@happy.colorado.edu> <1991Jun7.171606.5862@intellistor.com>
Reply-To: alan@tivoli.UUCP (Alan R. Weiss)
Distribution: usa
Organization: Tivoli Systems Inc., Austin, TX
Lines: 46

In article <1991Jun7.171606.5862@intellistor.com> wicklund@intellistor.com (Tom Wicklund) writes:
>>> 
>>> Anyone care to comment?
>
>>A few comments:
>
>>First, the IEEE is trying to do this (after a fashion) by establishing 
>>guidelines and standards for various kinds of project documents (Requirements
>>docs, design docs, user docs, etc.)  They also have standards for creating
>>QA plans, CM plans and test plans.  Together, these go a fair way towards
>>defining what it is that a software engineer is supposed to know about and
>>do on the job.  The DoD's 2167 standard also seems to have this goal in mind.
>
>
>Unfortunately, from what I can tell the emphasis in documentation
>standards (whether IEEE or DOD 2167) seems to be in generating paper
>in the correct format.  Very often format is more important than
>content when documents are required.  While supposed to improve
>software quality, they seem to do so by making it as hard as possible
>to make a change to allegedly working software.


Oh, I don't know ... I just used ANSI/IEEE 829-1983, "IEEE Standard
for Software Test Documentation" in creating my System Test Plan.
I found it to be tailorable, succinct, and not at all difficult
to understand.  It forced me (well, more like reminded me) to think
of various aspects of testing, and most importantly my Plan was
under 25 pages long and is well-organized for inspection.  BTW,
we're using the standard as the reference standard.

(Yes, that's right:  the QA/Test deliverables get inspected just
like the Development deliverables.  What's good for the goose ...)

I do agree that MIL-SPEC 2167a and 2168 are not very useful for commercial
software projects, but the ANSI/IEEE standard is great.  Considering
that it was developed with the input of some of Software Testing's
finest minds :-) this is not surprising.


_______________________________________________________________________
Alan R. Weiss                           TIVOLI Systems, Inc.
E-mail: alan@tivoli.com                 6034 West Courtyard Drive,
E-mail: alan@whitney.tivoli.com	        Suite 210
Voice : (512) 794-9070                  Austin, Texas USA  78730
Fax   : (512) 794-0623
_______________________________________________________________________