HDTenEightyP/NetNews huggingface dataset:
From: rms@miles.com (Rob Schultz)
Subject: SE Moving Offshore
Organization: Miles Inc., Diagnostics Division, Elkhart, IN
Date: Wed, 18 Nov 1992 20:59:19 GMT


I just received my copy of the November 1992 CASE Trends magazine.  In it,
Boris Beizer (world-renouned testing expert) has an article called "Losing 
It!".

In this article, there is a section about language barriers with respect to
software being written outside the US.  I have reproduced that paragraph
here without permission.  (Note that I also heard similar statements from 
Boris when he was here consulting a few weeks ago, and I also read an
advance copy of this paper some months ago.)

======Start Quote======

Language Barriers
There are no technically significant
language barriers.  In modern software,
the language the user sees is defined by
tables instead of written into the code.
The same applied to cultural peculiari-
ties of software.  The difference be-
tween a French and English word pro-
cessor, say, is handled by loading the
appropriate tables.  Whatever the na-
tive language of the software's origina-
tors might be, with proper design,
changing from a Japanese language
product, say, to an English product is a
matter of stuffing the right tables.  As
for instruction manuals, and prompts,
you get all the needed nuances of the
target language by hiring bilingual
translators.  This language barrier non-
sense makes about as much sense for
software as it does for TV sets, VCR's,
semiconductors, and automobiles.
Laugh about clumsy English now and
then, if you will, but who's laughing at
the bank?

======End Quote======


In my company, we develop medical screening devices.  Some of our
products are designed to be sold in a worldwide market, including
Japan and Europe.  If there is a language barrier preventing the
development of software-based products in Japan, Europe, or India,
then shouldn't there also be a similar barrier preventing us from
selling our products offshore?  (Note: There isn't, for my company
at least.)  Or are we just that much better at communicating than
our offshore competitors?  Perhaps we just take the extra time to
learn more about their languages and cultures than they take to learn
about ours?  Not!  Look at Europe, for example.  Virtually all 
Europeans are conversant in several languages.  Most US citizens
speak only American English.  And speak it poorly, at that!  Japan,
Singapore, and India are similar to Europe, in that most of their
citizens speak several languages, one of which is likely to be English.
-- 
Rob Schultz   At Home:                        At work:          +1 219 262 7206
                      rms@andria.miles.com                        rms@miles.com
      {uunet|iuvax}!gator!miles!andria!rms        {uunet|iuvax}!gator!miles!rms
Newsgroups: comp.software-eng
From: ilanc@mot.com (Ilan Cohen)
Subject: Re: Looking for RADC papers
Reply-To: ilanc@mcil.comm.mot.com
Organization: Motorola Communications Israel Ltd., Tel Aviv
Date: Sun, 22 Nov 1992 07:33:09 GMT

In article <1992Nov20.101935.14119@uklirb.informatik.uni-kl.de> lott@bogner.informatik.uni-kl.de (Christopher Lott AGSE) writes:
>Hello,
>
>Please pardon the blanket appeal.  I am looking for technical
>reports published by the Rome Air Development Center of Griffis
>Air Force Base, NY, USA.  I wrote them about 6 weeks ago to ask
>about availability of their TRs and I have basically given up hope
>of receiving an answer.
>
>I know this is a long shot, made considerably worse by the age of
>this thing, but here is the citation anyhow:
>
>J. A. McCall, P. Richards, and G. Walters.
>"Factor in Software Quality."
>Technical Report RADC-TR-77-369.
>Rome Air Development Center, Griffis AFB, NY.
>1977.
>
>
>If someone has a hardcopy of this or any later work, I'd be very
>interested to negotiate copying and shipping costs, etc.
>
>Thanks in advance.
>
>chris...
>-- 
>Christopher Lott    lott@informatik.uni-kl.de   +49 (631) 205-3334, -3331 Fax
>Post: FB Informatik - Bau 57, Universitaet KL, W-6750 Kaiserslautern, Germany

