HDTenEightyP/NetNews huggingface dataset:
From: phardie@nastar.uucp (Pete Hardie)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 13 Oct 92 14:32:44 GMT
Organization: Digital Transmission Systems, Duluth, GA.

In article <1992Oct13.050135.9547@tcsi.com> miket@hermes.tcs.com (Michael Turner nmscore Assoc.) writes:
>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.

This is true.  A small defense might be that such design documents are rarely
criticized for this lack of discussion of alternatives.  Ditto comments.
We can be justly criticized for not having block comments at the start of
modules that discuss the "Whys" of the module.  However, on most of the
projects I have worked on, schedules were such that comments were considered
extraneous by management and  staff - we had to get a working product out
the door by June, and comments did not make that any easier.  We all knew that
bad comments would make maintainence harder, but it is difficult to convince
your boss's boss that it's better to deliver late and correctly commented than
on-time and uncommented.

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

I disagree with the inclusion of 'high-level conceptual design' and 'the real
human motivations for writing software' in that list.  Both of these are not
rare (in my experience) in the field.


-- 
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               |
From: p00058@psilink.com (Ronald C. Schultz)
Newsgroups: comp.software-eng
Subject: Cost Estimating OO Software
Date: 9 Oct 92 23:32:04 GMT
Organization: Berard Software Engineering, Inc.
X-Mailer: PSILink (3.2)

I am interested in anyone knowing of any tools or techniques in cost 
estimating the developing of object-oriented software.  In those 
instances where specific tools are identified, I am interested in the 
factors applied for OO software vs. other forms of software as well as 
the tool itself.  Any articles, vendor names, books, and other pointers 
would be sincerely appreciated.

------------------------------------------------------------------------------
Ron Schultz 
Berard Software Engineering, Inc.
Columbus, Ohio Office                   Headquarters
5634 Claire Court                       101 Lakeforest Blvd.
Dublin, Ohio 43017-2440                 Gaithersburg, Md.  20877
(614) 798-0295 Phone                    (301) 417-9884 Phone
(614) 798-0296 FAX                      (301) 417-0021 FAX
ron@bse.com                             info@bse.com
------------------------------------------------------------------------------
Newsgroups: comp.software-eng
From: boag@world.std.com (Scott A Boag)
Subject: Productivity of a C programmer ? 
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Tin 1.1 PL3
Date: Sat, 10 Oct 1992 03:19:10 GMT


I use DSI (Deliverable Source Instructions) as one component of my
estimation method.  I estimate the DSI by breaking the units of 
the software down to the smallest units specified in the conceptual
design, and asign each unit a DSI and complexity factor. I am under
no illusion that these DSI really represent metric lines of code,
rather they are a way of sizing the code that seems to be (for me)
more reliable than simply guessing how fast someone can do it.
Anyway, I then feed the derived DSI and complexity into a CoCoMo
spreadsheet that does all sorts of cool things.  DSI per day breaks
down to 5 to 9 per person for GUI projects we have done.  
This includes design and quality assurance phases, is C code,
with a fairly experianced team o around 10 people.  Note also the
lines are metric, and do not count non deliverable utilities.
A am talking about a 200,000 DSI program.

The good thing about these CoCoMo quotes is that they are larger 
than I would make if I just tried to come up with a number out
of my head.  This way you also have some documentation about -why-
you thought the project was going to take 2 months.

I've seen some of the other quotes about people writing zillions 
of lines of code per day.  I don't beleave it.  Coding time should 
include design, testing, and re-write time, as well as code reviews
and month-long burn-outs from trying to get a deadline in on time.
Remember, DSI means DELIVERABLE source lines.

I think code that is based on the Mac, X-Windows, or MS Windows
should have much less DSI per day than code that is command based. 

