HDTenEightyP/NetNews huggingface dataset:
From: fjs@bonz.athena.lkg.dec.com (F. J. Shields)
Newsgroups: comp.software-eng
Subject: Re: Code Formatter/Pretty Printing
Date: 17 Nov 92 14:10:26 GMT
Reply-To: fjs@athena.lkg.dec.com
Organization: Digital Equipment Corporation


In article <1992Nov16.214624.15883@mprgate.mpr.ca>, swong@mprgate.mpr.ca (Susan Wong) writes:
>Does anyone know of any user configurable pretty printers? I'm looking for
>something that can be configured to put in the "right" number of spaces
>for each level of indentation, "{" on the "right" line, things of this
>nature.

It sounds like you want to use the indent program. The best of these that
I've seen is the GNU version: it has more options than any other version
of indent of which I am aware.  You can pick up a copy from
   gatekeeper.dec.com 	- /pub/GNU/indent-1.6.tar.Z
   prep.ai.mit.edu 	- /pub/gnu/indent-1.6.tar.Z
or from LOTS of other places.

--
F. Jay Shields
fjs@athena.lkg.dec.com
Digital Equipment Corporation
From: magu@se.alcbel.be (Mike Aguilar)
Newsgroups: comp.software-eng
Subject: Re: SUMMARY Tools to aid in testing, and requirements trace-ability.
Date: 18 Nov 92 10:30:46 GMT
Reply-To: magu@se.alcbel.be
Organization: Alcatel Bell Antwerp (AAL)


Hi there,

First time here.  Hope someone can help me out.

But before anything else, thanks for the compilation Carl.

I'm interested in a tool that lets the user define the requirements
and from that, generates test specifications.  If there's any other 
products not mentioned in the list, I'd like to know.

Also, are there any standards for requirement specification?
Or do they vary from application to application?

Thanks in advance. 

--
  // Mike Aguilar                          Phone: (32) 3 240 4289
\//  email : magu@se.alcbel.be             BELL ext. 4289
From: martinc@hatteras.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: Productivity vs. Complexity
Date: 19 Nov 92 19:22:45 GMT
Distribution: na
Organization: UNC Department of Computer Science
In-reply-to: travis@eecs.nwu.edu's message of 18 Nov 92 23:52:35 GMT

Let me try saying that again: obviously the KCS complexity of the *same*
function will always be the same assuming the same reference model of
computation.  What I really meant was that the complexity of functions
commonly realized in hardware is much smaller than the functions that are
realized with software.
--
		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
     "Oh God, please help me be civil in tongue, pure in thought, and able
      to resist the temptation to laugh uncontrollably.  Amen." -- Rob T
From: garyh@hprnd.rose.hp.com (Gary Harmon)
Date: Fri, 20 Nov 1992 18:41:31 GMT
Subject: Defect Tracking Software
Organization: HP Roseville Networks Division
Newsgroups: comp.software-eng

I'm investigating commercially available software products which can provide 
defect tracking capabilities.  It must work with DOS/UNIX PCs or UNIX work-
stations.  What are you using?  What are you aware of?  What comments do you
have?

Thanks.  E-mail responses are welcomed.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gary Harmon                                             Hewlett-Packard Company
garyh@hprnqa1.rose.hp.com                               Roseville, CA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Newsgroups: comp.software-eng
From: mat@mole-end.matawan.nj.us
Subject: Re: Will we keep ignoring this productivity issue?
Summary: Engineers managed by engineers, programmers by programmers
Organization: :
Date: Mon, 16 Nov 1992 09:05:09 GMT

In article <BxpLGC.DCp@cs.uiuc.edu>, johnson@cs.uiuc.edu (Ralph Johnson) writes:
> rcd@raven.eklektix.com (Dick Dunn) writes:
 
> >I'm honestly not sure...is this a lesson for software engineering, that we
> >have to assume anybody good enough will get shipped out?  Or is it a lesson
> >for management, that they seem reluctant to learn?
 
> ... One of the problems with software development is that the managers don't
> know enough about software to tell who are the stellar performers and who
> are the duds.  Thus, the strategy "just hire very good people" can't work
> because it can't be implemented: management is not able to tell who is
> good and who is not.

