HDTenEightyP/NetNews huggingface dataset:
From: jcardow@afit.af.mil (James E. Cardow)
Subject: Re: Goal of Software Engineering (Was: Do Software Engineers Actualy do so 
Keywords: Money Predictability Goal
Organization: Air Force Institute of Technology
Date: Thu, 15 Oct 1992 12:20:03 GMT

killops@ssd.intel.com (Scott Killops) writes:

>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?  

>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.)

I'm not so sure.  I was following the same line of reasoning originally.
That is, as a purist, the goal of *software engineering* can't be to
make money.  But what is the result of predictability?  Being able to
adjust to levels of uncertainty to maintain balance?  Money may have
been to crass a term, perhaps something more subtle like *value* would
be more acceptable.  However, value is very difficult to measure.  As
for the high tech layoffs, that presents a problem.  The layoffs do not
appear to be the result of increased productivity.  Nor do they appear
to be the result in a down turn in the demand.

Do ethics and safety still fall under the umbrella of *making money*?
Now as easy to fit into the formula, but I have to reflect back on the
auto industry.  They are driven by sales and lawsuits to make safer
cars.  Both affect the bottom line of money.

I'm not sure I changed the question, maybe put it in a different light.

Jim
Newsgroups: comp.software-eng
From: hart@zeus.franklin.edu (Drew Hart)
Subject: Re: Six Sigma Quality Challenge for IS
Organization: Franklin University
Date: Mon, 12 Oct 1992 17:21:09 GMT

There was an article in a magazine called "Enterprise Systems Journal"
in September 1991 on Motorola's Six Sigma Programs. In essence, the 
article discussed how statistical process control methods can applied
to a variety of IS tasks. The article mentions some examples: 

  - for network performance the number of packets sent/recieved
  - for source code the number of errors per function point or 1000
    lines
  - in payroll the number of checks printewithout error

Since the original requestor ( David Jones ) is across the pond, I
thought the following information might be helpful.

    ISSN 1053-6566 published by Thomas Publications, Inc. 
                                10935 Estate Lane Suite 375
                                Dallas, Texas 75238 
                                Telephone (214) 343-3717
                                Fax (214) 553-5603

Drew R. Hart
hart@zeus.franklin.edu

Newsgroups: comp.software-eng
From: lezz@merlin.dev.cdx.mot.com (Lezz Giles)
Subject: Re: Wanted: Info on "six-sigma" system
Keywords: sigma
Reply-To: lezz@merlin.dev.cdx.mot.com (Lezz Giles)
Organization: Motorola Codex, Canton, MA
Distribution: usa
Date: Mon, 12 Oct 1992 14:35:33 GMT

In article <1992Oct9.210152.9844@awdprime.austin.ibm.com>, alan@auntbea.austin.ibm.com (Alan R. Weiss) writes:
|>In article <1992Oct9.085040.2992@cbfsb.cb.att.com> djones@cbnewsg.cb.att.com (david.jones) writes:
|>>
|>>Has anybody heard of "six-sigma" ?
|>>
|>>What is it ?
|>>
|>>Any references ?
|>>
|>>Many thanks
|>>
|>>- Dave
|>This is the Quality Program of Motorola.  It may be proprietary
|>information of Motorola Corporation (HQ:  Schaumberg, Illinois USA).

I have seen it in publicly-available articles (I can't find them at
the moment, but if you want to know where then just ask) so I assume
that the high-level aspects of six-sigma are public-domain (is this the
correct legal term?).  The details of how to achieve this may be
proprietary, but I haven't seen them discussed here.

Lezz Giles

Disclaimer - the above view is possibly erroneous and has nothing to
do with my employer.
Newsgroups: comp.software-eng
From: mb@cadcam.kth.se (Mikael Bohlin)
Newsgroups: comp.software-eng
Subject: NIAM and SADT
Date: 16 Oct 92 09:17:37 GMT
Organization: IVF- KTH Manufacturing Systems
X-Xxmessage-Id: <A704473E6D01389B@eros.cadcam.kth.se>
X-Xxdate: Fri, 16 Oct 92 10:17:34 GMT
X-Useragent: Nuntius v1.1.1d12

