HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.software-eng

From: tada@athena.mit.edu (Michael J Zehr)

>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.
>Any comments?

Two solutions:
i) Fuller, more formal, better tested specifications. The spec. not only
mentions time requirements, but gives a full test example. If the
programmer still gets it wrong, it's clear what to do.

ii) Make sure the programmers actually understand what the code will be
used for. Then they won't make that kind of mistake.

Applicability:
i) is the way to go when you've got a neatly-circumscribable specification
(e.g. firmware component) and lots of time and money. If the environment
is open-ended (e.g. for most interactive software), it's impossible to
write a full specification, and attempts to do so rapidly become
counterproductive.

ii) is the way to go in these circumstances. When I've been unfortunate
enough to work in environments where programmers had no idea how their code
was to be used, I've been baffled how they make design decisions like the
one you cite. How do you know whether to use a linked list or hash table
for the wiggly-thing list if you've no idea how many wiggly things the
user is likely to create, how often they're likely to be searched for, and
how likely insertions are to take place into the middle of the list? Hack
programmers don't seem to bother much about such questions - so how do they
decide? Sometimes the software they produce is adequate, often it needs
extensive and expensive rework.

Dave
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Software Inspections
Date: 8 Oct 92 14:39:44 EST

In article <ld8pd6INNqti@exodus.Eng.Sun.COM>, chrisp@regenmeister.Sun.COM (Chris Prael) writes:
> 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.
> 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.

I don't have this book.  IS  the concept identical to Fagan's model in the 1975
IBM paper?

George Kambic
sd
From: bagwill@swe.ncsl.nist.gov (Bob Bagwill)
Newsgroups: comp.software-eng
Subject: Re: Wanted: Info on "six-sigma" system
Date: 9 Oct 92 20:47:44 GMT
Distribution: usa
X-Newsreader: TIN [version 1.1 PL6]

patrick.v.kauffold (cga66@cbnewse.cb.att.com) wrote:
: From article <1992Oct9.085040.2992@cbfsb.cb.att.com>, by djones@cbnewsg.cb.att.com (david.jones):
: So you want a component that will have a very small probability of
: failure before its design life (or within operating stress parameters).
: ....
: For software reliability, it is not quite so clear cut in that we
: don't have very good predictive models, failure modes, etc.

Just adjust the design life accordingly.  For shrink-wrapped software,
the design life is ten seconds before you open the package.  For custom
software, its ten seconds after the check clears.

:-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-)
--
Bob Bagwill
bagwill@swe.ncsl.nist.gov
Newsgroups: comp.software-eng
Subject: <None>
From: royce@mdcbbs.com (Royce D. Myers EDS/Unigraphics)
Date: 16 Oct 92 08:22:20 GMT
Organization: Electronic Data Systems, Unigraphics Division, Cypress CA
Nntp-Posting-User: shah

jcardow@afit.af.mil (James E. Cardow) writes:

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

Robert France responded to this article quite well, but on this point I must
disagree.  The high tech layoffs in California (north & south) are a _direct_ 
result of a down turn in the demand, especially in defense.

-- 
Royce Myers			EDS Unigraphics
royce@mdcbbs.com 		"Work is the curse of the drinking class"
					-- W. C. Fields
From: alan@auntbea.austin.ibm.com (Alan R. Weiss)
Newsgroups: comp.software-eng
Subject: Re: The Goal of Software Engineering
Date: 15 Oct 92 21:25:28 GMT
Organization: (speaking for myself)

In article <MARTINC.92Oct13101226@grover.cs.unc.edu> martinc@grover.cs.unc.edu (Charles R. Martin) writes:
>Jim Cardow asks "What is the goal of software engineering"?
>
>I don't think it's all that obscure or occult a thing.

Sure hope not.  My paymaster isn't the Devil, that's for sure!  :-)


>  The goal of
>software engineering is building software to a stated purpose.  As with
>other forms of engineering, we have to consider effects of scale: it's
>mechanical engineering of a sort if I design a hinge for my garden gate,
>but a lot more difficult job to design a garden gate that can be
>mass-produced economically.
>
>The goal of those of us who research software engineering is --- or
>ought to be --- the application of computer science (and other
>techniques such as operations research and industrial engineering) to
>develop methods for building software to a stated purpose.
>--
>		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.


I would add the following:  "... to a given specification, within defined
parameters, and to do so on a consistent, repeatable basis
while constantly improving quality by the application of those techniques."

