HDTenEightyP/NetNews huggingface dataset:
From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: Is SEI's CMM being used in Anger or just Marketing?
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Thu, 17 Dec 1992 00:45:10 GMT

In article <1992Dec16.210203.7119@netcom.com> kudzu@netcom.com (Michael Sierchio) writes:
>Your claim is that the model does not address the quality of the product,
>merely the process.  This is simply false.  The emphasis is on process,
>but that is the case in any industry which has instituted Juran's method
>of quality.

I agree that in any industry which has institutted Juran's method of
quality the emphasis is on the process. And I think it does address
product quality, but only of certain types. And I think that is true
in other industries as well.  The point is that product quality has
two aspects in a manufacturing view.  There's getting the right
definition of the product, and there's the ability produce that
specification to arbitrary precision, reliably, and cost-effectively.

Juran's method is great for addressing the latter issue. You can take
Juran's method and go from a Chevy Nova of yesteryear (poor
tolerances) to a Toyota Camry of today (good tolerances) and even to a
Lexus (excellent tolerances).  But Juran's method doesn't tell you if
Buick tail fins are more desirable than a boxy European shape, or a
sweptback Porche shape. It only tells you what to do if you have one
shape and determine the other is better through independent means
(like sales volume!).

I think the car manufacturers (and other industries) may have a better
grasp of what people desire in this other aspect of quality, than do
many software applications providers. Some of this is no doubt a
question of experience. The average auto firm is older than the
average software firm, and the average auto designer has more years of
experience than the average software designer.  But even so, auto
manufacturers make huge mistakes in their understanding of the public's
desires (e.g. the Edsel). And this also happens in other industries.
Juran's method doesn't prevent these mistakes from happening--these are
errors in judgement, not in execution.

But, perhaps because of the youth of the software industry, we feel
more need to put our attention on these issues than other industries
do. Until we get at least as good at product judgement as some of the other
industries, I think some of this attention to identifying what is the
right product (as opposed to how to produce it right) is very
appropriate, even though it isn't a focus of CMM or Juran. Wouldn't
you agree?



-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117-2967

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.



Newsgroups: comp.software-eng
From: mueller@b30news.b30.ingr.com ( Phil Mueller )
Subject: Re: average identifier length (was Comments: Code...)
Organization: Intergraph
Distribution: na
Date: Tue, 15 Dec 1992 13:13:02 GMT

In article <craigh.723767103@cserver> craigh@cserver.plexus.com (Craig Heilman) writes:
>jonathan@jspc.wimsey.bc.ca (Jonathan Story) writes:
>
>>In article <1992Dec5.094805@eklektix.com>
>>     rcd@raven.eklektix.com (Dick Dunn) writes:
>>> marick@cs.uiuc.edu (Brian Marick) writes:
>>> >Whether you use short or long names, as important as comprehensibility
>>> >of correct code is avoiding incorrect code...
>>> 
>>> fair enough, but only cautious approval here...
>>> 
>>> >My advice is to use whatever identifier style you like: but make sure
>>> >names are more than one typo away from other names in the same
>>> >routine.  "i" and "j" are bad loop indices;...
>>> 
>>> No, they're not.  At the least, when you're writing code to implement
>
>>Yes, they are.  Granted, loop indices probably don't need long
>>identifiers, but there is a second consideration: searching.  When you
>>want to see where variable 'i' is used, you are going to get a number of
>>false hits.  Recommendation: use 'ii', 'jj', etc.
>
>If you are using vi to look at your code then you can find all uses of
>any "word" by specifying your search as \<word\>.  For example, to find
>all uses of i you would say \<i\> (this search pattern can be specified
>anywhere you would normally use a search pattern...).  This search will 
>find all these i's:
>
>	long i;			
>	for (i = 0; i < MAX; ++i)
>	array[i] = ...
>
>but not these i's:
>
>	int j;
>	/* this is a test */
>	myVariableName
>
>Try it and see :-)
>

So you're going to force everyone to use vi?
AAAARRRRGGGGHHHH!!!!

I'm glad someone else uses the 'ii' technique.  Means that there's some
code I may have to maintain someday that doesn't use 'i' <gag>.

To Craig:
  If you got a mail message from me, sorry.  I typed 'R' instead of 'F'



