HDTenEightyP/NetNews huggingface dataset:
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: Testing (Was: Do Software Engineers Actualy Do So Badly?)
Date: 13 Oct 92 18:33:26 GMT
	<1992Oct13.025849.29887@sserve.cc.adfa.oz.au>
Organization: UNC Department of Computer Science
In-reply-to: ghm@sserve.cc.adfa.oz.au's message of 13 Oct 92 02:58:49 GMT

In article <1992Oct13.025849.29887@sserve.cc.adfa.oz.au> ghm@sserve.cc.adfa.oz.au (Geoff Miller) writes:

   >Of course, a purist might say that software needs to be proved, or
   >with proper design test isn't important, but the fact is that in most
   >environments testing is the most effective way to discover problems,
   >even when setup in the usual rather haphazard fashion.

   Purists work in Computer Science Departments with minimal connection
   with the real world.  (Not everyone in CS departments fits this
   description, of course:-)

I'd just like to note that no one, even in the academic formal methods
community, *really* believes that software that is proven need not be
tested.  It Is A Myth.  Unfortunately, this myth --- along with the
cognate one that proving software is so hard that it can't be done in
practice --- persists and is a major reason why people still write
software with dozens of defects per KSLOC.

And now, back to the testing argument.
--
		Charles R. Martin/(Charlie)/martinc@cs.unc.edu
     Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
	    3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
		 Remember what the little cake said to Alice.
Newsgroups: comp.software-eng
From: fredm@dsr.uucp (Fred Muhlenberg)
Subject: exit() in a library function?
Organization: DSR
Date: Fri, 16 Oct 1992 21:10:38 GMT

A discussion arose one day concerning an exit() which was
placed in a routine destind for a library function.

I maintain that library function should never exit and if
it returns a value, then some sort of SUCCESS or FAIL code
should be indicated.  The users code should decide to exit.

My co-worker says that an exit is an acceptable solution 
since it alerts the user to a problem, in this case that
some environmental variable has not been set.

With this general explanation, I would like to hear some 
feedback on just what the community has to say.

If you e-mail to me, I'll summarize.

Thanks,

Fred Muhlenberg

-- 
Fred Muhlenberg                  "My opinions are just that."
Digital Systems Resources, Inc.          
uunet!dsr!fredm
Newsgroups: comp.software-eng
From: mat@mole-end.matawan.nj.us
Subject: Re: Software, Architecture, Engineering, Technology - ????
Summary: Another view on Architecture
Keywords: same as subject...
Organization: :
Date: Thu, 8 Oct 1992 14:55:10 GMT

In article <1992Oct8.044318.11807@iti.gov.sg>, saradhi@frigg.iti.gov.sg (Motamarri Saradhi (KSL)) writes:
> Dear colleagues,
 
> The postings on the topic "Do Software Engineers Actually Do So Bad", have
> motivated me to put before you some interesting points.
 
> I wonder whether the software community has realised or not, the words
> architecture, engineering, technology have sometimes misinterpreted.
 
> ...
 
> An architect is primarily concerned with 'aesthetic considerations' of
> a product - may be a building, bridge, car etc. He need not be an engineer.

