Newsgroups: comp.software-eng
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!arrayb!wicklund
From: wicklund@intellistor.com (Tom Wicklund)
Subject: Re: Accepted Practices
Message-ID: <1991Jun7.171606.5862@intellistor.com>
Organization: Intellistor
References: <1991Jun6.125833.18549@dec254.uucp> <1991Jun6.101639.1@happy.colorado.edu>
Distribution: usa
Date: Fri, 7 Jun 91 17:16:06 GMT

In <1991Jun6.101639.1@happy.colorado.edu> hsrender@happy.colorado.edu writes:

>In article <1991Jun6.125833.18549@dec254.uucp>, toolsmit@dec254.uucp (Toolsmith) writes:
>> My point is that I think we (the software engineering community) need to
>> establish some sort of program or process to define accepted practices in the
>> same sense as the accepted practices of the other engineering disciplines.
>> 
>> 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.