> ...  I never have any trouble telling which of my students are good
> programmers: I read their code.  In my opinion, managers should look at
> what their employees are doing to see if they are doing a good job or not.
> In the case of software engineers, that means reading design documents,
> programs, test suites, and anything else they produce.  

In other words, the manager has to have an appreciation of the `useful
art' of programming!  Which means they have to be good programmers themselves.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
From: spsisira@sdrc.COM (spsisira)
Newsgroups: comp.software-eng
Subject: Re: SE going offshore?
Date: 19 Nov 92 18:14:28 GMT
Organization: Structural Dynamics Research Corporation, Milford OH 45150 USA
X-Newsreader: TIN [version 1.1 PL7]

mat@mole-end.matawan.nj.us wrote:
: In article <1992Nov16.133843.18058@sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes:
: > In article <2B05650C.29402@ics.uci.edu> ejw@siam.ics.uci.edu (Jim Whitehead) writes:
:  
: > >...  Many software faults can be traced either to faulty specifications,
: > >or incorrect interpretation of specifications.  ...  With programmers
: > >working on these projects whose primary language is not English ... the
: > >possibility for specification errors is very high, IMHO.
: >
: > Hate to tell you this, but in my experience the average graduate student
: > from India speaks better english than the average US graduate.  One reason
: > is that the main language of higher education in India ... is english,
: > and it is taught both exactingly and well.
: 
: It may depend on what you mean by `better.'  If you mean that the Indian
: student can understand and write Standard English competently, you may be
: write.  Oral communication also suffers from an `accent barrier' and not
  ^^^^^| 
       | I think you are a good example of what is being discussed in
         this thread. Who taught you English. May be self taught.

: all people who can write Standard English well can be understood by someone
: from Brooklyn or Atlanta or Lake Woebegone.  Heck, not all people from
: Brooklyn can be understood in Atlanta!

As far as software development is concerned I do not see how the `accent'
play any role. Afterall all you read is an ASCII string.

Sisira.
--- 

Sisira Jayasinghe PhD.D.
Sr. Technical Development Engineer

uunet!sdrc!cvg!spsisira      Structural Dynamics Research Corporation
spsisira@sdrc.com            2000 Eastman Dr.
spsisira@cvg.sdrc.com        Milford OH 45150 USA
-- 
Sisira Jayasinghe Ph.D.
Sr. Technical Development Engineer

uunet!sdrc!cvg!spsisira      Structural Dynamics Research Corporation
spsisira@sdrc.com            2000 Eastman Dr.
spsisira@cvg.sdrc.com        Milford OH 45150 USA
Newsgroups: comp.software-eng
From: dlw@atherton.com (Remo Williams)
Subject: Re: Need list of Config. Mgt. software
Organization: Atherton Technology, Inc.
Date: Thu, 19 Nov 1992 00:09:31 GMT

In article <1992Nov10.203541.9233@titan.tsd.arlut.utexas.edu>  
conditt@tsd.arlut.utexas.edu (Paul Conditt) writes:
As a side note, does anyone
> have any experience in using such a product, especially the build/make
> utility, in an Ada environment?
> 
Verdix has VADS PRO which does CM & Team programming in the ADA environment.

Verdix
205 Van Buren Street
Herndon, VA 22070
703.318.5800

--
David Williams -- dlw@atherton.com -- NeXTMail welcome
	          dlw@netcom.com   -- NeXTMail welcome
From: paj@uk.co.gec-mrc (Paul Johnson)
Newsgroups: comp.software-eng
Subject: Complexity metrics: Beyond McCabe.
Date: 20 Nov 92 09:46:37 GMT
Reply-To: paj@uk.co.gec-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, Essex

I've been having a look at complexity metrics.  McCabe "A Complexity
Measure" (IEEE Trans SE, SE2 1976) sounds like a good start.  He
measured complexity by counting flow control paths within a program.
Has anyone extended this work?  Is it seen as a significant kind of
metric?

I have had a look at function points.  The trouble is that they behave
like fractals: the closer you look the more you see.  This strikes me
as useless.

What makes a piece of code hard to understand and follow?  McCabe
concentrated on flow control because the debate of those days was
structured vs. unstructured programming, and he sought to show that
structured programs were simpler.  Today we have a debate on OO vs
non-OO.  Can we find a metric which measures what we intuitively call
"complexity" in a program?  (I think not, although we may be able to
approximate it).  Is it possible to show that an OO design can reduce
the complexity of a program?

