HDTenEightyP/NetNews huggingface dataset:
From: ilanc@mot.com (Ilan Cohen)
Subject: Re: TickIT
Reply-To: ilanc@mcil.comm.mot.com
Organization: Motorola Communications Israel Ltd., Tel Aviv
Date: Thu, 12 Nov 1992 05:49:12 GMT

In article <levy.48@elaine.ee.und.ac.za> levy@elaine.ee.und.ac.za (Dave Levy) writes:
>Can anyone tell me anything about TickIT?
>
>Thanks in advance
>
>Dave Levy

TickIT is a guide to software quality management system construction and
certification using ISO-9000 (and other related standards). Actually it is
more then a guide, it is a scheme to implement ISO-9000. 

Copies and more details can be obtained from: 
TickIT Project Office
68 Newman Street
London W1A 4SE
U. K.

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

The book includes ISO-9001 and ISO-9000-3.

Have fun,
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: jb7m+@andrew.cmu.edu (Jon C. R. Bennett)
Newsgroups: comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 12 Nov 92 21:35:37 GMT
	<1992Nov12.185131.14394@cbnewse.cb.att.com>
Organization: Robotics Institute, Carnegie Mellon, Pittsburgh, PA


cga66@cbnewse.cb.att.com (patrick.v.kauffold) writes:
> Since the translation of detailed designs into code is taking only
> a small (10-20%) of total effort, and is declining, this issue will
> be less and less important.  However, we will have to deal with the
> individual differences in designers, since this is where improvements
> will have to be made if we are to see any real improvements in
> productivity.

while true this understates the problem, ok so implermentation take
10-20%, but what about unit testing and system integration? most
importantly what about maintenence? maintaining bad code is where the
money goes.

jon
From: brad@delfin.com (Brad Heckman)
Newsgroups: comp.software-eng
Subject: Application Portability Profile?
Date: 13 Nov 92 01:24:00 GMT
Organization: Delfin Systems
X-Newsreader: TIN [version 1.1 PL6]

Can anyone provide contact information for the
Application Portability Profile
from the
National Institute of Standards and Technology?
Newsgroups: comp.software-eng
From: kcampb@ee.ualberta.ca (Kevin Campbell)
Subject: Re: Who tests?
Organization: University Of Alberta, Edmonton Canada
Date: Fri, 13 Nov 1992 07:28:55 GMT

rex@iqsc.COM (Rex Black) writes:

>Robert Firth writes:
>>So, in conclusion, I don't think more testing, by whomever, is the answer.
>>The answer must be to work smarter, not harder; and it's pretty clear
>>for the work of Boehm, Mills and others that it is far, far better not
>>to put defects into the product in the early days than to make heroic
>>efforts to weed them out in the final days.

>Here be dragons.  I think we need to distinguish between TQM, which is a 
>methodology for improving processes, and testing, which is a methodology 
>for finding defects.  TQM is about improving a process so that it runs 
>more efficiently and produces fewer defects.  Testing is about finding 
>defects before the customer does.  Robert, if your point is that once
>one has a _mature_ TQM program in place throughout the organization one 
>will expend fewer resources on testing and testing-related coding, then
>I'll buy that.  However, I believe it would be very foolish for any 
>company to scrap its testing efforts entirely immediately upon starting
>at TQM program.  TQM is a long term investment, while testing is a risk-
>reduction effort.

I like the way Bersoff (et al.) handles this in the book Software
Configuration Management An Investment in Product Integrity.  In this 
book he discusses SCM as one of a combination of methods for attaining 
and maintaining product integity.  
Product integrity meaning a product:
   1) Which fulfills user needs
   2) Which can be easily and completely traced through its life cycle
   3) which meets specified performance criteria
   4) whose cost expectations were met
   5) whos delivery expectations were met

Bersoff identifies the following product assurance disciplines:
   1) Configuration Management
   2) Quality assurance
   3) Verification and validation
   4) Test and evaluation

The major point I'd like to emphasis is, as stated by in the above 
argument, "Product integrity" can only be achieved through 
combined efforts in all areas.  A quality product can only be 
achieved by ensuring quality at every step in the process.  

--------------------------------------------------------------------
Kevin Campbell
kcampb@edson.ee.ualberta.ca

-- 
----------------------------------------------------------------------
Kevin Campbell
kcampb@edson.ee.ualberta.ca
----------------------------------------------------------------------
From: mjl@cs.rit.edu (Michael J Lutz)
Newsgroups: comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 11 Nov 92 19:55:15 GMT
Article-I.D.: cs.1992Nov11.195515.20763
Reply-To: mjl@cs.rit.edu
Organization: Rochester Institute of Technology