Hallo!

I'm interested to hear about exeperinces on using the NIAM-method and
tools supporting the method. The same questions for SADT. Any info is
welcome. 

I prefer answer by e-mail. Thank you.

Regards 

Mikael Bohlin
Newsgroups: comp.software-eng
From: chrisf@brtph316.BNR.CA (Chris Fulmer)
Subject: Re: *Theory* of configuration management
Keywords: CM, FTP
Reply-To: woodstock!chris@mcnc.org
Organization: BNR Dept 3B91, RTP
Distribution: comp
Date: Tue, 13 Oct 1992 13:47:18 GMT

In article <1992Oct10.181920.26933@polari>, kyl@polari.online.com writes:
> [...]
> A good place to start may be a Ph.D thesis by Douglas Wiebe,
> 
> "Generic Software Configuration Management: Theory and Design."
> 
> Among other things, it includes an extensive references.  It is close to
> 300 pages long.
> 
> University of Washington
> Computer Science Technical Report 90-07-03.

Is this available via anonymous FTP?

------------------------------------------------------
Chris Fulmer                    Bell-Northern Research
Sr. Software Designer            Research Triangle, NC
mail to woodstock!chris@mcnc.org (preferable) or...
        chrisf@bnr.ca            (not so preferable)
Oh yeah.  The usual disclaimers apply here.



Newsgroups: comp.software-eng,comp.object,comp.specification
From: kudzu@netcom.com (Michael Sierchio)
Subject: Seeking Object Modeling Tool
Followup-To: bux@tfs.com
Keywords: Booch, Object Modeling, ROSE, Rational
Reply-To: bux@tfs.com
Organization: True Love, and Home-Grown Tomatoes
Date: Wed, 14 Oct 1992 23:23:33 GMT

[Please do not reply to sender -- posted responses may not be read
 respond to 'bux@tfs.com'  Thanks]


I'm looking for some software (to run on my sparc ipx) that will help me 
draw object models using (preferably) the Booch notation.  Any
suggestings?

p.s. I've already seen Rational's product, "Rose".

Thanks,

David Buxbaum  (bux@tfs.com)
-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 14 Oct 92 14:58:29 EST

In article <1992Oct13.122727.10076@afit.af.mil>, jcardow@afit.af.mil (James E. Cardow) writes:
[...]
>asks: 
1.> 	What is the GOAL of software engineering?
> 
Oh boy, fun!

Actually we might want to attack this question by some re-emphasis of the
words.  (My caps key is NOT stuck.)

2. What is the goal of software ENGINEERING?

3. What is the goal of SOFTWARE engineering?


Does the GOAL mean final objective, personal objective, disciplinary objective,
project objective?  In asking this question, what domain are we conversing
about?  Without establishing a common ground, I have the feeling that this
thread could go on forever.  I  would suggest that we use as a basis Mary
Shaw's model  in Software Magazine, November 1990, as a starting point.  That
is, that first of all we are talking about a disciplinary goal.  To address
an answer to variation number 2 above, we are in the process of developing a
discipline that shall: create cost-effective solutions to practical problems by
applying scientific knowledge to building things in the service of mankind.

I would then argue that our goal is to take us to the point where we can
satisfy that definition.  But do we agree on what SOFTWARE is as noted in
variation number 3?  Most engineers in any other discipline would be able to
communicate about the field.  Do we have agreement on the terms, not just
intellectually, but viscerally.  We know many of the problems of the field, but
IMHO we cannot communicate sufficiently about the solutions yet, because they
often are not well known.  

My proposal seems to be tending to the following idea.  What we do now is not
engineering.  What we do is apply scientific and engineering methods to a field
that we suppose should follow those methods, but the theoretical underpining to
verify and support that supposition is not yet there.  To the field that we are
working in, we are contributing data, information and groundwork to help decide
if it can one day be an engineering discipine.  It is not there yet.

Once the field satisfies the definition, then we can agree that the goal of
software engineering can bethe same as the goals of any engineering discipline.  