Should a metric like this take numbers of variables into account?
Assignment statements?  If I take a chunk of code and put it into a
function, inserting a function call in its place, have I increased
complexity, decreased it or not affected it?

Any and all comments will be read with interest.

Paul.
Newsgroups: comp.software-eng
From: markham@brtph678.bnr.ca (Andrew Markham P205)
Subject: Comments:Code (what is the standard guideline?)
Organization: BNR Inc. RTP, NC
Date: Mon, 23 Nov 1992 15:20:46 GMT

Some friends wanted to settle a dispute on the comments-to-code
ratio that is generally suggested in software engineering circles.

Two of us believe a 60:40 comment-to-code breakdown, but the other 
thinks that is simply too many comments.

We know these aren't numbers to live by, but are just curious
if anyone had seen a figure answering this in a text somewhere...

Thanks.

-- 
Andrew W. Markham (markham@bnr.ca)
Bell Northern Research, Inc.
From: jmeinke@dcs.simpact.com
Newsgroups: comp.software-eng
Subject: Suggestions on Development Environment
Date: 20 Nov 92 09:28:48 PDT
Organization: Simpact Associates, San Diego CA

Howdy: 

Our organization has decided (at long last) that we need to
modernize our development environment, and I have been charged
with putting together the master plan. 

The plan needs to include configuration management, backups,
as well as development tools (debuggers, compilers, etc.),
maintenance, system configuration, network operations, etc. 

We have a scattered collection of VAXen running VMS, Ultrix,
and System V; PCs running MSDOS and OS/2; and Sparcstations
running BSD.  We have one DEC VMS Alpha machine, and we're
getting another with OSF/1. Most are tied together with
various TCP/IP packages or DECNET. 

We don't have much experience using CASE tools or in object
oriented methodology. 

If anyone has ideas about how to approach this, I would like
to hear about them.  I realize the solutions will be very
specific to our particular environment and politics, so what
I'm looking for most are approaches, items to consider,
checklists, etc., as well as things you have seen work well. 

If there have been articles previously posted to the network
addressing this topic, I'd be interested in the reference. 

Pleas email and I'll summarize. Thanks.
-- 
Jim Meinke, Simpact Associates        619-565-1865
9210 Sky Park Court                   jmeinke@dcs.simpact.com 
San Diego, CA  92123  

 "I really didn't say everything I said." -- Yogi Berra
From: cs89ssg@brunel.ac.uk (Sunil Gupta)
Newsgroups: comp.software-eng
Subject: wanted info on OO design methodologies
Date: 16 Nov 92 22:18:24 GMT
Organization: Brunel University, Uxbridge, UK
X-Newsreader: TIN [version 1.1 PL6]

The subject says it all. 

Id like to find out more details on Object Oriented development, especially 
on the following methodologies by the following people

	Booch
	Buhr
	Rumbaug
	Wirfs-brock
	Yourdon-Coad

Were currently attempting (as an undergraduate project) to select one of these
that would be best suited to the design of a Real time kernel. 