-- 
**********************************************************
*  Scott Boag
*  
**********************************************************
From: mswanson@cvbnet.prime.com (Mark Swanson)
Newsgroups: comp.software-eng
Subject: Re: Looking for SCCS -> RCS conversion tool
Keywords: CMS SCCS RCS
Date: 9 Oct 92 17:45:04 GMT
Reply-To: mswanson@cvbnet.prime.com (Mark Swanson)
Distribution: usa
Organization: Computervision, Inc

I had asked about a tool to convert from SCCS -> RCS format.
Several netters pointed me at the "sccs2rcs" shell script which is
part of GNU CVS and can be found in (amoung other places):

ftp.uu.net
	/usenet/comp.sources.misc/volume15
		drwxr-xr-x        512  Jul 29 17:22  sccs2rcs_kc/

This was quite successful once we fixed the usual glitches arising
from "shar wrapping" a file with lines longer than 80 characters.

Thanks to all who replied!
--------------------
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: dmarble@magnus.acs.ohio-state.edu (Duane F Marble)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: The Ohio State University
Date: Fri, 9 Oct 1992 22:55:09 GMT

Based upon a lot of experience in the GIS (Geographic Information Systems)
world, many of the slippage problems result from a failure to get the
user(s) to sign off on requirements. Once the signoff is accomplished,
changes should be implemented ONLY if additional time/$$ are assigned
to the project. Accepting "down stream" changes after signoff can only
be considered self-destructive.
-- 
Duane F. Marble			       E-mail: dmarble@magnus.acs.osu.edu
Department of Geography                Telephone: (614) 292-2250
The Ohio State University
Columbus, Ohio 43210                   Fax: (614) 292-6213
Newsgroups: comp.software-eng
From: greyham@research.canon.oz.au (Graham Stoney)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Canon Information Systems Research Australia
Date: Fri, 9 Oct 1992 06:48:23 GMT

ciarfela@sigma.ece.ucsb.EDU (Paul Ciarfella) writes:
>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.

What you need to realise is that there is a tradeoff involved here. Sometimes
it will be more efficient in the long run to work around a problem in software
than to get the hardware "fixed", particularly if a custom chip is involved.
You're right however that the long term cost of a software workaround is what
should be considered, which may include higher maintenance on any quick-hacks.
Hardware designers aren't "the enemy" though.

I hope that hardware-bashing isn't going to become the norm in this group;
An "us" vs "them" mentality isn't going to advance of software engineering one
iota. One particularly bad example was an article by Bertrand Meyer some months
ago that totally destroyed his credibility in my mind. Up until he launched
his virulent attack on hardware engineers, I had considered him a leader, and
someone to be listened to.

Graham Stoney,
Hardware/Software Engineer
Newsgroups: comp.software-eng
From: lehman@george.arc.nasa.gov (John Lehman -- GDP)
Subject: Goal of SW Eng. [Was: Do Software Engineers Actualy Do So Badly?]
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Thu, 15 Oct 1992 17:02:24 GMT

Someone recently wrote:  "What is the GOAL of software engineering?".
As a first cut:  The goal of software engineering is to know exactly
what each piece of software does.  (Once that is known, then comparisons,
costing, etc. will follow easily.)  "What each piece of software does"
must be verifiable.  The path toward the goal is documentation and testing.

lehman@ames.arc.nasa.gov   (aphoristicRus)
Newsgroups: comp.software-eng
From: cris@cl-next4.msu.edu (Cris J. Holdorph)
Newsgroups: comp.software-eng
Subject: Merge sort
Date: 16 Oct 92 22:11:05 GMT
Organization: Michigan State University


Perhaps this is not the best place to post, and as such I welcome
any comments as to WHERE I SHOULD place such a request.

I am looking for C code of merge sort.  Does anyone have a copy
they could e-mail me or tell me where I could get a copy.  This
would save me from having to track down the algorithm, typing
it into C code, and generally re-inventing the wheel.

All response is appreciated,

---- Cris J H