However, our work now is to prove that it is.  

One last thought (for this posting).  There is at least the possibility that
software should be put into its own box, not magic, not engineering, not
science.  I do not know what to call it.  I suspect that this unknown category
may not exist.  However, in pushing this work into a discipline, it may go
where we do not expect it.

George Kambic
sd

we are creating software solutions and building 
software things.
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
From: alanb@sdl.mdcbbs.com (Alan Braggins)
Date: 12 Oct 92 14:21:21 GMT
 929@ucsbcsl.ucsb.edu> <1992Oct8.155518.10265@athena.mit.edu><1992Oct10.212424.4869@intellistor.com>
Organization: Shape Data (Division of EDS), Cambridge UK
In-reply-to: wicklund@intellistor.com's message of Sat, 10 Oct 92 21:24:24 GMT

>>>>> On Sat, 10 Oct 92 21:24:24 GMT, wicklund@intellistor.com (Tom Wicklund) said:

> In <1992Oct8.155518.10265@athena.mit.edu> tada@athena.mit.edu (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_ ...."  

>>As an example, I've seen problems caused by a pilot development project
>>characterized by 350 data elements but expected to run in full
>>production on 2500+.  Some programmers implemented things that met time
>>requirements for the small data set, but were helplessly slow on the
>>large one.

> 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).
--
     Alan Braggins, alanb@sdl.mdcbbs.com, abraggins@cix.compulink.co.uk
Shape Data - A division of EDS-Scicon Limited.   Cambridge, UK +44-223-316673
   "Any technology distinguishable from magic is insufficiently advanced."
 "My employer does not necessarily share my views - but I'm working on it."
From: chrisp@regenmeister.Sun.COM (Chris Prael)
Newsgroups: comp.software-eng
Subject: Re: Software Inspections
Date: 8 Oct 1992 16:45:26 GMT
Organization: Sun Microsystems Inc., Mountain View, CA
NNTP-Posting-Host: regenmeister

From article <torres.718340429@yacht>, by torres@ee.fit.edu (Francisco Torres):
> I am taking a course in Software Engineering and have been asked to write a report on
> Software Inspections.  However, I have been unable to find any information on the subject.
> I would apprectiate any help that could be provided from people in this group.  I do not
> really know what Software Inspections are, but I have been told that they are essentially
> meetings where a group of people examine the code of a project line by line and question
> some of the decisions that were made.  I would appreciate any information either as a posting
> to this news group or as an E-Mail response.
> 
> 
> Thanks in Advance,
> 
> Frank

The concept was introduced in the book "The Psychology of Computer
Programming" about 1975. This book is probably still the most complete
source on the topic.  There has been little to no development of the
concept since then.

Chris Prael
From: martelli@cadlab.sublink.org (Alex Martelli)
Newsgroups: comp.software-eng
Subject: Re: Code Inspections and Walkthroughs (followup)
Keywords: inspections, walkthrough, verification, validation, Fagan
Date: 13 Oct 92 07:43:20 GMT
Organization: CAD.LAB S.p.A., Bologna, Italia

johnb@searchtech.com (John Baldwin) writes:
	...
:Mini Summary:
:
:   1.  Download the 88 page C++ inspections guide written by Ellemtel.
:
:   2.  Brian Marick of Testing Foundations in Illinois has written
:       a shorter inspections guide, which is also publicly available.
:       He has also written a coverage tool and several papers.

Please supply the anon ftp locations for Ellemtel's and Maricks' works.
-- 
Email: martelli@cadlab.sublink.org                   Phone: ++39 (51) 6130360
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: ++39 (51) 6130294 
Newsgroups: comp.software-eng
From: trajanos@fbmtds01.tu-graz.ac.at (Zlatko Trajanoski)
Subject: Boundary Element Software wanted!
Originator: trajanos@fbmtds01
Organization: Technical University of Graz, Austria
Date: Wed, 7 Oct 92 11:27:58 GMT

We are looking for any boundary element software package (C++ class libraries,
C libraries, FORTRAN libraries or completely developed application)
for a DECstation running under ULTRIX.

