HDTenEightyP/NetNews huggingface dataset:
From: jcrw@fmg.bt.co.uk (Jeremy Wilson)
Newsgroups: comp.software-eng
Subject: Re: metamodels, metalanguages, templates, domain models ...
Date: 21 Dec 92 09:43:15 GMT
Organization: British Telecom
X-Newsreader: Tin 1.1 PL5

Mike J. Sangrey (mike@sojurn.lns.pa.us) wrote:
: I've been reading Yourdon's book: "The Decline and Fall of the
: American Programmer," and in that book he brings up meta-languages.
: He gives an illustration from a three volume work about Architecture
: (which I don't believe to be computer architecture, but about
: buildings, villages, etc.)  The work suggests that as a technology
: matures, it develops a set of pattern languages that are used because
: they provide simple, elegant, efficient solutions to the problem
: domain.  While you drive down the road, you'll notice certain
: architectural patterns, repeated again and again.  Rectangles are
: frequently 2 times longer than they are wide; bricks for example.
: These patterns work, both to the eye as well as functionally.  Up here
: in the north east (Penna.) we have porches on the front of most
: houses.  That pattern serves many functions and does so efficiently,
: and, many times, rather elegantly.

There is an article by Peter Coad that might be of interest  in this context.

Object Oriented Patterns
Sept 1992 Vol 35 No.9 Communications of the ACM

+---------------------------------+----------------------------------------+
! Jeremy Wilson			  !	email: jcrw@fmg.bt.co.uk           !
! Room 3-07                       !     Telephone: 0473-227822             !  
! BT Development and Procurement  !     International: +44 473-227822      !
! Bibb Way			  !     Facsimile: 0473-210182             !
! IPSWICH                         !     International: +44 473-210182      !
! Suffolk  IP1 2EQ                !     Telex: 987705                      !
! United Kingdom                  !     International: +51 987705          !
!  				  !     				   !
+---------------------------------+----------------------------------------+
Newsgroups: comp.software-eng
From: riepjr@ucunix.san.uc.edu (Josette R. Riep)
Subject: Oracle DB Looking
Organization: University of Cincinnati
Distribution: usa
Date: Wed, 23 Dec 1992 05:42:28 GMT

From riepjr Wed Dec 23 00:41:08 EST 1992
Article: 11748 of comp.databases
Newsgroups: comp.databases
From: riepjr@ucunix.san.uc.edu (Josette R. Riep)
Subject: Oracle DB Looking
Organization: University of Cincinnati
Distribution: usa
Date: Wed, 23 Dec 1992 05:20:12 GMT


		I have been looking for the Oracle Database in third
	party software catalogs. But My search has been unsuccessful.
	I was wondering if anyone knew where I could get the Oracle
	Database and/or a network version of the Oracle Database.  I
	would also like to know the price range of the these Databases.
	

		Thankyou in advance !!

		Todd Sims

	p.s. I would rather recieve answers by email if possible...


Newsgroups: comp.software-eng
From: travis@eecs.nwu.edu (Travis Marlatte)
Subject: Re: Software Inspections.  How many does it take?
Summary: Having authors present at inspection
Organization: Rauland-Borg Corporation, Skokie IL
Date: Mon, 21 Dec 1992 19:05:32 GMT


The only reason not to have the author present at an inspection is
due to ego. This is a poor reason. Inspection teams must get past
that point to be productive whether the author is present or not.

Yes, the code should stand on it own. That's why the inspection is being
held. But having an inspection does not imply that the code is ready to
go. Changes will be made to code and in-line documentation as a result
of the inspection.

Having the authors present simply prevents the reviewers from mentally
wandering off the track. It is easier for the author to add 
information to the discussion, make a note that the information
should be added to the documentation and allow the inspection to continue.

My perspective on reviews and inspections is that it is a team effort
to improve the quality of the software. The author is a part of that
team and must be present.

