HDTenEightyP/NetNews huggingface dataset:
From: feathers@serss0 (Michael Feathers)
Subject: What is Software Design?
Organization: Florida International University, Miami
Date: Sun, 13 Dec 1992 17:30:30 GMT


I've just finished reading an article in the latest edition of _The C++
Journal_.  The article is named _What is Software Design_ and it was 
authored by Jack Reeves.

The ideas that he presents confirmed my suspicions about some of the problems
that we currently have in software engineering.  I whole-heartedly suggest
that anyone who can find the article do so and read it.
 
Here are some of the key points as I read them:
 
-There are some key differences between developing hardware and developing
 software.
-After hardware is designed, it is produced.  The cost of production is
 often in excess of the cost of design.
-For a meaningful parallel between hardware and software development to 
 exist, the coding of software should be considered part of the design process.
-Software is produced through the process of compiling and linking.  This is
 a rather low cost in comparision with the cost of design.
-Engineering designs must be complete so that production can be carried out
 successfully.
-The only document developed when software is designed that can be considered
 this complete is the source code.
-Testing and debugging are part of the design process.  "they are the software
 equivalent of the design validation and refinement processes of other
 engineering disciplines."
-"There are other design activities - call them top level design, module
  design...  A good software design process recognizes this and deliberately
  includes these steps."

All of these are basically changes in perception.  However, one consequence
of this change would be the recognition that coding as early in the process
as possible is useful.  But this should be no surpise to us, given the shifts
that we are seeing toward rapid prototyping and the like.
 
Comments?
From: kirby@xerox.com (Mike Kirby)
Newsgroups: comp.software-eng
Subject: Re: Is SEI's CMM being used in Anger or ju
Date: 14 Dec 92 15:33:13 GMT
Reply-To: kirby@xerox.com
Organization: Xerox Corporation, Webster NY

In article 2@cs.cmu.edu, msm@mse.cmu.edu (Mark S McWhinney) writes:
> In article <1992Dec11.180738.28064@spectrum.xerox.com>, 
> kirby@xerox.com (Mike Kirby) writes:
> 
> > The CMM *is* intended to be a grade.  The Departement of Defense
> > established the Software Engineering Institute at Carnegie Mello
> > University with the express intent of developing a system by which the
> > DOD could "grade" contractors.  
> 
> Not true.  The mission of the SEI is to provide leadership in
> advancing the state of the practice of software engineering to improve
> the quality of systems that depend on software.  Software process
> assessments and evaluations provide "grades", but the purpose of
> the CMM is to provide a framework for process improvement. 
> 
> You and everyone else who comments on the CMM should actually read it
> first.  The purpose of the SEI and the CMM is clearly stated on pages
> vii and viii of the CMM (CMU/SEI-91-TR-24).  To quote from page viii:
> "The SEI's goal ... is to encourage software organizations to focus on
> the CMM rather than on the maturity questionnaire [grade]."
> 
> 
> Mark
> 
> --- standard disclaimers ---

The grade is the CMM, the questionaire is just a test to determine whether it was
A,B,C,D, or F.  It was explained to me that the early days of the CMM, defense 
contractors were taking the questionaires and modifying their process so that they
met the questionaire, but did not necessarily understand or meet the CMM.

From the CMM:

CMU/SEI-91-TR-24
Pg vii

	In November 1986, the Software Engineering Institute (SEI) with assistance
	from the Mitre Corporation began developing a process maturity
	framework that would assist organizations in improving their software
	process.  This effort was initiated in response to a request to provide the
	federal government with a method for ASSESSING the capability of their
	software contractors.

Hmm.  THe word assessing says it all.  It *was* intended as a grade.  This paragraph
goes on to say that contractors took the questionaire as the model, rather than
understanding the CMM itself.  This is where the SEI wants companies to be careful.
They have to understand the model first.  Perform an assesment (made up of 
questionaires), and from the assesment they can derive their current location
in the model.

> You and everyone else who comments on the CMM should actually read it
> first.  The purpose of the SEI and the CMM is clearly stated on pages

Thank you for a wonderful suggestion.  Now that I have read it, I find that I 
am right.

