HDTenEightyP/NetNews huggingface dataset:
From: n305ac@tamuts.tamu.edu (Hong-Wei He)
Newsgroups: comp.software-eng
Subject: book review--"software that works"
Keywords: none
Date: 8 Apr 92 21:33:16 GMT
Organization: ~/lib/organization


i just finished reading a book about software engineering, 
"software that works" by Michael Ward of Unisys Corp. it 
seems to be a very good one. the topic ranges from all prospects
of software engineering, like functional spec, design, testing,
even flow chart. the book is full of humor which makes it 
fun to read it.
	anybody else have read the book? i would very much
like to hear other opinions about it. 

Newsgroups: comp.software-eng
From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: C++ Critique in comp.lang.c++
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Wed, 8 Apr 1992 12:14:53 GMT

I have placed a critique of C++ in comp.lang.c++. This will be of interest
to software engineers.
-- 
Ian Joyner                                     ACSNet: ian@syacus.acus.oz
ACUS (Australian Centre for Unisys Software)   Internet: ian@syacus.acus.oz.au
Tel 61-2-390 1328      Fax 61-2-390 1391       UUCP: ...uunet!munnari!syacus.oz
From: cimshop!davidm@uunet.UU.NET (David S. Masterson)
Newsgroups: comp.software-eng
Subject: Re: Lines of Code Metric
Date: 10 Apr 92 00:40:47 GMT
Organization: Consilium Inc., Mountain View, California
In-reply-to: rcc@zycor.lgc.com's message of 3 Apr 92 20:29:46 GMT
X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> On 3 Apr 92 20:29:46 GMT, rcc@zycor.lgc.com (Randy Clarke) said:

> In article <5789@charon.cwi.nl> Huub.Bakker@cwi.nl writes:

>> It doesn't matter which LOC metric you use: they are all highly correlated.

>> You only need a specific LOC metric definition if you want to compare you
>> metric-data with results of measures in other organisations. Then you have
>> to use the same definition.

>> If you need a LOC metric tool just use the UNIX 'wc' program.

> You're kidding, right?  Coding styles differ not only between organizations,
> but also between individuals.  In some cases, the styles can be very
> drastic...  Using a simple program like 'wc' to measure code productivity
> would most likely encourage programmers to be as verbose as possible; and
> that doesn't necessarily translate into a quality program.

Off hand, I could think of two approaches:

1.  Don't tell your programmers that you are measuring LOC.  This will allow
you to measure their standard LOC with less chance for abberations.

2.  Tell *ALL* your programmers that you are measuring LOC.  If they want to
artificially increase their LOC, it will still average out because everyone is
increasing their LOC.

Naturally, you don't want to compare LOC's that were measured in radically
different ways.  That's like comparing apples and oranges.  However, if you
are comparing apples and apples, they can be used as a relative measure of how
productive things are.

You are right, though, LOC is a measure of productivity not quality, so it's
probably not the only measure of how your programmers are doing that you
should be tracking.  For instance, tracking bugs and what had to be changed to
correct the bug.  Then dividing a programmer's LOC by the number of bugs found
in his code *begins* to give you a measure of *his* quality.

Obviously, these are back-of-the-envelope measures and should not be used as
the *sole* means of determining whether a programmer continues in his job or
is let go.  At most, it should be used as a mechanism for determining where to
focus training and other resources.
--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
uunet!cimshop!davidm				Mtn. View, CA  94043
====================================================================
From: jfoster@everest.srd.bt.co.uk (John Foster)
Newsgroups: comp.software-eng
Subject: Re: Separation of Software testing from System Testing
Date: 8 Apr 92 12:00:17 GMT
Reply-To: jfoster@everest.srd.bt.co.uk
Organization: British Telecom

From article <1992Apr6.210631.3132@Miles.COM>, by rms@Miles.COM (Rob Schultz):
> 
> Hello, all 
> 
> I am involved in a discussion regarding the roles of a Software Testing
> group and a Software Quality Assurance Group.  The discussion centers
> around how much involvement the Software Test Group should have in the
> Systems Testing for an embedded instrument.  The basic disagreement is 
> whether Software System Testing should be a separate stage of testing or 
> if it should be a part of the System Testing performed on the instrument.
> 
	[ Summary of positions deleted ... ]

One question that I would ask would be: does the software have to cope
with hardware failures (for instance, by running diagnostics/ giving error
messages on component failure etc)?

If the answer to that is "yes" then you might ask the "system test only" 
proponents how they propose to test that functionality, short of spending
a very long time installing and removing failed components in the hardware.

