HDTenEightyP/NetNews huggingface dataset:
From: tcubed@ddsw1.mcs.com (James Hanlon)
Subject: Re: SE going offshore?
Date: Tue, 17 Nov 1992 20:43:45 GMT
Organization: ddsw1.MCS.COM Contributor, Chicago, IL
X-Newsreader: Tin 1.1 PL3

jov@styx.ornl.gov (Judd Jones) writes:
: One of his many claims was that just as the US has virtually lost
: the DRAM industry (global market share down from 100% in 1976 to
: 15% today), it will also lose the software industry.
: 
: His basic argument is that there are plenty of clever, well-trained
: people in developing countries willing to work for less than their
: US-based competitors. One example is the HP software shop in Bombay.
: It will be economically inevitable that this labor-intensive
: industry will be exported to places where labor is cheap.
: 
Yes, it's inevitable, and happening faster than you think. One reason
is the impact of communications technologies on opening up formerly
remote markets. Another is simple: management policy. Large US corporations
seeking international market expansion are regularly offered deals
contingent on their establishing cooperative manufacturing/development
ventures. The economics of exporting tasks to the low-wage areas is
compelling (in fact it's management's fiduciary duty to do so); the obvious
result is a rapid decrease in job advancement possibilities in the higher-wage
location, followed by division closings. This last effect sometimes is lost
on managers until it's too late.

As for language barriers, forget it. There are plenty of smart kids in
Jakarta, Santiago, and Moscow desperate to learn enough English to
qualify for a $500/mo job with a multinational firm. They'll do just
fine with software development, once they get access to the computers.

Jim Hanlon
tcubed@ddsw1.mcs.com
Newsgroups: comp.software-eng
From: rzeplins@fraser.sfu.ca (George Zygmunt Rzeplinski)
Subject: Object Oriented Analysis
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Mon, 23 Nov 1992 23:02:51 GMT

Is Object Oriented Analysis, Design and Programming the future for
Software Engineering?

-- 
==========================================================================
=                              |        Jesus is Lord          +         =
=                              |                            +++++++      =
=                              |                               +         =
Newsgroups: comp.software-eng
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
From: mcgregor@netcom.com (Scott Mcgregor)
Date: Sat, 21 Nov 1992 00:27:51 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)

In article <1992Nov20.181132.25549@news.arc.nasa.gov> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:

>I have read are pretty long on labor intensive design processes

The book I cited is particularly interesting because they look at the
DESIGN process as well, and have some quantitative measurement of that.
It is worth looking at for that reason.

> The
>"crisis" is simply one of failed expectations based on false
> analogies.

I agree entirely.

-- 

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



Newsgroups: comp.software-eng
From: dougank@wl.aecl.ca
Subject: RE: Looking for RADC papers
Organization: AECL RESEARCH
Date: Fri, 20 Nov 1992 22:06:50 GMT

Chris,
   Those RADC "papers" are only available in microfiche form.  I have read
the three volumes to which you refer, and I currently have RADC-TR-83-175
(3 vol.) "Software Quality Measurement for Distributed Systems."
   My personal opinion is that you will not find them of much use.  I am
assuming you are interested in software metrics.  Also, RADC-TR-85-37 (3 vol.)
"Specifications of Software Quality Attributes" would most like be the info
you are after (especially Volume III).  TR-85-37/III contains factors/criteria
that RADC developed, and also a 100 page checklist (!!!) used for reviewing
software documentation and source code.  From the checklist the RADC was able
to obtain measures of quality.  I personally would not use such a comprehensive
checklist (it could be quite a burden for those asked to fill them out).
   Anyway, back to your problem.  Try to obtain these documents from your
national library -- that the how I got my hands on them.

Ken Dougan
dougank@wl.aecl.ca

Newsgroups: comp.software-eng
From: bryk@IDA.ORG (Bill Brykczynski)
Subject: Spec example
Organization: IDA, Alexandria, VA
X-Newsreader: Tin 1.1 PL4
Date: Mon, 23 Nov 92 20:23:15 GMT

(Note:  I am posting this for a colleague)