Mike Kirby
Xerox Corp
E-Mail: kirby.roch803@xerox.com
Newsgroups: comp.software-eng
From: biesty@ide.com (Bill Biesty)
Subject: Re: metamodels, metalanguages, templates, domain models ...
Organization: IDE, San Francisco
Date: Fri, 18 Dec 1992 06:54:24 GMT

The following is a list of article refernces that ca@cs.washington.edu
requested from me but my mail bounced.
----

Larger Scale Systesm Require Higher-Level Abstractions
Mary Shaw
Proc. 5th Int. Wksp. Soft Spec. and Design
IEEE 1989 pp. 143

Heterogeneous Design Idioms for Software Architecture
Mary Shaw
Proc. 6th Int. Wksp. Soft Spec. and Design
IEEE 1991 pp. 158

Elements of a Design Language for Soft arch.
Mary Shaw
Pos paper for IEEE Design Automation Workshop
Jan 1990


The last one maybe hard to find. Her address is:
Mary Shaw
Soft. Eng. Inst.
CMU
Pittsburg, PA 15213-3890

--
Bill Biesty          <biestie@aol.com> (I don't read this too often)
<biesty@ide.com>     These are not the opinions of my employer.
Newsgroups: comp.software-eng,alt.sources.d,comp.sources.d
From: guru@camelot.bradley.edu (Jerry Whelan)
Subject: Re: cscope? trus?
Organization: The Smelly Ditch
Date: Sun, 20 Dec 92 22:47:46 GMT

In article <1992Dec19.191727.1407@vpnet.chi.il.us> hb@vpnet.chi.il.us (hank barta) writes:

-}    'cscope' shows up in the man pages of both SCO and ISC development
-}    kits w/out attribution to SCO, Microsoft or LPI, so I believe that
-}    it is probably part of the AT&T development tools. (And for this
-}    reason, may not work with ANSI code.)

	Cscope comes with most (if not all) SVR4 development packages,
including AT&T's.  As the SVR4 cc is ansi, cscope must support ANSI.
And, indeed it does as I've used it on ANSI code.

-------------------------------------------------------------------------------
``written by a drunken insane pathological liar''        guru@stasi.bradley.edu
From: martinc@hatteras.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: C code Layout
Date: 16 Dec 92 16:17:34 GMT
	<1992Dec14.235521.1557@cbnewsm.cb.att.com>
	<KANZE.92Dec15171105@slsvdnt.us-es.sel.de>
	<1992Dec16.083733@eklektix.com>
Organization: UNC Department of Computer Science
In-reply-to: rcd@raven.eklektix.com's message of 16 Dec 92 08:37:33 GMT

In article <1992Dec16.083733@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:

   kanze@us-es.sel.de (James Kanze) writes:
   >lfd@cbnewsm.cb.att.com (Lee Derbenwick) writes:
   >|> One reason that I personally dislike very large comments embedded in
   >|> the code is that they greatly reduce the amount of code within my
   >|> visual field (whether on a screen or on paper):...
   ...

   Scott McGregor talks about the same phenomenon (and some of the tradeoffs
   surrounding it) in considerably more detail.  But it's a good point in any
   case.

But then ... it was just one news item ago that you were enjoining us to
get tools that suit the job rather than perverting the work to suit the
tool.  Doesn't that apply to 25-character screens as well?

I'm actually serious -- an acquaintance seriously noted that getting
full-page screens for their terminals improve productivity substantially
on a big project, just because it allowed holding a whole function in
one screenful.



--
		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
Newsgroups: comp.software-eng
From: terry@asl.dl.nec.com
Subject: Re: Is SEI's CMM being used in Anger
Originator: terry@aslws01
Organization: (Speaking only for myself)
Date: Mon, 14 Dec 1992 05:55:18 GMT

Hi folks,

In article <1992Dec13.174850.26842@spectrum.xerox.com>
kirby@xerox.com (Mike Kirby) writes:

> In article 24010@asl.dl.nec.com
> terry@asl.dl.nec.com (Terry Bollinger) writes:
>
> | I have a *lot* of problems with the way [SEI's process maturity model]
> | tries to order things... the FIRST thing you should look for are the
> | process problems with the biggest payoffs.  Waiting until you have
> | umpteen different "metric programs" in place ... is just a recipe for
> | disaster...
>
> NO NO NO NO...
>
> Okay.. Let me try this one more time.

Very slowly, please.  (And be sure to repeat key points, repeat key points,
repeat key points, repeat key points... oh heck, you get the idea!)

> The whole idea of the metrics program is so we can take specific measure-
> ments of the process and product and make specific recomendations based on
> those metrics... [lots deleted]  What they are saying is that we are
> measuring the PROCESS as well as the product and predicting the quality
> in any given project within a particular application domain.  Of course
> a level 4 organization can detect when something goes wrong with their
> process, but doesn't have the capability to do anything about it.  That
> is what a level 5 organization does.

I enjoyed your posting immensely, but probably not in quite the fashion you
were expecting.  Best of luck on your process improvement program.

				Cheers,
				Terry Bollinger

+--------------------------------------------+-------------------------------+
| Terry Bollinger                            | Phone: 214-518-3538           |
| Advanced Switching Laboratory, NEC America |   Fax: 214-518-3499           |
| 1525 Walnut Hill Lane, Irving, Texas 75038 | Email: terry@asl.dl.nec.com   |
+--------------------------------------------+-------------------------------+
From: neveu@tintin (Jean-Sebastien Neveu)
Newsgroups: comp.software-eng
Subject: Re: Test coverage
Date: 15 Dec 92 17:35:47 GMT
Organization: Ecole Polytechnique de Montreal
X-Newsreader: TIN [version 1.1 PL6]

R.T. Herbst (herbst@seq.uncwil.edu) wrote:
: 
: There are two facilities in UNIX V rel 4 that will help in 
: evaluating a test. Ctrace and  lprof.
: Ctrace will trace a program giving lvalues for each statement 
: executed.
: 
: Lprof will display the frequency of execution 
: of statements or the statements executed.
: 
: I find both ctrace and lprof useful in debugging and in 
: determining the coverage of a test.
: herbst@seq.uncwil.edu
: 

There is also "tcov" which can be use in conjunction with the "-a" option
of the C compiler.

I find all these built-in tools very limited.  There are plenty of other tools
useful in determining test coverage.  Datrix and GCT are only two of them.

--
/************************************************************************\
* Jean-Sebastien Neveu, ing. jr.  | Humain, sais-tu comme c'est interes- *
* Laboratoire de Genie Logiciel   | sant, cette chose que tu decris ?    *
* Ecole Polytechnique de Montreal | Avata n'a pas de dieu.  Comment se   *
* CP 6079, succ. A,               | fait-il que tu aies un dieu ? Avata  *
* Montreal, Quebec, H3C 3A7       | a le Soi, Avata a cet univers.  Mais *
* Tel: (514) 340-4599             | toi, tu as un dieu.  Ou as-tu trouve *
* FAX: (514) 340-3240             | ce dieu ?              KERRO PANILLE *
* E-Mail: neveu@rgl.polymtl.ca    |           Les traductions de l'Avata *
\************************************************************************/
Newsgroups: comp.software-eng
From: claird@NeoSoft.com (Cameron Laird)
Subject: Commenting style (was: C code Layout)
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Mon, 14 Dec 1992 14:03:10 GMT

In article <1992Dec14.074411@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:
			.
			.
			.
>Well, ;-) or no, that's a bad attitude.  Reality is trump; get used to it.
>It's hard to defeat something that works in practice with an argument only
>demonstrated on paper (or phosphor:-).
>
>>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 the real significance of it before doing any more pontificating
>about commenting code.  This is not an "Is Too!"-"Is Not!" matter; it is a
>theory-vs-practice matter.
I don't have anything to add to Mr. Dunn here,
'cept my ongoing admiration of those who seek
out reality.
			.
			.
			.
>...and useful, necessary explanations like:
>
>>   /*
>>    *  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;
>
>The *idea* of commenting this situation is good.  You don't want somebody
>looking at it, wondering whether the increment is supposed to be there or
>was left over from a different sequence, etc...it's a good situation for
>stopping to describe what's going on.  It's the realization that is bad.
>(To a C programmer, the first problem is that the code should be
>    i++;
>You don't ignore the idioms of the language unless you're trying to confuse
>the people reading the code.  I thought we were trying to avoid that!)
			.
			.
			.
>what Bryant is showing us here.  How about:
>    i++;		/* done with widget i; skip the one after it */
Nice illustration.