Of course, it does leave open the difficult question of how you _do_ test
for that sort of thing ...


--
John Foster
Systems Research Division, BT Labs, Martlesham Heath, Ipswich IP5 7RE, UK
jfoster@srd.bt.co.uk        fax: (+44) 473 643019
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 10 Apr 92 16:39:53 EST

In article <1992Apr8.150236.8716@awdprime.austin.ibm.com>, jerry@heyman.austin.ibm.com (Jerry Heyman) writes:
> In article <7APR199214170281@adpdp2.lanl.gov>, 105126@adpdp2.lanl.gov
> (John Curtis) writes:
>> The problem with the Lines of Code metric is really "what is a line of code"?
>> If five different programmers can accomplish the same action using five
>> different types of commands, how do you count that? Or better yet, what
>> happens when you can "stack" commands on a line OR (in the same program) put
>> commands on separate lines? Do you have to enforce a programming (coding)
>> standard and make all you programmers write their code in the same "style"?
> More to the point, how do you count modified lines of code?  In a development
> shop that goes through mulitple releases of the same software, counting lines
> of code becomes a tricky exercise.  Obviously in the first release you count
> lines of code because its all new.  In subsequent releases what do you count?
> Obviously you can't just count total lines of code because that gives an 
> unrealistic (IMHO) number as to the amount of coding that was done.
> 
> How do you split out modified lines of code from the existing lines of code?

You can count at different levels.  A modified LOC is "new" code in one sense. 
It does something different from what it did before and you  can use a
comparator to determine the number of differences.  You may want to deal with
the volatility concept = |LOC removed|+|LOC added|+|LOC modified|/|baseline|.
This gives you a relative measure of the change in the module.  On the other 
hand you may want only to work at the CM level, and count changed modules.  If
you touch it, it's been modified.  On the third hand(?), you cannot use LOC as
an independent metric.  Suppose your system never changes size while at the
same time being highly volatile.  The LOC count provides nothing, but the
volatility along with other goodies, defect rates, etc.  On the fourth hand
maybe you only want to count shipments (we actually got it out the door!).

Good luck

George Kambic
standard disclaimer

Newsgroups: comp.software-eng
From: kummer@possum.den.mmc.com (Jim Kummer)
Subject: Re: Software Repositories
Keywords: Repositories reusability Fips APP
Organization: Martin Marietta Astronautics Group, Denver
Date: Mon, 6 Apr 1992 13:21:44 GMT

In article <1992Apr4.014042.16272@twisto.eng.hou.compaq.com> brace@columbia.eng.hou.compaq.com (Don Brace) writes:
>	I am working on a term paper which is based on software
>repositories. I have found several references to some federal
>standards, but I would like more informaion on the following;
>	Informaion Resource Dictionary System (IRDS)
>		ANSI X3.138	ISO TC97
>		Fips 156
>

The last reference I saw on the IRDS cited the ANSI standard as 
X3.138-1988.  Does anyone know if this has since been revised?

>	Also, any references to the basic methodology of the
>management of these repositories would be appreciated.
>
Another reference I've seen cited is:
-- Law, Margaret Henderson, "Guide to Information Resource Dictionary 
-- System Applications:  General Concepts and Strategic Systems 
-- Planning", National Bureau of Standards Special Publication 
-- 500-152, 1988.

>	The theme of my paper is to create a software repository
>methodology of my own, which would enhance/stimulate software
>reusability.
>
>Thankx.


-- 
 
-- Regards ----- James Kummer --- Martin Marietta Corporation --
----- kummer@pogo.den.mmc.com --- Astronautics Group ----------- 
(standard disclaimer applies)
From: francis@concour.cs.concordia.ca (FRANCIS andrew)
Newsgroups: comp.software-eng
Subject: Japan's Software Factories: What is the "Needle probe" technique?
Keywords: testing,quality control,V&V
Date: 13 Apr 92 15:10:50 GMT
Organization: Concordia University, Montreal, Quebec

In the chapter four ("Organizing for Process and Quality Control") of
Cusumano's book, there are references to a "Needle probe" technique for
software testing. I have not heard this term before. Can anyone describe
it in detail.

                                Thank you,
                                Andrew Francis
                                Concordia University.
                                francis@concour.cs.concordia.ca
Newsgroups: comp.software-eng
From: sr@seas.gwu.edu (Stan Rifkin)
Subject: Re: FOLLOW-UP INFO on SPIN
Keywords: SPIN software process improvement network
Organization: George Washington University
Date: Fri, 17 Apr 1992 15:11:04 GMT