Several CASE systems are advertising explicit support for software test 
activities (for example, test scenario generation during the requirements 
specification phase). I am looking for an example case study that can be
used to demonstrate (and compare) such test capabilities for several CASE
systems.  The example should cover both requirements specification and
design phases and, ideally, include Ada code. Also ideally, I would like an
example from a real development effort.

Please let me know if you have such as example to hand.

Christine Youngblut
Institute for Defense Analyses
youngblut@ida.org
(703) 845-6636
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Test Completion Criteria
Date: 20 Nov 92 10:27:10 EST

In article <1efq9dINN5ps@griffin.orpington.sgp.slb.com>, monteiro@edda.nl (Francisco Monteiro,207) writes:
> One of the most difficult question to answer when testing a program is 
> determining when to stop, since there is no way of knowing if the error 
> just detected is the last remaining error. What criteria is the common for 
> industry, as the ones i know of are both meaningless and counterproductive.

Be interested in the ones you ahve seen.

> If anybody has experiance please reply to net.

Sure.  Testing is done when I say it is done.  (8:-))

Testing is done when: 
The cost of fixing the last error os greater than the
cost of creating a new release, testing, releasing, and installing it.

The measured number of errors equals the historically predicted number of erros
for the type of application under development.

Coverages agreed to in advance for unit, integration, functional, and systems
testing are all achieved, while the bumber of errors detected remains below the
cost/benefit line of resolution before release.

You tested what you agreed to test.

etc.

There are more that others will no doubt be adding to this list.

George Kambic
sd
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Test Completion Criteria
Date: 20 Nov 92 16:03:12 EST

In article <MARTINC.92Nov20132339@grover.cs.unc.edu>, martinc@grover.cs.unc.edu (Charles R. Martin) writes:
> 	<1992Nov20.102710.9319@iccgcc.decnet.ab.com>
> In article <1992Nov20.102710.9319@iccgcc.decnet.ab.com> kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) writes:
>    Testing is done when:    You tested what you agreed to test.
> 
> Actually, I think this is the canonical answer, which I propose we name
> Kambic's Law.  The amount and kind of testing ought to be part of the
> specification process (along with specific tests); testing is therefore
> done when the specification of the tests is fulfilled.

Gulp!  Actually this is something testers know intrinsically but which is very
seldom agreed to by other parts of the development organization.  It is
crucial and very important (as well as satisfying Satchel Paige's rules for
life for software test engineers) for the testers to establish the contract for
testing *before* the testing starts.  Then the testing is done when the
contract is satisfied.  This is not to say there will not be more testing. 
This removed what I call the delta-function effect on testing near the end of
a product development.

George Kambic
sd

Newsgroups: comp.software-eng
From: jcardow@afit.af.mil (James E. Cardow)
Subject: Hypothetical Process Question
Keywords: Level-5, process
Organization: Air Force Institute of Technology
Date: Fri, 20 Nov 1992 13:29:25 GMT

During last weeks IEEE Conference on Software Maintenance Ted Keller
presented a keynote speech on the IBM Federal Systems support on the
shuttle (an excellent presentation).  It would appear that this section
of this organization is one of few, if not the only organization
approaching the "optimized" level of SEI Maturity.  (I'm purposely
avoiding using numbers since that is creating new problems.)  After
hearing about this organization and realizing that an optimized-level
organization might really exist I started wondering:

	Given a clean slate (new organization), sufficient resources,
	and a management (customer) mandate; could you create an
	optimized-level organization?  a managed-level organization? or
	atleast a defined-level organization?

Now, before the fur starts flying about moving up in levels taking years
and management commitment, etc., I agree.  I understand and truely
support the need for evolutionary changes in improvement.  That is not
what I'm asking.  I'm asking, if once I see and observe one of these
criters can I form one from scratch?  I also know that it is not common
to start an organization from scratch, but it does happen.  New
maintenance organizations are formed, but they live with the results
(mistakes) of development.  New products are created, but they generally
pickup the traits of some previous effort.  

Think about it, then let me know why it is possible, or impossible.