The post questioning the value of "scribes" and "moderators" is missing
the point. Eventually, the author has responsibility for incorporating
any changes that should be made as a result of the inspection. Having
a scribe or recorder seperate from the author simply allows the author
to concentrate on the discussion and points of confusion. The notes
taken will end up with the author anyway. It is not just a way of
creating metrics.

Professionals or not, any group of people involved in a discussion with
time limits needs to have someone in control. Clearly, professionals
should be able to calmly come to a consensus. But people involved
in a discussion often fail to recognize the passage of time. It is better
to have a moderator who can say, "Well, obviously this is a point of
confusion. Made Bill and Frank can get together with Jane to iron out
the details later. Lets move on with page 1573."



-- 
Travis Marlatte
travis@eecs.nwu.edu
708-297-0055
Xref: sparky comp.software-eng:5130 comp.lang.c:18803
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.software-eng,comp.lang.c
Subject: Re: C code Layout
Date: 22 Dec 92 23:12:15 GMT
Followup-To: comp.lang.c
Organization: negligable

In article <1992Dec18.151710.23851@scott.skidmore.edu> pvonk@scott.skidmore.edu (Pierre VonKaenel) writes:
>In article <AJ3U.92Dec17172600@onyx.cs.virginia.edu> aj3u@onyx.cs.virginia.edu (Asim Jalis) writes:
>>I prefer the K&R style of using braces with statement blocks:
>>
>>    keyword (condition) {
>>        statement1;
>>        statement2;
>>        statement3;
>>    }
>>
>
>I used to use this syntax until once I forgot one of the { and it
>wasn't noticable.  Took a while to find that bug.  At least..
>
>    keyword (condition) 
>    {
>        statement1;
>        statement2;
>        statement3;
>    }
>
>is easier to spot.  It's also more symmetric, which means from an
>artistic view, more pleasing   (I know, I know... subjective!)


All this argument between style A:

	keyword (condition) {
		statement1;
		statement2;
		statement3;
	}

and style B:

	keyword (condition) 
	{
		statement1;
		statement2;
		statement3;
	}


... am I in the minority here by preferring style C:

	keyword (condition) 
		{
		statement1;
		statement2;
		statement3;
		}

This is essentially a minor variant with all the advantages
of style B, but the additional advantage that the braces match
the indentation level of the statements they surround, consider
this -- if you have:


	if (cond)
		statement;

and then have to add another statement to it:

	if (cond)
	{
		statement;
		statement2;
	}

My editor (vi with auto-indent set) requires additional effort
to move those braces back to the "outdented" position, whereas

	if (cond)
		{
		statement;
		statement2;
		}

can be accomplished much quicker.


btw: I really detest the K&R style (style A), for reasons
already mentioned, among them (but not limited to):

	difficult to see block alignment
	hides "else" keyword
	even MORE difficult to make a single-line if-body
		into a block than style B

		-Richard Hartman
		hartman@uLogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Ideas are not responsible for the people who believe them."

Newsgroups: comp.software-eng,news.answers
From: fox@wubios.wustl.edu (Dave Fox)
Subject: LBMS INFO (case tool)
Keywords: CASE LBMS
Organization: Division of Biostatistics, WUMS, St. Louis, MO
Date: Wed, 30 Dec 1992 21:08:25 GMT



I am interested in information on your use of 
the LBMS Case Tool products.


Please contact me via e-mail.


Thanks in advance.
Newsgroups: comp.software-eng
From: dmmatt@bigez (Mike Mattix)
Subject: Re: Debugging the process
Organization: Monsanto Agricultural Company
Date: Thu, 31 Dec 1992 11:22:59 GMT

In article <1992Dec30.185928.367@cs.rit.edu>, jeh@cs.rit.edu (James E Heliotis) writes:
> 
> This is the classic argument against software engineering process
> standards, but let's face it; not all of us are good enough to satisfy
> the above quote.  We still need a defined process to make the mediocre
> people somewhat productive, both in engineering and management.  I also
> suspect, that if the good people followed the same processes, that this
> would also facilitate communication between the good ones and the
> mediocre ones.
> 
> In summary, 'good' engineers may not require 'good' management, but
> good management is required for the engineering process to run smoothly,
> and that's what you need to pull the majority of the engineers into your
> program.
> 
> 

  The problem is how to add the 'good' management without putting roadblocks
in the way of the 'good' engineers.  A couple of months ago a post mentioned
a specific DOD Software Development Policy and another poster thought that
that policy's main objective was to drown the software development process 
in so much red tape as to mask the amount of time the actual development 
took.  While this is sarcastic, quite frequently management in the effort
to 'help' improve the not-so-good engineers, constrict the 'good' engineers
by the overhead introduced into the process.  I have been in this business 
20+ years and we are still raving about how this new 'control' technology
will improve the accuracy and timeliness of the systems we are building.
I submit we will still be raving about the current trendy technology 10 
years from now and will still be having the same problems.  The only 
improvements in accuracy and timeliness of systems in the last 20 years
can be traced directly back to technological breakthroughs not new 
project management/software engineering procedures.  I am refering to
on-line development vs batch development and Desktop development vs
mainframe development.  These developments have impacted the ability 
of software engineers to deliver cost-effective systems that the users
need far more than any 'methodology' of the last 20 years.
  

-- 
Mike Mattix
Agricultural Group of Monsanto
P.O. Box 174
Luling, LA 70070
INTERNET Address: dmmatt@bigez.monsanto.com
From: nancy@murphy.ICS.UCI.EDU (Nancy Leveson)
Subject: Re: Concurrent Engineering
Newsgroups: comp.software-eng
Reply-To: nancy@ics.uci.edu, leveson@cs.washington.edu
Date: 24 Dec 92 23:16:43 GMT


(I just wrote something about concurrent engineering last week for a
book I am working on.)

Concurrent Engineering was a popular idea in the 1950s.  The political
pressure was very high to develop a nuclear warhead with deliverable
capability.   The concurrent engineering philosophy was developed in an
attempt to shorten the time required between the concept and definition
of a weapon system and the initial operational capability.

Under the concurrency concept, the missiles and the facilities in which
they were to be maintained in ready conditions for launch were built at
the same time that tests of the missiles and training of personnel
were going on.  It was recognized that there would be many modifications
and retrofit efforts that would cost more money.  However, with the world
nuclear threat, it was concluded that additional expenditure of money was
a cheap way to buy time (remember, this was the same time we threw away
$15 billion on a boondoggle to build an atomic airplane, and at that time
a billion dollars actually bought something :-)), and a tremendous effort
was exerted to make the concurrent approach work.