In article <4652@gemini.cs.nps.navy.mil> bonsig@cs.nps.navy.mil (Joseph Bonsignore) writes:
Regarding Software >process Improvement Network (SPIN), here is what I've found:
>
>1.  There is a SPIN in the Washington, D.C. are with others starting
                                             area
>in L.A. and Cal Irvin.

The one in "Los Angeles" is being discussed. The one at the Univ of
California at Irvine is operational and holds regular meetings. At
last week's Software engineering process group workshop in Washington
DC discussions were also started on beginning SPINs in Boston,
Philadelphia, San Francisco area, and London, as i recall.

>
>2.  The D.C. SPIN usually meets th1st and 2nd Wed. of each month.
                                 the 1st *or* 2nd Wed
>
>3.  The next D.C. meeting will be May 5th 7:30-9:30 pm at CRC.
                                                           PRC Inc.,
1500 Planning Research Dr. To make a reservation (which is req'd) 
or get your name on the meeting announcement mailing list, 
please call Beth Madden, 703/556-1174, and tell her how you 
heard about SPIN. Her internet addr is madden_beth@po.gis.prc.com.
From: rh@smds.UUCP (Richard Harter)
Newsgroups: comp.software-eng
Subject: Re: selectable-change model based version control
Date: 9 Apr 92 05:20:06 GMT
Organization: SMDS Inc., Concord, MA

In article <1992Apr3.152704.1@happy.colorado.edu>, hsrender@happy.colorado.edu writes:
]> In article <10078@goanna.cs.rmit.oz.au>, gtj@goanna.cs.rmit.oz.au (Glenn T Jayaputera) writes:
]>> In the Byte mag, Jan edition.  There is an article talking about selectable-
]>> change model, used as a basis model for version control.  Unfortunately the
]>> author did not put any bibliography..., I am wondering if anybody had read
]>> or seen any technical paper re:selectable-change model.

] > The only major work I have seen in this areas has been done on the EPOS
] > project at the U. of Trondheim, Norway.  References follow.

] Almost forgot one:

] @inproceedings{lie89a,
]     keywords=":scm:epos:sde:",
]     title="Change Oriented Versioning",
]     author="Anund Lie and Reidar Conradi and Tor Didriksen and
]         {Even-Andr\'{e}} Karlsson and Svein O. Hallsteinsen and Per Holager",
]     booktitle="Proceedings of the 2nd European Software Engineering
] Conference",
]     volume="LNCS 387",
]     editor="C. Ghezzi and J. A. McDermid",
]     publisher="Springer-Verlag",
]     month= sep,
]     year="1989",
]     pages="191--202"}

That's probably about it.  As far as I can tell the best reference material
on the subject is in vendor manuals and educational literature.  One other
reference is an a paper by Susan Dart at CMU doing an analysis of the
underlying models of several commercial CM systems.  Among commercial
CM and version control systems explicitly or implicitly using the model
are Aide-De-Camp (mentioned in the article), the CDC Update system,
Historian Plus, and IBM Update (IEBUPDATE).  Regrettably, many academic
researchers have a tendency to ignore commercial literature and government
reports.

The Dr. Dobbs article is actually elementary and somewhat superficial; this
is unavoidable, I suppose, in a popular journal article.  The article draws
on deeper theoretical issues which are not fully elucidated; the issues
involved are complex.

-- 
Richard Harter: SMDS Inc.  Net address: rh@smds.com Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742.    Fax: 508-369-8272
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
From: hsrender@happy.colorado.edu
Newsgroups: comp.software-eng
Subject: New CM book
Date: 15 Apr 92 21:49:30 GMT
Organization: University of Colorado, Colorado Springs

There's a newish book out on software configuration management, and it's about
the best I've seen.  I recommend it to anyone attempting to learn about the
subject and practice it.

	Title: Methods and Tools for Software Configuration Management
	Author: David Whitgift
	Publisher: John Wiley and Sons
	Copyright: 1991
	ISBN: 0-471-92940-9
From: jerry@heyman.austin.ibm.com (Jerry Heyman)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 8 Apr 92 15:02:36 GMT
Reply-To: jerry@ajones.austin.ibm.com
Organization: IBM, Austin