_________________________________________________________________________
I'm trying very hard not to use the more convienent SEI numbers for
levels (1-5) because it is becoming increasingly clear that managers and
many technical people are setting goals of being level-3.  A worth while
goal.  However, when questioned, they seem to have little understanding
of what that means (buzz-word status).  I'm hoping that the terms
"defined," "managed" etc. will have more meaning.  


	Jim Cardow, Capt, USAF
	Air Force Institute of Technology
	Instructor in Software Engineering
	Professional Continuing Education Program

		Office: Bld-125, Room-2417
		Phone: (513) 476-4500, DSN 986-4500
		E-mail:  jcardow@afit.af.mil
		Mail:	AFIT/LSS
			Wright Patterson AFB, OH 45433-6583
From: ch981@cleveland.Freenet.Edu (Tony Alicea)
Newsgroups: comp.software-eng
Subject: Looking For C lang --> PDL Convertor
Date: 16 Nov 1992 21:43:57 GMT
Organization: Aeronautical Radio, Annapolis
Reply-To: talicea@arinc.com (Tony Alicea)
NNTP-Posting-Host: hela.ins.cwru.edu


	I am looking for a product that will take a "c" language code
source program and generate PDL from it. Does anybody know of such
animal?

	Please "Reply-To:" above e-mail address.

	Thanks!

Tony Alicea
talicea@arinc.com
From: torcy@bangalore.esf.de (Eric de Torcy)
Newsgroups: comp.software-eng
Subject: CASE communique & CASE alliance ?
Date: 20 Nov 92 09:24:24 GMT
Reply-To: torcy@bangalore.esf.de (Eric de Torcy)
Organization: ESF Headquarters, Berlin, FRG

Can anybody send me information on CASE communique & CASE  interoperability alliance?

Please reply by e-mail, and I will summarize if there is enough interest.


						Eric

---
********************************************************************
**  Eric de Torcy                                                 **
**                                                                **
**  ESF Headquarters                  Tel :     +49+30-820 903 22 **
**  Hohenzollerndamm 152              Fax :     +49+30-820 903 19 **
**  D- 1000 Berlin 33                 Internet: eric@esf.de       **
**  Germany            	                                          **
********************************************************************
Newsgroups: comp.software-eng
From: geoff@flash.bellcore.com (Geoffrey Clemm)
Subject: Re: Need list of Config. Mgt. software
Organization: Bellcore
Date: 23 Nov 92 17:51:25

In article <7280002@hpfcso.FC.HP.COM> ync@hpfcso.FC.HP.COM (Alan Chen) writes:

   From: ync@hpfcso.FC.HP.COM (Alan Chen)
   Newsgroups: comp.software-eng

   Hi:
     Why don't you try HP's DSEE.
     Good luck.

It's rather silly to call it "HP's" DSEE system, when it was developed
at Apollo, and only runs on Apollo machines, just because HP happened
to buy Apollo.  Let's give credit where credit is due.

More importantly, Dave LeBlang and the other developers of DSEE left
Apollo after it was purchased by HP, and formed a new company, Atria,
to build and sell what should have been the next generation of DSEE
(if HP had the software foresight to not have driven them away :-).
Atria's product is called ClearCase, and it runs currently on Sun,
HP, and SGI machines (Atria was on the original posters list).

Cheers,

Geoff
--
geoff@bellcore.com
Newsgroups: comp.software-eng
From: terry@asl.dl.nec.com
Subject: Hey Congress, Let's Zero Out SCE Funding!
Originator: terry@aslws01
Organization: Me speaking for myself.
Date: Fri, 20 Nov 1992 16:22:36 GMT

In article <1992Nov19.192618.22594@pony.Ingres.COM>
daveb@lotus (Dave Brower, DBMS hack, [510] 748-3418) writes:

> The cynical might consider the software immaturity model as a morale
> crutch for organizations on the lower levels of the SEI maturity
> model.  Now there's somewhere lower to (not) be:

The even more cynical such as myself might observe that after five or
six years of who knows how much expense both to the taxpayers and to
private industry that NO organization has ever reached anything above
Level 3.  My source?  Bill Curtis at a luncheon.  The current watch
phrase is that there are only "organizations with characteristics of
Levels 4 and 5," whatever that means.

