HDTenEightyP/NetNews huggingface dataset:
From: tcl@csi.UOttawa.CA (Tim Lethbridge)
Subject: Wanted: Reengineering tools
Organization: Dept. of Computer Science, University of Ottawa
Date: Fri, 6 Nov 92 03:05:12 GMT

I am preparing a course entitled 'Software maintenance and re-engineering'.
While I am well versed in theory and proprietory technilogy, I am not
familiar with current commercial offerings.

Would anybody who has information about re-engineering tools (or re-engineering
capabilities of broader-scope tools) please tell me what you know. I am primarily
interested in PC-based software that can run in the students' lab.

I will post a summary in a week of anything I get by email.

Thanks
-- 
Timothy C. Lethbridge             tcl@csi.uottawa.ca
(613) 564-8155                   FAX: (613) 564-9486
Department of Computer Science, University of Ottawa
150 Louis Pasteur,    Ottawa,    Canada      K1N 6N5
Newsgroups: comp.software-eng
Subject: CASE tools for teaching?
From: Guszti.Bartfai@comp.vuw.ac.nz (Guszti Bartfai)
Date: Thu, 5 Nov 1992 23:12:18 GMT
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.


Hello all,

I guess I'm asking a FAQ, but I haven't been following this group for a while.

I would like to know what CASE tools (commercial and shareware) are around
that can be used in undergraduate SW engineering courses, both for student
projects and teaching.

Any help (pointer, suggestion, experience, etc) would be appreciated. I'll
summerise if I get enough responses.


-- 
--- Guszti Bartfai ---		Mail:	P.O. Box 600, Wellington, New Zealand.
				Phone:	+64 4 471-5328  
				FAX:	+64 4 495-5232
From: duitz@mksol.dseg.ti.com (mitchel n duitz)
Newsgroups: comp.software-eng
Subject: Re: Who tests?
Date: 13 Nov 92 15:36:37 GMT
Article-I.D.: mksol.1992Nov13.153637.8643
Organization: Texas Instruments, Inc

In article <kcampb.721639735@edson> kcampb@ee.ualberta.ca (Kevin Campbell) writes:
>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.  

One area of "Product Integrity" that is continually being ignored
is reliability.  Given the 4 assurance disciplines above does not
assure quality.  Depending on the method of testing it is usually 
inpossible to give a measure of software reliability.  Without random
test cases based upon some sort of usage model, the testing will only
take care of expected or though out cases.  The 4 listed above will give
some level of confidence in the software, depending upon how serious
the software engineers too verification and validation.
duitz@dseg.ti.com
standard disclaimer - my views and not of TI's.
Newsgroups: comp.software-eng
From: sr@seas.gwu.edu (Stan Rifkin)
Subject: Re: Defect Costs
Keywords: cost of quality COQ Dion
Organization: George Washington University
Date: Sat, 7 Nov 1992 13:33:11 GMT

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.
>
>I would be interested in hearing from others with information from
>similar studies.
>
>
>Peter R. Spool
>Siemens Corporate Research
>Princeton, NJ
>(609) 734-3385
>prspool@siemens.com

Ray Dion's work ranks as among the best examples of the application of
Phil Crosby's cost of quality approach applied to software
development. He is an inspiration to all of us, and so are his process
improvement gains.  Ray has always been willing to speak about his
work, so if you have any questions for him you might try calling him
at 508/440-2236, the last number i have for him.
From: kroczak@knoblake.sybase.com (Barbara Kroczak)
Newsgroups: comp.software-eng
Subject: Re: Excelerator
Keywords: info
Date: 8 Nov 92 22:02:09 GMT
Distribution: comp

Are you referring to a company called Xellerated Systems Inc?  
They're at 3944 Murphy Canyon Rd, Suite C201, San Diego, CA 92123. Tel: (619)
576-3080.

Barbara Kroczak
Newsgroups: comp.software-eng
From: peter@philips.oz.au (Peter Martiniello)
Date: Wed, 11 Nov 92 09:39:50 GMT
Organization: Philips Public Telecommunications Systems, Melbourne, Australia
Subject: Distributed Development

