HDTenEightyP/NetNews huggingface dataset:
From: John Amason <jma@sesqui.net>
Subject: IDEF info??
X-Xxmessage-Id: <A6FBC43C5A01960A@highside.sesqui.net>
X-Xxdate: Fri, 9 Oct 92 07:20:28 GMT
Organization: Innovative Computing Solutions
X-Useragent: Nuntius v1.1.1d11
Date: Sat, 10 Oct 1992 04:19:29 GMT

I would like to know where to obtain a copy of the IDEF specification.

I would also like to know of experiences and why I should not use a
method,  such as, Rumbaugh instead.

Thanks
John Amason
From: phardie@nastar.uucp (Pete Hardie)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 9 Oct 92 14:29:46 GMT
Organization: Digital Transmission Systems, Duluth, GA.


One of the more common problem with software development is that the 
requirements often change *very late*.  Nearly every project I've worked on
has had changes made almost up to delivery date, because of the joint
perception of management and customer that software can be changed willy-nilly
without impact.

Another problem is that a given program is often expected to be modified
*in place* without substantial change.  Such things are unlikely in the world 
of 'real' objects - buildings are never made taller without extensive 
examination of structural soundness, automobiles are modified only after a
definite study period, etc.  It is not uncommon for a customer to request
a program be extended from 100 data items to 1000 data items and expect it
to be a quick change, with no additional effect.