This is a substantial pulling back from all the earlier informal baloney
that was giving the *impression* that there were Level 4 and 5 organizations,
when in fact there are none.  And as I've mentioned before here, some of
projects (projects, not organizations) with Level 5 ratings are actually
using a *lot* of old code that was developed under Level 1 policies, so
that they have a strong "code maintenance" (vs. new development) flavor.

Also, the same cynic might observe that Dave Card's description of the
amazingly inconsistent results of the (now secret again) SCE program
in the September issue of IEEE Software sounded more like a description
of poorly planned Marx Brothers film than the culmination of millions
of dollars of money and effort the DoD has been dumping into this effort
to "grade" potential DoD contractors.


Let's put it more bluntly:  I say that SCE is a expensive, miserable
failure that needs to be put out of its misery.  Will the new congress
and/or administration please either cut out the funding for this charade,
or at least start doing some serious policing of where *their* "contract
money" is going?

What's good for the goose is good for the gander -- and I say that if SEI
has taken it upon themselves to try to evaluate the industry with this
slipshod set of procedures, then by golly, someone in the right congress-
ional appropriations groups ought to return them the favor and do a really
blistering analysis of how effective SEI in general and SCE in particular
have been at doing *their* job right after five or six years of floundering.

Please keep in mind that I happen to be one of the folks who *does* think
our software development industry needs certification.  Indeed, that is
precisely why I find the SEI effort so annoying.  While they are getting
funded mostly by harping on a very real need, to date don't seem to be
doing a very good job of delivering what they promised.

(A *real* cynic might even note that SEI does seem to be extraordinarily
effective at making sure nothing they do damages the little mini-consulting
industry that seems to have grown up around their five-level model and
rather arbitrary full-factory-model "maturity" assumptions...  But I'm not
*that* cynical. (Are you?)   :-)

				Cheers,
				Terry Bollinger
				(Speaking only for myself)
From: bagwill@swe.ncsl.nist.gov (Bob Bagwill)
Newsgroups: comp.software-eng
Subject: Re: SE going offshore?
Date: 17 Nov 92 14:33:42 GMT
X-Newsreader: TIN [version 1.1 PL6]

Judd Jones (jov@styx.ornl.gov) wrote:
: (I note that even a 20:1 productivity differential cannot overcome
: a greater than 20:1 cost differential, so greater per capita domestic
: productivity may not be terribly relevant.)

Here's something to consider:

Q: What's the most effective method for catching design and
   coding problems?

A: Group code reviews.

Q: What's the most [upfront] expensive method for catching design
   and coding problems?

A: Group code reviews.

Q: What technique is easiest to apply if you have skilled,
   highly-motivated low-paid workers with little hardware or
   software support?

A: Group code reviews.

A U.S. company could hire a bunch of local marketeers and
superprogrammers to do the design and then group review the code with
cheaper non-local labor until it's six sigma.

--
Bob Bagwill
bagwill@swe.ncsl.nist.gov
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Survey - Research
Date: 20 Nov 92 10:38:47 EST

In article <1992Nov19.031718.18494@nmt.edu>, drkhoe@nmt.edu (ONID) writes:
>                               QUESTIONNAIRE
>                          TO EXAMINE CAFFEINE USE
>                         AMONG COMPUTER SCIENTISTS
>                          AND ELECTRICAL ENGINEERS

I'm sorry.  This is company confidential information.  I cannot answer this
questionnairre.

George Kambic
sd
From: martinc@hatteras.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: Productivity vs. Complexity
Date: 19 Nov 92 19:20:16 GMT
Distribution: na
Organization: UNC Department of Computer Science
In-reply-to: travis@eecs.nwu.edu's message of 18 Nov 92 23:52:35 GMT

In article <1992Nov18.235235.423@eecs.nwu.edu> travis@eecs.nwu.edu (Travis Marlatte) writes:

   If we look at software as an extension of hardware (which it is), then
   the time it takes to design a software system of X complexity should take
   as long as designing a hardware system of X complexity.

Actually, hardware is just an extension of software, but I agree with
you otherwise.

   We seem to look at the time it takes to develop software and wonder why
   it takes so long - looking for ways to improve productivity.
   At the same time, if we would consider using hardware
   to solve the same problem, there would be alot of head nodding and
   people saying, "It will never work!"