-- 
Phil Mueller    mueller@b30news.b30.ingr.com
The preceeding opinions are not necessarily those of Intergraph Corporation.
Newsgroups: comp.software-eng
From: herbst@seq.uncwil.edu (R.T. Herbst)
Subject: ii/i/loops
Keywords: C loops
Organization: Univ. of North Carolina @ Wilmington
Date: Wed, 16 Dec 1992 14:20:23 GMT

Using vi or  your favorite editor, say, ed to find loop control
variables, like i 0r ii or j 0r jj  is weird.
Why not 
in 
vi
do
/for
or /while
or /do

all of the above are keywords and therefore 
are not 
allowed as variables.
herbst@seq.uncwil.edu
From: dzik@access.digex.com (Joseph Dzikiewicz)
Newsgroups: comp.software-eng
Subject: Re: C code Layout
Date: 17 Dec 1992 17:23:41 GMT
Organization: Express Access Online Communications, Greenbelt, MD USA
NNTP-Posting-Host: access.digex.com

In article <1992Dec14.175533.8400@fcom.cc.utah.edu> bryant@ced.utah.edu writes:
>In article 074411@eklektix.com, rcd@raven.eklektix.com (Dick Dunn) writes:
>
>Remember that "strings" assignment? The original source fit on one
>page. Many students would argue the fact that small programs can be
>the HARDEST ones!

Tony Hoare, in his Turing Award lecture, told about programming languages
in which programmers drop a one-line program on each other's desk with
a note saying "Guess what this does."  I'm pretty sure he was talking
about APL, but the same thing could apply to 'C'...


Newsgroups: comp.software-eng
From: david@hawk.adied.oz.au (David Hatley)
Subject: SWIFT/FURPS
Summary: Request for infor mation on SWIFT and FURPS
Keywords: SWIFT FURPS
Organization: Australian Defence Industries
Date: Thu, 17 Dec 1992 02:59:48 GMT

While reading the discussion on the SEI model I have noticed several 
references to SWIFT and FURPS. As I am currently looking at having an
SEI assessment done on our company I would like some information on these
and how they relate to the SEI model.

David

david@pf.adied.oz.au
Newsgroups: comp.software-eng
From: mat@mole-end.matawan.nj.us
Subject: Re: C code Layout
Summary: Kernighan and Plauger, again
Organization: :
Date: Wed, 16 Dec 1992 14:59:17 GMT

> >If you believe that K&R is "about right", then we will never
> >come to agreement on what the right amount of comments is.

> If you don't understand why K&R is "about right", you need to stop and
> think about ... it before ... pontificating about commenting code.  ...
 
> ...  the style of code and the amount/style of comments do not differ
> significantly from what you'd have found in the UNIX source 10-15 years
> ago.  In other words, Ritchie and Kernighan...and Thompson ... wrote and
> write C in a style not too different from what you see in K&R.

> Next, step back and look at where UNIX has gone.  That code has been read
> and understood by tens of thousands of people, and has been successfully
> modified over and over again for many years, often by people with almost no
> training or aptitude.  Like it or not, there is massive evidence that the
> style DOES work, IS understandable, and IS maintainable.  ...

The`secret' of that code's strength is not how it is commented; it goes
much, much deeper.  And the `manifesto' of that `secret' is _The Elements
of Programming Style_, by Kernighan and Plauger.  Yes, I mentioned it
earlier.  I've received mail to the effect of ``if only people would
read it ...''  No, it won't turn your code into UNIX v6.  But it can make
a huge difference.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.software-eng
From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
Subject: Re: Is SEI's CMM being used in Anger or ju
Reply-To: jhull@vulcan-gw.den.mmc.com
Organization: Martin Marietta Astronautics Group
Date: Sun, 13 Dec 1992 00:26:13 GMT

In article 28064@spectrum.xerox.com, 
kirby@xerox.com (Mike Kirby) writes:
|>...  To establish higher levels
|>of the CMM, it requires a serious ammount of overhead. 

I don't think so.  Certainly, most of the current DoD contractor
community have corporate cultures that will drive them in the
direction of overhead positions, voluminous standards, etc, but
"required?"  I think not.

Smaller companies will have one person take ownership of the CMM
process & encourage "working engineers" to contribute & will 
create superior results because of their approach.


