HDTenEightyP/NetNews huggingface dataset:
From: alh@tekig1.PEN.TEK.COM (Al Hooton)
Newsgroups: comp.software-eng
Subject: Dependency management tools?
Date: 18 Nov 92 20:53:25 GMT
Organization: Tektronix, Inc., Beaverton,  OR.


	Haven't had much luck looking around on my own, so I thought I'd
ask the net for a little help...

	I'm looking for some kind of a package to do generalized
dependency management.  It doesn't have to be real fancy, but I think the
following would be the major components of the package:

- Able to enter simple dependencies: X is affected by Y, X affects Y.

- Some kind of simple presentation method for displaying cascading
  dependencies (X affects Y, Y affects Z; somehow, we should be able
  to be told that X affects Z without having to explicitly enter
  that dependency into the system).  This means only the simple
  dependencies have to be initially understood by us slow humans...

- Ability to detect cycles in the dependency graph, which are possibly
  indications that something has been entered incorrectly (yes, I know,
  not always, but the ability to recognize cycles is still useful).

- Simple searching capabilities.

- Possibly some small number of hardcopy-producing options.

	It would also be nice to be able to specify different types
of dependencies between parameters, instead of all dependencies being
assumed to be the same.  But, this complicates things in a couple of
different ways, and is not necessary in my initial application.

	Once you start having to manage more than about 20 parameters
in the dependency graph, doing this by hand is prohibitive.  Using a
drawing tool of some type usually falls apart at about this number of
parameters as well.  A simple matrix can handle a few more, maybe 40 
parameters, but doesn't make the cascading dependencies obvious.

	My initial application will involve 200 to 250 parameters, at
current estimates.

	Please e-mail responses to me, I'll summarize to the net.  Thanks!!

-------------------------------------------------------------------------------
 The story so far: In the beginning the           | Al Hooton, SW Quality Guy
 Universe was created.                            |     Telecom Products
                                                  | Tektronix, Inc. 
 This has made a lot of people very angry and     | (503) 627-4216 (wk)
 has been widely regarded as a bad move.          | (503) 626-6849 (hm)
                 - Douglas Adams                  | alh@tekig1.pen.tek.com
-------------------------------------------------------------------------------
Newsgroups: comp.software-eng
From: rms@miles.com (Rob Schultz)
Subject: US v. the World in SE (Statistics)
Organization: Miles Inc., Diagnostics Division, Elkhart, IN
Date: Wed, 18 Nov 1992 21:16:54 GMT


All statistics quoted here are taken from the class notes
of Capers Jones' Applied Software Measurement seminar.

More of my input for the software war between the USA and the
rest of the world.  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

Software Productivity Rankings overall (1991)

Country		Delivered Feature points per Staff Month

Japan		2.00
France		1.65
USA		1.55
England		1.47
Germany		1.45
Switzerland	1.40
South Korea	1.37
Taiwan		1.35
Canada		1.33
Norway		1.30

Software Quality Rankings overall (1991)

Country		Delivered defects per Feature Point

Japan		0.32
Canada		0.64
USA		0.75
Germany		0.82
England		0.83
France		0.86
Taiwan		0.89
South Korea	0.91
India		0.97
Thailand	1.03

I would have to say that if the USA hasn't already lost the 
software industry to offshore producers, we are on the fast
track for doing so, unless we make some major changes, and 
quickly.
-- 
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
From: cga66@cbnewse.cb.att.com (patrick.v.kauffold)
Newsgroups: comp.software-eng
Subject: Re: SE going offshore?
Date: 16 Nov 92 17:36:30 GMT
Article-I.D.: cbnewse.1992Nov16.173630.25882
Organization: AT&T

From article <1992Nov13.142754.12335@ornl.gov>, by jov@styx.ornl.gov (Judd Jones):
> 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.

Read Yourdon, _Decline and Fall of The American Programmer_ for a first-
hand view of India's developing software industry.  He does not share
the view that cheapness of labor is the only factor, but he does issue
a wake-up call.