In article <1992Nov11.173103.15814@blaze.cs.jhu.edu>, wilson@rhombus.cs.jhu.edu (Dwight Wilson) writes:
|> In article <1992Nov11.055130@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:

|> >How *can* we afford to be off pondering complexity metrics, bantering about
|> >25% changes, gaping in awe at the occasional arguably-possible factor of
|> >2, when there's this sort of fundamental difference that's been staring us
|> >in the faces for the past several decades?
|> 
|> Before we try to fix this problem, does anyone have
|> analogous numbers for other professions?  I would expect that
|> professions demanding high creativity would have a large
|> difference between the best practitioners and average ones, and
|> an order of magnitude is not particularly surprising.  
|> 
|> -Dwight

Well, Bill Curtis of the SEI (formerly MCC) talked about this at ICSE-13
in Austin.  His analogy was that of running: Ben Johnson on steroids can
run 100 meters in approx. 10 seconds.  Any person who is not physically
disabled can do the same in < 30 seconds (even in high heels).  This is
a 3:1 differential -- against which a 20:1 differential does seem quite
extraordinary.

Note that the 20:1 is not Donald Knuth vs. a student in Intro. Programming.
Instead, it is the difference between (supposedly) professional developers
in industrial settings.  I've worked with many EE's and ME's in my day,
and while competency varies, I've yet to see a 20:1 difference.  On the other
hand, I have seen a 20:1 difference in software groups.

-- 

Mike Lutz
Department of Computer Science
Rochester Institute of Technology
Rochester, NY 14623-0887  USA
+1 (716) 475-2472
mjl@cs.rit.edu
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Defect Costs
Date: 9 Nov 92 11:40:00 EST

In article <prspool.721000280@terra>, prspool@siemens.com. (Peter Spool) writes:
> The closest I've seen to a recent assessment of "Defect Costs"
> was a presentation on the "Cost of Quality" by Ray Dion of the Raytheon
> Equipment Division. The talk was given at the Software Engineering Symposium
> in Pittsburgh this past September.   He tracked three categories of costs:
> 1. Appraisal Costs: which included Reviews, Walkthroughs, Inspections,
>    Testing (the FIRST time), Independent Verification and Validation
>    (the FIRST time), and Audits.
> 2. Prevention Costs: which included Training, Tools, Mehtodologies,
>    Policies and Procedures, Planning, Data Gathering and Analysis,
>    Quality Improvement Projects, Fault and Root Cause Analysis.
> 3. Cost of Non-Conformance: Re-reviews, Re-tests, Fixing Defects in
>    Code and Documentation, Engineering Changes, and Patches to Delivered Code.
> Total Cost of Quality = Appraisal Costs + Prevention Costs + 
>                         Cost of Non-conformance
> Over a three year period, the Cost of Quality went from about 60% of the
> total product cost, to about 40%.  The savings were about $20 million.
> Unfortunately, there was no mention during his talk, of the rate of 
> increase in cost to fix defects as time goes on.

But he did keep track of the total rework costs, cost of quality, which
continued to go down.  My suspicions are that once the cost of quality begins
to level out, they will go for more detailed causal analysis, which may break
out what you ask for.  
> 
> I would be interested in hearing from others with information from
> similar studies.
> 

Only have internal (confidential), but Dion's talk was excellent.

George Kambic
sd

Newsgroups: comp.software-eng
From: rich@kastle.com (Richard Krehbiel)
Subject: Re: Will we keep ignoring this productivity issue?
Followup-To: comp.software-eng
Organization: Kastle Development Associates, Arlington, VA, USA
	<1776@aviary.Stars.Reston.Unisys.COM> <1992Nov11.055130@eklektix.com>
Date: Wed, 11 Nov 1992 09:51:40 GMT

In article <1992Nov11.055130@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:

>   This was in the "productivity of a C programmer" thread, about a week ago.
>   I haven't seen anyone picking up on it--esp. in comp.software-eng, where it
>   damned well *should* generate discussion!  Bob Munck (munck@stars.reston.
>   unisys.com) wrote:
>
>   >...However, it is a fairly-well-established rule of thumb that
>   >very good programmers can be an order of magnitude or more productive than
>   >the average and do a good job...
>
>   We toss this number around a lot.  A couple years ago I tossed it at a
>   friend who does a lot of real-time, control-system, etc. programming...just
>   to test his reaction, since he's generally good for a strong opinion.  But
>   his retort came from a direction I hadn't expected: he said "It's more like
>   *two* orders of magnitude!  You get the first order-of-magnitude difference
>   when the code is written.  The second comes during maintenance."  (Cf. also
>   Mark Terribile's comments about changes being made to the best code, because
>   it's the code people can figure out how to change.)
>
>   Well, maybe the difference is an order of magnitude, maybe two.  Be very
>   conservative, go below the geometric mean; assume it's only a factor of 20.
>
>   *ONLY*???
>
>   How *can* we afford to be off pondering complexity metrics, bantering about
>   25% changes, gaping in awe at the occasional arguably-possible factor of
>   2, when there's this sort of fundamental difference that's been staring us
>   in the faces for the past several decades?

    Perhaps because there's nothing that can be done about it?

    I think that those with the 20-fold advantage have a gift, not a
skill.  It's rather like perfect pitch or photographic memory.  Or,
put another way, can you train someone out of color blindness?

    Oh, perhaps selective breeding... :-)

    Seriously, somewhere in the book "Quality Software Management"
(Gerald M. Weinberg, Dorset House Publishing, ISBN 0-932633-22-6) is a
passage that also mentions this 20-fold discrepancy between
programmers, and it includes a footnote; I couldn't find it again
after ten minutes of searching, and I have real work to do, so maybe
some research has been done in this area after all.
--
Richard Krehbiel              rich@kastle.com or richk@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
Newsgroups: comp.software-eng
From: mat@mole-end.matawan.nj.us
Subject: Re: Re-Use (was Re: Testing (Was: Do Software Engineers Actualy Do So Badly?))
Summary: Firefighting
Organization: :
Date: Fri, 6 Nov 1992 04:37:39 GMT

In article <28030014@otter.hpl.hp.com>, adw@otter.hpl.hp.com (Dave Wells) writes:

> 			    ... If a support programmer found code which
> duplicated library functionality, he would be likely to march into the
> development office with a demeanor similar to that he would adopt if he'd
> found a development programmer urinating in his wastebasket. (Apologies for
> the somewhat crude analogy, ...

Well, when you look at what has been done to code in the name of
`putting out fires,' this analogy takes on new meaning.  Some of that
code would be improved by a day or two of lining a birdcage ...
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
From: ejw@siam.ics.uci.edu (Jim Whitehead)
Subject: Scalability criteria
Newsgroups: comp.software-eng
Reply-To: ejw@ics.uci.edu (Jim Whitehead)
Organization: Univ. of Calif., Irvine, Info. & Computer Sci. Dept.
Date: 12 Nov 92 04:47:54 GMT


As a grad. student at U.C. Irvine, I am currently taking a course on
software engineering.  Recently we had our midterm exam, which
contained the following interesting question:

A classic criticism of many proposed software engineering techniques
is that they do not scale-up to large systems.  Give at least three
criteria that need to be met in order for techniques to be scalable.

Since it was a take-home exam, there was enough time to examine the
literature and software engineering texts.  I was not able to find
any criteria for scalability in my searches, and so I present the
question to the net.

The test is done and over and graded, so have no fear you'll be
an accessory to breaking UCI's academic code.

I answered the question as follows, and I welcome comment:


Scalibility criteria:

At the most fundamental level, the scalability of a technique depends
on how the complexity of the technique increases with the size of the
project to which it is applied.  Low complexity implies scalability.
I see three cases:

Complexity varies linearly:

complexity_of_technique := scalability_constant * project_size

a) The scalability constant is small

b) The scalability constant is large

c) Complexity varies exponentially:

   complexity_of_technique := scalability_constant * project_size ^ exponent


I defined my three criteria to handle these cases:

1) Desirable results for projects of all sizes and types

This criteria handles case a) above where the complexity of the technique
may be small, but the technique just doesn't produce good results for
large projects.  One example of this is the method of stepwise refinement.
Stepwise refinement can easily be used on projects of all sizes, but it
just doesn't produce good results for medium to large projects.

2) Economical for projects of all sizes and types

This criteria handles case b) above where the complexity of the technique
is very large for large projects, but still varies linearly with project
size.  The typical symptom of this behavior is that the technique becomes
uneconomical for most users of the technique.  An example is software
code inspections.  Using published estimation metrics, software code
inspections should be appx. 15-25% of the total development cost.  Only
big money projects would be able to afford such a technique.

3) Feasibility for projects of all sizes and types

This criteria handles case c) above, where the complexity increases
exponentially with project size.  This behavior is demonstrated by
the Petri Nets specification technique.  As the size of the project
being modeled increases, the number of model elements increases
exponentially.  For even medium size systems, the full Petri Nets model
is huge and unmanageable.

---------------------
Jim Whitehead
ejw@paris.ics.uci.edu
From: davidm@consilium.com (David S. Masterson)
Newsgroups: comp.software-eng
Subject: Re: Terminal vs. workstations productivity
Date: 7 Nov 92 23:41:11 GMT
	<1992Nov6.075017.22154@informatik.uni-bremen.de>
	<BEVAN.92Nov6204326@hippo.cs.man.ac.uk>
Distribution: comp
Organization: Consilium Inc., Mountain View, California
In-reply-to: bevan@cs.man.ac.uk's message of 6 Nov 92 20:43:26 GMT
X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> On 6 Nov 92 20:43:26 GMT, bevan@cs.man.ac.uk (Stephen J Bevan) said:

> In article <1992Nov6.075017.22154@informatik.uni-bremen.de>
> mfr@Informatik.Uni-Bremen.DE. (Michael Froehlich) writes:

>    Yes, of course. That's a great solution.
>    I know a lot of people tieing their shoe-laces with a pair of pincers :-)

> I thought the usual complaint was that (GNU) Emacs was much to large
> and so a better analogy would be tying your shoelaces with a robot arm
> hooked up to some virtual reality kit.

In comparison to X??  If that's the analogy for Emacs, then the analogy for X
must be like tying your shoelaces with three hundred, independently thinking
hands -- eventually it can be done, but do you really need all the excess
power and capability?
--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
davidm@consilium.com				Mtn. View, CA  94043
====================================================================
People were out there looting their asses off... When they saw us,
they shouted, `Viva Bush!'
                -- A US soldier present at the invasion of Panama.
Newsgroups: comp.software-eng
From: geoff@flash.bellcore.com (Geoffrey Clemm)
Subject: Re: Code Coverage tools for the kernel
Organization: Bellcore
	<Bx5BtH.EHr@cs.uiuc.edu> <1992Nov04.201837.14950@Veritas.COM>
	<weyJd=200WAjIVN756@andrew.cmu.edu>
Distribution: usa
Date: 5 Nov 92 17:03:45

In article <weyJd=200WAjIVN756@andrew.cmu.edu> jb7m+@andrew.cmu.edu (Jon C. R. Bennett) writes:
   joshua@Veritas.COM (Joshua Levy) writes:
   > >So, by "decent C coverage tool", I was assuming one that used an
   > >in-core table written out at the end of program execution.  Since the
   > >I/O is done in one place, it should be easy to tailor.  For example,
   > >when using GCT on the kernel, you just reach in through /dev/kmem and
   > >read the table.
   > 
   > This is fine from a coverage point of view, but it is a major security 
   > problem.  If the person running the tests (which hopefully includes 
   > lots of development and QA engineers, not to mention some pseudo-real
   > users) can read /dev/kmem, then those people can steal passwords, 
   > including the root password.

   in the context described, the person is testing the KERNAL, if you could
   compile the kernal, and install the kernal, and run the kernal, then it
   dont realy mater that you might be able to get the root password, beacuse
   you already have the root password.

If you are going to post to thousands of people, a couple of points probably
should be kept in mind:

1) Read the article you are responding to.

As Joshua explicitly states, the individual that installs the kernel
is often not the person that tests the kernel.

2) Take the extra few seconds it takes to correct spelling and syntax errors.

Seven errors in a four line paragraph is rather excessive.

Cheers,

Geoff
--
geoff@bellcore.com
Newsgroups: comp.software-eng
From: mal2n@fulton.seas.Virginia.EDU (Matt Leonard)
Subject: Simple Circuit Schmatic Drawing App. for Windows....
Organization: University of Virginia
Date: Wed, 11 Nov 1992 04:01:26 GMT

I am looking for a program to draw simple circuits to paste into Word for
Windows...  Anyone know of such a program?
From: miket@hermes.tcs.com (Michael Turner nmscore Assoc.)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Teknekron Communications Inc.
Date: Thu, 12 Nov 1992 22:54:40 GMT