In other words, you don't *need* software engineering nor software
process models to build software to a stated purpose .... ONCE.
We can always pull Heroic Efforts (tm) to do so.  And, frankly,
a stated purpose says nothing about doing so in a cost-effective
manner, where cost-effective is defined as being on the positive
side of the cost/benefit equation.  Finally, it is not enough
to just build to a stated purpose, but rather to constantly advance
our discipline's ability to deliver ever-improving quality.

I'm sure that even this definition is wholely inadequate, so I submit
it to this forum's peer review for dart-throwing.  :-)

Alan

-- 
   _  Alan R. Weiss   IBM AWD Austin AIX Kernel   11501 Burnet Rd, Bld 905
 _| ~-. alan%auntbea.austin.ibm.com@ibmpa.awdpa.ibm.com | Austin, TX 78758
 \, *_} Inside IBM:  alan@auntbea.austin.ibm.com        | 512-838-8281
   \(   DISCLAIMER:  Working at, not speaking for, IBM  | NEW NUMBER!!
Newsgroups: comp.software-eng
From: lehman@george.arc.nasa.gov (John Lehman -- GDP)
Subject: Re: Do Software Engineers Actually Do So Badly? [Was: "Actualy"]
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Thu, 15 Oct 1992 16:20:59 GMT

>> cost of construction the English channel tunnel ("Chunnel") was about TWICE 

> I would consider this an unfair example as on high profile projects like 
> this, it is almost guaranteed that the "advertised" cost is going to be 
> 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,

Now this, as you have portrayed it, looks like a _good_ example, not of 
engineering per se, but of what I'd call "politics".  As for "high profile":  
if my project has a profile just high enough that someone could refuse me 
money for it, won't I be tempted to cheat in my estimate?  Aren't most 
of the estimates which are given by people asking for money, set more by a 
will to persuade than by a will to show the truth?  

Where does most of the error in estimates come from:  (1) ignorance on the 
part of the estimator, (2) cynical deceit, or (3) a kind of "bad faith" 
where all estimates are inflated because they are expected to be inflated?  

(I didn't use to know what a politishun was, but now I are one.)

lehman@ames.arc.nasa.gov
Newsgroups: comp.software-eng
From: djones@cbnewsg.cb.att.com (david.jones)
Subject: Wanted: Info on "six-sigma" system
Keywords: sigma
Organization: AT&T
Distribution: usa
Date: Fri, 9 Oct 1992 08:50:40 GMT


Has anybody heard of "six-sigma" ?

What is it ?

Any references ?

Many thanks

- Dave


----------
David G Jones            |    Voice: +44 666 832273
AT&T Network Systems     | Internet: mltsa!djones@mlgtw.att.com
Swindon Road             |     UUCP: {...att...}!mlgtw!mltsa!djones
Malmesbury               |
ENGLAND                  |
----------
Newsgroups: comp.software-eng
From: keck@castor.trl.OZ.AU (Brian Keck)
Subject: Re: Request for info - Software Testing Tools
Organization: Telecom Research Labs, Melbourne, Australia
Date: Fri, 9 Oct 1992 14:48:29 GMT

In comp.software-eng, scip2060@nusunix1.nus.sg (SARDJONO INSANI) asked:
	REQUEST FOR INFO - SOFTWARE TESTING TOOLS
	Could anyone please give me information on software testing tools
	commercially available, with brief comments of their functionality,
	price and address of vendors?

I have what I guess is a similar question.

What I have in mind are tools that take up where lint leaves off,
for C primarily, but also C++ & Eiffel.

I've seen the thread on Purify/dbmalloc/Sentinel, but am more interested
in programming style as it affects maintainability & other good things
(reliability, efficiency, portability, interoperability, ...).

Thanks for any help,

Brian Keck

b.keck@trl.oz.au, phone +61 3 253 6407, fax +61 3 253 6362 
Network Services & Signalling, Telecom Research Laboratories
770 Blackburn Rd, Clayton Victoria 3168, Australia
b.keck@trl.oz.au, phone +61 3 253 6407, fax +61 3 253 6362 
Network Services & Signalling, Telecom Research Laboratories
770 Blackburn Rd, Clayton Victoria 3168, Australia
Newsgroups: comp.software-eng
From: kyl@polari.online.com
Subject: Re: *Theory* of configuration management
Organization: Seattle Online Public Access Unix (206) 328-4944
Distribution: comp
Date: Sat, 10 Oct 1992 18:19:20 GMT

In article <MARTINC.92Sep28222825@grover.cs.unc.edu> martinc@grover.cs.unc.edu (Charles R. Martin) writes:
>Has anyone read anything about the theory of configuration management?
>That is, not "this is a new CM system" but "this is the mathematical
>basis that underlies CM"?
>
>Any pointers gratefully accepted....
>--

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.

kyl@polari.online.com

Newsgroups: comp.software-eng
From: miket@hermes.tcs.com (Michael Turner nmscore Assoc.)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Teknekron Communications Inc.
Date: Tue, 13 Oct 1992 05:01:35 GMT

In article <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.
>....
>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".

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.
---
Michael Turner
miket@tcs.com
Newsgroups: comp.software-eng
From: James.Kandler <James.Kandler@mixcom.mixcom.com>
Subject: Requirements for Safety in Realtime System
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.
Distribution: usa
Date: Mon, 12 Oct 1992 05:02:43 GMT

I have been putting together a list of recomendations and don't for design
requirements for a realtime embedded system that has critical functions that
have a strong impact on safety.  There is several items that I have already
listed like the use of status bytes not bits, etc.

I am interested in other items that you would put on the list.

thanks
jim
-- 
+---------------------------------------------------------------------+
| james.kandler@mixcom.mixcom.com                                     |
| "To error is human, not to attempt to find it is stupid."           |
+---------------------------------------------------------------------+
From: auro@mri.com (Aurobindo Tripathy)
Newsgroups: comp.software-eng
Subject: European Computer Manufacturers' Association reference model
Keywords: ECMA framework
Date: 9 Oct 92 22:24:52 GMT
Organization: Microtec Research Inc., Santa Clara, CA

Is anyone aware of what the ECMA model is? Where can I get more information. `
It has also been adopted by the National Institute of Standards and Technology.

Any help will be appreciated.

auro@mri.com
Newsgroups: comp.software-eng
From: tada@athena.mit.edu (Michael J Zehr)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Massachusetts Institute of Technology
Date: Thu, 8 Oct 1992 15:55:18 GMT


I'm glad to see a return to this topic, with a bit more support for the
premise that software engineering is not like [civil | mechanical | etc.]
engineering.  Imagine a bridge that needs to have its capacity doubled
after a few years in use, and for only a fraction of the initial cost!
(Not to mention with minimal impact on the bridge users!)

Yet to say that software engineers have problems because higher-ups
think of it as only a 'software problem' and change the requirements
frequently is to pass the buck.

The problem isn't to explain why software engineering has problems, but
to accept that we need to find different solutions in order to solve the
different problems the field faces.

[This is not to say we shouldn't pursue things like software reuse,
which in some senses is an idea borrowed from, say, civil engineering,
which designs things out of well-defined smaller pieces.]

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.

Any comments?
-Michael J. Zehr
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: <None>
Date: 15 Oct 92 11:51:52 EST

In article <1992Oct14.210241.3504@afit.af.mil>, jcardow@afit.af.mil (James E. Cardow) writes:
[...]
> 
> Aren't the things suggested above as goals really part of the
> measurement?  Especially predictability?  As strange as it sounds, I
> know and believe that process improvement and measurement are solutions,
> but I just can't fix on the goal, so I can't help wondering if we are
> running faster on a treadmill.  We teach a lot of process stuff here and
> just once I stopped and asked the class if they ever saw a sound
> financial arguement for doing process improvement, none had, neither had
  ^^^^^^^^^^^^^^^^^^^
> I.

One possible answer here is a paper presented at the SEI symposium in Pgh.  Ray
Dion of Raytheon presented a paper showing of close to $20M over a couple year
period when they applied process improvement techniques. Is that the type of
thing that you are looking for?

George Kambic
standard disclaimer

Newsgroups: comp.software-eng
From: johnb@searchtech.com (John Baldwin)
Subject: Code Inspections and Walkthroughs (followup)
Keywords: inspections, walkthrough, verification, validation, Fagan
Organization: Search Technology, Inc.
Date: Fri, 9 Oct 1992 17:33:17 GMT


   About 3-4 weeks back, I posted to c.s-e looking for code walkthrough
   checklists and the like.  I was out of the office for all of last
   week and most of this week... it seems others have discussed the
   topic via a separate thread as well.

   I agreed to post a summary upon my return, but due to the other
   thread, I won't, unless there is enough demand.


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.

   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.

   4.  Read the books by Fagan and by Weinberg.



   If any of this covers topics that were not covered by the recent
   discussion thread, then I'll post a summary if demand > 6 messages.
   Otherwise, I'll email you!


-- 
John Baldwin                                        johnb@searchtech.com
Search Technology, Inc.                             uupsi!srchtec!johnb
4725 Peachtree Corners Circle, Suite 200            johnb@srchtec.uucp
Norcross, Georgia  30092   USA
Newsgroups: comp.software-eng
From: claird@NeoSoft.com (Cameron Laird)
Subject: Re: Properties of software, _not_ systems
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Thu, 15 Oct 1992 13:20:51 GMT

In article <wegner.719078055@gmd.de> wegner@gmd.de (Eberhard Wegner) writes:
>Here is my list of particularities of software. Please check it and
>help me to improve it.
			.
			.
			.
>2) ... [R]eplication is trivial and does not
>even require preparation for new models. 
>3) A copy cannot be distinguished from the original (except by the
>data media that carry the two). However, presumably identical
			.
			.
			.
Good list, Mr. Wegner, but the comments about
"copies" provoke one of my pet complaints.  We
all know it's easy to make copies, but I claim
we need to think through that knowledge more
carefully.

The key premise behind the "ease" of copying is
that we can identify software with its embodi-
ment in a single file.  I see at least three
problems with this:
1.  innovative thinkers are exploring new
    paradigms for human-machine interfaces;
    already there are pen OSs which don't
    interact with the user in terms of files;
2.  MOST commercial software doesn't exist as
    a single file.  Think how SysAd, installa-
    tion of X, and so on are regarded--
    justifiably!--as tasks for experts;
3.  in any case, *customers* define software
    behavorially, not by extension (or file
    enumeration).  Until we teach files to
    carry more information about how to in-
    stall themselves, set privileges, assign
    environment variables, and so on, we
    cheat ourselves in thinking
        "software = file(s)".

I raise these issues because of my own industri-
al experience.  Two of the things that seem
hardest for young software engineers to learn
are
1.  exception-handling; and
2.  the gulf between one successful run,
    which makes a nice display, and a
    commercial product.  Judging the op-
    eration of "copying" trivial is part
    of this.

I'm sure you already appreciate these issues,
but I suggest that it's time our profession
talk about "copying" in different ways, to keep
them in the consciousness of neophytes.

We *should*, of course, be able to automate
software replication ...
-- 

Cameron Laird
claird@Neosoft.com (claird%Neosoft.com@uunet.uu.net)	+1 713 267 7966
claird@litwin.com (claird%litwin.com@uunet.uu.net)  	+1 713 996 8546
From: robert@cse.fau.edu (Robert France)
Newsgroups: comp.software-eng
Subject: Re: Goal of Software Engineering (Was: Do Software Engineers Actualy do so
Keywords: Goal
Date: 15 Oct 92 13:35:16 GMT
Organization: Florida Atlantic University, Boca Raton, FL, USA

In article <1992Oct14.210241.3504@afit.af.mil> jcardow@afit.af.mil (James E. Cardow) writes:
>
>Another input to my question asked if we shouldn't look to architecture
>as the model, with recognition that the goal was to design buildings
>meeting customer needs and safe.

I think from the customer's perspective the goal of software engineering
is quite simple and clear: to produce software that meets current needs.
Since one can expect needs to change during intial development and after
delivery of product then an important concern of software engineering 
is the creation of products that are amenable to controlled change
(modifiable/adaptable specifications, designs, programs; mechanisms
supporting controlled change (e.g. modularity, abstraction) etc.). 
The comparisons with architecture (and other engineering fields) may have
some merits but it is important to note the differences which make 
the problems of SE unique.

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

Hmmm, from a software developer's perspective this may be a goal. Which raises
the following questions: Is the software engineering goal dependent on
perspective (customer/developer)? Should it be dependent on perspective?

>
>Jim
>

Robert
-- 
Robert B. France                              |    Tel: (407) 367-3857
CS&E Dept, Florida Atlantic University,       |    Fax: (407) 367-2800   
Boca Raton, FL 33431-0991                     |    email: robert@cse.fau.edu
===============================================================================
Newsgroups: comp.software-eng