Small point:  I have a small bias toward grammatical,
completely punctuated sentences in standard English.
There's nothing wrong with Mr. Dunn's idiomatic cap-
sulization, but I generally incline toward something
that looks like

			/* We have finished widget i; skip the one after it. */
	i++;

purely on "multi-cultural" lines.  I know all the pro-
grammers from my home town could parse Mr. Dunn's
comment without hesitation; I also know that anything
we write today is almost certain to be read by non-
native speakers of English, and by English speakers
from places far removed from my idiolect.  It's good
paring one's words down to just the essentials; it's
also good to form those words in a syntax that is
unambiguous, particularly across the ethnic boundaries
that are a significant feature of our professional 
landscape.
			.
			.
			.
-- 

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
Newsgroups: comp.software-eng
From: herbst@seq.uncwil.edu (R.T. Herbst)
Subject: C Code Layout
Keywords: c Code
Organization: Univ. of North Carolina @ Wilmington
Date: Tue, 15 Dec 1992 02:32:35 GMT


Here is a way to have your code and eat it too.
Each comment suggesct that you escape the editor and look 
at a file the can be as large as you please.  The files
should be in the same directory as the code that is being 
tested or written. The code is not cluttered with long comments.
Imagine a screen of comments followed by a single instruction that is
followed by 20 lines of comments. 

/* Document 
* :! vi doc.file
*/
#include <stdio.h>
main()
{
/* Declare internal variables.*/
	int c;
	while(( c = getchar()) != '\n') /* :! vi comment1*/
	;
}

cat doc.file
This program is intended to read characters into the integer c
until a newline is encountered.

cat comment1

This often used construct will read characters from the standard
input file until a nelwline is encountered. It is also very 
useful in removing newlines left in the standard input file as a result
of executing scanf.
herbst@seq.uncwil.edu

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: Fri, 18 Dec 92 19:23:04 GMT

I know this is dangerous considering some of my earlier
postings, but here we go:

   if ( ... )
     {
     statement;

     } /* end if */
   else
     {
     statement;

     } /* end else */

The editor I use (emacs) does the indenting automatically, so
I don't have to use spaces or small tabs. In general, I use
the following rule:

  Same scope, same indent.

It also doesn't use as much hor. space as the other
alternative...

Bryant Eastham
Center for Engineering Design
University of Utah
bryant@ced.utah.edu

Newsgroups: comp.software-eng
From: TENG63@waccvm.corp.mot.com (Steven Lynch)
Subject: Version Control - Software Configuration Change Management
Organization: Motorola
Date: 17 Dec 1992 05:14:41 MST

Hello.

We are trying to get to an SEI Level 2 organisation. One of the main
points we fall down on it to have Version control and an effective
change management system in place.

Is anyone aware, please, of any systems which would control all of the
information associated with a software project under some sort of
version control?

This would extend through :

       - all project documents (work requests, plans, reviews, analysis
                                design, implementation, production, etc)

       - all project source code
Our main platforms are PCs and Macs.

Any help would be most welcome.

Best regards,

Steven Lynch,
Motorola SPS Ltd,.
Scotland.
Newsgroups: comp.software-eng
From: biesty@ide.com (Bill Biesty)
Subject: Re: metamodels, metalanguages, templates, domain models ...
Organization: IDE, San Francisco
Date: Wed, 16 Dec 1992 00:13:09 GMT

In article <1992Dec15.191917.1072@mprgate.mpr.ca> janzen@mprgate.mpr.ca writes:
>In article <1992Dec13.203011.24702@sojurn.lns.pa.us>,
>mike@sojurn.lns.pa.us (Mike J. Sangrey) writes:
>>[...]
>>There seems to me to be a certain set of patterns
>>that, when incorporated into software, provide a great deal of
>>flexibility and efficiency.  [...]
>>   
>>    What patterns should a software engineer look for and lean
>>    towards using, when doing analysis and design of a software
>>    system?  I'm looking for cookbook answers and justification
>>    for it's inclusion into this cookbook list.
>>
>>       1)  read-write-open-close
>
>Um, shouldn't "open" come first? :-)
>
>>	2)  dynamic redirection of information flow
>>	3)  ???
>
>OK, here are a few that I've found myself using over and over:
>
>3) finite state machines
>4) event-driven processing (eg. X Window System)
>5) control breaks in sorted input
>6) mixin classes

