HDTenEightyP/NetNews huggingface dataset:
From: leisner@wrc.xerox.com ( Marty Leisner)
Subject: Re: Estimating Large S/W Development Efforts
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
X-Newsreader: TIN [version 1.1 PL7]
Distribution: usa
Date: Fri, 20 Nov 1992 02:31:08 GMT

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

If you considering so much code, you should take a good, hard look at what your
doing...gcc is about 150Klines, A Vax BSD Unix kernel is even less...

--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom
From: cbarber@bbn.com (Chris Barber)
Newsgroups: comp.software-eng
Subject: Re: SE going offshore?
Date: 23 Nov 92 16:34:47 GMT
Organization: BBN Systems and Technology, Inc.

In article <2282@sdrc.COM> spsisira@sdrc.COM (spsisira) writes:
>mat@mole-end.matawan.nj.us wrote:
>: It may depend on what you mean by `better.'  If you mean that the Indian
>: student can understand and write Standard English competently, you may be
>: write.  Oral communication also suffers from an `accent barrier' and not
>  ^^^^^| 
>       | I think you are a good example of what is being discussed in
>         this thread. Who taught you English. May be self taught.
>
>: all people who can write Standard English well can be understood by someone
>: from Brooklyn or Atlanta or Lake Woebegone.  Heck, not all people from
>: Brooklyn can be understood in Atlanta!
>
>As far as software development is concerned I do not see how the `accent'
>play any role. Afterall all you read is an ASCII string.         ^^^^^^^|
                     ^^^|                                                |
                        It is ordinarily considered to be bad form to point
                        out grammatical and spelling mistakes in an other's
                        post, but if you are going to do it, make sure that
                        your own is correct!

I hope you are joking. Of course accent is important! As long as you have
to communicate verbally with the people you work with, your accent will be
important. Software developers usually have to be able to communicate
effectively with their fellow engineers, with management, and sometimes with
clients. In the USA, this means that any accent that deviates far enough
from standard "broadcast" english will slow down communications and 
consequently lower productivity.  If someone's accent is different enough, 
it can lead to a situation where other people do not want to talk to the
person because it is too much work to understand him. I know that this is
not fair, but it is also what happens in the real world.


-- 
Christopher Barber
(cbarber@bbn.com)
Newsgroups: comp.software-eng
From: mjl@cs.rit.edu (Michael J Lutz)
Subject: Re: productivity "vs" predictability
Reply-To: mjl@cs.rit.edu
Organization: Rochester Institute of Technology
Date: Mon, 23 Nov 1992 22:03:50 GMT

In article <1992Nov20.065254@eklektix.com>, rcd@raven.eklektix.com (Dick Dunn) writes:
|> tada@athena.mit.edu (Michael J Zehr) brought up an interesting point out of
|> the productivity discussion:
|> >It seems like part of the problem is that software engineers would like
|> >to increase productivity, but software managers would like to increse
|> >predictability.  
|> It's possible to get productivity and predictability completely at odds
|> with one another.  It doesn't happen in the extreme a lot, but there's more
|> of it than there should be:  *One* way to increase predictability is simply
|> to add a measure of make-work to the project--which doesn't serve any real
|> purpose, but makes the variability part of a larger overall number, hence a
|> smaller fraction.

I thought this was the rationale behind DOD 2167A -- swamp the process with
so many documentation demands that any variability in the actual
production phase becomes a small insignificant blip. :-)

Theory of the month:

Documentation that no one needs, no one reads, and no one understands
should not be produced.  The radical idea here is that documents of
any form and at any stage should have a existential purpose beyond
meeting contractual obligations.

-- 

Mike Lutz
Department of Computer Science
Rochester Institute of Technology
Rochester, NY 14623-0887  USA
+1 (716) 475-2472
mjl@cs.rit.edu
Newsgroups: comp.software-eng
From: nigel@wrs.com (Nigel Standing)
Subject: Re: TickIT
Organization: Wind River Systems, Inc.
Date: Tue, 17 Nov 1992 22:57:06 GMT

levy@elaine.ee.und.ac.za (Dave Levy) writes:

>Can anyone tell me anything about TickIT?

I would like to get hold of a copy of "Guide to Software Quality Management
System Construction and Certification using ISO 9001/EN 29001/BS 5750
Part I (1987) dated 28 February 1992, Issue 2.0, which I believe is
published by TickIT. (TickIT is an organization of IT professionals and
is supported by the Department of Trade and Industry and the British
Computer Society).

Does anyone have an address/telephone/fax to order the above book. I have
tried all the local sources and no one has heard of it.

Thanks,

Nigel -

Newsgroups: comp.software-eng
From: jerbil@ultra.com (Joseph Beckenbach {Adapter Software Release Engr})
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Ultra Network Technologies
Date: Thu, 19 Nov 92 18:28:39 GMT

	In his article, ghm@sserve.cc.adfa.oz.au (Geoff Miller) writes:

>Sure, you can teach people to do 
>something well, but there is a difference between "good" and
>"great".  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.

		Joseph Beckenbach
		toolsmith and releaser
-- 
----
Joseph Beckenbach	jerbil@ultra.com	408-922-0600 x246
	(speaking from, but not for, Ultra Network Technologies)
From: johnw@johnwuu.canb.auug.org.au (John Wright)
Newsgroups: comp.software-eng
Subject: Is SEI's CMM being used in Anger or just Marketing?
Distribution: world
Date: Mon, 23 Nov 92 10:59:19 GMT
Organization: Computer Sciences of Australia
Reply-To: johnw@canb.auug.org.au

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?

+========================================================================+
| John Wright                    |   Standard   | Voice : +61 6 249-1871 |
| Computer Sciences of Australia |  Disclaimer  | Fax   : +61 6 253-1259 |
| johnw@canb.auug.org.au         |    Notice    | Locn  : Canberra       |
| 100032.553@compuserve.com      |   Applies    |         Australia      |
+========================================================================+
Newsgroups: comp.software-eng
From: cga66@cbnewse.cb.att.com (patrick.v.kauffold)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: AT&T
Date: Mon, 16 Nov 1992 18:07:18 GMT

> 
> If all managers were capable of doing this then they could implement
> the strategy  of "pick a small team for any job, and the harder the
> problem, the better the people must be".  

Or you can let the leading software engineers pick their own teams,
or at least be intimately involved in team selection.

I personally like the "surgical team" approach put forth, I think, 
by Brooks.

My experience is that (in large organizations) managers tend to
pick teams as if people were plug-compatible.  And then they wonder
why the team can't seem to get it together.

Pat Kauffold
Newsgroups: comp.software-eng
From: cga66@cbnewse.cb.att.com (patrick.v.kauffold)
Subject: certification
Organization: AT&T
Date: Mon, 23 Nov 1992 14:45:37 GMT
Keywords: certification iccp computer professional


Are you a senior programmer, doing internal program design, 
coding, unit testing, module integration, module testing, 
code walk-throughs, code inspections, program maintenance, 
or field support?  Are you interested in professional
advancement, and the advancement of your profession?

If so, you are invited to join the ICCP Procedurel 
Programming Test Advisory Committee. As a member of this
committee, you will advise the ICCP on the technical content 
of the Procedural Programming exam and Study Guide, and 
contribute to the evolution of the certification program.
The subject matter of the exam is not language-specific.

The Institute for Certification of Computer Professionals
(ICCP) has established recognized professional standards 
within the data processing/information technology industry.
To qualify for an ICCP designation, candidates must meet 
professional requirements and pass a combination of 
certification exams.  ICCP exams are offered twice annually 
worldwide. 

There is no geographic limitation on committee membership.  
People who are outside the Chicago area may participate by
e-mail, fax, or teleconference.

ICCP's constituent and affiliate societies include DPMA, ACM,
AIM, ASM, AWC, CIPS, COMMON, FNUG, ICCA, ISTE, BITS, DAMA, 
HKCS, ISCA, and NaSPA.

If you are interested in this opportunity for service to the
profession, and you would like more information, please contact:

Pat Kauffold
AT&T Bell Laboratories
IH 6D-307
2000 N. Naperville Road
Naperville, IL 60566
(708) 713-4726 (Voice)
(708) 979-8451 (FAX)
p_kauffold@attmail.com
Newsgroups: comp.software-eng
From: marick@cs.uiuc.edu (Brian Marick)
Subject: Re: Engineering Software (Was: ...ignoring this productivity issue?)
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Mon, 16 Nov 1992 20:56:30 GMT

rsd@sei.cmu.edu (Richard S D'Ippolito) writes:

>The Air Force Institute of Technology (AFIT) has been incorporating the
>Model-Based Software Development (MBSD) method into the Master of Software
>Engineering Program, and we just presented a joint tutorial with Major Paul

Interesting.  Where can we learn more about it?  Also, could you
describe the method's weaknesses?  What important topics does it fail
to address?  What things do you wish it did better?  What did your
experience with applying it (bravo!) cause you to change or wish you
could change?

I ask these questions because I find the best way to evaluate a
technique is to explore where it doesn't work and why.  I confess it's
also a quick reality check - I've asked this of presenters who could
not think of *anything* wrong with their technique.  In a world
overfull of ideas, those people can be safely ignored.

(On request, I will provide such a list for my own approach to
testing.) 

Brian Marick, marick@cs.uiuc.edu
Testing Foundations:  Consulting, Training, Tools.
Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README

Newsgroups: comp.software-eng
From: mjl@cs.rit.edu (Michael J Lutz)
Subject: Re: Software Reliability - how to calculate?
Keywords: software reliability reference calculation
Reply-To: mjl@cs.rit.edu
Organization: Rochester Institute of Technology
Distribution: na
Date: Mon, 23 Nov 1992 21:49:22 GMT

In article <1992Nov17.225751.4475@nmt.edu>, al@nmt.edu (Al Stavely) writes:
|> 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?
|> 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

Also look at the work of Bev Littlewood (UK), and John Musa, et.al.
at AT&T.  More specifically, check out:

Software Reliability: Measurement, Predication, Application
John Musa, Anthony Iannino, Kazuhira Okumoto
McGraw-Hill, 1987

I also know that a shorter version of the same book, emphasizing
application of the theory rather than the foundations, was issued
in the past couple of years.  Sorry, don't have the reference at hand.

-- 

Mike Lutz
Department of Computer Science
Rochester Institute of Technology
Rochester, NY 14623-0887  USA
+1 (716) 475-2472
mjl@cs.rit.edu
From: baragry@latcs1.lat.OZ.AU (Jason M Baragry)
Newsgroups: comp.software-eng
Subject: Software Designs
Date: 18 Nov 92 05:13:09 GMT
Organization: Comp Sci, La Trobe Uni, Australia


	As part of my research in design techniques I have read a lot about
different design methodologies and tools. I have also read alot about 
the importance of dissemination of design knowledge and reuse. However,
apart from published articles about applications which include design 
information and a description, it is hard to find design examples for 
commercial or large-scale systems.

	I would like to be able to analyse some real-life designs and 
determine some way of representing design knowledge or simply generalize the
design so it can be understood independantly of the application domain it is
used in.

	I realize that it would be hard to obtain designs of commercial systems
but any pointers to papers or addresses I could contact to obtain such 
info would be greatly appreciated.

regards,

Jason Baragry

-------------------------------------------------------------------------------
Jason Baragry.			|	Amdahl Australian Intelligent 
Dept Comp. Sci. & Comp. Eng.,	|		Tools Program
La Trobe University.,		|	baragry@latcs1.lat.oz.au
Bundoora. 3083.			|	Phone:	+61 3 479 1477
Australia.			|	Fax:	+61 3 470 4915
--------------------------------------------------------------------------------
Newsgroups: comp.software-eng
From: ilanc@mot.com (Ilan Cohen)
Subject: Re: TickIT
Reply-To: ilanc@mcil.comm.mot.com
Organization: Motorola Communications Israel Ltd., Tel Aviv
Date: Wed, 18 Nov 1992 06:31:14 GMT

>I would like to get hold of a copy of "Guide to Software Quality Management
>System Construction and Certification using ISO 9001/EN 29001/BS 5750
>Part I (1987) dated 28 February 1992, Issue 2.0, which I believe is
>published by TickIT. (TickIT is an organization of IT professionals and
>is supported by the Department of Trade and Industry and the British
>Computer Society).
>
>Nigel -
>

TickIT Project Office
68 Newman Street
London W1A 4SE
U. K.

Tel +44-71-383-4501
Fax +44-71-383-4771

Regards,
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 ]
Newsgroups: comp.software-eng
From: hasker@cs.uiuc.edu (Rob Hasker)
Subject: Re: SE going offshore?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Tue, 17 Nov 1992 17:24:58 GMT

igb@fulcrum.co.uk (Ian G Batten) writes:

>In article <2B05650C.29402@ics.uci.edu> ejw@siam.ics.uci.edu (Jim Whitehead) writes:
>> 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
>
>Have you seen the standards of English of, for example, the Indian
>professional classes?  Now consider what passes for English from many
>native speakers.
>
>ian

How well the person understands English isn't really the whole issue.
You also need to understand a lot of the culture before you can really
understand the client, and a good understanding of English doesn't
imply a complete understanding of culture.  On an exam, I once had
students draw an entity-relationship diagram which contained "caboose"
and "motor." Hardly any of the Asian students knew what a caboose was
(probably not suprisingly), and most thought "motor" meant "motor car"
(this did surprise me).  I can see such cultural differences causing a
number of problems.  Of course, formal specifications would probably
lessen the number of such problems, so we can't assume that all
software for people in the US has to be written in the West.

Rob
Newsgroups: comp.software-eng
From: TAP@TRZ860 (5.855 Krhenmann Thomas )
Subject: computer disaster
Organization: Alcatel STR AG, Switzerland
Date: Mon, 23 Nov 1992 09:39:00 GMT
X-News-Reader: VMS NEWS 1.24

Is there anyone who is familiar with computer disasters?
Preferably projects over one million US dollars?
Is there a news group which is focussing this subject?
From: drake@Autodesk.COM (Dan Drake)
Newsgroups: comp.software-eng
Subject: Re: The "immaturity" model
Date: 23 Nov 92 17:57:53 GMT
Organization: Autodesk Inc., Sausalito CA, USA

daveb@Ingres.COM (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:
+ 
+    "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.

Yes, but look on the bright side.  With respect to the TOP of the model,
the barely real Level 4 and the purely hypothetical Level 5, the BEST
organizations are no longer just mid-pack, but (percentage-wise) very
close to the top.

--
Dan Drake                 In software, the *complete* design *is* the software!
drake@Autodesk.com        --Hugh Lamaster
Newsgroups: comp.software-eng
From: lott@bogner.informatik.uni-kl.de (Christopher Lott AGSE)
Subject: Looking for RADC papers
Organization: Universitaet Kaiserslautern FB Informatik
Date: Fri, 20 Nov 1992 10:19:35 GMT

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
Newsgroups: comp.software-eng
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: Estimating Large S/W Development Efforts
Organization: eklektix - Boulder, Colorado
Date: Sun, 22 Nov 1992 01:10:19 GMT

jsm@mse.cmu.edu (James S Murphy) writes:
>leisner@wrc.xerox.com ( Marty Leisner) writes:
>|> If you considering so much code, you should take a good, hard look at
>|> what your doing...[size figures for a couple large-ish programs]

>  I'm not sure of your point.  If you are saying that anything larger than
>about 150K to 200K LOC is excessive, I must disagree...

Marty didn't say that 150-200k LOC was excessive; he said that if you're
looking at so much code, you ought to consider whether you really need so
much.

The anticipation that a project will be very large is often self-fulfilling.

>  Applications on the order of >1MLOC are quite common,...
Empirical evidence says this is all too true, but...
>...as well as being
>appropriately sized for the tasks at hand.
This is at best conjecture.  There *are* tasks that require >1MLOC, but
nowhere near as many as the number of tasks which have been afflicted
with >1MLOC "solutions".  One need not search too far to find large appli-
cations which contain an order of magnitude more code than was needed to
do the job.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Simpler is better.
From: swh7333@bcstec.ca.boeing.com (Steve Haffner)
Newsgroups: comp.software-eng
Subject: Re: US v. the World in SE (Statistics)
Keywords: Skeptical
Date: 20 Nov 92 18:52:56 GMT
Organization: Boeing

In article <1992Nov18.211654.15244@miles.com> rms@miles.com (Rob Schultz) writes:
>                    Unofficial estimates of the number of software
>developers and managers as of roughly 1991:  
>
>Country		Developers	Managers	Total
>
>USA		1,693,200	253,980		1,947,180
>USSR		1,445,000	216,750		1,661,750
>India		1,252,500	187,875		1,440,375
>China		  990,000	148,500		1,138,500
>Japan		  850,000	127,500		  977,500
>Germany		  505,600	 75,840		  581,440
>Indonesia	  460,000	 69,000	 	  529,000
>Brazil		  441,000	 66,150		  507,150
>England		  370,550	 55,575		  426,075
>Italy		  365,400	 54,810	 	  420,210

I was curious about the ratio of developers to managers. 
Imagine my surprise to find that all of the above countries
have exactly the same ratio: 6.667 to 1!

Which of the above numbers do you suppose were made up?


---
Steve Haffner
Seattle, Washington








Newsgroups: comp.software-eng,misc.legal.computing,misc.int-property
From: Gerry_Furseth@mindlink.bc.ca (Gerry Furseth)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: MIND LINK! - British Columbia, Canada
Date: Wed, 18 Nov 1992 05:06:46 GMT

|I recall my first software class.  Here is Fortran syntax; write a
program.
|Not much training.  Not much experience. Compare that to the first _TWO_
|years of hardware.

My experience in the land of software has been entirely similar.  I have
found, though, that my EE courses come second to thermodynamics (but still
ahead of computing courses).  For those of you who skipped thermo in favour
of more relevant courses, the basic precept is that every analysis begins
with:
1: what is the best possible behaviour of this system?
2: what is the worst possible behaviour of this system?
3: how near to the best case can I realistically expect?
4: what information do I need to solve this problem?

The last question seems obvious and unnecessary at first glance.  But, after
three semesters, my point of view had changed.  As an example, an essential
piece of information in evaluating the efficiency of any fuel powered engine
is the ambient air temperature.  Not always the first thing that leaps to
mind.

The thermodynamic analysis ends with: what assumptions are hidden in my
solution?
For a computing example this time, "I assume that no one will want a file
larger than 1Gb."  This might strike a chord with DOS developers: "I assume
that a single-user operating system need not be re-entrant."

The level of discussion on this topic has been consistently high; perhaps
someone can restate what I mean more compactly and argue for or against.

Aphorism: If you can't write a testing plan from your design, the resulting
code will be unreliable.
Collorary: If you write and execute a testing plan for all your designs, you
are not working in software.

All (my) opinions are no more reliable than the author.
Gerry.
Newsgroups: comp.software-eng