==================================================
= Christopher J. Holdorph              Team OS/2 =
= ACM Chairperson, Michigan State University     =
= e-mail:  holdorph@frith.egr.msu.edu            =
= NeXT mail:  cris@cl-next4.cl.msu.edu           =
= "...Your dream is over, Or has it just begun?" =
=  ---"Silent Lucidity",  Queensryche            =
==================================================
Newsgroups: comp.software-eng
From: dwwx@cbnewsk.ATT.COM (david.w.wood)
Subject: Re: Class Testing
Organization: AT&T Bell Laboratories
Date: Sun, 11 Oct 1992 05:07:02 GMT


Class testing is really any different than testing any software
component where state is involved (eg, c function with static variables).

Both Myers and Boriz Beizer desribe a technique (one calls it cause-effect
graphing and the other cause-effect matrices) which is most applicable
(note that there is the unstated assumption that you are also performing
both equivalence class and boundary-value analysis).

Basically, what it boils done to is this:

1. For inputs, outputs and state of the class, perform equivalence class
	analysis

2. For the results of (1), perform boundary value analysis

3. Using the behavioural specification for the class (notice that this
	should NOT be the code, otherwise you would be doing little
	more than testing whether or not you READ the code correctly,
	NOT finding problems with the code) determine how inputs and
	state maps to outputs and state changes (this mapping could
	be via graphs or matrices, I prefer matrices myself because
	they are more concise and I think they are are easier to 
	understand).  Boundary values should be the values used in
	the inputs/states/outputs (note1 that each state should be
	treated as a boundary value) (note2 each error condition/mesg
	should be treated as a boundary value) (note3 each public
	and protected member function should be treated as an input;
	you should exercise, at least, pairwise combinations of all
	operations available to a user of the class)

4. From the cause-effect matrix, write your test case (assuming that
	inputs, state, outputs, state changes values are along rows,
	each column would be test case)

This process has several advantages:

1. It helps you "test" the specification before a single line of code
	has been written because it doesn't depend on code.  You
	would be surprised at the number of ambigous situtations you
	will discover, especially with regards to condition/error
	handling/signaling/messages.

2. It provides a systematic approach to developing the test cases to
	help ensure functional coverage (ie, did you cover everything).