In article <7APR199214170281@adpdp2.lanl.gov>, 105126@adpdp2.lanl.gov
(John Curtis) writes:
> 
> The problem with the Lines of Code metric is really "what is a line of code"?
> If five different programmers can accomplish the same action using five
> different types of commands, how do you count that? Or better yet, what
> happens when you can "stack" commands on a line OR (in the same program) put
> commands on separate lines? Do you have to enforce a programming (coding)
> standard and make all you programmers write their code in the same "style"?
> 
> John

More to the point, how do you count modified lines of code?  In a development
shop that goes through mulitple releases of the same software, counting lines
of code becomes a tricky exercise.  Obviously in the first release you count
lines of code because its all new.  In subsequent releases what do you count?
Obviously you can't just count total lines of code because that gives an 
unrealistic (IMHO) number as to the amount of coding that was done.

How do you split out modified lines of code from the existing lines of code?

Just curious...

jerry
Jerry Heyman                         external : jerry@ajones.austin.ibm.com
IBM PSP Dev Env Tools MS 9631        VNET     : HEYMAN at AUSTIN
Austin, TX  78758                    internal : jerry@heyman.austin.ibm.com
*** All opinions expressed are exactly that - my opinions and NOT IBM's
Xref: sparky comp.software-eng:1736 comp.edu:703 comp.specification:176
From: John Lacey <johnl@landshark.cs.indiana.edu>
Subject: International Conferences on Software Engineering
Organization: Computer Science, Indiana University
Date: Mon, 13 Apr 92 17:14:33 EST
X-Mailer: ELM [version 2.3 PL11]

I am looking for the proceedings for the 4th and 5th International
Conferences on Software Engineering, 1979 and 1981.  Does anyone know
if these were published in the literature anywhere?

I looked in IEEE Trans. Soft Eng., and SIGPLAN Notices, and SIGSOFT.

-- 
John Lacey,                  How can I do this? I don't know; and because I do
johnl@whale.cs.indiana.edu   not know, I shall make the attempt.  e e cummings
From: sassam@insectus.unx.sas.com (Sue McGrath)
Newsgroups: comp.software-eng
Subject: Looking for Warren Harrison
Date: 14 Apr 92 16:51:36 GMT
Organization: SAS Institute Inc.
Originator: sassam@insectus.unx.sas.com
X-Bytes: 430

Please excuse the network noise, but I am trying to get in
touch with Warren Harrison and can't find his email address.
Thanks.

Sue McGrath V406                SAS Institute Inc.
sassam@unx.sas.com              SAS Campus Drive
(919) 677-8000 x7032            Cary, NC 27513


-- 
Sue McGrath V406                SAS Institute Inc.
sassam@unx.sas.com              SAS Campus Drive
(919) 677-8000 x7032            Cary, NC 27513
Newsgroups: comp.software-eng
From: cyen@ponder.csci.unt.edu (Chris Young Enoch)
Subject: Need info about testing software
Summary: none
Keywords: none
Organization: University of North Texas
Date: Wed, 8 Apr 1992 07:35:40 GMT

Hi,
   I am doing research on the software tools available for testing software,
and looking for real-live tools that are currently being used in industry.

   Does anyone out there know any article discussing this topic?  Any infomation will be appreciated.

Thanx in advance
Chris

e-mail:cyen@cs.unt.edu
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 9 Apr 92 15:17:01 EST

In article <1992Apr8.151718.1@mdcbbs.com>, ivler@mdcbbs.com (J.M. Ivler    ivler@mdcbbs.com) writes:
> Would you as a General Contractor to estimate the cost of building you a home 
> on how many nails it will take?
> 
> I thought not. How is that differnt than lines of code. Issues such as the
> complexity of the software, is it real-time, batch, cpu intensive, hooked into 
> the OS? All of these things have to be taken into account.
> 
> A "better mousetrap" was proposed by Steven Colborne and Dr. Hannes Callison of 
> Magnavox Advanced Products and Systems Company in Torrance, CA. This system was 
> called SAFE, for Syntatical Analysis For Estimation. It was mildly based one B. 
> Bohems work in cost modeling as well as the strict definitions that are 
> required in DOD requirements documents.

Wherefore art thou references to this SAFE tool?

George Kambic
standard disclaimer
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Separation of Software testing from System Testing
Date: 7 Apr 92 17:25:22 GMT
Article-I.D.: iccgcc.1992Apr7.122522.7751