Can anyone supply any references to books, articles, experiances, etc. that
discuss the problems and soultions in developing a product amoung different
developers separated by large distance ( different countries ).

    Some issues that I am interested in:

        -   how to maintain software configuration over different sites.
        -   how are general project libraries built - what site, how often.
        -   tools that may support remote development

Thanks
Peter
-- 
-----------------------------------------------------------------
Peter Martinello
Philips Public Telecommunications Systems    Phone: +61 3 8813666
Melbourne, Australia      		       Fax: +61 3 8813577
Newsgroups: comp.software-eng
From: swong@mprgate.mpr.ca (Susan Wong)
Subject: ISO-9000 Certification
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Fri, 6 Nov 92 00:10:23 GMT

Hi,

I'm interested in getting in touch with companies who have
been through the certification process for ISO-9000. In particular,
I'm interested in ISO-900-3, the software component.

Has it proven worthwhile?

Thanks,

Susan Wong

swong@mprgate.mpr.ca
Newsgroups: comp.software-eng
From: bagwill@swe.ncsl.nist.gov (Bob Bagwill)
Newsgroups: comp.software-eng
Subject: Re: Application Portability Profile?
Date: 13 Nov 92 14:31:41 GMT
X-Newsreader: TIN [version 1.1 PL6]

Brad Heckman (brad@delfin.com) wrote:
: Can anyone provide contact information for the
: Application Portability Profile
: from the
: National Institute of Standards and Technology?

Gary Fisher, (301)975-3275, gfisher@nist.gov
NIST, Bldg 255, Room B266, Gaithersburg MD 20899

--
Bob Bagwill
bagwill@swe.ncsl.nist.gov
Newsgroups: comp.software-eng
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: Will we keep ignoring this productivity issue?
Summary: but...what is it, then?
Organization: eklektix - Boulder, Colorado
Date: Thu, 12 Nov 1992 08:40:32 GMT

rich@kastle.com (Richard Krehbiel) writes:
[why do we ignore as much as a 20-fold difference in productivity?]
>    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?

or whatever...

But back to the question.  In terms of what Rich said - is there anything
that can be done about it?  Is it a gift, or an aptitude that just happens
to be developed in certain circumstances, or what?

Maybe there's nothing there we can take advantage of...or maybe there is.
We don't know.  Back to Munck's question: why aren't we looking at it?

It might be a hard problem.  It might not yield a useful solution.  But we
don't know, because we haven't looked.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Simpler is better.
Newsgroups: comp.software-eng
From: wilson@rhombus.cs.jhu.edu (Dwight Wilson)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: The Johns Hopkins University CS Department
Date: Wed, 11 Nov 1992 17:31:03 GMT

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

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
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.software-eng
Subject: Re: Terminal vs. workstations productivity
Date: 11 Nov 92 15:07:51 GMT
	<BEVAN.92Nov3232420@hippo.cs.man.ac.uk>
	<1992Nov9.200351.17122@den.mmc.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: richard@crowded-house.den.mmc.com's message of 9 Nov 92 20:03:51 GMT

In article <1992Nov9.200351.17122@den.mmc.com> richard@crowded-house.den.mmc.com (Richard Armstrong) writes:

   >Maybe, but I don't see anything in the above that _required_ a
   >X-Terminal, all you seem to need is the ability to have two "windows"
   >visible on the screen.  

   I guess you missed the word "mouse".