The result?  Within 18 months after the fleet of 72 Atlas F ICBMs became
operational, four blew up in their silos during operational testing.
Multimillion-dollar missile/silo launch complexes were lost in frequent
accidents.  [More details about some of these accidents will be found in
my book, if I ever get it finished.]  The missiles also had an extremely
low launch success rate.

Not only were the losses themselves costly, but the resulting investigations
found serious safety deficiencies in the systems that would require
extensive modifications to correct.  In fact, the cost of the modifications
would have been so high that a decision was made to retire the entire
weapon system and accelerate deployment of the Minuteman.  Thus, a major
weapon system originally designed to be used for a minimum of ten years
was in service was for less than two years primarily because of safety
deficiencies.  Better system engineering and engineering management methods
were developed for the later systems that provided up-front planning and
analysis, resulting in a much more successful product.

Not studying the past and learning from our mistakes is like riding a
merry-go-round -- we end up going round and round in circles without really
getting anywhere.

Prof. Nancy Leveson
UCI and Univ. of Washington

Newsgroups: comp.software-eng
From: marick@cs.uiuc.edu (Brian Marick)
Subject: Re: Testing bug fixes - request for data
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sun, 3 Jan 1993 14:55:46 GMT


Here are the papers I forgot to reference.

"Experience with the Cost of Test Suite Coverage Measures",
Pacific Northwest Software Quality Conference, October, 1991.
(Also cs.uiuc.edu:/pub/testing/experience.ps.Z.)

"The Weak Mutation Hypothesis",
Proceedings of the ACM SIGSOFT Symposium on Testing, Analysis, and
Verification, October, 1991. 