---
-- -- -- --  --
	   _   _
    /_    / ) / ) Jeff Hull           j.hull@vulcan-gw.den.mmc.com
   //_) -/- -/-   1544 S. Vaughn Cir  
/_/ \_/ /   /	  Aurora, CO 80012    303-977-1061

No matter where you go ... there you are.
#include <standard.disclaimer.h>

Newsgroups: comp.software-eng
From: claird@NeoSoft.com (Cameron Laird)
Subject: Re: >>>  Value of High Code Coverage Metrics in Testing - Request for Opinion
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Mon, 14 Dec 1992 14:16:41 GMT

In article <ssimmons.724336081@convex.convex.com> ssimmons@convex.com (Steve Simmons) writes:
			.
			.
			.
>> 2)  Is it a cost effective excersize to get engineers to achieve a particular
>>    %BFA as a completion criteria?
>
>Sure... if you have the time in the schedule and effective tools to do it. 
PARTICULARLY if you don't have time in the schedule.
Try it; in my experience, people learn a lot from their
first coverage exercises.  It's far better to learn
those things *before* shipping the product.
>Usually, it is best to have people do coverage analysis on their own code
>and have people who don't know the code test it for unanticipated conditions.
>
>> 3)  What is a realistic %BFA to aim for?
>
>Fairly low percentage of 50% is usually the maximum possible value.  Much 
>code is assertion testing.  However, every condition should be accounted. 
85%.  Serious.
			.
			.
			.
If you're lucky, Brian Marick will tune in to this
conversation; he's the gentleman with the most ex-
perience and insight on this topic.
-- 

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: dws@menlo.cadre.com (David W. Smith)
Newsgroups: comp.software-eng
Subject: Re: Request for reuse tool info
Date: 15 Dec 92 00:46:26 GMT
Article-I.D.: menlo.1992Dec15.004626.28389
Organization: Cadre Technologies Inc., Menlo Park Operation

In article <Bz9Kzo.HAM@unx.sas.com> Phil Julian sets up the interview
scenario:

>Also, I can anticipate the reaction when you explain your past projects:
>   "Oh, I borrowed most of the code and adapted it to my own needs."
>   "But, what did you really write yourself?"
>   "Well, you don't understand.  I reused the code, which is good."
>   "But, can you show me something that you have done yourself?"
>   "Well, this part here, and that piece there."
>   "Next applicant!"
>
>From this scenario, reuse is bad for resumes.  What do other
>programmers or employers value more -- reusing old code or writing
>original code?  The problem may be our own attitudes and the attitudes
>of the marketplace.  Reuse is not valued as an intrinsic skill.  I
>know this is trite, but have you ever seen "reuse" as a desired skill
>on a job description?

In most of the places I've worked, the willingess to reuse code is an
indication of an engineer's maturity, in much the same way that willingness
to delegate is a measure of a good manager.

Change the scenario slightly and see how it plays.

    "Oh, I borrowed most of the code and adapted it to my own needs."
    "Even the key algorithms?"
    "Good implementations already existed, so I reused them."
    "You didn't rewrite them!?"
    "I would have loved to, but that would have been a poor use of my time."

If the interviewer is looking for an engineer with good judgement, the
candidate might well get the job.  At least s/he wouldn't have lost points
by demonstrating a not-invented-here attitude.

-- 
Dave Smith, Cadre Technologies Inc. - Database Tools Division
4500 Bohannon Drive, Suite 150, Menlo Park, CA  94025
Newsgroups: comp.software-eng
From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
Subject: Re: Which Software Configuration Management too
Reply-To: jhull@vulcan-gw.den.mmc.com
Organization: Martin Marietta Astronautics Group
Date: Tue, 15 Dec 1992 21:26:29 GMT

In article 18925@sun.DFSUN, kaare@nft.no (Kaare Trefall) writes:
|>I am trying to find which configuration management (CM)
|>tools ...
|>- TeamNet from TeamOne Systems
710 Lakeway Drive Suite 100
Sunnyvale, CA 94086
800-442-6650

---
-- -- -- --  --
	   _   _
    /_    / ) / ) Jeff Hull           j.hull@vulcan-gw.den.mmc.com
   //_) -/- -/-   1544 S. Vaughn Cir  
/_/ \_/ /   /	  Aurora, CO 80012    303-977-1061