Back in March 86, I attended a presentation of Ron Willis of Hughes
Aircraft, at an Conference on Software Quality and Productivity.

He mentioned the work done at RADC, and described a "Modified"
approach. Back at that time, I wanted to get hold of either
publications, and I can't recall why I havn't done so.

Does anybody have more details on the Hughes approach? Is it available?

Thanks in advance

Ilan

-- 
[ Ilan Cohen                            | SQA & Process Improvement Manager  ]
[ INTERNET..ilanc@mcil.comm.mot.com     | System Software Development        ]
[ PHONE. . . . .++(972)3565-8714        | Motorola Communication Israel Ltd. ]
[ FAX. . . . . .++(972)3565-8754        | 3 Kremenitski St, Tel-Aviv, Israel ]
From: al@nmt.edu (Al Stavely)
Newsgroups: comp.software-eng
Subject: Re: Software Reliability - how to calculate?
Keywords: software reliability reference calculation
Date: 17 Nov 92 22:57:51 GMT
Article-I.D.: nmt.1992Nov17.225751.4475
Distribution: na
Organization: New Mexico Tech, USA

In article <1992Nov17.182119.13475@clpd.kodak.com> figueroa@serum.kodak.com writes:
>
>I told her point blank that I was not aware of any process used to
>calculate software reliability.  Is there one?  I would be very
>interested to know how the reliability is measured in an application
>programming environment as compared to how it is determined for a
>device driver, for example.

You might try:

P. Allen Currit, Michael Dyer, and Harlan D. Mills
Certifying the Reliability of Software
IEEE Transactions on Software Engineering, vol. SE-12, no. 1
		(January 1986), pp. 3-11.

It gives a method for estimating a program's mean time to failure from the
results of statistical testing.  I have no direct experience with this myself,
but this is part of the Cleanroom method for which IBM reports an impressive
record of success.

-- 

	- Allan Stavely, New Mexico Tech, USA
From: chrisf@nms.otca.oz.au (Christopher Fraser)
Newsgroups: comp.software-eng
Subject: Graphical Object Design Tools (OMT, Booch..)
Keywords: object oriented design tools
Date: 20 Nov 92 11:12:25 GMT