I certainly did and I apologise.  Mice do not work for me (and believe
me I've tried hard to use them) but that doesn't mean they don't work
for others.  My personal wish (and I'm mentioned this before) is for a
trackball roughly where my right thumb lies when touch typing%, or
failing that an a4 terminal.

bevan

% I know you can get Mac's with keyboards like this, but I don't
  develop on/for Mac's
From: greg@thirdi.uucp (Greg Holmberg)
Newsgroups: comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 13 Nov 92 22:28:26 GMT
Reply-To: greg@thirdi.UUCP (Greg Holmberg)
Organization: Third Eye Software, Menlo Park, CA

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

	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?

	>...I've always felt that the path to **IMPROVING SOFTWARE
	>PRODUCTIVITY** should start with an investigation of why that's
	>so and how to take advantage of it.  Instead, we are spending
	>$hundreds of million$ to lower the skill level needed for
	>programming.

	Or, if I may reword what Bob said rather less kindly, we are
	spending vast sums to get code out of the people who can't
	program, instead of finding out how the folks who can program
	do it.

An excellent article on this subject is "No Silver Bullets" by
Frederick P. Brooks, Jr. (author of "The Mythical Man-Month").  This
article appeared the November 1987 issue of Unix Review (Volume 5
Number 11).

In it, he discusses successs in software development productivity in
the past and analyzes the reasons for their successes.  He then looks
at some hopes for the future, including:

    Programming environments and tools, workstations
    Ada and other high-level language advances
    Object-oriented programming
    Artificial intelligence
    Expert systems
    Automatic programming
    Graphical programming
    Program verification
    Reuse
    Requirements refinement and rapid prototyping
    Incremental development
    Great designers

In the end, he holds some hope for object-oriented programming (he
says, "Many students of the art hold out more hope for object-oriented
programming than for any of the other technical fads of the day.  I am
among them."), but says that first priority must be to find and nurture
great designers.  He makes the case that attracting and growing the
right people will be the only real solution to our software development
problems.

I agree and I highly recommend this article.
-- 
Greg Holmberg

Third Eye Software, Inc.                415/321-0967 Voice
750 Menlo Avenue, Suite 300             415/321-2066 Fax
Newsgroups: comp.software-eng
Subject: BOOKS ON SOFTWARE ENGINEERING
From: ling@mdcbbs.com (Gen Lin)
Date: 9 Nov 92 11:18:28 PDT
Distribution: world
Organization: M&E (Division of EDS), Cypress CA
Keywords: software engineering

Is anybody out there can recommand few good text books on the SOFTWARE ENGINEERING?
From: travis@eecs.nwu.edu (Travis Marlatte)
Newsgroups: comp.software-eng
Subject: Re: How big is a manmonth
Date: 12 Nov 92 23:16:28 GMT
Organization: Rauland-Borg Corporation, Skokie IL

Man-months vary from company to company and from person to person.
We do initial estimates based on a pure man-month concept and then
load it with various factors such as planned and unplanned vacations and
time off, holidays, efficiency, etc.

To assume that an engineer is going to work a full day at 100%
efficiency is crazy. We expect engineers to statistically spend some portion
of every day staying current in their field, going to conferences,
and productively chatting around the coffee pot. By the way, chatting
about that new wall you're putting in the basement is considered
productive.

Many people claim that software engineers don't estimate well. I think that
that is a short sighted view. In most cases the estimates are right on
target but they don't include other aspects of every engineers day.

When considering estimates from our engineers, we have to be careful. Some
of them includes different factors in their estimates. Especially as
an engineer becomes more experienced with the results of his own
estimates, he will start including many of the weightings that we make
sure are in the final figure.
-- 
Travis Marlatte
travis@eecs.nwu.edu
708-297-0055
From: martinc@hatteras.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: How big is a manmonth
Date: 12 Nov 92 01:24:34 GMT
Organization: UNC Department of Computer Science
In-reply-to: peter@philips.oz.au's message of 11 Nov 92 09:42:43 GMT

Depends on what you mean by an "actual working hour".

A standard staff-month is (40 * 52) / 12 hours
		       =   2050 / 12 hours
		       =   170 hours

(That's 52 40 hour weeks.)  Of that, in the US, assume 80 hours are
vacation, about another 80 to 100 hours are holidays and personal time.
Studies suggest that a "good working day" is one in which about 3/4ths
of the time are spend on work, and not on going to the toilet, drinking
coffee, smoking -- if it is still permitted -- talking about the
bodacious new secretary, etc.  

I believe COCOMO is calibrated in terms close to the 170 hour month.
The figure 164 comes to mind.
--
		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
Subject: Tracking and Managing Change in Software Development
From: kcampb@ee.ualberta.ca (Kevin Campbell)
Date: Fri, 6 Nov 1992 06:28:10 GMT
Distribution: comp.software-eng
Organization: University Of Alberta, Edmonton Canada
Keywords: Software Environments, Change
Summary: Interested in research into managing change during sw development

I am currently writing a paper for a graduate SE course on change during
the software development life cycle.  I have been reading this group for
a couple of weeks and believe that some of you may have some insight into
this subject.

It is commonly accepted that changes in requirements are going to occur
later in the sw life cycle.  Traditionally once a product of the life cycle
was deemed to be stable it was baselined and put under configuration management
in an attempt to track and reduce the impact of changes.  All changes had
to be more formally specified and ideally they were reviewed by  
configuration control board (CCB) to determine the impact of the change (basic
SCM).  The concept as I understand it is to make change more visible and
provide a tracking mechnism.

In a recent paper from IEEE Trans. on Software Engineering, May 1992:
        Environment Evolution: The Prism Model of Changes
        Nazim H. Madhavji
Madhavji has built a model of changes supported by two environment 
infrastructures (Dependency and Change structure).  The purpose is to
record changes to the environment going beyond simply recording changes
to files.  Madhavji advocates that changes to anything in the environment
should be analyzed and recorded.  This includes for example:  people,
policies, laws, resources, processes and results.  The dependency structure
is used for describing various items and their interdependencies and for
identifying the items affected by a given change.  The change structure
is for classifying, recording and analyzing change-related data.

I believe in a Integrated Software Development Environment (ISDE) it would
be possible to have tools that would derive interdependency information
on items created during the life cycle.  This for example could recognize that
a given design decision was dependant on requirements X, Y and Z in the SRD.
This tool could then be used to aid in analyzing the effects of a change 
in requirements or design decisions.

I would be interested in any references relating to attempts to go beyond
traditional SCM in managing change.  Additionally I would be interested in 
peoples comments on the subject.

---
Kevin Campbell
kcampb@edson.ee.ualberta.ca
Newsgroups: comp.software.licensing
From: mcglough@rtsg.mot.com (Mark McGloughlin)
Subject: Network License Server Technical Info Sought
Organization: Motorola Inc., Cellular Infrastructure Group
Date: Thu, 12 Nov 1992 17:15:44 GMT

A student friend of mine is doing a final year project
which involves writing a client-server license managment
package..  I am only aware of the Flex product. Are there
any others and does anyone know where I might be able to
source some technical white papers on the subject. Flex
papers or anything else would do.

Thanks in advance,
Mark...
--
   _   _     Mark McGloughlin            | Ph:   +353-21-357101
 _/ \_/ \_   Motorola Ireland Ltd.       | Fax:  +353-21-357635
/ \_/ \_/ \  Cellular Infrastructure Div | POST: Q10543@email.mot.com
\_/ \_/ \_/  Blackrock, Cork, Ireland.   | Inet: mcglough@glas.rtsg.mot.com
-- 
---------------------------------------------------------------------
Mark McGloughlin       | UUCP:          ...uunet!motcid!glas!mcglough
Motorola Ireland Ltd.  | Internet:         mcglough@glas.rtsg.mot.com
Blackrock, Cork, Eire. | Ph: +353-21-357101.      Fax: +353-21-357635
Newsgroups: comp.software.licensing
From: mcglough@glas.rtsg.mot.com (Mark McGloughlin)
Subject: Network License Server Technical Info Sought
Organization: Motorola Ireland Ltd., Cork, Ireland.
Date: Wed, 11 Nov 1992 17:09:16 GMT

A student friend of mine is doing a final year project 
which involves writing a client-server license managment
package..  I am only aware of the Flex product. Are there
any others and does anyone know where I might be able to
source some technical white papers on the subject. Flex
papers or anything else would do.

Thanks in advance,
Mark...
-- 
   _   _     Mark McGloughlin            | Ph:   +353-21-357101
 _/ \_/ \_   Motorola Ireland Ltd.       | Fax:  +353-21-357635        
/ \_/ \_/ \  Cellular Infrastructure Div | POST: Q10543@email.mot.com
\_/ \_/ \_/  Blackrock, Cork, Ireland.   | Inet: mcglough@glas.rtsg.mot.com