Finally, in software we work with an infinitely malleable medium, unlike the 
materials of civil, mechanical, and electrical engineering.  Data can follow
nonsmooth curves, with abrupt discontinuities, arbitrary values, and so on.
Civil engineers do not have a problem with division by zero - there is no
physical equivalent (I believe - CE's are free to provide a counterexample)

-- 
Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
Digital Transmission Systems, Inc., Duluth GA
Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
Position:  Goalie               |
Newsgroups: comp.software-eng
From: killops@ssd.intel.com (Scott Killops)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Followup-To: comp.software-eng 
Keywords: predictability 
Organization: Supercomputer Systems Divison, Intel Corp.
Date: Tue, 13 Oct 1992 14:34:08 GMT

In article <1992Oct13.122727.10076@afit.af.mil>, jcardow@afit.af.mil (James E. Cardow) write|> I've been following this thread off and on as the discussion has
|>   
|>    What is the GOAL of software engineering?
|>
I'll bite.  The goal of software engineering is predictability.  We want to
produce software with a predictable set of features, with predictable quality
characteristics (reliability, performance, usability, etc.), on a predictable
schedule, at a predictable cost.  We don't want surprises.

When I worked at a gas station in my student years, the only people coming
in for gas with hood locks were those who had *already* had their battery
stolen.  It seems to me that the organizations trying hardest to make soft-
ware engineering happen are those that have *already* been burned by a poor
product release, a large schedule/cost overrun, etc.  (and those, like NASA,
where safety is very clearly a critical requirement).

Chow, Scott
killops@ssd.intel.com
From: sammy@smds.com (Samuel Murphy)
Newsgroups: comp.software-eng
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Date: 13 Oct 92 15:14:13 GMT
Reply-To: sammy@ishmael.UUCP (Samuel Murphy)
Organization: Software Maintenance & Development Systems, Inc.

In article <9210081531.AA16269@bangalore.esf.de> graham@esf.de, tholome@esf.de writes:
>I was interested to read in article <1992Oct6.185140.10259@news.arc.nasa.gov>
>of comp.software-eng Hugh LaMaster's comment that he thinks that:
>
> `many people have deluded themselves into falsely applying models that come
>  from manufacturing... there is no such animal [as a Software Factory], and
>  never has been.  The proper model for software is "project", not "factory",
>completely dependent on standardised components and on the whole system that
>creates and maintains the standards.  When was the last time you ordered a
>screw with a non=standard pitch?  I doubt if even General Motors does this. I
 -------------------------------

Does any sci-historian that might be reading this know how long
it took from the introduction of the screw to standardization was
actually agreed upon? I am certainly amazed at the variety of screw,
bolt and nut sizes! I also see non-standard heads, that require a special
screw driver! 

Is industrial standardization so complete? How much easer would it be to
compile C code in Roumainia than screw in an American light bulb? :-)

-Sam

sammy@smds.com  or sammy@world.std.com
Newsgroups: comp.software-eng
From: killops@ssd.intel.com (Scott Killops)
Subject: Re: Goal of Software Engineering (Was: Do Software Engineers Actualy do so 
Followup-To: comp.software-eng
Keywords: Money Predictability Goal
Organization: Supercomputer Systems Divison, Intel Corp.
Date: Thu, 15 Oct 1992 00:23:29 GMT

In article <1992Oct14.210241.3504@afit.af.mil>, jcardow@afit.af.mil (James E. Cardow) writes:
|> 
|> But let me ask a really off the wall question (academics this one will
|> hurt), why isn't the goal to make money for us as well?  As a craft, we
|> did okay.  Lotus, microsoft, and many government software houses did
|> well, especially as the only source of products.  As a production effort
|> we seem to have problems, unpredictable schedules and costs, unreliable
|> systems etc.  That is why the term software engineering was coined, but
|> unfortunately this approach seems to be the goal is to solve our
|> problems.  Would we be better off with a competitive goal similar to
|> money?  If results of productivity efforts were tied to the goal would
|> there be unrealistic management promises?  Would products that did not
|> meet the customer needs or expectations continue to be a problem?
|> 

Now you're changing the question.  If you had asked "What is the goal
of a software factory (or a business whose primary product is software)?"
I would have said "To make money."  To answer otherwise is to not have
lived the reality of high tech over the last dozen years; many many
layoffs.  "Software Engineering" is a collection of principles, methods,
tools, policies, and such that may be employed in attempting to reach the
goal.

I answered before that the goal of *software engineering* is predictability.
Another way of saying this is that we use software engineering in order to
reduce the risk associated with trying to make money through producing and
selling software.  (In critical applications, I would say that we employ
software engineering in order to reduce the risk of a catastrophic failure
of the deployed software.)

Chow, Scott
killops@ssd.intel.com
Newsgroups: comp.software-eng
From: ludemann@quintus.com (Peter Ludemann)
Subject: Re: Finding memory-related defects (was: Re: SUMMARY Re: Purify vs dbmalloc)
Organization: Quintus Corporation, Palo Alto, CA
Date: Mon, 12 Oct 1992 22:38:16 GMT

In article <BvstCF.L55@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes:
> wahl@dickh.enet.dec.com (David Wahl) writes:
> 
> >These memory leak & over-write detectors all work by essentially building 
> >debug reporting into the application ...
> 
> 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, you could do something "radical" and use a high level language
like Prolog, Lisp, or Smalltalk which takes care of all this memory allocation
stuff for you.  (These are not exactly new technologies --- Lisp is nearly as
old as Fortran; Prolog just celebrated its 20th birthday --- and both have
pretty decent compilers these days.)  

The mind boggles ... what could we do with all those programmers who
no longer spend their days looking for memory bugs?  Put them to work
fixing programs that'll break in the year 2000?  :-)

-- 
	Peter Ludemann  +1-415-813-3800  ludemann@quintus.com
Newsgroups: comp.software-eng
From: miket@hermes.tcs.com (Michael Turner nmscore Assoc.)
Subject: Re: It's not an engineering problem.[Was:Re:DoSoftwareEngineersActualy...]
Organization: Teknekron Communications Inc.
Date: Fri, 16 Oct 1992 22:44:30 GMT

In article <1992Oct15.175405.3834@news.arc.nasa.gov> lehman@george.arc.nasa.gov (John Lehman -- GDP) writes:

>The problems which are distinctly software problems or engineering problems
>are so obviously overwhelmed by general management problems and other broad 
>psychological or "people-" problems, that if we really wanted to address
>what's wrong in our work lives we would more appropriately be posting in
>some "management" or "human-nature.practical-work-around" newsgroup.

I have yet to see such a newsgroup.  I went looking for it for the
first time in my life the other day, because I thought that, at the
vary least, we should be cross-posting there, if not confining the
discussion to it entirely.

>As interesting as all that is, in comp.software-eng it would be appropriate
>to first separate out the problems which are unique to software, and then 
>address those problems.

I fear that might take us straight back to the people problems.
Computers are information machines, and information is terribly
political.  Information systems projects are sold all the time on
criteria that have no real bearing on deliverable value to the client.
Can we expect an honest craft of software engineering to emerge until
it can be sold as such?  You can't do a "rigged demo" of a bridge,
a manufacturing line, or a passenger jet.  You can in software.
Software lends itself to politics because, to paraphrase you
("Politics is presentations and statements developed with anything
but objective true facts being the highest value"), software also
lends itself to presentations and statements developed with
anything but objective truth behind it.  Whose job is it, then, to
resist this temptation?  Engineers themselves too often abdicate
responsibility for resistance (and often don't handle it well
when they attempt to pick it up.)  Is something missing in our
education?  Maybe computer science curricula should drop
differential equations and start requiring anthropology.  I can't
remember the last time I needed to take a first derivative, but
the last time I needed to understand a slightly oblique human
interaction was just this morning. 

>It is said that engineering _is_ in large part management; but I think a
>more useful point is that good engineering is not political.

I heartily agree.  The question is: how to depoliticize engineering.
If software engineering practice doesn't accommodate the depoliticizing
of software projects, it is brittle stuff indeed.  Perhaps before a
complete separation of engineering and politics can be made, we will
need more direct engagement.  Bad news for most engineers, I guess,
but in what other direction can real change be seen?
---
Michael Turner
miket@tcs.com
From: apengell@axion.bt.co.uk (Alan Pengelly)
Newsgroups: comp.software-eng
Subject: Design verification
Date: 12 Oct 92 11:46:31 GMT
Reply-To: apengell@axion.bt.co.uk (Alan Pengelly)
Organization: British Telecom Research Labs



I'm looking for a range of techniques which deal with design
verification. Can anybody help?

						many thanks

						Alan

+-----------------------------------------------------------------------------+
| Alan Pengelly ,             (apengell@axion.bt.co.uk)      (+44) 473 646652 |
| Software Development Division,                                              |
| BT Laboratories, Martlesham Heath, Ipswich, IP5 7RE, Suffolk, England, U.K. |
+-----------------------------------------------------------------------------+
From: jon@cs.washington.edu (Jon Jacky)
Newsgroups: comp.software-eng
Subject: Re: Functional Spec. Lang??? (What is P+ ?)
Summary: What is P+ and Maurice data modelling?
Keywords: P+  Maurice data modelling
Date: 14 Oct 92 17:26:44 GMT
Organization: Computer Science & Engineering, U. of Washington, Seattle

>  boag@world.std.com (Scott A Boag) writes ...
>
>
> The kind of work we do is more function/feature-driven
> rather than data-driven.  Since our formal methodology
> (P+) is based on Maurice data modiling, ...

What are P+ and Maurice data modelling?   Some friends in industry say their
company is considering P+, but I've never seen it described anywhere.   Are
there any books or articles about it?  

- Jon Jacky, jon@radonc.washington.edu, University of Washington, Seattle USA
Newsgroups: comp.software-eng
From: jgg@evb.com (Xmiester)
Subject: Re: Code Inspections and Walkthroughs (followup)
Organization: EVB Software Engineering, Inc.
Date: Mon, 12 Oct 1992 01:42:52 GMT

 johnb@searchtech.com (John Baldwin) writes:


>Mini Summary:
>
>   [stuff deleted...]
>
>   4.  Read the books by Fagan and by Weinberg.
>

I was aware Fagan had papers out, but what book are you
referring to?

John Goodsen
goodsenj@ajpo.sei.cmu.edu


Newsgroups: comp.software-eng
From: rbanksjr@nyx.cs.du.edu (Richard E. Banks Jr.)
Subject: Memory leaks
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Fri, 16 Oct 92 02:24:35 GMT


What is the definition of a memory leak as most people on the net use it?
Thanks.
Rich
Newsgroups: comp.software-eng
From: dsanders@doc.bmd.trw.com
Newsgroups: comp.software-eng
Subject: KBSE Reference
Date: 7 Oct 92 14:01:47 MST

Re: Knowledge-based Engineering References

The text "Knowledge Engineering: Concepts & Practices for
Knowledge-Based Systems", by G. Steven Tuthill, is a solid
reference for work in this area.  The date of copyright is
1990.  The ISBN is 0-8306-9297-5.

I would appreciate other people's suggestions and comments
regarding references for knowledge-based system engineering.

Thanks,
Dale Sanders
Newsgroups: comp.software-eng
From: jerbil@ultra.com (Joseph Beckenbach {Adapter Software Release Engr})
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Ultra Network Technologies
Date: Tue, 13 Oct 92 20:10:28 GMT

Greetings, Captain Cardow and everyone else!

	My background is civilian-academic and business, with a CS degree
and a few years of sysadmin and software release and toolsmithing since then.
I have few of the answers anyone of us wish to have, so take this with the
appropriate grain of salt.

	Of course our field's done poorly so far -- too few practitioners
far from academia have had enough contact AND time with the stuff to use it
effectively.  And those "remote" practitioners still seem to form the bulk
of the software creation personnel.  Of course we have little faith at the
present -- look at our track record to date, and notice how long it takes
for any new paradigm to trickle out into use.


>	What is the GOAL of software engineering?

	My first cut answer matches several others' first cut answers:
To produce software which solves problems without creating them, and produce
that software reliably, on time and on budget.

	The process is the solution, says Humphrey;  the process of figuring
out what you're doing lets you figure out what you're doing wrong, and then
fix it.  This is a part of engineering.  It's also negative feedback, which
most people feel uncomfortable with, and thus avoid.

		Joseph Beckenbach
-- 
----
Joseph Beckenbach	jerbil@ultra.com	408-922-0600 x246
	(speaking from, but not for, Ultra Network Technologies)
Member, Non-Sequitor Club -- we got all our eels in our hovercraft
Newsgroups: comp.software-eng
From: wicklund@intellistor.com (Tom Wicklund)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Intellistor, Inc.
Date: Tue, 13 Oct 92 21:42:57 GMT

In <ALANB.92Oct12152121@sdlhpp2.sdl.mdcbbs.com> alanb@sdl.mdcbbs.com (Alan Braggins) writes:

>> Even more of a problem is that too many software developers don't
>> design with changing requirements in mind.  When a product requires
>> 250 data elements, they write "250" as the array size throughout the
>> product (even worse, a few places they'll write 251, 500, or 2001).
>> Real examples are much more perverse, of course, but boil down to the
>> same issue.

>Changing #define MAX_ELEMENTS 250 to #define MAX_ELEMENTS 3000 is trivial.
>Changing /* linear search along linked list */ to /* lookup in balanced tree */
>is harder (and might have been a waste of time for the small data set).

I agree.  The problem is when the programmer didn't bother to #define
anything, just entered absolute numeric constants.  It's a sign of
poor programming practice but happens all too often in the real world
projects which generate bad press for software in general.

Newsgroups: comp.software-eng
From: matt@bacchus.esa.OZ.AU (Matthew Atterbury)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Expert Solutions Australia.
Date: Thu, 8 Oct 1992 07:21:11 GMT

In article <1992Oct6.185140.10259@news.arc.nasa.gov> lamaster@pioneer.arc.nasa.gov (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 ("Chunnel") was about
> TWICE the original estimate.  I don't know whether the actual overrun was twice,
> but it is enough that it is causing a lot of heartburn among the investors.

    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.

Int article <whatever> hasker@m.cs.uiuc.edu (Rob Hasker) writes:

> So I see no real reason why software engineers should hang their heads
> in apology.  We aren't the only ones to make mistakes.

    No, but we do make them fairly consistently. It is still a rarity
    for a S/W project to be on-time and on-budget. Another point is
    that the building in both the examples are still usable (and are
    used, albeit with complaints), whereas a "bad" S/W project may
    just not be used by the customer if they are unhappy with it,
    so there is no chance that they will learn to live with it and it
    will always be a [complete] failure.
-- 
-------------------------------------------------------------------------------
Matt Atterbury [matt@bacchus.esa.oz.au]   Expert Solutions Australia, Melbourne
UUCP: ...!uunet!munnari!matt@bacchus.esa.oz.au            "klaatu barada nikto"
ARPA: ...!uunet!murtoa!bacchus.esa.oz.au!matt         "consider this a divorce"
From: mswanson@cvbnet.prime.com (Mark Swanson)
Newsgroups: comp.software-eng
Subject: Looking for SCCS -> RCS conversion tool
Keywords: CMS SCCS RCS
Date: 8 Oct 92 19:38:07 GMT
Reply-To: mswanson@cvbnet.prime.com (Mark Swanson)
Distribution: usa
Organization: Computervision, Inc

I am looking for a tool which could convert SCCS archives into RCS
format without losing too much of the change history information.
Does anyone know of any?

--------------------
Mark A Swanson     617/275-1800x4927    mswanson@cvbnet.prime.com
Computervision  MS 5-2, 14 Crosby Road, Bedford, MA 01730
Newsgroups: comp.software-eng
From: mark@drd.com (Resident.Alien)
Subject: RFR: SoftTech Corp. and ISO 9001 short course
Reply-To: mark.lawrence@drd.com
Organization: DRD Corporation
Distribution: na
Date: Mon, 12 Oct 1992 16:10:53 GMT
Expires: Thu, 22 Oct 1992 05:00:00 GMT

I've received a brochure from SoftTech Corp. advertising a 3 day short
course on ISO 9001 and software organizations to be held in San Jose
October 26-29.  I'm looking for referrals on the company and the
instructors:

Dr. Walter Utz
Arif Khan

Are these folks legitimate?  Can anybody comment as to the quality,
breadth and depth of the material presented at tutorials sponsored
by SoftTech?

Thanks in advance.
-- 
mark.lawrence@drd.com                                     (918)743-3013
DRD Corp., 5506 South Lewis Ave., Tulsa, OK 74105         (918)745-9037 fax
Newsgroups: comp.software-eng
From: marick@m.cs.uiuc.edu (Brian Marick)
Subject: Re: Code Inspections and Walkthroughs (followup)
Keywords: inspections, walkthrough, verification, validation, Fagan
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sun, 11 Oct 1992 17:32:08 GMT

johnb@searchtech.com (John Baldwin) writes:


>   3.  One of Marick's most interesting (albeit dismaying) findings is
>       that it isn't really practical to come up with a truly general
>       taxonomy of error types at all levels of abstraction.

Let me qualify this: *I* could not find, nor invent, a really useful
error taxonomy.  Someone else might.

My opinion:

At the code level, simple classifications like 
	omission fault vs. fault of commission
	interface fault vs. internal fault

work OK.  (These are the types of classifications used by Basili/SEL,
Ostrand and Weyuker, etc.)  When I find a bug, I note what category
it's in, as a way of monitoring my own programming.  My testing
concentrates on faults of omission, because those are an important
class.  I tend to make "obligation" faults (such as memory leaks), so
I concentrate on avoiding and finding those.

However, attempts to compare people or projects run into enormous
variation due to subjectivity of classification, type of application,
nominal process, actual process, etc.  The problem gets worse if you
try more ambitious classifications.  

Finding ways to reduce that variation didn't seem promising, so I gave
up.  I decided that "grand unified" classifications of faults weren't
needed to find useful ways of preventing or discovering them.

Brian Marick, marick@cs.uiuc.edu, uiucdcs!marick, marick@testing.com (pending)
Testing Foundations:  Consulting, Training, Tools.
Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README
Newsgroups: comp.software-eng
From: littlec1@jaguar.uofs.edu (Chris Little)
Newsgroups: comp.software-eng
Subject: Writing technical papers - Donald Knuth
Date: 9 Oct 92 02:42:21 GMT
Organization: University of Scranton


I've heard of a paper by Donald Knuth on how to write a technical paper.
Can anyone out there give more details on the paper.  I would like to
get my hands on it.  Thanks in advance.

--
Chris Little, Programmer/DBA                    University Computing Systems
                                                University of Scranton
  LITTLEC1@JAGUAR.UOFS.EDU                      Scranton, PA 18510
Newsgroups: comp.software-eng