"Three Ways to Improve Your Testing", invited paper,
Pacific Northwest Software Quality Conference, October, 1992.
(Also cs.uiuc.edu:/pub/testing/three.ps.Z.)
Newsgroups: comp.software-eng
From: nancy@murphy.ICS.UCI.EDU (Nancy Leveson)
Subject: Re: Concurrent Engineering
Newsgroups: comp.software-eng
Reply-To: nancy@ics.uci.edu, leveson@cs.washington.edu
Date: 24 Dec 92 23:39:15 GMT


(I just wrote something about concurrent engineering last week for a
book I am working on.)

Concurrent Engineering was a popular idea in the 1950s.  The political
pressure was very high to develop a nuclear warhead with deliverable
capability.   The concurrent engineering philosophy was developed in an
attempt to shorten the time required between the concept and definition
of a weapon system and the initial operational capability.

Under the concurrency concept, the missiles and the facilities in which
they were to be maintained in ready conditions for launch were built at
the same time that tests of the missiles and training of personnel
were going on.  It was recognized that there would be many modifications
and retrofit efforts that would cost more money.  However, with the world
nuclear threat, it was concluded that additional expenditure of money was
a cheap way to buy time (remember, this was the same time we threw away
$15 billion on a boondoggle to build an atomic airplane, and at that time
a billion dollars actually bought something :-)), and a tremendous effort
was exerted to make the concurrent approach work.

The result?  Within 18 months after the fleet of 72 Atlas F ICBMs became
operational, four blew up in their silos during operational testing.
Multimillion-dollar missile/silo launch complexes were lost in frequent
accidents.  [More details about some of these accidents will be found in
my book, if I ever get it finished.]  The missiles also had an extremely
low launch success rate.

Not only were the losses themselves costly, but the resulting investigations
found serious safety deficiencies in the systems that would require
extensive modifications to correct.  In fact, the cost of the modifications
would have been so high that a decision was made to retire the entire
weapon system and accelerate deployment of the Minuteman.  Thus, a major
weapon system originally designed to be used for a minimum of ten years
was in service was for less than two years primarily because of safety
deficiencies.  Better system engineering and engineering management methods
were developed for the later systems that provided up-front planning and
analysis, resulting in a much more successful product.

Not studying the past and learning from our mistakes is like riding a
merry-go-round -- we end up going round and round in circles without really
getting anywhere.

Prof. Nancy Leveson
UCI and Univ. of Washington


------- End of Forwarded Message
From: jeh@cs.rit.edu (James E Heliotis)
Newsgroups: comp.software-eng
Subject: Re: Debugging the process
Date: 30 Dec 92 18:59:28 GMT
Organization: Rochester Institute of Technology, Rochester, NY

kirby.roch803@xerox.com (Mike Kirby) writes:

>All the SEI is saying is that you need to have a management process in
>place before an engineering process will be able to take hold.  and you
>need both processes before you can determine if a product failure is
>due to engineering or to management.  AND you need to be able to
>measure both.  Once you can do these things then you will be able to
>continously improve the processes.

peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>
>This is the clearest statement I've seen yet of the SEI
>misunderstanding that generates so much opposition among engineers.
>
>Management is not engineering. Management has the ability to hinder
>engineering, and it has the ability to facilitate it. However, good
>engineering can be performed (with difficulty) under bad managers;
>conversely, good management does not guarantee good engineering.
>

I am not sure about this response.  Are you saying that
kirby.roch803@xerox has a misunderstanding?  If so, I am not sure that
your statement is really a rebuttal.  kirby talks about an engineering
PROCESS, which is part of what SEI is trying to tell us.  You
(peterd@pjd.dev.cdx.mot) are saying, I think, "Given a group of good
engineers, they can do a good job, with or without the support of
management."

This is the classic argument against software engineering process
standards, but let's face it; not all of us are good enough to satisfy
the above quote.  We still need a defined process to make the mediocre
people somewhat productive, both in engineering and management.  I also
suspect, that if the good people followed the same processes, that this
would also facilitate communication between the good ones and the
mediocre ones.

