HDTenEightyP/NetNews huggingface dataset:
From: cga66@cbnewse.cb.att.com (patrick.v.kauffold)
Newsgroups: comp.software-eng
Subject: Re: Wanted: Info on "six-sigma" system
Date: 9 Oct 92 17:38:34 GMT
Distribution: usa
Organization: AT&T

From article <1992Oct9.085040.2992@cbfsb.cb.att.com>, by djones@cbnewsg.cb.att.com (david.jones):
> 
> Has anybody heard of "six-sigma" ?
> 
> What is it ?

It stands for six standard deviations (from the mean).  The concept
comes from reliability engineering predictions of system or component
failure probabilities.  For example, the wearout time of a component
may be Normally distributed (mean, standard deviation).  So you want
a component that will have a very small probablilty of failure before
its design life (or within operating stress parameters).  If you set
this at one sigma from the mean, you get ~80% reliability; 2 sigmas
give you ~95%, 3 sigmas give you ~99%, etc.  Six sigmas, if I 
remember correctly, is ~99.99999% -- damn near perfect.

The process for getting six sigmas for mechanical or electronic
components is well known.  Consult any basic reliability engineering
text.

For software reliability, it is not quite so clear cut in that we
don't have very good predictive models, failure modes, etc.  One
approach is to predict faults remaining as a function of faults
found in earlier phases.  Six sigmas would mean that your process
will find ~99.99999% of all of the faults before the software is
put into service.

Easy for me to say . . .

Pat Kauffold
AT&T Bell Labs
Naperville, IL
(708) 713-4726
Newsgroups: comp.software-eng
From: lehman@george.arc.nasa.gov (John Lehman -- GDP)
Subject: What solution? Re:Truth in estimating.[Was:Re:DoSoftwareEngineersActu]
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Thu, 15 Oct 1992 18:23:34 GMT