No matter where you go ... there you are.
#include <standard.disclaimer.h>

Newsgroups: comp.software-eng
From: kudzu@netcom.com (Michael Sierchio)
Subject: Re: Is SEI's CMM being used in Anger or just Marketing?
Organization: True Love, and Home-Grown Tomatoes
Date: Wed, 16 Dec 1992 21:04:38 GMT

In article <18065@autodesk.COM> drake@Autodesk.COM (Dan Drake) writes:
>+ 
>+ Continuous process improvement is enabled by Level 5 -- In which the key
>+ practices are Defect Prevention and Technology Innovation.
>
>This states precisely where the SEI departs from well established theory
>and practice of quality management.  It's a shocking statement, and
>it's official SEI dogma: you can start to do Continuous Improvement only
>afet you've achieved an advanced stage of enlightenment (which in fact
>virtually no organization has ever achieved).

No, you just don't get it.  It doesn't mean that you can't engage in that
activity until you've achieved a certain level in the model.  It means you
don't achieve a certain level in the model until you practice all of the
parts of that level.  Which was stated in my post.  You are engaging
in an intentional fallacy.


-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+
From: overmyer@plains.NoDak.edu (Scott Overmyer)
Newsgroups: comp.software-eng
Subject: Re: Rapid Prototyping
Date: 13 Dec 92 05:18:40 GMT
Article-I.D.: ns1.Bz6Mr4.I4J
Organization: North Dakota Higher Education Computing Network

In article <1992Dec9.172130.21909@den.mmc.com> heck@hercules.den.mmc.com writes:
>In article 1qC@bcstec.ca.boeing.com, spady@bcstec.ca.boeing.com (Robyn Spady) writes:
>
>The key to correct or proper use of a methodology is training and education. Not
>only do the software developers need to be trained, but also the managers and
>the customer. That way everyone knows what they are getting and do not expect
>the prototype to be the complete system. Prototyping is an powerful anaysis tool
>that can be abused just like any other tool. 
>
Is everyone speaking about rapid prototyping as an interactive,
"throw-away" simulation of the user interface to a system under
design/development?  If this is the common definition, then
I'm curious to know how people are using rapid prototyping in the
requirements arena.  Specifically, is anyone saying that rapid prototyping
can be used to specify requirements?

scotto...
-- 
Scott P. Overmyer               | 
College of Business             |   Walter Payton for President.  
Minot State University          |   
Minot, North Dakota 58701 USA   |
Newsgroups: comp.software-eng
From: whg@inel.gov (Bill Gray)
Subject: Re: C Code Layout
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho
Date: Thu, 17 Dec 92 17:18:15 GMT

In article <45360002@hpcuhe.cup.hp.com>, defaria@hpcuhe.cup.hp.com (Andy DeFaria) writes:
|> ... 
|> 	if (condition) {
|> 	   statement;
|> 	} /* if */
|> ...
|> 
|> 	if (condition) {
|> 	   statement;
|> 	} else {
|> 	   statement;
|> 	} /* if */

My $0.02:

	if  ( condition )  {
	    stuff;
	}/* if  */
	^   ^^
	    The closing comment lines up with "stuff".
	The closing "}" lines up with the opening "if".


	if  ( condition )  {
	    stuff;
	}/* if  */
	else  {
	    more_stuff;
	}/* else */

Sometimes,  if it's longer and more complex than it should be, the
closing comment includes the condition:

	}/* if ( condition ) */
========== long legal disclaimer follows, press n to skip ===========

Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.
Newsgroups: comp.software-eng
From: bryant@ced.utah.edu (Bryant Eastham,MEB 3116,581-5353)
Subject: Re: C code Layout
Reply-To: bryant@ced.utah.edu
Organization: Center for Engineering Design
Date: Sat, 12 Dec 92 20:06:19 GMT