Other than the "casepm" tool for UNIX, are there other case tools for
UNIX? (couldn't find the FAQ)

If there are any people developing OO case tools, is it possible to get
an evaluation version of it?  We propose to use such a case tool to 
identify whether it can support real time system design, and propose
changes to it. (in a strictly non-commercial academic environment.)
-- 
------------------------------------------------------------------------------
           Sunil Gupta ---- member of the studentsoft project
	        and a computer scientist in my spare time 
	cs89ssg@uk.ac.brunel          studentsoft@uk.ac.brunel
------------------------------------------------------------------------------
Newsgroups: comp.software-eng
From: swong@mprgate.mpr.ca (Susan Wong)
Subject: Code Formatter/Pretty Printing
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Mon, 16 Nov 92 21:46:24 GMT

Does anyone know of any user configurable pretty printers? I'm looking for
something that can be configured to put in the "right" number of spaces
for each level of indentation, "{" on the "right" line, things of this
nature.

Thanks in advance,

Susan Wong
swong@mprgate.mpr.ca

MPR Teltech Ltd., Burnaby, B.C., Canada
Newsgroups: comp.software-eng
From: samuel@shemp.cs.wisc.edu (Samuel Bates)
Subject: Effectiveness of Partial Code Coverage
Summary: seeking references, articles
Keywords: adequacy criteria
Cc: samuel@cs.wisc.edu
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.
Date: Thu, 19 Nov 1992 22:54:46 GMT


Hi.  I am looking for any references to empirical work on the effectiveness
of partial code coverage.  Are there any studies that:

  - look at typical amounts of code coverage (.e.g., "test suites typically
    cover 90% of the statements and 80% of the branches of the tested 
    program"), or

  - relate code coverage to error discovery or failure rates (e.g.,
    "exercising 85% of the branches led to a failure rate of X per 1000
    lines of code")?

I know that there is no theoretical basis for claiming that more code coverage
leads to more error discovery; what I am looking for is any evidence that it
works (or doesn't work) in practice.  Anecdotes are fun, but I'd really prefer
references to conference or journal papers.  Thank you.

							--Samuel Bates
							  samuel@cs.wisc.edu
Newsgroups: comp.software-eng
From: shanks@saifr00.cfsat.honeywell.com (Mark Shanks)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Honeywell Air Transport Systems Division
Date: Tue, 17 Nov 92 14:43:51 GMT

In article <1992Nov16.090509.22236@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
>In article <BxpLGC.DCp@cs.uiuc.edu>, johnson@cs.uiuc.edu (Ralph Johnson) writes:
>> ... One of the problems with software development is that the managers don't
>> know enough about software to tell who are the stellar performers and who
>> are the duds.  Thus, the strategy "just hire very good people" can't work
>> because it can't be implemented: management is not able to tell who is
>> good and who is not.
>
>> ...  I never have any trouble telling which of my students are good
>> programmers: I read their code.  In my opinion, managers should look at
>> what their employees are doing to see if they are doing a good job or not.
>> In the case of software engineers, that means reading design documents,
>> programs, test suites, and anything else they produce.  
>
>In other words, the manager has to have an appreciation of the `useful
>art' of programming!  Which means they have to be good programmers themselves.
>--                                     ^^^^

I strongly disagree. With no desire to cast aspersions upon the value of
good programers, in my experience the abilities required of a good
manager are completely different than those required by a good programmer.
In too many cases I've seen excellent engineers promoted into management
positions where 1) They were unhappy and frustrated, and 2) Their
management ability sucked the shit out of dead cats. 

Good managers MUST be able to deal with people. Most good programers
I've known were not stellar performers in that area. Managers must
be schedule and budget conscious; this is not at the top of most
engineers' list of things to think about. Managers are best off when they
have a wide range of experience themselves; most good programmers have at
best a limited background (and I don't mean how many programs they've
worked on.) 

If management can't tell who is a good programmer and who isn't, that's
right, they ARE technically incompetent. But they're also lousy managers.
It certainly would be IDEAL to find a good programmer who would also
make a good manager, but IMHO, a good manager doesn't NEED to be/have been
a good programmer. IMHO.

Mark Shanks
shanks@saifr00.cfsat.honeywell.com
From: sjk@strl.labs.tek.com (Steven King)
Newsgroups: comp.software-eng
Subject: Yet more information on CM vendors (Atherton and Object Tech.)
Date: 18 Nov 92 01:43:37 GMT
Reply-To: sjk@strl.labs.tek.com (Steven King)
Followup-To: comp.software-eng
Organization: Software Technology Research Lab, Tektronix, Inc.

I've been asked about two more software CM tool vendors, Atherton
(product is Software Backplane) and Object Technology Inc. (product
is called Envy Manager).  It is my understanding that Envy currently
supports smalltalk, with plans for other languages soon (why that
would be a problem, I don't know.  Perhaps it's tightly coupled with
the smalltalk environment).  Software Backplane was mentioned by the
HP folks at the PNWSQ conference.

I would appreciate contacts, phone numbers, email addresses, etc. for
these two companies.

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)
From: igb@fulcrum.co.uk (Ian G Batten)
Newsgroups: comp.software-eng
Subject: Re: SE going offshore?
Date: 17 Nov 92 15:19:30 GMT
Organization: Fulcrum Communications

In article <2B05650C.29402@ics.uci.edu> ejw@siam.ics.uci.edu (Jim Whitehead) writes:
> United States.  This means that either the problem description or
> the specification or both will be expressed in English.  With
> programmers working on these projects whose primary language is
> not English (the case with off-shore programming teams) the possibility

Have you seen the standards of English of, for example, the Indian
professional classes?  Now consider what passes for English from many
native speakers.

ian
Newsgroups: comp.software-eng
From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster)
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Fri, 20 Nov 1992 18:11:32 GMT

With reference to Scott McGregor's article, I am pretty much in
agreement with most of what he says.  (I haven't read the book he
refers to, but the various books on Quality and design productivity
I have read are pretty long on labor intensive design processes
[I have no doubt that the focus on requirements and quality is good,
BTW] and pretty short on numbers...)  Anyway, I like, and concur with, 
the examples he cites at the end.  I merely wanted to point out the 
obvious once again: there is a gaping chasm between the *kind* of
engineering estimates he cites, with their sometimes large variances,
and the *kind* of *very* precise estimation which many have attempted,
failed at, and then proceeded to reaffirm the "software crisis".  The
"crisis" is simply one of failed expectations based on false analogies.
In the meantime, software project management continues to improve, 
using both generally applicable techniques (e.g. walkthroughs,
configuration management), and techniques specific to software (e.g.
high(er) level programming languages, source code debuggers).

Let me make a tongue-in-cheek prediction:

In the year 2018(?), a software developer will be able to specify, 
implement, test, debug, and deploy a complete client-server database 
in somewhere between an hour and a day.  In the same year, at the 
official fiftieth anniversary birthday celebration of the "software
crisis", people will still be griping because the variance in software
project estimates and completion times will be greater than ever.


-- 
  Hugh LaMaster, M/S 233-9,     UUCP:      ames!lamaster
  NASA Ames Research Center     Internet:  lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035-1000  Or:        lamaster@george.arc.nasa.gov 
  Phone:  415/604-1056                     #include <usenet/std_disclaimer.h> 
Newsgroups: comp.software-eng
From: janzen@lichen.mpr.ca (Martin Janzen)
Subject: Re: wanted info on OO design methodologies
Reply-To: janzen@mprgate.mpr.ca
Organization: MPR Teltech Ltd.
Date: Tue, 17 Nov 92 20:29:27 GMT

In article <Bxtxyp.6Ez@brunel.ac.uk>, cs89ssg@brunel.ac.uk (Sunil Gupta) writes:
>Id like to find out more details on Object Oriented development,
>especially on the following methodologies by [...]
>
>Were currently attempting (as an undergraduate project) to select one of
>these that would be best suited to the design of a Real time kernel. 

Have a look at the article, "Object-Oriented and Conventional Analysis
and Design Methodologies: Comparison and Critique", by Robert G. Fichman
and Chris F. Kemerer of MIT, in the October 1992 issue of COMPUTER.

The same issue has another article dealing with real-time O-O systems
that may also interest you.

-- 
Martin Janzen                     janzen@mprgate.mpr.ca (134.87.131.13)
MPR Teltech Ltd.                  Phone: (604) 293-5309
8999 Nelson Way                   Fax: (604) 293-6100
Burnaby, BC, CANADA  V5A 4B5
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Hey Congress, Let's Zero Out SCE Funding!
Date: 23 Nov 92 10:30:18 EST

In article <1992Nov20.162236.7094@asl.dl.nec.com>, terry@asl.dl.nec.com writes:
[...]
> Let's put it more bluntly:  I say that SCE is a expensive, miserable
> failure that needs to be put out of its misery.  Will the new congress
> and/or administration please either cut out the funding for this charade,
> or at least start doing some serious policing of where *their* "contract
> money" is going?
> 
> What's good for the goose is good for the gander -- and I say that if SEI
> has taken it upon themselves to try to evaluate the industry with this
> slipshod set of procedures, then by golly, someone in the right congress-
> ional appropriations groups ought to return them the favor and do a really
> blistering analysis of how effective SEI in general and SCE in particular
> have been at doing *their* job right after five or six years of floundering.

Terry raises some critical issues regarding how we measure the software
industry.  As readers know, I don't always agree with what he says, but these
are a set of questions that *must* be brought into the open and addressed.

George Kambic
standard process intensive disclaimer

Newsgroups: comp.software-eng