> Correct, working software costs more than anyone seems to be willing to
> pay for it.  Thus the only way to get someone to pay for software is to
> lie to them to get the contract/commitment/whatever, then nickel and
> dime them to death with cost overruns, schedule slips, bug fixes, etc.
>
> I believe (but don't know) that it would be cheaper to do it right the
> first time, but nobody seems to be willing pay the price up front.  The
> customers all seem to be looking for a free lunch.  And there is always
> another contractor out there who'll tell the big lie just to get the
> contract.
>
> I'm sick to death of it, but I don't know what to do about it.

> Douglas Surber

My software engineering instructor spoke of this problem and
claimed that his estimates really were the truth; I noticed he
changed jobs a lot, but at least he was able to get work.

The problem you state is really a very, very general problem,
occurring in everything from personal relationships to presidential 
elections.

However, I doubt that there is really a solution short of risking
losing your job or, in some areas, saying goodbye to a promotion.
In other words, if you want to solve the problem then you have to tell
the truth regardless of the consequences.  So, either one can't allow 
oneself to get into a position of really needing the money; or else, 
just put up with the problem or the risks.  Some people _can_ lead 
satisfying careers using nothing more than the truth, but those are 
rare people.

There's some hope in building a reputation for telling the truth.  But,
it takes time for this to bear fruit, and people feel like they don't 
have that much time.

lehman@ames.arc.nasa.gov
From: kjones@luke.eecs.wsu.edu (Kent Jones - EECS)
Newsgroups: comp.software-eng
Subject: Public Domain Software Project Planning Tools Survey
Keywords: Gantt, Pert, Project Planning etc...
Date: 8 Oct 92 20:49:56 GMT
Article-I.D.: serval.1992Oct8.204956.2580
Organization: Washington State University!

Hi,

I started out by wondering if there is any public domain project planning tools 
available for UNIX/Xwindows. I would like something that generates a 
time-line from a block diagram or something like that. I searched the 
FAQ and archie, but could not find anything. 

I decided that in the past I have just queried for information, recieved it,
thanked the senders, and then no one else on the net benefits from my 
query. So I decided to do a survey and then somehow get that information
into the FAQ for this newsgroup. I feel I would have then repayed all the
help others have given me. So, here is the proposal:

email me with the information on how to access any public domain
software project planning tools for any machine. To make my life easier,
organize the information as follows:

----------------------------------------------------------------------------

TOOL NAME:	

MACHINE IT RUNS ON:

OPERATING SYSTEM:

WHERE ON INTERNET ITS LOCATED:

----------------------------------------------------------------------------

my email address is:

	kjones@eecs.wsu.edu

I will 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 also.

If there is software available for other systems other than UNIX, label it
clearly and I will add it to the FAQ list.

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
From: byrne@cstore-next.cl.msu.edu (Eric J. Byrne)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 16 Oct 92 15:54:10 GMT
Organization: Michigan State University


James Cardow asked:

> > 
> >         What is the GOAL of software engineering?

Tom Royer replied:
> > 
> 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 would say that the goal of software development is to create a
   software system that solve's your customer's problem.

> 
> 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.
> 
    I would say that software engineering and software development are not
  the same thing. Even though the two terms are often loosely used
  interchangably. Hence, the goals of each are not identical.  

       Development focuses on creating a solution
       Engineering focuses on how to create a solution.

  Need I say, IMHO ...

    Eric Byrne
Newsgroups: comp.software-eng
From: tcubed@ddsw1.mcs.com (James Hanlon)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: Thu, 15 Oct 1992 17:11:57 GMT
Organization: ddsw1.MCS.COM Contributor, Chicago, IL
X-Newsreader: Tin 1.1 PL3

wicklund@intellistor.com (Tom Wicklund) writes:
: Changing requirements are a problem, and they should be tracked
: better.
: 
: 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 ......
: 
: In general I've found any attempt to make a project "general" is
: criticized because we need to meet schedule. 

I have heard other reasons, but the broader point, of software practitioners
resisting generality, is valid in my experience. Something about generality
or flexibility is somehow perceived to be hard, or risky, or costly. But, as
the great thinkers have noted, change is the one constant in life. Not
factoring it in at every turn seems shortsighted and self-defeating. And
it's especially ironic to find it absent in software--after all, isn't that
why they call it "soft" ?

Jim Hanlon
tcubed@ddsw1.mcs.com
Newsgroups: comp.software-eng
From: kyl@polari.online.com
Subject: Re: Too many standards
Keywords: 2167A, IEEE, ISO
Organization: Seattle Online Public Access Unix (206) 328-4944
Date: Tue, 13 Oct 1992 01:43:19 GMT

In article <1992Oct2.161426.6074@inesc.pt> belen@rabbit.inesc.pt (Belen de Vicente) writes:
>Hi!
>
>I'm a little confused with software engineering standards, there are
>so many: DoD-2167A, ANSI/IEEE, ISO, ...
>

I believe it should be attributed to Tannenbaum:

"The beauty of standards is that there are so many to choose from."

kyl@polari.online.com
From: wicklund@intellistor.com (Tom Wicklund)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Intellistor, Inc.
Date: Sat, 10 Oct 92 21:24:24 GMT

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_ ...."  

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

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

I think you've hit much of the problem.

Changing requirements are a problem, and they should be tracked
better.

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.

I've also found that very, very few software developers, let alone
managers, are willing to design with changing requirements in mind.
In general I've found any attempt to make a project "general" is
criticized because we need to meet schedule.  The fact that it'll cost
a fortune down the line, and that the product will eventually be even
later, isn't a factor.  I find the answer is to make it general and
don't tell anybody, but this isn't a good answer.
From: byrne@cstore-next.cl.msu.edu (Eric J. Byrne)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 16 Oct 92 16:14:08 GMT
Organization: Michigan State University


R.T. Herbst writes:

     ...  Stuff deleted ...
> Let us admit 
> that we do not have a mathematical model for software. But we do have many
> very good tools.

   No, lets not admit that.  Software is well grounded in mathematics.  The
  meaning or semantics of any piece of software can be expressed and reasoned
  about using mathematics and mathematical theories.  

    Yes, we have many tools, but many tools seem to embody ad-hoc techniques
  or solutions to a particular need or problem.  The development and use
  of mathematical models provide insights into the fundamental characteristics
  of a problem and the use of these models provide a solid foundation
  for the development of useful techniques that can then be embedded into
  tools.  As an example, consider the development of finite state machines
  and push down automate as a mathematical model underlying the problem
  of parsing programming languages.  True, parsers existed before these
  models were development, but development of parsers was a black-art with
  no basis.  The arrival of FSM's and PDA's destroyed the black-art approach
  and provided the basis for much better parsers.

   Eric Byrne
   Kansas State University
From: ciarfela@sigma.ece.ucsb.EDU (Paul Ciarfella)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 7 Oct 92 17:41:39 GMT
Article-I.D.: ucsbcsl.5929
Reply-To: ciarfela@sigma.ece.ucsb.EDU (Paul Ciarfella)
Organization: University of California and Digital Equipment Corporation

In article <1992Oct6.194745.11306@saifr00.cfsat.honeywell.com>, shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
|> In article <20991@plains.NoDak.edu> kmagel@plains.NoDak.edu (ken magel) writes:
> 
|> I'm sure most of you have heard the phrase "It's only software" used
|> as an excuse for a change in the requirements. I am convinced many
|> large-program managers haven't a clue on the vital importance of
|> freezing requirements at SOME point or suffer the consequences, i.e.,
|> overrun schedules and/or blown budgets. As long as the mentality of
|> "it isn't made of metal or concrete, so it can easily be changed"
|> persists, and requirements remain fluid and subject to change,
|> software projects will run late and expensive.
|> 
|> Mark Shanks


What's even worse is the attitude encountered in firmware environments
when a problem is found in the target hardware.  The consensus (made by the
hardware designers) is that the problem will be easy to fix in the software.
Program managers are quick to agree because it can take far less time to fix
the problem in software than to respin a board.
 
Fixing the problem in software usually involves a schedule change, to 
	   a. design the fix, implement, and test it, and
	   b. to work around the hardware problem until the fix is in place
	      (if you're able to)

Much worse, the fix can complicate the software by the inclusion of a hack 
or special code to handle the problem hardware.  This has far-reaching
implications, especially down the line with maintenance releases for hardware
which contains the bug, and new hardware which might not now contain the bug.

Paul Ciarfella
From: sean+@andrew.cmu.edu (Sean McLinden)
Newsgroups: comp.software-eng
Subject: Wanted: Rumbaugh OOM Tool
Date: 9 Oct 92 07:27:52 GMT
Article-I.D.: andrew.wepOHsW00WBNM2TFd6
Organization: Carnegie Mellon, Pittsburgh, PA


Is anyone aware of the availability of modelling tools which support
the Rumbaugh methodology. I know about OOMTool, which we have tested,
but it is only available for the SPARC platform. References to other
Unix or Mac based tools would be appreciated.


Sean McLinden

 
Newsgroups: comp.software-eng
From: herbst@seq.uncwil.edu (R.T. Herbst)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Summary: Part b of your response should be emphasized. I have studied
	 many books and papers on software engineering. Almost none deal
	 with the use of software tools. For example the use of SCCS
Date: 15 Oct 92 03:28:27 GMT
Organization: Univ. of North Carolina @ Wilmington

In article <1992Oct13.145651.8121@msuinfo.cl.msu.edu>, byrne@cstore-next.cl.msu.edu (Eric J. Byrne) writes:
> 
> 
> James E. Cardow writes:
> > (1)	- We have very little faith in our own field.  The basis for the
> > 	thread in this news group is repeated very often.  We don't
> > 	believe we do a very good job.
> > 
> > (2)	What is the GOAL of software engineering?
> 
> 
> Maybe this is too simplistic of an answer, but look at (1) again.  If
> we don't believe software engineers do a good job, then isn't the goal
> of software engineering to (a) improve the quality of engineering
> products, and (b) improve the means by which these products are created.
> 
> 
>   - Eric Byrne
>     Kansas State University

Certailny item b above is very important. I have studied thrity or more books
on software engineering. Almost none of these deal with the
use of software tools. For example the use of SCCS in software manufacture. 
Electrical engineers have many tools and testing devices. Some EE's
even use computers to design such things as vlsi chips. Let us admit 
that we donot have a mathematical model for software. But we do have many
very good tools. Compilers, editors, SCCS, tracing programs, programs that
will indicate test coverage. In teaching SE, I emphasize the use of
tools to do the job. We at times have invented a few tools. Each tool 
is supposed to help improve the product.
herbst@seq.uncwil.edu
From: phardie@nastar.uucp (Pete Hardie)
Newsgroups: comp.software-eng
Subject: Re: Testing (Was: Do Software Engineers Actualy Do So Badly?)
Date: 15 Oct 92 14:51:53 GMT
Organization: Digital Transmission Systems, Duluth, GA.

In article <MATT.92Oct14204612@raven.bacchus.esa.OZ.AU> matt@bacchus.esa.OZ.AU (Matthew Atterbury) writes:
>    But isn't this the point? A TTL component _could_ have any
>    conceivable values on its output (not just 0/+5V or whatever it
>    is), but it _doesn't_ - it is considered a TTL component because
>    it follows the standard. One of the goals of people who argue that
>    S/W should be more like ICs is to come up with these standards.
>    Brad Cox has a lot more intelligent things to say on this subject
>    than I do.

Exactly - EEs in digital design have lots of great automation tools, because
of this standard.

Those EEs in analog have a more difficult job.  And they have a little help
in that nature prevents abrupt transitions in electrical fields, for the
most part.

As I mentioned in a previous post, if we had a software standard that limited
our function values to a small set, ALWAYS, then we would have a better shot
at quality control, and reuasble software components.

But we don't have this - programs are still at the craftwork stage, largely.
Major projects still require custom software because they involve non-standard
components of other things.  From my current work, we have built a network
management system that is not a standard because the client did not want to
have the managed elements comform to a NM standard. (Or did not have the time
to allow this).  Nobody wants an off the shelf solution if it requires them to
change their current way of doing things.  Everyone has just *one* little thing
they want to do differently, and can you change this over here, too?

Perhaps this is the result of us software types being agreeable to such tactics,
and letting the specs change on the fly.


-- 
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: sp_pm@space.alcbel.be (Paul Moore)
Subject: Has anyone successfully used HOOD?
Date: Mon, 12 Oct 92 10:51:36 +0100
X-Received: by usenet.pa.dec.com; id AA01112; Mon, 12 Oct 92 05:22:05 -0700
X-Received: by inet-gw-1.pa.dec.com; id AA29485; Mon, 12 Oct 92 05:19:54 -0700
X-Received: from ub4b.buug.be by mcsun.EU.net with SMTPid AA08520 (5.65b/CWI-2.179); Mon, 12 Oct 1992 13:19:23 +0100
X-Received: from alcbel.UUCP by ub4b.buug.be (5.65c/ub4b_02)id AA28517; Mon, 12 Oct 1992 13:18:15 +0100
X-Received: from se.alcbel.be by alcbel.be (4.1/SMI-4.1)id AA04438; Mon, 12 Oct 92 10:47:39 +0100
X-Received: by se.alcbel.be (5.57/SE_04)id AA26070; Mon, 12 Oct 92 10:52:28 +0100
X-Received: from btmpjw.space by space.alcbel.be (4.1/SMI-4.0)id AA03349; Mon, 12 Oct 92 10:51:36 +0100
X-To: comp.software-eng.usenet

Hello,

I have just started working for a company working in the aerospace field. I
have some questions about the use of HOOD, and I would be grateful for some advice.

1. I have had some experience with the Ward/Mellor and Hatley/Pirbhai
   structured analysis methodologies. There are two excellent books available
   that explain how to use these methodologies [1] and [2], each with
   lots of examples showing how the method is used. It seems that the only
   documents available explaining how to use HOOD are the HOOD User Manual,
   and the HOOD Reference Manual. These two manuals do not explain how to use
   the methodology, and certainly do not explain the methodology to new users.
   Are there any better books available that teach the use of HOOD? It should
   *NOT* be necessary to attend a training course to learn how to use HOOD.

2. It seems that HOOD is used at the structured design level of the 
   analysis/design/implementation software project cycle, as defined by
   Constantine/Page-Jones and Yourdon/Ward/Mellor. This means that its use
   should be preceeded by a structured analysis phase. Is this correct? How
   does it relate to modern structured analysis techniques, such as the two
   mentioned in point 1 above, and which structured analysis methodology is
   recommended for use with the HOOD methodology?

3. It seems that HOOD is oriented towards Ada as the implementation language.
   Does this mean that HOOD is still mandated by ESA when the language used
   is not Ada, for example C and C++. If so, can HOOD still be used if the
   implementation language is not Ada. For example, HOOD appears to take
   advantage of Ada's built-in inter-process-communication facilities. What
   if these facilities are not present in the implementation language used?

I will summarise responses I get to the net, if sufficient interest warrants.

Regards, Paul

[1] Structured Development for Real-Time Systems, Vols 1-3, 
    Paul T. Ward and Stephen J. Mellor, 1985.
[2] Strategies for Real-Time System Specification,
    Derek J. Hatley and Imtiaz A. Pirbhai, 1987.

---
Paul Moore,                      email: sp_pm@space.alcbel.be
Alcatel Bell Telephone,
Space Dept. TS 664,              phone: (+32) 3/829.5024
Berkenrodelei 33,
2660 Hoboken,
Belgium
From: phardie@nastar.uucp (Pete Hardie)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 7 Oct 92 14:31:12 GMT
Organization: Digital Transmission Systems, Duluth, GA.

In article <1992Oct6.190453.14230@m.cs.uiuc.edu> hasker@m.cs.uiuc.edu (Rob Hasker) writes:
>Even bigger mistakes abound:  Here at U. of Illinois in Urbana-Champain,
>the newly constructed computer science building was to have a glass-covered

> [ atrium plan and cooling cost snafu ]

At the Georgia Institute of Technology, the state's premier engineering
university, they designed a parking deck for students that regularly gets
flooded.  Pretty embarassing for a discipline that has been around for how
many centuries?

-- 
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: uunet!lkba!lkb (Larry Blische)
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Reply-To: uunet!lkba!lkb
Organization: LKB Associates, Inc.
Date: Wed, 14 Oct 1992 03:33:41 GMT

In article <1992Oct13.151413.28119@smds.com> sammy@smds.com (Samuel Murphy)  
writes:
> 
> 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!

Like ISO, SAE, etc...
A problem with standards: they don't evolve well, nor should they.
They are argmented with other 'standards' that address the weaknesses of  
their predecessors.  With so many standards there can be much confusion.

>                     I also see non-standard heads, that require a special
> screw driver! 

I'm not sure what the justification for TORX (star) heads are but I bet GM  
service providers like them since less people changed their own headlights  
when they first came out, maybe still! (half :-)).  And the cable TV boxes  
use the TORX with the central stud to keep out prying, security breaking  
eyes!  Following the standard is too open for them.

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

Larry Bliache
uunet!lkba!lkb
Newsgroups: comp.software-eng