To the extent that this is true, the architect is neglecting his real job.
The real job of an architect is to ensure that the various facilities will
`work' together when people use them.

In a broader sense, architecture is the arrangement of components into a
functional whole.  And computer programming does _lost_ of that, often
badly.

Both architect and engineer should have the strength in their fields to
gain the freedom to consider esthetics.  Both should have the educated
taste to do so well.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
From: kjones@luke.eecs.wsu.edu (Kent Jones - EECS)
Newsgroups: comp.software-eng
Subject: PROPOSAL ***PLANNING TOOLS SURVEY*** PROPOSAL
Keywords: Gantt, Pert, Project Planning etc...
Date: 9 Oct 92 17:57:07 GMT
Article-I.D.: serval.1992Oct9.175707.18028
Organization: Washington State University!

This is to catch everyone I missed the first time and also to expand
the survey to include commercial tools -- given the low number of responses 
the first time:

PROPOSAL:
email me with the information on how to access any public domain/commercial
software project planning tools for any machine. i.e. something that 
produces Gantt, timeline or other information. I will summarize and 
post a summary of what I find a week from this coming friday (OCT 16). 
I would also be willing to send the information to whoever maintains the FAQ 
for this group. To make my life easier, organize the information as 
follows:

----------------------------------------------------------------------------
TOOL NAME:	
PUBLIC DOMAIN/COMMERCIAL:
MACHINE IT RUNS ON:
ADVANTAGES/DISADVANTAGES:
OPERATING SYSTEM:
WHERE ON INTERNET ITS LOCATED:
----------------------------------------------------------------------------

my email address is: kjones@eecs.wsu.edu

If you think this is a terrible idea email me also and I'll apologize.

If there is no such tool available, and enough people are interested, maybe
we could make it into a GNU project... (I dont have time -- what am I saying!)

Thanks -

Kent 
kjones@eecs.wsu.edu
Washington State University 
Electrical Engineering and Computer Science
From: wahl@dickh.enet.dec.com (David Wahl)
Newsgroups: comp.software-eng
Subject: Finding memory-related defects (was: Re: SUMMARY Re: Purify vs dbmalloc)
Date: 7 Oct 92 19:03:34 GMT
Article-I.D.: nntpd2.1992Oct7.190334.25018
Reply-To: wahl@dickh.enet.dec.com (David Wahl)
Organization: Digital Equipment Corporation


---
These memory leak & over-write detectors all work by essentially building 
debug reporting into the application (by replacing the relevant functions
in the c library).  Are there any thoughts from participants as to whether
it's best to find such defects through inspection or through test measures
other than turning on the debug output?

Thanks,
Dave Wahl
===================================================================
Digital Equipment Corporation
DIDDLY Development Team (CX02-1/7D)
301 Rockrimmon Blvd. S.
Colorado Springs, CO 80920-2080

Tel 719-548-2351
Email: wahl@hootus.enet.dec.com
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The opinions expressed are my own, not Digital's.               %
% "I suppose you would have to be very well educated to get that  %
%  kind of job."                                                  %
% "Extremely well educated.  Typing, everything."                 %
% -- Donald Barthelme, "The Emerald"                              %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Subject:  asd
From:  Scott Duncan <duncan@ctt.bellcore.com>
Newsgroups: comp.software-eng
Organization: Bellcore - Information Technology, Morristown, NJ
Reply-To:  Scott Duncan <duncan@ctt.bellcore.com>
X-Gateway: ALEX.ims.bellcore.com
Date:  Wed, 14 Oct 92 8:31:56 EDT
To:  news-post@ctt.bellcore.com (NetNews)
Message-ID: <1992Oct14.123742.9508@ALEX.ims.bellcore.com>
Newsgroups: comp.software-eng

Sent this the other day, but haven't seen it show up, so I thought I'd try
again.  Sorry if it comes twice.

cpcahil@virtech.uucp (Conor P. Cahill) writes:

[In response to a posting by bushell@fox.nstn.ns.ca (Tom Bushell) quoting a
Brad Cox statement about a U.S. GAO report where it appears that, as Tom
reads it "only 5% of software written for Uncle Sam before 1979 was ever used."]

>The problem is that you don't have info on the reasons for these
>statistics.  Therefore you can't reasonably use the statistics to
>substantiate your opinion that "software engineers are doing real bad".

As I recall hearing several times, these GAO numbers were for projects which
had already been identified as in trouble/jeopardy of some sort.  Thus, they
are not numbers for all projects, but only for a select group that were not
deemed as on solid ground anyway.

Speaking only for myself, of course, I am...
Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan)
                (Bellcore, 444 Hoes Lane  RRC 1H-210, Piscataway, NJ  08854)
                (908-699-3910 (w)   609-452-9054 (h))
From: Roger_Alexander@rock.intersolv.com
Newsgroups: comp.software-eng
Subject: Email Address of IEE
Date: 8 Oct 92 23:46:00 GMT

Does anyone know of an email address for the IEE (not the IEEE) ?  Please post 
responses to roger_alexander@intersolv.com

Thanks,

Roger Alexander
INTERSOLV
Newsgroups: comp.software-eng
From: cpcahil@virtech.uucp (Conor P. Cahill)
Subject: Re: Finding memory-related defects (was: Re: SUMMARY Re: Purify vs dbmalloc)
Organization: Virtual Technologies Inc.
Date: Thu, 8 Oct 1992 10:33:51 GMT

wahl@dickh.enet.dec.com (David Wahl) writes:

>These memory leak & over-write detectors all work by essentially building 
>debug reporting into the application (by replacing the relevant functions
>in the c library).  Are there any thoughts from participants as to whether
>it's best to find such defects through inspection or through test measures
>other than turning on the debug output?

These libraries are no replacement for code walkthroughs/inspections.  
However, the problems discovered by the libraries are the type that is 
very hard to discover in a code inspection and are such that they can
waste alot of time during the development (pre-walkthrough) stage as 
the developer attempts to track down the error.

Of course, I may think this because I am selling such a product, but 
after you spend a couple of yours trying to track down an allocation
problem, you will eventually come to see my point of view.

-- 
*** SENTINEL(tm) The ultimate Debugging Environment - email for more info ***

Conor P. Cahill              (703)430-9247            cpcahil@virtech.vti.com
Virtual Technologies, Inc.  46030 Manekin Plaza          Dulles, VA 20166 
Newsgroups: comp.software-eng
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Finding memory-related defects (was: Re: SUMMARY Re: Purify vs dbmalloc)
Organization: Computer Science, University of Melbourne, Australia
Date: Sun, 11 Oct 1992 07:37:38 GMT

wahl@dickh.enet.dec.com (David Wahl) writes:

>cpcahil@virtech.uucp (Conor P. Cahill) writes:
>
>|>Of course, I may think this because I am selling such a product, but 
>|>after you spend a couple of yours trying to track down an allocation
>|>problem, you will eventually come to see my point of view.
>
>Actually, I've spent quite a few years tracking down such problems through
>inspection and preventing them through judicious application of design and
>coding standards.  I asked the question to see if there were similar 
>experiences and attitudes among the participants of the newsgroup.  I'm not
>out to slam your product; just asking some questions from an SE perspective.
>
>While I agree that the use of such tools is valuable during development, 
>I'm not convinced that they are worth the cost of licensing the run-time 
>for volume shipments of a product.
[...]
>Also, I want to know that a library which is 
>shipped with my product to do something so basic as memory allocation is 
>ABSOLUTELY free of defects and won't collide with all the other unexpected
>products operating on the system my customer will use.

Why ship your products with the debugging library?
Surely it would be better to use tools for development and testing, and then
ship the final version with an efficient set of memory management routines,
instead of one that catches errors and helps to identify the cause of
the problem quickly. This is exactly akin to compiling with -g during
developement, but compiling with -O3 for the version you will ship.
(Of course, in both cases you will want to re-run your regression tests
on the optimized version to ensure that there aren't any bugs in the
efficient malloc or in the optimized.)

>I'm also concerned about the fact that 
>the system services I depend on (such as certain well-known window systems) 
>are using the basic OS memory allocation routines and not a special library 
>which traps such defects.

It is true that these products may not work if you use the basic memory
allocation routines provided by the operating system (brk/sbrk on unix).
If that's the case, then don't use them, or get a version that does work
in in this situation. Alternately, write your own!

If the windowing system you refer to is X Windows, then rest easy,
for dbmalloc (and probably also the commercial products) also provides
drop-in replacements for XtAlloc(), etc.
If it's something different, then you can probably modify dbmalloc
to do what you want without too much difficulty. (This is the
benefit of free software :-)

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: s897336@minyos.xx.rmit.oz.au (Lip Meng Soh)
Newsgroups: comp.software-eng
Subject: End-user computing
Date: 10 Oct 92 06:57:15 GMT
Organization: RMIT Computer Centre
NNTP-Posting-Host: minyos.xx.rmit.oz.au

To manage the risks of end-user application development ( End-user computing)
is extremely difficult, until expert systems for software development is 
developed.

Please give comments to this proposition!
Thanks.

*********************************************************************************		Please email: Lip M. SOH ( s897336@otto.bf.rmit.oz.au)         *
********************************************************************************
Newsgroups: comp.software-eng
From: sue@netcom.com (Sue Miller)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Tue, 13 Oct 1992 16:08:37 GMT

> Michael Turner writes:
>> Michael J Zehr writes:
>>....
>>Here's one thought:
>>Problem: SE's often have to face changing requirements.
>>Solution: Requirements have to be tracked throughout the development
>>lifecycle.  We need comments like "this code does blah _because_ ...."  
>>
>>But this can require developers with more understanding and training.
>>It's easier to have someone implement a particular function than to have
>>them understand the requiremtns, document things like time contraints,
>>big-O execution time, memory usage, etc.
>>....
>>Any comments?
>>-Michael J. Zehr
>
>Programmers are "How" people, more than they are "Why" people.  I'm more
>of a "Why" person, but many programmers I've worked with find this
>grating and irritating.  "Why" is considered a legitimate question
>when pursuing bugs (when it bears a strong family resemblance to "How",
>anyway).  The rest of the time, it's a question to be gotten out of
>the way quickly, and (preferably) arbitrarily, since actually
>thinking about it takes time away from "real work".

I agree, and consider this very issue to be a large source of grief
in my professional life recently.  I left my last position because of it.
Why is at least as important as how.  If you haven't worked out
the why, then you might as well not bother.  

>
>Most code comments say little about "because", apart from considerations
>of "how" the given function couldn't be done some other way.  Worse,
>few *design* documents say much about why the choices presented were
>made, what the alternatives were, and why they were rejected.  This is
>because design documents are still typically written by people who
>are, or have been, programmers; people who are typically very
>"how"-oriented.
>
>I think that much of the problem is because it (typically) takes
>a certain kinds of personality to handle the technology at all, and
>that those personalities aren't necessarily ideally suited to tasks like
>understanding markets, requirements acquisition, high-level conceptual
>design, effective user interface design, managing teams effectively,
>and any area that looks back to the real human motivations for writing
>software at all.

This is very true in my experience.  I can only hope that it changes.
It seems so impractical not to consider the underlying motivations
for writing a particular piece software.  Yet so few programmers do.
I like writing software, I *do* like the how.  Yet I am not happy
when told to produce software that I know doesn't make sense from the
'why' angle, even if it is a cool project technically.

Newsgroups: comp.software-eng
From: smccoy@dw3g.ess.harris.com (Scott McCoy)
Subject: Re: IDEF info??
Date: Sat, 10 Oct 1992 20:33:27 GMT
Organization: Harris Corporation Information Systems Division
Keywords: idef

The IDEF series of specifications runs (last time I looked)
from IDEF0 to IDEF22 (?).  Each IDEF specification typically 
deals with a different problem domain.  For example (and I quote):

	IDEF0 is used to produce a function model which is a 
structured representatation of a manufacturing system or 
environment and the information and objects which interrelate 
those functions.  (Also called process modeling.)

	IDEF1X is used to produce an information model which 
represents the structure of information needed to support the 
functions of a manufacturing system or environment.

	IDEF2 is used to produce a dynamics model which 
represents the time varying behavior of functions, information,
and resources of a manufacturing system or environment.

	and so on and so forth...

(The above is from the introduction in the IDEF0 spec).

IDEF stands for Integrated Computer Aided Manufacturing (ICAM) 
Definitions.

Anyway, if you want either the IDEF0 (process modeling) or
IDEF1X (information modeling) specifications, I know you can
order them from 

	Knowledge Based Systems, Inc.
	2746 Longmire Drive
	College Station, TX  77845-5424
	(409) 696-7979

-- 
Scott McCoy	Harris ISD	Opinions expressed are my own.
Staff Eng - SW	Internet: 	smccoy@dw3g.ess.harris.com
Newsgroups: comp.software-eng
From: Oliver.Otto@p1.f2006.n241.z2.fidonet.org (Oliver Otto)
Newsgroups: comp.software-eng
Subject: Looking for software-engineering tools
Date: 6 Oct 92 15:34:52 GMT
Article-I.D.: fast.718573132.F00001

Hello All!

I am looking for some software-engineeering tools like SA or SADT but the
products I am looking for should do more than design software systems -
they should consider all the 6/7 phases as discribed in the
Software-ENGINEERING book bei Ian Sommerville. He mentioned that there
might be some projects developing such systems - is here anyone around like
to talk about such systems or has got some information for my study?
Everything might be interessting for me so please write :-)

Oliver

   _____  _____   _____   ___
  / _  / /  __/  /  __/  /  /  Oliver Otto
 / // / __\ \   __\ \   /  /   FIDO:     2:241/2006
/...././..../. /..../. /../.   INTERNET: OLIVER.OTTO@OSSI.FIDO.DE
From: brw@aber.ac.uk (Benjamin Roy Whittle)
Newsgroups: comp.software-eng
Subject: Component Description
Date: 12 Oct 92 10:24:59 GMT
Organization: University of Wales, Aberystwyth

Can anyone give me the reference for CDL2 a component description language.
I think the author is Bayer.

Thanks
ben
Newsgroups: comp.software-eng
From: rharmon@triton.srg (Robert Harmon)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Arinc Research Corporation, Annapolis MD
Date: 9 Oct 92 13:10:36
	<MATT.92Oct8172111@raven.bacchus.esa.OZ.AU>


   In article <1992Oct6.185140.10259@> (Hugh LaMaster) writes:
>> A very good question. I heard on the news last night (so it MUST be TRUE :-)
>> that the cost of construction the English channel tunnel  was about
>> TWICE the original estimate.  ...
    In article: 92Oct8172111: matt@bacchus.esa.OZ.AU (Matt Atterbury) writes:
       I would consider this an unfair example as on high profile
       projects ike this, it is almost guaranteed that the "advertised"
       cost is going to much lower than the "real" cost, just to make it
       more likely to get commitment from Govt, investors, etc. Once the
       project is started and you're half way across and you run out of
       money, _nobody_ is going to say "Ok, that's all the money gone,
       let's stop now" - you have to keep going to have any chance of
       getting your money back.

DX Imaging, Lionville PA was shut down after being 2 years late on
delivery.

DX was a joint venture between Dupont and Xerox to develop high
quality image proofing equipment for the GraphicArts industry.
The idea was to use Xerox machine expertise and Dupont
Liquid Pigments expertise to develop a LiquidInk printing
techknology.  

Unfortunately management was basically lying to dupont/xerox management
(it'll be done next month,... yeah thats it).  
--
rharmon@srg.uunet.uu.net        |
Robert B. Harmon ms:5-230       |  This space is left intentionally blank.
Arinc Research 2551 Riva Rd.    |  
Annapolis, Md 21401             | 
Newsgroups: comp.software-eng
From: troyer@mitre.org (Tom Royer)
Subject: Re: Testing (Was: Do Software Engineers Actualy Do So Badly?)
Organization: The MITRE Corporation
Date: Wed, 14 Oct 1992 13:48:22 GMT

In article <1992Oct13.025849.29887@sserve.cc.adfa.oz.au> 
ghm@sserve.cc.adfa.oz.au (Geoff Miller) writes:

> This, of course, is not trivial.  People talk about "top-down
> development" and "top-down testing", using dummy routines at
> the lower levels to test the functioning of the higher levels,
> but this often ignores the way in which that functioning depends
> on the values returned from subroutines.  By the time you have
> developed a dummy which returns the full range of possible values
> you could often have written the real thing.

I have this theory that the amount of test code written for a given
application is pretty much the same whether one approaches
testing from the top (with stubs) or the bottom (with drivers).  
You'll end up with a few enormous drivers or lots of small stubs.
Note, by the way that I agree with the poster, good stubs are 
generally not as trivial to write as some people believe.

> 
> I guess I'm unconvinced that testing tools will ever be useful outside
> specialised areas, although probably very useful within such.  IMHO the
> best test is a nasty-minded person, and _never_ the one who wrote the 
system.
> 

I pretty much agree with this.

I'd point out, in addition, that testing should not wait until the code 
exists.  Testing begins as soon as a system concept exists.  The
architecture can be tested (either mentally, in a walkthrough, or with
a more formal model) against the expected operational environment.
The design can, and should, be exercised against normal and off-normal
stimuli before any code is written.

I once heard of a design review in which the most junior members of each
development team were presented with an input situation and were asked to
describe (without help or prompting from the leaders of the teams) how
their subsystem (or component, whatever) would respond, either to the
initial input or the output of the "upstream" component.  Very 
enlightening.  A review like this is as much testing as actually executing
code.

--
Tom Royer