Interesting book, anyway.

Pat Kauffold
AT&T Bell Labs
Newsgroups: comp.software-eng
From: leisner@wrc.xerox.com ( Marty Leisner)
Subject: Re: Productivity vs. Complexity
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
X-Newsreader: TIN [version 1.1 PL7]
Distribution: na
Date: Fri, 20 Nov 1992 01:49:19 GMT

Travis Marlatte (travis@eecs.nwu.edu) wrote:
: 
: Training a person to design a software system is no different than
: training that person to design a hardware system. It takes basic
: engineering skills refined for a particular discipline.
: -- 

Wow!!

Electrical engineers will agree on a good design.  Software engineers generally won't.

I think writing software is as much "enginnering" any type of creative activity.
--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom
Newsgroups: comp.software-eng
From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: Hypothetical Process Question
Keywords: Level-5, process
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Mon, 23 Nov 1992 09:01:57 GMT

In article <1992Nov20.132925.3768@afit.af.mil> jcardow@afit.af.mil (James E. Cardow) writes:

>	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?

This was discussed here before in great length. Check the archives. 
In short, one could create an organization that had processes that
were up to supporting optimized processes: but such a new organization
would not have any organization specific information to tell it how to
decide what to optimize.   It could support a managed process
(comparing actuals vs. plan targets and either tweaking the plans or the
implementation of the plans), but it can't know if its targets are
appropriate to the long term success of the organization.  It can
define its plans, but it can't know if they are correct for the new
organization's peculiar circumstances.  It can keep the information
necessary to repeat its process, but it hasn't repeated one yet.

In short, you can crate an organization that has POTENTIAL to be a
mature organization, but it can't be a mature organization until to
add the one thing that takes you out of potentiality into reality:
experience.  The scaffolding that you can erect at each level of the
maturity curve is really designed to allow you to efficiently and
accurately collect and keep the knowledge that you are getting by
experience. Without such scaffolding and memory you can have
experinece without gaining knowledge (that's what keeps some old
organizations at the initial/chaotic level). 

But there is no substitute for real organization specific success
criteria and knowledge.  Automating your new org's process and running it at
the optimized level without building up an experience base could allow
you to ensure your organization just does the wrong things more
consistently and quickly. That's why the repeatable level is so
critical. It culls out those who do things that are so wrong that they
aren't worth repeating even if done more efficiently.

A problem that every new organization faces is learning the market
survival criteria that apply specifically to it. And each new organization
is critically dependent upon the specific people it hires and their
skills, which can't be known until they are hired, trained and have run
a project successfully.

-- 

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: erwin@trwacs.fp.trw.com (Harry Erwin)
Subject: Inquiry
Organization: TRW Systems Division, Fairfax VA
Date: Thu, 19 Nov 1992 19:35:27 GMT


MITRE performed a study calibrating Barry Boehm's CoCoMo work sometime in
the last 5 years. I know the results; I'm looking for a reference.
 
I might add that they found that they found the 10%/90% limits for Barry's
model were +/- 20%. I.e., if CoCoMo predicted a project schedule of 10
months, the actual length would be 8-12 months in 80% of the cases.
 
Cheers,


-- 
Harry Erwin
Internet: erwin@trwacs.fp.trw.com

Newsgroups: comp.software-eng
From: goutal@hammer.crim.ca (Jean-Michel Goutal)
Subject: Free OO CASE Tools?
Reply-To: goutal@hammer.crim.ca
Organization: CRIM (Centre de Recherche Informatique de Montreal)
Date: Thu, 19 Nov 1992 20:15:06 GMT


Does anybody know some OO CASE tools or OO  Application developpment environments 
that are availble for free on the network.

Thank in advance

---
Jean Michel Goutal
Conseiller Genie Logiciel/ Consultant sotfware engineering
From: mick@muppet.bt.co.uk (Mick Burnell)
Newsgroups: comp.software-eng
Subject: Re: TickIT
Date: 19 Nov 92 17:56:10 GMT
Reply-To: mick@muppet.bt.co.uk
Organization: British Telecom