I've been looking at James Rumhaugh's OMT design methodology over the past few
days (well, actually, attending a seminar he's been presenting), and was
wondering if anyone would like to share their experiences with actually
applying a methodology like OMT or Booch (even if you just used the object
notations to document your own design methodology). I'm particularly interested
if you used a graphical design tool.

My general impression of OMT itself was fairly positive. The object model 
basicly a sanitised version of ER techniques, with additional notations like
inheritance (I though his concept of information paths was especially useful).
The Dynamic model was based on state transition diagrams, with some nice
techniques for modularising the schema. The functional model was, well,
functional decomposition and was presented as something that could feed back
into the object model (Rumhaugh talked a lot about iterative design ... which
was comforting).

Methodology aside I though the actual OMT notion itself captures a lot of design
information in a fairly succinctly, formal form. However, the thought of manually
maintaining the diagrams didn't particularly appeal to me; hence this
post. (Much more appealing was the thought of design tools developing into tools
which could actually help the developer track design constraints, like Rhumbah's
information paths).

I had a look at the Rational tool, Rose, and wasn't especially impressed.
It's a nice drawing tool (but then, so is MacPaint!) using Booch's
constructs. Mostly, it seemed lacking in the ways it could present the actual
schema information you had painstaking entered; you couldn't filter out
information on the schema, you couldn't merge them together and queries
on the relationships an object was involved in only returned a textual list.
(I probably shouldn't really comment, since I'm not especially familiar
with building them, but schemas built using Booch's notation seem more
cluttered and less design information dense than the equivalent OMT
representation. The Booch notation certainly captures a lot more implementation
semantics. Opinions?).

I was also told Ratonal were working on tools to reverse-engineer a Booch
schema for C++ code. They also demonstrated a beta version of a tool for
generating code stubs (which seemed lacking in the required configurability).
Does anyone else know of work being done in these areas?

Cheers,
--
Christopher Fraser      "First time surrealists are often confused by the
chrisf@nms.otca.oz.au    similarities between fish and telephones"
Newsgroups: comp.software-eng
From: daveb@Ingres.COM (Dave Brower, DBMS hack, [510] 748-3418)
Subject: The "immaturity" model
Originator: daveb@lotus
Reply-To: daveb@lotus (Dave Brower, DBMS hack, [510] 748-3418)
Organization: Ingres, an ASK Company
Date: 19 Nov 92 19:26:17 GMT

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:

   "Hey, we made it from foolish to initial.  We used to be lunatics!"

It instantly makes most on-going concerns mid-pack rather malingerers
on the bottom.

This is as reassuring as "I'm not a crook," "Read my lips," and "I
didn't inhale."

-dB
-- 
Windows/NT - the VMS of the 90s

Newsgroups: comp.software-eng
From: saradhi@iti.gov.sg (Motamarri Saradhi)
Subject: Software Market Size in $$$
Keywords: Software, Market, Dollars...
Reply-To: saradhi@iti.gov.sg
Organization: Information Technology Institute, National Computer Board, S'pore
Date: Fri, 20 Nov 1992 04:16:15 GMT

Dear colleagues,

Anyone is having statistics about the annual expenditure on software

worldwide, or atleast, USA? Would like to hear any subgroupings like

expenditure on 
   
   - new developments

   - maintenance (of existing code)

   - tools

   - educationa and training.

Thanks in advance...

--- M Saradhi.

---
+-------------------------------------------------------------------------+
| Motamarri Saradhi, Life Mem ISCA;Mem ACM |Office : (65)772 0931         |
| Information Technology Institute         |Res    : (65)774 3805         |
| National Computer Board                  |Fax    : (65)777 3043         |
| 71 Science Park Drive                    |Bitnet : Saradhi@itivax.bitnet|
| Singapore - 0511.                        |Int'net: saradhi@iti.gov.sg   |
| ------------------------------------------------------------------------|
| "Man is guided by his stomach. He walks. His stomach goes first.        |
|  Then his head. Have you not seen that? It takes ages to make the       |
|  head go first."                                   - Swami Vivekananda  |
+-------------------------------------------------------------------------+
From: monteiro@edda.nl (Francisco Monteiro,207)
Newsgroups: comp.software-eng
Subject: Test Completion Criteria
Date: 19 Nov 92 10:29:01 GMT
Reply-To: monteiro@edda.nl
Organization: Geco Prakla.
NNTP-Posting-Host: edda.delft.sgp.slb.com

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.
If anybody has experiance please reply to net.
Regards
Francisco Monteiro
Newsgroups: comp.software-eng
From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: Estimating Large S/W Development Efforts
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Distribution: usa
Date: Thu, 19 Nov 1992 04:24:50 GMT

In article <1992Nov18.173255.3827@den.mmc.com> carnahan@possum.den.mmc.com (Rich Carnahan) writes:
>Anyone had any *real* success estimating large (>1M LOC) s/W development
>efforts?  I'm interested in hearing about any creative (sic) techniques.
>

First of all, I would point out that *real success* in estimating
large software projects should be measured in the same way that large
civil engineering projects are.  Such projects often are successfully
estimated to withing 50% of the mean cost and times.  But large civil
engineering companies build in plenty of safety error to ensure that
the projcts will still be profitable in a worst case scenario.
Software people often fail to do the latter even though they might
successfully estimate means and variances just as well.

Second of all, the collection of projects that I have looked at
suggests that the very best predictor of project duration is the
previous project done predominantly by the same organization,
management or individuals.  If an organization has never done a
project of that size before, historical evidence suggests that they
won't finish it this time either--the project will be cancelled before
it is completed.  The primary reason this seems to be so is that
projects are more constrained by the EXPECTATIONS of the participants,
which in turn are molded by past experience, than they are by things
like lines of code, functionality or complexity.

The evidence seems to show that the only way to "break the cycle of
expectations" is to bring in a new manager or team.  And this is only
successful at a greater risk of conflict between the unchanged parts
of the organization.  In other words, bringing in a new project
manager might allow the organization to do a longer project that such
a manager has experience with, but the organization does not.  But it
may set that manager in conflict with more senior managers who fear
that such a longer project can never succeed.  And it may set that
project manager at odds with senior developers who work for the
manager but who suspect that senior management will eventually pull
the plug--and so they do things the old way as a personal safety
valve.  If the project manager successfully avoids these twin shoals
the project is most likely to complete on a schedule like their past
projects. Otherwise the most likely result is cancellation when the
project exceeds the organizations historical norms.

If anyone has data which illustrates different results, I would like
to see it.

-- 

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: firth@sei.cmu.edu (Robert Firth)
Subject: Re: SE going offshore?
Organization: Software Engineering Institute
Date: Mon, 16 Nov 1992 13:38:43 GMT

In article <2B05650C.29402@ics.uci.edu> ejw@siam.ics.uci.edu (Jim Whitehead) writes:

>I disagree.  Many software faults can be traced either to faulty
>specifications, or incorrect interpretation of specifications.  For
>the immediate future, the largest market for software will be the
>United States.  This means that either the problem description or
>the specification or both will be expressed in English.  With
>programmers working on these projects whose primary language is
>not English (the case with off-shore programming teams) the possibility
>for specification errors is very high, IMHO.

Hate to tell you this, but in my experience the average graduate
student from India speaks better english than the average US
graduate.  One reason is that the main language of higher education
in India, and in most of the Commonwealth of Nations, is english,
and it is taught both exactingly and well.
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: Test Completion Criteria
Date: 20 Nov 92 18:23:39 GMT
	<1992Nov20.102710.9319@iccgcc.decnet.ab.com>
Organization: UNC Department of Computer Science
In-reply-to: kambic@iccgcc.decnet.ab.com's message of 20 Nov 92 15:27:10 GMT

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.

--
		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: lee@torrid.ogo.dec.com (wooga wooga wooga!)
Subject: Re: Will we keep ignoring this productivity issue?
Reply-To: lee@torrid.ogo.dec.com 
Organization: Digital Equipment Corporation
Date: Wed, 18 Nov 1992 20:32:18 GMT

In article <Bxvrr4.G60@cs.uiuc.edu>, johnson@cs.uiuc.edu (Ralph Johnson) writes:
~
~You are both half right.  Managers have to have an appreciation of
~programming, but they don't have to be good programmers themselves.
~They need to be able to read two programs and tell which is easier
~to understand, which is faster, and which is more robust.  On the
~other hand, a manager needs a whole bunch of abilities that a programmer
~won't have.  Being a good manager is *harder* than being a good programmer.
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
~If you are going to manage programmers than you have to know something
~about programmers (note: not be as good as them, just be able to tell
~who is doing a good job and have some idea of what the people who
~are having troubles need to do to improve).  Good managers must be
~able to deal with people, and many good programmers are not good at
~this.  But this doesn't excuse managers from understanding what they
~are managing.  The idea that any good manager can manage anything is wrong.


	I don't think being a good manager is more difficult than being
	a good programmer, even if the two are directly comparable, which
	seems doubtful.  Different skill sets are involved, certainly, but
	in my experience, exceptional managers are as rare as exceptional
	programmers.

--

   *A* 


Andy Lee
lee@n2itiv.enet.dec.com   or   ...!decwrl!n2itiv.enet.dec.com!lee
lee@torrid.ogo.dec.com    or   ...!decwrl!torrid.ogo.dec.com!lee
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 20 Nov 92 10:35:53 EST

In article <1992Nov19.182839.20445@ultra.com>, jerbil@ultra.com (Joseph Beckenbach {Adapter Software Release Engr}) writes:
> 	In his article, ghm@sserve.cc.adfa.oz.au (Geoff Miller) writes:
[...]
 You can teach someone to play the trumpet  -  can
>>you teach them to improvise like Miles Davis?
> 
> 	The answer is "yes", though by that time you're already high up in
> that top 10% -- and it'd be time to learn directly from Miles Davis.  Exactly
> as you point out later, practice and hard work are necessary but not sufficient
> for this "greatness".  This is as true in our fields of endeavor as for any of
> the others in this world.

Definition time.  Are we copying the improvisations of Miles Davis here?  We
can teach that, but that is not the "genius" we've been talking about.  We need
to be able to teach the thought process  that leads someone to say, hey that
can be improvised upon, nad here is a unique improvisation, not done before,
and I am expanding the envelope of the discipline massively, not marginally. 
Is Davis a paradihm shifter?  I think so.  Cna we teach that?  I think not.

George Kambic
sd

Newsgroups: comp.software-eng
From: marick@cs.uiuc.edu (Brian Marick)
Subject: Re: SUMMARY Tools to aid in testing, and requirements trace-ability.
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Thu, 19 Nov 1992 15:10:20 GMT

magu@se.alcbel.be (Mike Aguilar) writes:

>I'm interested in a tool that lets the user define the requirements
>and from that, generates test specifications.  If there's any other 
>products not mentioned in the list, I'd like to know.

T from Programming Environments Inc, 908-918-0110
SoftTest from Bender and Associates, 415-924-9196

I have no connection with either of these companies.

Brian Marick, marick@cs.uiuc.edu, testing!marick@uunet.uu.net
Testing Foundations:  Consulting, Training, Tools.
Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README
Newsgroups: comp.software-eng
From: mzimmers@netcom.com (Michael Zimmers)
Subject: Re: Is SEI's CMM being used in Anger or just Marketing?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 24 Nov 1992 00:54:41 GMT

In article <722516359snx@johnwuu.canb.auug.org.au> johnw@canb.auug.org.au writes:

>I have seen references to the SEI's Capability Maturity Model with levels
>from Chaotic (1) to Optimised (5).  I have also heard of one large US
>company adopting the CMM as a means to improve their software development.
>
>Is the CMM being used as a serious model on which to base an organisations
>future, or is it being considered for this role?
>
>What acceptance does the CMM have, or are there doubts as to its usefulness?

Some very important people are taking it very seriously.  A year and a
half ago I attended a bidders conference for a $50 million DoD program.
The CBD synopsis hinted that bidders not already at a level 3 would
have a tough time getting the business.  This conference was very
heavily attended (largely by lobbyists, I presume).  The program manager's
boss was the first to speak.  From memory, what he said was essentially,
"People, I've recieved a ton of questions about this 'SEI stuff'.  Some
of you have asked me to delay the requirement, set it aside or reduce
it to a level 2.  I just want to say now that we're going to leave it
as is, and you'd better get used to it, because it's going to become a
way of life."  The room was very quiet as he stepped down.

Since then I've heard stories that leading agencies in the DoD have
adopted similar stances on various contracts.  I don't know that I'd
describe their motives as anger.  It's more that they are profoundly
dissatisfied with their vendors' collective ability to produce and
maintain software on time, under budget, of acceptable quality and in
conformance with the user's requirements.  Firm-fixed price contracts
don't get it done, so they're trying something new.  Despite the jokes
we hear about $600 screwdrivers, when the DoD has to cancel a $2 billion
program because the software doesn't work, people stop laughing.

I've also heard some success stories from firms who voluntarily go
the CMM route.  One story told of a company who saw a 200% return
on investment within two years of moving from a 2 to a 3.  The author
said that the financial savings was secondary to the improvement of morale.

So, while the CMM isn't a panacea, and wasn't intended to be used as
a bidding weapon, it seems to be working for some people and gaining
popularity.
-- 
Michael Zimmers                                    |  Home:  408 996 1984
SoftHelp                                           |  Work:  408 996 1965
Software Solutions for Open Systems                |  Data:  408 996 1974
Newsgroups: comp.software-eng