In article <1992Nov11.173103.15814@blaze.cs.jhu.edu> wilson@rhombus.cs.jhu.edu (Dwight Wilson) writes:
>In article <1992Nov11.055130@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:
>
>>>...However, it is a fairly-well-established rule of thumb that
>>>very good programmers can be an order of magnitude or more productive than
>>>the average and do a good job...
>>
>>							... "It's more like
>>*two* orders of magnitude!  You get the first order-of-magnitude difference
>>when the code is written.  The second comes during maintenance." ...
>>
>>How *can* we afford to be off pondering complexity metrics, bantering about
>>25% changes, gaping in awe at the occasional arguably-possible factor of
>>2, when there's this sort of fundamental difference that's been staring us
>>in the faces for the past several decades?
>
>Before we try to fix this problem, does anyone have
>analogous numbers for other professions?  I would expect that
>professions demanding high creativity would have a large
>difference between the best practitioners and average ones, and
>an order of magnitude is not particularly surprising.  

First let's get our own numbers straight!  From _Controlling Software Projects_,
I remember something like a factor of 4 to 5 (not 10) between AVERAGE and best,
and a factor of 10 between WORST and best.

The possibility of two orders of magnitude difference -- one from
initial construction, the second from maintenance -- ignores a common
trade-off: that some of the most prolific construction programmers can
produce almost unmaintainable code.  And the some of the best
programmers from a maintenance point of view code slowly -- maybe even
more slowly than the average, in some cases.

Still, I think it's possible to have SOME of the best of both worlds.  If you
think of a new program as one that you are "maintaining into existence" (Cf.
Peter Deutsch's famous comment: "Programming is debugging a blank sheet
of paper"), then you can expect to keep a fairly high rate of productivity
on a sustained basis, because you are investing continuously in future
productivity.  But how many of us have the range of skills, abilities,
knowledge, etc. to be this good all the time?  I try to be this way myself,
but get infected quite often by the attitudes of those around me.

There is a big problem with the strategy of "Pick the best programmers
and support them totally" as the best approach to higher productivity.
This is not a new idea -- take a look at _The Mythical Man-Month_ for
a review of the Chief Programmer Team concept.  TECHNICALLY, it's very
hard to refute.  The problem, I think, is not technical but political:
it gives these highly productive programmers too much power!
---
Michael Turner
miket@tcs.com
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: REVISITING THE MYTHICAL MAN-MONTH
Date: 13 Nov 92 14:04:11 EST
Distribution: comp

In article <MBERKLEY.92Nov11121407@visions.uvic.ca>, mberkley@visions.uvic.ca (Mike  Berkley) writes:
> (This survey is being posted for a friend without Usenet access.)
Argh!  For one more time.  Commercially, I cannot reply to any such survey no
matter how good the questions are.  Please contact the legal department.

Argh.

George Kambic
sd
Newsgroups: comp.software-eng
Subject: BOOKS ON SOFTWARE ENGINEERING
From: ling@mdcbbs.com (Gen Lin)
Date: 9 Nov 92 13:17:42 PDT
Distribution: world
Organization: M&E (Division of EDS), Cypress CA
Keywords: software engineering

IF anyone out there can recommand some good text books on the subject of software engineering.

Thanks!

Newsgroups: comp.software-eng
From: conditt@tsd.arlut.utexas.edu (Paul Conditt)
Subject: Need list of Config. Mgt. software
Organization: Applied Research Laboratories, University of Texas at Austin
Date: Tue, 10 Nov 1992 20:35:41 GMT


Pardon me if this is a FAQ, but I wasn't able to find one for this
newsgroup.  I am researching the different configuration management/
version control software available for UNIX platforms.  So far, I've
evaluated Polytron's (Intersolv's) PVCS and build utility.  I'm 
interested in knowing of other commercially available products and
how to get in touch with the vendors.  As a side note, does anyone
have any experience in using such a product, especially the build/make
utility, in an Ada environment?

Please email replies to:

conditt@titan.tsd.arlut.utexas.edu

Thanks a lot for your help.

Paul Conditt

Newsgroups: comp.software-eng
From: cga66@cbnewse.cb.att.com (patrick.v.kauffold)
Subject: Re: E-R diagram tool?
Organization: AT&T
Date: Thu, 12 Nov 1992 18:18:37 GMT

> I'm looking for PC based tools (free or commercial) which support
> Entity Relationship (E-R) diagram generation. 

E-R Designer

Chen & Associates
4884 Constitution Ave
Baton Rouge, LA 70708
(504) 928-5765
Newsgroups: comp.software-eng