In article 4092@lmpsbbs.comm.mot.com, ilanc@mot.com (Ilan Cohen) writes:
>>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

Just for the record ...

TickIT is NOT an organisation of IT professionals.

It is a certification scheme for quality management systems of organisations 
involved in the development and supply of software and IT systems.

The scheme has been devised by professionals and is supported by the 
Department of Trade and Industry and the British Computer Society.

The aim of the TickIT scheme is to achieve improvements in the quality of software products and information systems throughout the whole field of IT supply.

Hope this helps,

Mick.
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: 18 Nov 92 11:44:14 EST

In article <17556@mindlink.bc.ca>, Gerry_Furseth@mindlink.bc.ca (Gerry Furseth) writes:
[...good stuff...]
> Aphorism: If you can't write a testing plan from your design, the resulting
> code will be unreliable.
Test then code.  Consider if you are hiding what you want to test.

> Collorary: If you write and execute a testing plan for all your designs, you
> are not working in software.
> 
I think that this is pushing it a bit.  (first you have to design, hee hee
hee...).  Actually what I am seeing in practice is a real push to test early and
often, starting with review techniques at the specification stage.

George Kambic

Newsgroups: comp.software-eng
From: craigh@cserver.plexus.com (Craig Heilman)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Plexus Corp. -- Neenah Wisconsin
Date: Mon, 16 Nov 1992 20:07:32 GMT

mcgregor@netcom.com (Scott Mcgregor) writes:

>Chief Programming Teams and power:

>I think the idea that Chief Programming Teams gives one individual too much
>power for management's taste is only part of the situation. It makes
>you very vulnerable to a HUGE slip if that person leaves. Now, that
>may seem like too much power in the sense that you have to do a lot to
>make them stay.  But occasionally people leave the team for other
>reasons, including accidental death or serious illness.  You can be
>just as much hurt if your chief programmer leaves the team due to
>death. And often the people you contracted with, or your market
>opportunity has no sympathy for your loss. CPTs can be great if you
>are willing to take big risks.  The longer the project the bigger the
>risk.  Chief Programming Team organizations often have the kind of
>volatility that businesses such as music and entertainment which also
>rely on the star system have.  There is nothing wrong with such
>systems, but they don't go well with other goals that SOME (but not
>all) people have such as STOCK PRICE STABILITY and EMPLOYMENT STABILITY.

I went out and bought "The Mythical Man-Month" this weekend (great book and
really quite easy reading) and have read through the "The Surgical Team"
chapter (which I believe corresponds to the chief programmer concept - term
coined by Mills).  I think you might have missed the description of the
copilot which states that: "He is the alter ego of the surgeon, able to do
any part of the job, but is less experienced.... He knows all the code
intimately.... He obviously serves as insurance against disaster to the
surgeon."

--
*                           * "I just found out that the brain is like a   *
* Craig A. Heilman          * computer.  If that's true, then there really *
* craigh@cserver.plexus.com * aren't any stupid people.  Just people       *
*                           * running DOS." - VH1's Stand Up Spotlight     *
From: tgl+@cs.cmu.edu (Tom Lane)
Newsgroups: comp.software-eng
Subject: Re: Comments:Code (what is the standard guideline?)
Summary: quantity != quality
Date: 23 Nov 92 17:02:23 GMT
Article-I.D.: cs.By6I01.1wF.2
Organization: School of Computer Science, Carnegie Mellon

markham@brtph678.bnr.ca (Andrew Markham P205) writes:
> Some friends wanted to settle a dispute on the comments-to-code
> ratio that is generally suggested in software engineering circles.
> Two of us believe a 60:40 comment-to-code breakdown, but the other 
> thinks that is simply too many comments.