I agree with you *very* much: if you look, e.g., at the Chaitin
complexity of the function computed by hardware, it is often *very* much
smaller than the same function computed by software.  I suspect very
strongly that this accounts for many things in the s/w vs h/w disputes
that come around every so often.

--
		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: miket@hermes.tcs.com (Michael Turner nmscore Assoc.)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Teknekron Communications Inc.
Date: Wed, 18 Nov 1992 02:38:32 GMT

In article <1992Nov17.144351.8384@saifr00.cfsat.honeywell.com> shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
>In article <1992Nov16.090509.22236@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
>>
>>In other words, the manager has to have an appreciation of the `useful
>>art' of programming!  Which means they have to be good programmers themselves.
>>--                                     ^^^^
>
>I strongly disagree. With no desire to cast aspersions upon the value of
>good programers, in my experience the abilities required of a good
>manager are completely different than those required by a good programmer.
>In too many cases I've seen excellent engineers promoted into management
>positions where 1) They were unhappy and frustrated, and 2) Their
>management ability sucked the shit out of dead cats. 

"Completely different" doesn't mean "completely incompatible."  But it
does seem to work out that way.  In my not-so-humble opinion, I can be
a good programmer.  In my (so far) single stab at management, if my ability
in that area didn't get quite to the coprophilic stage, it was largely
because I recognized that we needed to get a better manager hired soon,
or my project was going to get into even more trouble.

>It certainly would be IDEAL to find a good programmer who would also
>make a good manager, but IMHO, a good manager doesn't NEED to be/have been
>a good programmer. IMHO.

The best project I ever worked on was run by a guy who was a pretty 
good programmer (coming originally from EE, by the way), as well as
a pretty good, down-to-earth manager.  But that's one project out of a
dozen or so, by now.  I'm beginning to despair of seeing anything
similar happen between now and retirement.
---
Michael Turner
miket@tcs.com
From: zaphod@cs.mcgill.ca (Morris BERNSTEIN)
Newsgroups: comp.software-eng
Subject: Teaching Software Engineering
Summary: What to assign as term project?
Date: 23 Nov 92 22:52:23 GMT
Organization: SOCS - Mcgill University, Montreal, Canada


After working as a professional software developer for a number of
years, I've developed a deep understanding of software engineering.
I've continued my reading, so I understand both how it should be done
and how it is actually done, and I've developed some humble insights
into why it tends not to be done the way it should be done.

I've been given the opportunity to teach a software engineering course
in January.  It's a night course in the continuing education
department for a certificate (something less that a Bachelor's degree).

I have more than enough to talk about, but I'm wondering about the
term project.  Traditionally in this sort of course, you divide the
class into groups and each member is responsible for some particular
facet.  i.e. structure it like a real software engineering project.

The main benefit is that it does give students some experience in
group work, which is essential in real engineering projects.

I'm concerned that this will only in give each group member a feel for
a single facet of software development.  The purpose of the course is
not for the students to *do* software engineering, but to *understand*
SE.

I'm also tempted to make the simulation more real by changing the
requirements in mid-stream.  I won't do it because it is mean and
unfair, but it's typical of what really happens.

Ironically, academic experience is often cited as one of the reasons
why software reuse has not (yet) lived up to its potential:
	- constraints against plagiarism (yes, I looked up the
	  spelling)
	- tendency to work on problems from first principles


So, does anyone have any suggestions for a term project?  I don't
particularly want to overwhelm the students with large amounts of
work, and I don't want to require particularly fancy programming
techniques, but I do what to give them the flavour of the process.


Morris
Newsgroups: comp.software-eng
From: tada@athena.mit.edu (Michael J Zehr)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Massachusetts Institute of Technology
Date: Mon, 16 Nov 1992 19:50:49 GMT


Remember a few weeks ago the big discussion about Quality (read
Predictabilty)? 

It seems like part of the problem is that software engineers would like
to increase productivity, but software managers would like to increse
predictability.  

Are these opposing goals? Probably somewhat -- predictability generally
requires more tracking and measuring.

-michael j zehr

PS. Research topic: does disbling netnews decrease or increase
productivity?  short-term vs. long-term?  *grin*y
Newsgroups: comp.software-eng