I've never heard of this one. Could someone fill me in?

>7) Model-View-Controller
>
>I'd be interested in seeing your "completed" list...

Me too.

Recently a friend gave me copies of some papers by  Mary Shaw
at Carnegie Mellon U. on high level abstractions. Paradigms
she mentions are:

8) pipeline (stream filter stream filter ....)
9) data abstraction (structures)
10) layering (libraries within libraries)
11) rule based systems
12) blackboard systems
13) table driven interpreters
14) repositories

--
Bill Biesty          <biestie@aol.com> (I don't read this too often)
<biesty@ide.com>     These are not the opinions of my employer.
Newsgroups: comp.software-eng
From: nigel@ietech.demon.co.uk ("Nigel G. Backhurst")
Subject: O-O and Swift
Distribution: world
Organization: IE Technical Services Holland
Date: Tue, 15 Dec 1992 01:49:24 +0000

I have heard on the that Swift in Brussels have successfully used
OOA and OOD on a major software project coded in C++.  Apparently
this was produced on time and underbudget.  Anybody have any
information on this, especially on what systems they used for
development?

Nigel
---------------------------------------------------------------------
Nigel Backhurst ( nigel@ietech.demon.co.uk )
Koggestraat 10D, 3028 VX Rotterdam, Netherlands
IE Technical Services Holland, Deventerstr 150, 7321 CE Apeldoorn, NL
---------------------------------------------------------------------

Newsgroups: comp.software-eng
From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
Subject: Re: Software Inspections.  How many does it
Reply-To: jhull@vulcan-gw.den.mmc.com
Organization: Martin Marietta Astronautics Group
Date: Thu, 17 Dec 1992 18:09:47 GMT

In article <1992Dec14.192008.15480@gallant.apple.com>, 
neumann.m@applelink.apple.com (mark neumann) writes:
mn>


In article 2q2E@austin.ibm.com, 
dugal@austin.ibm.com (Doug Gray) writes:
dg>

mn>
mn> It seems obvious that having someone check your work is a good idea.  It
mn> also seems that each additional person that checks your work is less
mn> likely to find a problem (on average).
mn>
dg>
dg>Actually, although it does seem obvious, it is probably not the case.  There is an
dg>article in the April '92 issue of ACM Transactions on Software Engineering and
dg>Methodology which addresses that theory (at least for Requirements)  "An Experimental
dg>Study of Fault Detection In User Requirements Documents" (Schneider, Martin & Tsai) 
dg>found that when independent inspection teams reviewed the same requirements document,
dg>they did not duplicate the work of each other.

But mn wasn't talking about *independent* review teams.  He was talking about
adding more people to a team.  In this case, I suggest that the amount/number
of errors detected per person added to the team decreases rapidly for team sizes
beyond four or five.


dg>The same sort of relationship can be developed for a review team as well.  When a
dg>review team signs off that the deliverable is acceptable, ALL members of the team
dg>become responsible for the quality of that product - in some ways more responsible
dg>than the original author.

I agree with dg completely.  I do suggest, however, that significantly superior
results will be obtained from 2 completely independent review teams of perhaps
3 or 4 people than a single review team of 6 to 8.


-- -- -- --  --
	   _   _
    /_    / ) / ) 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: ii/i/loops
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Thu, 17 Dec 1992 14:26:16 GMT
Keywords: C loops

In article <1992Dec16.142023.24363@seq.uncwil.edu> herbst@seq.uncwil.edu (R.T. Herbst) writes:
>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

Wow!  This shows how far our understandings of the same
words can diverge.  What Mr. Herbst says above isn't the
point I got from this at all.
1.  "/for" doesn't work, 'cause it'll also match
    "fortran", "foreign", "reformat", ...
2.  More crucially, when I go off looking for "i",
    it's usually because something has gone wrong
    with my loop, and I suspect that some third
    party is off in a corner abusing one of my
    variables ("Look!  'i = TRUE;', where they
    probably meant 'in = TRUE;'.").  All the folks
    I know who ask their editors to search for "i"
    are doing so because they want to find the things
    about which they do *not* already know, that is,
    *not* the well-controlled loops and such.

This is surely a dead horse I'm beating, but it's interesting
to me to realize how far apart we can get in so short a span.
-- 

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