IMHO the mere ratio of code to comment characters is uninteresting,
and any attempt to standardize a ratio is bureaucratic mindlessness.
The only useful measure of the value of comments is how much information
they convey that isn't obvious from the code, and this is UNRELATED to
volume.

Let me give you two examples at opposite extremes.  A sorting routine
might well be considered fully commented with the single line
	/* See Knuth's Art of Computer Programming, vol 3, pp 114-117 */
if it is a direct implementation of Knuth's exposition of Quicksort.
There is very little you would want to know that you wouldn't find
in Knuth's book.

On the other hand, I have seen FAR too much assembly code in the style of
	...
	add	#1,d3		; add 1 to i
	...
where the comments are voluminous but convey hardly any new information.
(To say nothing of the possibility that the comments are actually in error.)

I also believe that assembly coding usually requires a greater density of
comments than do high-level languages; for instance, you often use comments
to mark constructs like loops, if-then-else, and so on, which require no
comments in HLLs.  This suggests that any comment-to-code ratio is
language-specific.

In short, the interesting question is not the volume of comments, it's
the quality of the comments.  I'm not aware of any simple way of measuring
the quality; I would say that almost by definition, there is no mechanical
way of measuring it.

			regards, tom lane
Xref: sparky comp.software-eng:4457 comp.object:4296 misc.books.technical:1682 alt.books.technical:330
From: tensu@cs.tut.fi (Tero Ahtee)
Newsgroups: comp.software-eng,comp.object,misc.books.technical,alt.books.technical
Subject: software eng. reference list updated (22.11.)
Followup-To: comp.software-eng
Date: 23 Nov 1992 06:43:16 GMT
Organization: Tampere University of Technology
Distribution: world
NNTP-Posting-Host: hemppo.cs.tut.fi
Keywords: book analysis design quality object test software
Originator: tensu@hemppo.cs.tut.fi


	Hi netlanders, 

I just updated software engineering reference book list
"SE.references.????92" (where ????92 is modification date in european
format). It is a 7-bit ASCII text file (size about 189 kb) made with
emacs. 

The list can be accessed via anonymous ftp from machine "cs.tut.fi"
(130.230.4.2) from directory "pub/tut". 

The list contain ONLY books, not articles. References are NOT sorted
by subject, but only by author's name in alphabetical order. (Yes, I
know that it would be more useful, if it would be sorted by subject,
but I don't have time to do such sorting, sorry.) 

There are references about software engineering in general, e. g.
databases, project management, quality, CASE-tools, object-oriented
techniques and object-oriented programming languages. 

There are no, or few, references about user interfaces, artifical
intelligence, conventional programming languages and communications.

There are some abbreviations in the end of some lines. They have the
following meaning
 <SF> = reference is in finnish
 <D> = reference is in german
 <S> = reference is in swedish. 