In article 8582@seq.uncwil.edu, herbst@seq.uncwil.edu (R.T. Herbst) writes:
>While directing the eforts of 125 people in producing the 
>A Data switching system for the Bell System- Good ol'
>Ma bell-- I asked for a sample of code. I founr the comments to
>be utter nonsense,. If one removed the code, the comments made no sense.
>It was better to let the code speak for itself. If fact the code
>was hidden in by the comments. Certainly we need well commented code.
>Too many comments that try to say what the code is saying are IMHO
>distracting. The code in this case was assembler. Since that time
>higher level languages came into use. In particular C language.
>My philosophy is to let the language speak for itself. Add comments
>where necessary. Again while directing the efforts of hundreds of
>people on the Safequard Anti-Balistic Missile System, we set standards
>for commenting that let the code be seen. The project met its objectives
>and schedule -- one of the few in that time frame. 
>Flame on and damned be he or she who flames out.
>herbst@seq.uncwil.edu

Anyone can get lucky a couple of times. ;-)

If you believe that K&R is "about right", then we will never
come to agreement on what the right amount of comments is.

There is a difference between "letting the code speak for itself" and
trying to let the code explain the algorithm. Clearly, lines like:

   i = i + 1;   /* Increment i */

are useless and cause "clutter" that should be "avoided". But the
same line:

   /*
    *  We are now done with the code for widget i, and while
    *  the "for" loop will increment i again, we want to skip
    *  the next widget and so we increment i here as well.
    */

   i = i + 1;

can be a lifesaver for some poor person trying to maintain the
code at a later time. The fact is that the second comment is
MUCH larger and could even "hide the code", but there is no
way that I will stop putting such comments in my code. I care
too much for those who will follow me.

Bryant Eastham
From: cbrophy@axion.bt.co.uk (Connor Brophy)
Newsgroups: comp.software-eng
Subject: Real Time CASE
Date: 16 Dec 92 08:21:48 GMT
Reply-To: cbrophy@axion.bt.co.uk (Connor Brophy)
Organization: British Telecom Research Labs


To whom it concerns,

	I work in BT in England and I am going to writing a State of the Art
report on Real-Time CASE. 
	
	I am looking for any information on Real Time CASE I can get my hands
on. Does anybody out there know any books or references on the subject?

	Also does anyone have any interesting experiences with Real Time CASE?
If so what important issues (specific to RT CASE) came up. Did the tools 
provide the productivity gain that they clamied they would? Were they at the
end of the day worth the incredible expense that it cots to follow a RT Case
solution. What was the learning curve like? - etc etc..

	I would be grateful for any inofrmation and help,

Thanks in anticipation,

	Conor
Newsgroups: comp.software-eng
From: srctran@world.std.com (Gregory Aharonian)
Newsgroups: comp.software-eng
Subject: Re: DoD and NIST undermining commercial CASE in
Date: 12 Dec 92 20:30:41 GMT
Organization: The World

>I would like to point out that Source Translation & Optimization
>(Greg Aharonian) markets a product called the Government Source Code
>Directory for $149 (paper or disk) or $249 (paper & disk) that is
>very little more than a list of the simtel-20 archives.

Being Greg Aharonian, I would like to point out that this is a very false
statement.  The list of simtel-20 archives makes up the appendices of the
directory.  The main section of the directory lists the titles and some
abstracts to about 9000 government and university computer programs for
the most not cataloged anywhere else.  So the snide remark is just that.

At some point in the future, the directory will contain the abstracts to
the 15,000+ government and university computer programs I have managed
with my own money (I don't have nice taxpayer pots to dip into like Martin
Marietta) to track down and catalog.

One would think with all of the interest and public posturing on federal
technology transfer I would not have to do all of this by myself.  But
for the most part, all I hear is public posturing.

Greg Aharonian
Source Translation & Optimization
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178
Newsgroups: comp.software-eng
From: david@hawk.adied.oz.au (David Hatley)
Subject: Re: Software Design Documentation !! Help
Organization: Australian Defence Industries
Date: Tue, 15 Dec 1992 00:35:17 GMT

bryan@eggneb.astro.ucla.edu (Bryan LittleField ) writes:

> I'm trying to write up a software design document (general)
> For me and other programs to use a guide in the future...

> And I'm not sure were to start ...

> Does anybody know of some design documments stuff on the net
> I could get my hands on ....
> Or anything else, you personally have or books etc. that would help..

> Thanks for your help in advance 

> --Bryan  bryan@igpp.ucla.edu

>----
You could try ANSI/IEEE Std 1016 Recommended practice for Software Design
Descriptions. There are associated standards on requirements specifications,
test plans, CM, etc.


--David  david@pf.adied.oz.au

Newsgroups: comp.software-eng