3. It allows someone else to check over your work to make sure you
	are covering everything (everything is there in a nice
	concise format as opposed to pages and pages of text trying
	to say the same thing.

REFERENCES:
The Art of Software Testing
Glenford Myers

Software Testing Techniques  ??
Boris Beizer

FURTHER NOTES:
Of course, when you actually execute the test cases, you should be using
a coverage analyzer to ensure that you are testing everything you
think you are (functional testing should get you pretty close to 80-90%
coverage; looking at what didn't get covered will allow you to get the
rest with a few special cases).


David Wood
AT&T Bell Labs
(908) 957-3852
Newsgroups: comp.software-eng
From: saradhi@frigg.iti.gov.sg (Motamarri Saradhi (KSL))
Subject: The Reality - never expressed by software community
Keywords: Software Engineers, Bad Performance, Software Factories...
Organization: Information Technology Institute, National Computer Board, Singapore
Date: Thu, 15 Oct 1992 03:37:46 GMT

Dear colleagues,

I have been observing the flood of postings on whether software engineers
do really bad and on the topic of software factories.

Most people may be surprised to note that a majority of the problems 
cited for software creation (a better agglomeration than software engg or
software technology) basically suggest a lack of appreciation of reality.
The reality is that programmers burn their mental efforts to give light -
a usable software. But do we respect the act of programming or actual
coding? What needs a self-realisation!

I strongly urge the readers of the net to go through my outcry on the
darker sides of software creation presented in my latest paper

   "Software Engineering from a Practical Perspective"

    ACM-SIGSOFT Software Engineering Notes, Vol 17 No 3, July 1992.

I guarantee that the article has depth as well as breadth in addressing
a huge set of issuses that surround the art of software creation. If any
of you have no access to the journal I am glad to mail a copy of the article.
I will be very happy to hear any criticisms and/or remarks on my views.

Awaiting for a fruitful discussion which should in turn help us in making
software creation as a robust disicipline...

Regards...   M Saradhi.

-- 
+-------------------------------------------------------------------------+
| Motamarri Saradhi, Life Mem ISCA;Mem ACM |Office : (65)772 0931         |
| Knowledge Systems Lab                    |Res    : (65)774 3805         |
| ITI, National Computer Board             |Fax    : (65)777 3043         |
| 71 Science Park Drive                    |Bitnet : Saradhi@itivax.bitnet|
| Singapore - 0511.                        |Int'net: Saradhi@iti.gov.sg   |
| ------------------------------------------------------------------------|
| "Man is guided by his stomach. He walks. His stomach goes first.        |
|  Then his head. Have you not seen that? It takes ages to make the       |
|  head go first."                                   - Swami Vivekananda  |
+-------------------------------------------------------------------------+
From: prspool@siemens.com. (Peter Spool)
Newsgroups: comp.software-eng
Subject: Six-Sigma
Summary: Has Motorola Applied the same techniques to software?
Date: 15 Oct 92 15:43:33 GMT

If Motorola has applied the same techniques used
in the "Six-Sigma" program to software, . . .
What are the major important and/or original features
of the Motorola software development process?

Thanks.
Peter R. Spool
Siemens Corporate Research
Princeton, NJ
prspool@siemens.siemens.com
From: fielding@simplon.ics.uci.edu (Roy T. Fielding)
Newsgroups: comp.software-eng
Subject: Need references on Experience w/ Spiral Model
Keywords: Spiral Model
Date: 16 Oct 92 02:01:48 GMT
Organization: UC Irvine Department of ICS

Hello all,

Having just covered Barry Boehm's "A Spiral Model of Software Development
and Enhancement" (1988) in a course, several students have asked for
further references (i.e. papers or books) detailing actual experience
with using the spiral model.

Does someone out there have such a list?  Even just one recent article
would be helpful.  I will summarize the responses to the net.

......Roy Fielding     ICS Grad Student, University of California, Irvine
      (fielding@ics.uci.edu)
From: alan@auntbea.austin.ibm.com (Alan R. Weiss)
Newsgroups: comp.software-eng
Subject: Re: distributed testing tools?
Keywords: distributed test tools
Date: 9 Oct 92 14:04:23 GMT
Organization: (Speaking for myself now)

In article <1992Sep30.172037.21661@osf.org> bvs@osf.org (Brian Van Schaick) writes:
>
>Does anyone know of any distributed test environment toolkits/scaffolds? What we're looking for is a test scaffold in the public domain (or soon to be in the public domain) that supports testing in a distributed computing environment. Any information would be greatly appreciated. Please direct all replies to me via email: bvs@osf.org or uunet!osf.org!bvs.
>
>Thanks.

Brian:

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

I also understand that it was evaluated and found to be seriously
lacking in functionality and quality.  Is the OSF going to fix D-TET,
or is the OSF going to simply scrap the idea and move to some other
"industry standard test system."

The question is relevent, because many companies are standardizing
on TET, knowing full well that the current version is doesn't support
distributed operations, but expecting that at some time in the (hopefully
near) future it will.

The topic of "how to design a distributed test system" is one worth
exploring -- it can be done inexpensively, or it can be very elaborate
and use rpc, sockets, transport you wish.  It would be VERY helpful if
you sent out a Requirements Specification for such a system so that people
wouldn't waste your time and their's offering up inadequate solutions
to an unspecified problem set.

Best Regards,

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!!
From: phardie@nastar.uucp (Pete Hardie)
Newsgroups: comp.software-eng
Subject: Re: Testing (Was: Do Software Engineers Actualy Do So Badly?)
Date: 13 Oct 92 14:39:49 GMT
Organization: Digital Transmission Systems, Duluth, GA.

In article <1992Oct13.025849.29887@sserve.cc.adfa.oz.au> ghm@sserve.cc.adfa.oz.au (Geoff Miller) writes:
>But surely this is the advantage of re-usable code, software libraries
>and so on.  Not only do they speed up development, but they enable you
>to construct a system largely from tested components whose behaviour is
>known.  You can then concentrate on testing how those components interact.

In my experience, there is rarely a piece of code that can be reused on another
project 'as is'.  Every project has different data structures, and sorting
them requires a (slightly) different function - or the original function is
very baroque.

One thing that I can say about the idea that software modules can be treated
similarly to ICs and the like - how many different values can a function
return, compared to an IC component?  The software has a much greater range
of values, and this complicates the interconnection of one module to another
greatly.  An EE knows that all his TTL components return binary signals, and
s/he can connect the output of a NAND gate to a serial input line without
concern for breaking the serial input line.  Not so with the return value of
a sort procedure into the calling procedure.


-- 
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: kjones@luke.eecs.wsu.edu (Kent Jones - EECS)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 9 Oct 92 20:29:39 GMT
Article-I.D.: serval.1992Oct9.202939.20426
Organization: Washington State University!

>>	[mention of English channel tunnel cost overruns]
>>    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,....
>Which is just another attribute that the chunnel and most software
>projects have in common.  Not only have they never done it before, but
>they had to low-ball the bid just to get funding to start the project.
>If we are going to solve the problem (for either software or public
>works), we have to start here.

I agree completely! Its not that our estimation techniques are bad, (The
COCOMO and PUTNAM models *if* applied correctly and modified to fit
the organization can be made to work fairly well) Its just that the
business people and managers dont want to believe the results! If 
a competitor comes along and says "I'll do it in half the time at 
half the cost" the competitor is believed and gets the contract. As it 
turns out, the COCOMO and PUTNAM models predict ~60% of total work is
spent on maintenance and long term support. Thus although the competitor
*may* devliver a product in half the time -- it is likely to be full of
bugs and require massive amounts of time and labor to maintain and support!

Also the "ripple effect" implies that software projects are never *really* 
100% finished -- the customer requests a change and the resulting changes 
to the software result in more schedule delays etc...
This is why it is *so* important that the customer and developer work very 
closely together in the requirements and specification phases of a project.

Just my stupid, nogood, personal opinion...

Kent
Newsgroups: comp.software-eng
From: byrne@cstore-next.cl.msu.edu (Eric J. Byrne)
Newsgroups: comp.software-eng
Subject: Re: Do Software Engineers Actualy Do So Badly?
Date: 13 Oct 92 14:56:51 GMT
Organization: Michigan State University



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
From: sjk@strl.labs.tek.com (Steven King)
Newsgroups: comp.software-eng
Subject: Contacts for CM tool vendors Prisma, Sherpa and Shape
Date: 16 Oct 92 22:33:42 GMT
Article-I.D.: crl.4844
Reply-To: sjk@strl.labs.tek.com (Steven King)
Followup-To: comp.software-eng
Organization: Software Technology Research Lab, Tektronix, Inc.

I have contacts with all the "major" Software CM tool vendors.
There are a few that I cannot find.  Specifically, I'm looking 
for contacts with the Software CM tool vendors Prisma (CVS Tool 
Set), Sherpa (Database Management System) and University of Berlin
(Shape Toolkit).

If anyone can give me names, phone numbers, e-mail addresses or
the like, I would appreciate it.

Thanks,

Steven (sjk@strl.labs.tek.com)

"Sometimes if you have a cappuccino and then try again it will work OK."
(Dr. Brian Reid)  "Sometimes one cappuccino isn't enough." (Marcus Ranum)
"A double vanilla latte always works."  (Me)