The best way you can take advantage of the list is to keep it on file
and use e.g. 'grep' command for finding interesting references. (It
doesn't make sense to print the whole list, I think.) 

If you know more good refrences, please let me know by e-mail. 

If you have corrections to my list, please let me know by e-mail. 


	Tensu 

--------------------------------------------------------------
Tero Ahtee * tensu@cs.tut.fi * 
Tampere University of Technology * Software Systems Laboratory
P.O. BOX 553 * 33101 Tampere * Finland * Europe 

-- 
Tero Ahtee * tensu@cs.tut.fi  *  Tampere  *  Finland  *  Europe 
Login ergo sum.   <>   Workload is not killing - it is challenging.
COMMERCIAL : Why should you pay less for a better computer - buy IBM !

Newsgroups: comp.software-eng
From: jsm@mse.cmu.edu (James S Murphy)
Subject: Re: Estimating Large S/W Development Efforts
Organization: CMU/SEI Master of Software Engineering Program
Distribution: usa
Date: Fri, 20 Nov 1992 18:32:48 GMT

In article <1992Nov20.023108.13035@spectrum.xerox.com>, leisner@wrc.xerox.com ( Marty Leisner) writes:
|> 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...
|> 
|> --

  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.  Products such as
gcc and a BSD kernel are certainly non-trivial, but they do not represent the
upper bound of computational complexity, either in theory or in practice.

  Products such as compilers, operating systems, development environemnents
are mearly the tools that will allow us to build larger and more complex
systems that do actual work for something outside the realm of computing.
To produce a 200K tool for making 50K applications is a bit narcisistic, eh?

  Applications on the order of >1MLOC are quite common, as well as being
appropriately sized for the tasks at hand.

  If I missed the point of Rich's post, then redirect this response to 
/dev/null.

      Jim Murphy                                jsm@mse.cmu.edu
      PP-ASEL-IA                                Carnegie Mellon University


Newsgroups: comp.software-eng
From: mmaccorm@fox.nstn.ns.ca (Mike Mac Cormack)
Newsgroups: comp.software-eng
Subject: RFP for I-CASE?
Date: 17 Nov 92 19:20:50 GMT
Organization: Micronav International

Does anyone have any information on the final Request for Proposal (RFP) for 
the Integrated Computer Aided Software Engineering (I-CASE) program wich 
was issued by the U.S. Air Force Communiations Command's Standard 
Systems Center?  An article in "Defense Elecronics", October 1992, stated 
that it was distributed on diskettes and is available on the Standard System 
Center's electronic bulletin board system at (205) 416-5653.  Is this 
document also available on the Internet?  Any information would be 
appreciated.

Mike Mac Cormack
Micronav International Inc
P.O.Box 1523 / 104 Marine Drive
Sydport Industrial Park,
Sydney, N.S. Canada B1P 6R7
Tel: 902-564-8833      Fax: 902-564-8764
Newsgroups: comp.software-eng
From: dichter@chdasic.sps.mot.com (Carl Dichter)
Subject: Re: Code Reviews (was SE going offshore?)
Organization: SPS
Date: Sun, 22 Nov 1992 19:58:02 GMT


I don't know whether you'd call them group code reviews or not:
The way that we recommend (described in detail in the January 92 Unix Review 
article "Two Sets of Eyes") is inspection before meeting.

In this method, you send your code to at least two, but no more than five people. 
Ideally, this includes at least one experienced and one in-experienced person.

These reviewers read the code and provide results to a person designated as 
a review recorder. This recorder may be the owner of the code, or one of the 
reviewers. A meeting may not be held if no errors were found, or so many
that the code needs to be completely reworked.

If a meeting is held, only the issues/problems found are discussed--
you don't sit together while +20K lines of code are being reviewed.

Modules of code are reviewed as they are available to prevent future
problems by educating the code author and all participants.
If you wait until the code is all done to review it, you'll find
many instances of the same errors-- most preventable.

Biggest reasons to do inspections:
1. Improve the process of making code by educating all participants.
2. Find opportunities for reuse: "You don't need to write that-- there
   is one in Greg's code" or "That's great! Could you generalize it a little
   and put it in the library?"
3. Make code more reusable and maintainable, by pointing out where it can 
   be generalized or improved.
4. Finding bugs in code, design, requirements, etc.

Bob Bagwell's idea of using skilled, cheap, non-local workers to do inspections
only helps in 3 & 4. Seperate workers may catch errors, but unless the US
workers study the review results, they'll continue to crank out rubbish (1) --
more so-- they know someone is picking up after them! These separate workers
won't have the knowledge of other code, future code needs, conventions, or the 
end-user requirements and market (2,3,4). 

However, if Bob means that the "super-programmers" and the "cheap labor" work together,
you'll build a good crew and accomplish all of the objectives. You don't have to 
use non-local labor, you can use recent grads or software technicians (cheap
programmers). After a while, most of your "cheap labor" will have become 
"super-programmers": you can take on more projects (after you find more "cheap
labor").

----------------------
Carl R. Dichter               "iwannanugui"
Motorola ASIC Division
email: dichter@chdasic.sps.mot.com
/*
** "People who never make mistakes work for people who dare to."
*/