In summary, 'good' engineers may not require 'good' management, but
good management is required for the engineering process to run smoothly,
and that's what you need to pull the majority of the engineers into your
program.


============================================================================
Jim Heliotis			Computer Science Department
				Rochester Institute of Technology
jeh@CS.RIT.EDU			Rochester, NY 14623-0887
716-475-6133			[FAX] 716-475-7100
============================================================================
-- 
				Jim Heliotis
				Rochester Institute of Technology
				Rochester, NY 14623-0887
				jeh@CS.RIT.EDU
Newsgroups: comp.software-eng
From: shanks@saifr00.cfsat.honeywell.com (Mark Shanks)
Subject: Re: When do we inspect [getting LONG]
Keywords: Inspections
Organization: Honeywell Air Transport Systems Division
Date: Wed, 23 Dec 92 16:26:49 GMT

In article <Bzo1ML.GK6@NeoSoft.com> claird@NeoSoft.com (Cameron Laird) writes:
>    Mr. Shanks, are you saying
>    that you approve of the way it is, or that you're
>    stuck with something you see as suboptimal, and
>    therefore you don't wish to "start that process
>    any sooner than necessary"?  If the former,
>    please fill in a few more of the details on how
>    such a system is a benefit.  It would make me
>    feel as though I'm in a trailer factory, say,
>    welding away on my assigned joints, and I notice
>    that I need more light on my worktable to jig up
>    the pieces carefully.  I get the feeling that,
>    in the factory where you work, I'd have to call
>    a meeting of the union first.  Is there no
>    cheaper way for me to improve my process?

My goodness, such formality on the net. I haven't been called
"Mr. Shanks" since I was a cadet :> (and back then, we were issued
things called "slide rules" :> :>)

The fact that you ask whether I favor the type of CM system I
have described indicates that (so far) I have been able to
present the facade of objectivity about it. In truth, my efforts
to change this system (all in the spirit of "continuous process
improvement" and "empowerment") have to date been met with 
curious resistance. "Curious" because the people I have tried
to convince don't see anything wrong with the present process/
system in spite of the metrics indicating the very large number
of engineer-hours spent on it with no discernable benefit, or
rather, benefits such as the code-checking you referred to in an
earlier posting. The crux of the question (to me, anyway) is,
"What is a configuration management system for?" If the CM
is designed solely for the purpose of having an auditable trail
of document/code history, the benefit of checking material into
the system comes by doing that just before the first official 
release of the material. To do so before that, IMHO, is creating
an unnecessary amount of "trail" of design/requirements changes
with the cost of literally thousands of engineering hours and
resultant impact on design/coding/integration - in another word:
schedule. (Not to get too far off the point, but I've seen too
many people for whom this process is in itself some kind of job
satisfaction; they LIKE to sit around in inspections, fill out
inspection logs, check things in and out, and all those other
"cook-book" kind of non-creative/is-this-really-engineering
activities.)

Mark Shanks
shanks@saifr00.cfsat.honeywell.com
All opinions here are mine, not my employers
Newsgroups: comp.software-eng
From: mcp@sei.cmu.edu (Mark Paulk)
Subject: Re: Appeal to SEI (was: Debugging the process)
Keywords: "sei cmm" "sw engineering" "process improvement" "sw quality"
Organization: Software Engineering Institute
Date: Mon, 28 Dec 1992 11:31:48 EST

What we intend the CMM to say is that an organization has to have a good
metrics program in place to achieve level 4.

We do not say that an organization cannot, or should not, have metrics in
place much earlier.  In fact, some specific measurements are called out in the
CMM at each level, although we try not to overspecify what measures or require
an organizational measurement program at level 2.

The belief that the SEI requires that "you have to be level 4 to do
measurement" is a fairly widespread misconception that we have tried
repeatedly to correct.  It's about as explicit in CMM v1.1 as we can say it.

Mark C. Paulk
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA 15213-3890
Newsgroups: comp.software-eng