Interesting responses will be summerised.

Thanks.

Zlatko Trajanoski
-- 
| Zlatko Trajanoski                  e-mail: trajanos@fbmtds01.tu-graz.ac.at |
| Institute of Biomedical Engineering   Tel: +43 316 873 7389                |
| Graz University of Technology         Fax: +43 316 465348                  |
| Inffeldgasse 18, 8010 Graz, Austria                                        |  
Newsgroups: comp.software-eng
From: R14482@paccvm.corp.mot.com (Arthur Chung)
Subject: Re: Productivity of a C programmer ?
Organization: Motorola
Date: 10 Oct 1992 14:30:12 HKT

Hi,

Regarding on this topic, how about analyse the relationship of
number of working hours and line of code. We can also think about
doing some analysis about the errors that the programmer generates in
his codes during compilation. Later on, we can compare these data
with the complexity of the software. Then, we may be able to conclude
whether the programmer is productive or not. Does it make sense?

However, I want to get people's comments on what other information
or data that we can extract during during development. The more
information we can get, the more analysis that we can have for
productivity. Currently, only using LOC, # of working hours, # of
errors are rather primitive.

My thanks in advance for any ideas!

Arthur
From: aro@aber.ac.uk (Andrew Ormsby)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 12 Oct 92 11:29:40 GMT
Reply-To: aro@aber.ac.uk (Andrew Ormsby)
Organization: CS Dept, University College of Wales, Aberystwyth

In article <1992Oct6.185140.10259@news.arc.nasa.gov> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:

In article <20991@plains.NoDak.edu>, kmagel@plains.NoDak.edu (ken magel) writes:
|> 
|>       Many articles here and in the popular press bemoan the "fact" that
|> software engineering does not do anywhere near as well as other more mature
|> forms of engineering in delivering completed products on time and within 
|> budget.  However, I recently was involved in two incidents involving other 
|> forms of engineering which indicate that every form has similar difficulties.

> 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 can't remember the precise details, but it is certainly true that
the cost of the Channel tunnel (actually a Anglo-French project, not
merely English) have escalated and the opening date has slipped and
continues to do so. So does the share price.

It seems to me that a large number of big engineering projects get
into trouble when they try to do something new. Even when doing
something which isn't new, many problems arise. The Channel tunnel has
been plagued with late changes to the original specification, mainly
due to fears about safety. Late specification changes are something
that most software engineers are only too familiar with.

When builing something more novel than a tunnel, things can go very
wrong. Concorde is supposed to have cost 545% more than originally
planned. I seem to remember that the Space Shuttle also cost rather
more than was originally planned. Bridges fall down, buildings
collapse, refineries blow up...

Petroski's book ("To Engineer is Human --- the role of failure in
successful design") has been mentioned in this forum before, but I
make no apologies for doing so again. Engineers learn largely by
making mistakes. Failure is a necessary part of the engineering
process (he argues). The important thing is to learn from them and try
to make sure that they don't happen again. The real test for software
engineering is the extent to which it succeeds in doing this.

--
Andy Ormsby, aro@aber.ac.uk
Newsgroups: comp.software-eng
From: bhaim@osf.org (Bruce Haimowitz)
Subject: Re: distributed testing tools?
Keywords: distributed test tools
Cc: bhaim, alan@auntbea.austin.ibm.com
Organization: Open Software Foundation
Date: Mon, 12 Oct 1992 20:37:15 GMT

>
> It was my understanding that OSF developed something called D-TET,
> or Distributed TET (TET is the X/Open standard Test Environment Toolkit).
>

The implementation of D-TET was done by X/Open.

> I also understand that it was evaluated and found to be seriously
> lacking in functionality and quality.

As far as we know D-TET is the most complete
distributed test implementation available.
Please explain what you mean by "lacking".