In article <1992Apr6.210631.3132@Miles.COM>, rms@Miles.COM (Rob Schultz) writes:
> 
> Hello, all 
> 
> I am involved in a discussion regarding the roles of a Software Testing
> group and a Software Quality Assurance Group.  The discussion centers
> around how much involvement the Software Test Group should have in the
> Systems Testing for an embedded instrument.  The basic disagreement is 
> whether Software System Testing should be a separate stage of testing or 
> if it should be a part of the System Testing performed on the instrument.
> 
> The two sides of the issue are summarized as follows:
> 
> Software System Testing should be a part of System Testing for the
> instrument, since there is so much overlap between the two.  Many of
> the software functions cannot be adequately tested without some hardware
> intervention (primarily since the System Specification never made a clear
> distinction between the hardware operations and the software operations -
> there is no clear interface).  Therefore, let's just skip the Software
> System Testing since it will all be handled during the Instrument System
> Testing anyway.
> 
> The other side is that Software System Testing should NOT be a part of the
> System Testing, since System Testing targets a much broader type of errors
> than Software System Testing.  The fear here is that if the Software 
> System Testing phase is skipped, then an entire class of errors may be 
> missed or masked out by the hardware or systems issues.
> 
> The response to this is that it really doesn't matter, since the system
> testing will prove out the instrument's functionality.  After all, we are
> building a system that consists of Mechanical, Optical, Chemical, Electrical,
> and Software Components.  The end result is more than just a software
> product.

It doesn't matter what you call it.  Where is your highest _risk_ concentrated? 
Then you figure out how to allocate your testing.  If the class of errors to be
discovered in sw systems testing contains the highest, better do it.

George Kambic
standard disclaimer
Newsgroups: comp.software-eng
From: gfouque@csi.UOttawa.CA (Gilles Fouque)
Subject: e-mail address
Organization: Dept. of Computer Science, University of Ottawa
Date: Thu, 16 Apr 92 20:25:09 GMT

 Does anyone has the e-mail address of 

Weyuker E.J.
Courant Institute of Mathematical Sciences of New York.

She is working about data flow testing.

Thanks

Gilles Fouque
University of Ottawa
gfouque@csi.uottawa.ca
From: jxl@krell.pwx.bull.com (John X. Laporta)
Newsgroups: comp.software-eng
Subject: Re: Lines of Code Metric
Date: 11 Apr 92 02:10:26 GMT
	<CIMSHOP!DAVIDM.92Apr9174047@uunet.UU.NET>
	<1992Apr10.165516.28888@sol.UVic.CA>
Organization: Bull Worldwide Information Systems Inc.
In-reply-to: ajackson@csr.UVic.CA's message of 10 Apr 92 16:55:16 GMT

I believe most engineers agree that LOC is pretty crude and
eminently subject to abuse. Correct me if I am wrong.

I claim:

We should require that any language we use be supplied with a modular
parser that can easily be used in library fashion to create programs.
We then maintain a set of programs that serve as metric tools for each 
approved language. These tools include programs that can:

(1) Identify and count statements. "Statement" would be defined
    appropriately for the language.

(2) Compute an average density for a stretch of statements.
    The density would be a measure of the complexity of the
    statements.

(3) The metric for defects would then be
	defects / (number of lines * average density).

The "identify" function in (1) is a part of all compilers. Yes?
The "density" could be calculated from the size of the compiler 
   parse tree for the stretch of statements. Since I am not a 
   compiler expert I would like to hear comments abou this
   point.





--
    John X. Laporta
    Senior Software Engineer
    Bull Worldwide Information Systems, Inc.
    M.S. MA30-806A
    300 Concord Road
    Billerica MA 01821
    FAX (508) 294-0108
    email: jxl@pwx.bull.com
           !uunet!zion!know!laporta
Newsgroups: comp.software-eng,news.answers
From: cimshop!davidm@uunet.UU.NET (David S. Masterson)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 10 Apr 92 18:01:40 GMT
Distribution: comp
Organization: Consilium Inc., Mountain View, California
In-reply-to: ivler@mdcbbs.com's message of 8 Apr 92 15:17:18 GMT
X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> On 8 Apr 92 15:17:18 GMT, ivler@mdcbbs.com (J.M. Ivler ivler@mdcbbs.com)
>>>>> said:

> Would you as a General Contractor to estimate the cost of building you a
> home on how many nails it will take?

I'm sure you meant that to say:

"Would you as a General Contractor estimate the cost of a building *ONLY* on
how many nails it will take?"

because the answer to the way you phrased it is:  Yes.
--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
uunet!cimshop!davidm				Mtn. View, CA  94043
====================================================================
All obvious theorems are true.
 - Pommersheim's Principle

All true theorems are obvious.
 - Keane's Kriterion
Newsgroups: comp.software-eng