-- 
Bruce Haimowitz
OSF (617) 621-8936
11 Cambridge Center * Cambridge MA 02142
bhaim@osf.org
Newsgroups: comp.software-eng
From: wicklund@intellistor.com (Tom Wicklund)
Subject: Re: Testing (Was: Do Software Engineers Actualy Do So Badly?)
Organization: Intellistor, Inc.
Date: Sat, 10 Oct 92 21:38:38 GMT

Let me throw out a few thoughts on testing.

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.

One of the differences between software and other disciplines is how
testing is done.

If you build something physical, each component is generally tested.
Either on receipt, or by the manufacturer in some manner.  In
electronic products early on all parts may be tested, then those with
proven reliability may be spot tested or one may buy pre-tested parts
from the manufacturer.  It's the exception to put together a mainframe
computer (or larger) then turn it on without any intermediate test.

Yet this is how software is often developed.

I see two general reasons for this lack of test (other than the fact
that the developer finds test cases boring).  Note I'm talking about
component test right now, not final product test (which should have a
separate test suite).

1.  It's hard to test individual components.  I work with software
attached to physical devices (disk drives, host computers).  It's very
hard to test a single unit of code because the device needs too much
of the outside world attached.  And it's very hard to simulate this
because the timing can be extremely complex.  Physical devices also
like to do things which you never would have expected (neither do the
developers of those devices in many cases).

2.  Even when components can be tested, it's extremely painful.  For
example, in the UNIX/C environment when I've seen tests for software
they are often in the form of a main program attached to the end of
the source file which is turned on via a #define.  This is very nice
but means that in order to run the test one must compile and link
specially (with the test enabled), test the component, then recompile
without the test.  Of course, this tends to be ignored for "minor"
fixes or when time is running out.

What is needed is a way to painlessly run a regression test on a
component during a normal make of the main program.  The regression
test also needs to be easily modified as the component is modified
(ideally still in the same source file) since it's too easy to say
"we'll update the test later".

The test tools I've seen advertized tend to be designed to test the
finished product, especially tests which replay keystrokes (since
interactive programs tend to fit in category #1 above).  This is nice
but when a problem occurs you still have to find the component in
error.

If such products exist I'd be interested in hearing about them.  I've
got something hacked together to provide fairly painless C++ class
testing as part of a normal make, but it's just been spare time
playing around.
Newsgroups: comp.software-eng
From: troyer@mitre.org (Tom Royer)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: The MITRE Corporation
Date: Wed, 14 Oct 1992 14:11:38 GMT

In article <1992Oct13.122727.10076@afit.af.mil> jcardow@afit.af.mil (James 
E. Cardow) writes:
> 
>         What is the GOAL of software engineering?
> 
Let me be a heretic.  When I, as a software engineer, get assigned to a
project, my goal is to solve my customer's problem -- not improve the
engineering process.

I think that we very often spend too much time worrying about software
and not enough on what that software is supposed to do and how it will
be used in real operation.  A great deal of the failed software reported
by the GAO failed, not because it didn't work in some sense, but because
the product that was bought didn't meet the end users' expectations;
and that because the users' expectations weren't communicated to the developers.

Now, before I get flamed too much, improving the engineering process
should make it easier for me to solve the users' problem.  In fact,
that's my definition of improving the process.

--
Tom Royer
From: rrt@mpd.tandem.com (Robert Teisberg)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 13 Oct 92 18:36:09 GMT
Article-I.D.: devnull.2632
Reply-To: rrt@amadeus.UUCP (Robert Teisberg)
Organization: Surely you jest

In article <1992Oct13.143244.4833@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:
>               A small defense might be that such design documents are rarely
>criticized for this lack of discussion of alternatives.

Indeed, I was once instructed by my boss to remove from a design
document a discussion of alternatives rejected.  The justification for
this was that it would confuse the readers who only wanted to know
what I planned to do.  They didn't care what I had chosen not to do,
much less why.
-- 
Bob Teisberg @ Tandem Computers, Inc. | rrt@mpd.tandem.com
14231 Tandem Blvd.                    | (512) 244-8119
Austin, Texas  78728                  |
Jimmy and I have a deal.  Jimmy doesn't hack code; I don't speak for Tandem.
Newsgroups: comp.software-eng