HDTenEightyP/NetNews huggingface dataset:
From: kroczak@knoblake.sybase.com (Barbara Kroczak)
Newsgroups: comp.software-eng
Subject: Re: Code Coverage tool
Keywords: Code Coverage
Date: 8 Nov 92 21:39:38 GMT
Distribution: usa

Purify by Pure Software is also worth looking at for a C code coverage tool.
Tel: (408) 720-1600, Sunnyvale, CA.



In article <1992Nov3.170544.22498@hemlock.cray.com>, lleone@cypress49.cray.com (Larry Leone) writes:
|> 
|> For those of you looking into C test coverage tools, checkout Hindsight
|> from Advanced Software Automation.  Pretty good IMHO.  A FORTRAN version
|> was just announced.  A C++ version is coming in 93.
|> 
|> Contact:
|> 
|>   Dan Zimmerman
|>   3130A Coronado Drive
|>   Santa Clara, CA 95054
|>   Tel: 408-492-1668
|>   Fax: 408-492-1669
|>   email: zimme@hindsight.com
|> 
|> It's not freeware, but you do get what you pay for.
|> 
|>   --Larry
|> -- 
|> Larry Leone, Systems Test				Cray Research, Inc.
|> Phone: (612) 683-5385					655F Lone Oak Drive
|> E-mail: lleone@cray.com or uunet!cray!lleone		Eagan, MN 55121
From: travis@eecs.nwu.edu (Travis Marlatte)
Newsgroups: comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 12 Nov 92 22:42:23 GMT
Organization: Rauland-Borg Corporation, Skokie IL

The difference in productivity between professional programmers is a real
concern. However, I doubt that large projects actually experience the kind
of added expense that was suggested due to differing productivity.

More likely, large projects experience an average productivity that is
insignificantly lower than the best compared with all the other reasons
that projects cannot be scaled up with a linear response in development
time.

All engineering fields that I have contact with (directly and through
friends) seem to have similar productivity curves. There are the talented
few who seem to make the right guess the first time when creating a design.

There will always be the group at the bottom that struggle with every
decision and never seem to learn from their own or anyone else's mistakes.
These are the people who leave the field due to lack of promotion or
because their are promoted up the managerial ladder. 1/2 :-)

In my experience, it is the people who can grasp the bigger picture and
can adapt to the exceptions that are most productive. Using mental models
of what has worked in the past and fitting the new challenge into an
existing model allows that individual to focus on the differences between
what was done before and what is needed now - rather than trying to solve
the new challenge from scratch.

Not a new technique and certainly not specific within programming. Passing
this or other techniques on to those who are less productive is the concept
behind time management courses or classes that teach organization and
thought clarification.

Let me relate an analogy that I have found most appropriate.

A friend of mine is a musician and dabbles in programming. I am a programmer
and dablle in music. In our discussions, it became apparent that we each
approached our own fields in a similar way. Our best theory suggests that
either due to extensive training or, we think more likely, a natural
talent, we each could grasp the larger picture of our respective fields.

For instance, I look at a listing of software and quickly begin formulating
the overall flow and interaction of the code. When confronted with a
question, I can make a first guess based on that larger picture and quickly
narrow down my search to specific lines of code.

When I look at a sheet of music, I see individual notes. I can work my
way through sequentially - moving from note to note or chord to chord but
I have no feel for the overall structure.

My friend is just the opposite. She can review a piece of music and quickly
has a feel for the structure. She can discuss the music at a high level
and understands how the smaller portions fit into the big picture.

When she looks at code, she is seeing bits and pieces that she understands
but it is a struggle for her to comprehend the larger scope of it.


-- 
Travis Marlatte
travis@eecs.nwu.edu
708-297-0055
From: mattb@ssc-vax (Matt Baney)
Newsgroups: comp.software-eng
Subject: Re: Requirements Traceability Tools
Summary: Automated Software Analysis
Date: 10 Nov 92 19:14:03 GMT
Reply-To: mattb@ssc-vax.boeing.com (Matt Baney)
Organization: Boeing Aerospace & Electronics

I am posting this for a colleague who doesn't have access to the net??
Please email any information directly to Debbie, or to me and I will
forward it??

thanks 
matt
-------------------------------------------------------------

  SUBJECT: Automated Software Analysis
  KEYWORDS:  Software analysis, reverse engineering, re-engineering,
             re-use.
  E-MAIL:  rickend@net.a1.ca.boeing.com   
             (!! thats a1 (as in the steak-sauce), and not aI or al !!)

  Recently attended a discussion on automated software analysis 
  tools for transformation of existing software systems into 
  reusable components.   I am looking for information on any tools 
  that may be available to parce an existing segment of source code, 
  create functionality flows, data control, flows, and/or relationships 
  of the functions and data (if possibly the source code is object 
  related), etc.  The purpose of these tools is to perform reverse
  engineering on existing software systems where the documentation and
  any diagrams of the system is out-of-date, and possibly incorrect.  
  Then the segments may then be incorporated into an upgraded version, 
  or even new, software systems (re-use).

  --Thanks,
  --Debbie


-- 
|  Matt Baney         | Boeing Defense and Space Division    |
|  -----------------  |   Knowledge Systems Group            |
| "I can't tolerate   | UUCP:        ..!bcstec!ssc-vax!mattb |        
| intolerant people!" | Internet:   mattb@ssc-vax.boeing.com |
Newsgroups: comp.software-eng
From: michels@ide.com (Alan Michels)
Subject: Re: Software Through Pictures
Organization: Interactive Development Environments, SF
Date: Thu, 5 Nov 92 23:08:44 GMT

In article <5758@naucse.cse.nau.edu> kwc@elden.cse.nau.edu (Ken Collier) writes:

   I'd like to get in touch with the Software Through Pictures (STP)
   vendor.   I think the company is IDE in San Fransisco but I can't
   seem to get a number or an address for them.   Does  anyone  have
   this info?  Thanks.

   Ken Collier                            Internet:kwc@elden.cse.nau.edu
   College of Engineering and Technology 		
   Northern Arizona University
   Flagstaff, Arizona

You can get in touch with IDE at:

IDE
595 Market St.
10th Foor
San Francisco, CA 94105

ideinfo@ide.com, ...!uunet!ide!ideinfo

(415) 543-0900

Since you are in Arizona, you can also try our Arizona sales office:

2999 N 44th St
Suite 300
Phoenix, AZ 85018

Phone: (206) 391--0231
Fax: (206) 392-1826

-Alan Michels

-- 
Alan Michels
michels@ide.com      ..!uunet!ide!michels
IDE - Interactive Development Environments
595 Market St, 10th floor San Francisco, CA 94105
From: cga66@cbnewse.cb.att.com (patrick.v.kauffold)
Newsgroups: comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 12 Nov 92 18:51:31 GMT
Article-I.D.: cbnewse.1992Nov12.185131.14394
Organization: AT&T

Small companies have less of a problem with this than large ones,
particularly if they compensate the top producers.  Entrepreneurial
companies tend to attract and retain the better performers, and drive
out the non-performers.

Big companies, on the other hand, find individual differences very
uncomfortable.  "The nail that sticks up gets pounded down."  Big
companies, IMHO, would much rather spend money on snake oil solutions
than encourage and reward high performers.  Managers who are not
technically competent are particularly blind to differences in
ability and performance.

So there is a cultural aspect to this condition (not problem, really).

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.

By the way, two orders of magnitude is a factor of 100, not 20.

Pat Kauffold
At a really big company.
From: richard@crowded-house.den.mmc.com (Richard Armstrong)
Newsgroups: comp.software-eng
Subject: Re: Terminal vs. workstations productivity
Date: 9 Nov 92 20:03:51 GMT
Organization: Martin Marietta

In article <BEVAN.92Nov3232420@hippo.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>In article <1992Oct30.000254.15144@den.mmc.com> richard@crowded-house.den.mmc.com (Richard Armstrong) writes:
>   You should have been sitting here with me over the past two days trying to
>   find a subtle bug in a C program on a Unix box telnetted across a network
>   from a PC. I would have killed for an X-Terminal so that I could pull up
>   xdb, or some other X-based debugger.  I would have been MUCH more productive
>   in this situation alone.  Being able to cut and paste code with a mouse in
>   vi could have saved me hundreds of hours in productivity during this past
>   year. X-Terminals DO save time and increase productivity.
>
>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".

>Granted there isn't much software that lets
>you do this, but you could always use Emacs :-)
>
>bevan


-- 
My company never said any of this... I didn't either.
Richard Armstrong, Software Engineer, Martin Marietta
Email->>>> richard@crowded-house.den.mmc.com <<<<-Email 
Newsgroups: comp.software-eng
From: MICHAEL.WILLETT@OFFICE.WANG.COM ("Michael Willett")
Subject: SDW Case Tool?
Organization: Mail to News Gateway at Wang Labs
Date: Mon, 9 Nov 1992 22:21:12 GMT

Is anyone familiar with a CASE tool called SDW?  If so, what
might be its strengths and weaknesses?  Your advice and
recommendations would be very much appreciated!

Thank you,

Michael.Willett@OFFICE.Wang.com
From: richard@crowded-house.den.mmc.com (Richard Armstrong)
Newsgroups: comp.software-eng
Subject: Re: Terminal vs. workstations productivity
Date: 9 Nov 92 20:12:06 GMT
Organization: Martin Marietta

In article <1653@seqp4.sequoia.com> markr@seqp4.sequoia.com (Mark Roddy) writes:
>In <1992Nov6.075017.22154@informatik.uni-bremen.de> mfr@Informatik.Uni-Bremen.DE. (Michael Froehlich) writes:
>
>>In article 92Nov3232420@hippo.cs.man.ac.uk, bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>>>In article <1992Oct30.000254.15144@den.mmc.com> richard@crowded-house.den.mmc.com (Richard Armstrong) writes:
>>>you do this, but you could always use Emacs :-)
>>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>>bevan
>
>>Yes, of course. That's a great solution.
>>I know a lot of people tieing their shoe-laces with a pair of pincers :-)
>
>On the serious side, the effect that I noticed when we converted engineering
>from ascii terminals to X terminals was an increase in the amount of source 
>code that could be worked on at one time. Where 24 lines is the most you can
>view at one time on a typical ascii terminal, 60 or more lines are visible
>on an X display. 
>
>There is nothing inherent in an Xterminal that a 70x180 ascii terminal
>and a windowing editor can't do :-)

Except use a mouse to get from window to window!  There are numerous other
things that X-Terminals can do that ascii terminals cannot; but I do not
think that this line of conversation is possible if those who have never
and cannot use X Terminals argue with those who do and can use them.  It is
much like Mac people arguing with IBM people.  If any good point is made,
the opponents will merely discount the point as being not important to them.
In the end, nobody wins, and dividing lines are stiffened.

>-- 
>-Mark Roddy
>Sequoia Systems, Inc.          (508) 480-0800 x1284
>markr@seqp4.sequoia.com        m2c!seqp4!markr


-- 
My company never said any of this... I didn't either.
Richard Armstrong, Software Engineer, Martin Marietta
Email->>>> richard@crowded-house.den.mmc.com <<<<-Email
From: jubber_s@kosmos.wcc.govt.nz
Newsgroups: comp.software-eng
Subject: Info on Case Prog sought
Date: 11 Nov 92 22:08:23 NZST
Organization: Welligton City Council, Public Access.
NNTP-Posting-Host: kosmos.wcc.govt.nz

Hi


Please could any body help me . Our company is looking at case tools to help
us in development of several large projects. We have just finished looking at
a Cognos product called powerdesigner but it needs OS2 to run and also seems
to be abit of an overkill for our purposes.

What we had heard of is a product called Software Architect from Bopkin
Software. I am looking for any information on this product as to its
capibilities , useability , cost and availibility.

Also if anyone has info on other suitable case tools I would appreciate it.

Thanks very much

Please send Email to the address below


Steve Jubber
jubbers@fcnz.co.nz

Forestry Corporation of NZ

Newsgroups: comp.software-eng
From: scurry@pansy.srg (Scott Curry)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: ARINC Research, Corp.
Distribution: World
Date: Fri, 13 Nov 92 21:20:56 GMT

In article <1992Nov11.195515.20763@cs.rit.edu> you write:
>
>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.
>


Playing devil's advocate...

Isn't Software Engineering touted to "level the playing field" to make
these ratios smaller?

Is it not at least partly the purpose of the various methodologies and
paradigms  ( e.g. Object Oriented Design, Formal Specification, V&V, etc.)
to allow quality software to be built by mere mortals.

Scott Curry

-- 
***Disclaimer: The above are solely my own opinions, NOT of Arinc Research.  *
* Scott Curry, Analyst	 		 Email: scurry%srg@uunet.uu.net	     *
* Phone:  (410)266-4940 		 Smail: 2551 Riva Road  MS 5-230     *
* Fax:    (410)573-3024		                Annapolis, MD  21401-7461    *
--
***Disclaimer: The above are solely my own opinions, NOT of Arinc Research.  *
* Scott Curry, Analyst	 		 Email: scurry%srg@uunet.uu.net	     *
* Phone:  (410)266-4940 		 Smail: 2551 Riva Road  MS 5-230     *
* Fax:    (410)573-3024		                Annapolis, MD  21401-7461    *
Newsgroups: comp.software-eng
From: mfr@Informatik.Uni-Bremen.DE. (Michael Froehlich)
Subject: Re: Terminal vs. workstations productivity
Reply-To: mfr@Informatik.Uni-Bremen.DE.
Organization: University of Bremen, Germany
Date: Fri, 6 Nov 1992 07:50:17 GMT

In article 92Nov3232420@hippo.cs.man.ac.uk, bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>In article <1992Oct30.000254.15144@den.mmc.com> richard@crowded-house.den.mmc.com (Richard Armstrong) writes:
>   You should have been sitting here with me over the past two days trying to
>   find a subtle bug in a C program on a Unix box telnetted across a network
>   from a PC. I would have killed for an X-Terminal so that I could pull up
>   xdb, or some other X-based debugger.  I would have been MUCH more productive
>   in this situation alone.  Being able to cut and paste code with a mouse in
>   vi could have saved me hundreds of hours in productivity during this past
>   year. X-Terminals DO save time and increase productivity.
>
>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.  Granted there isn't much software that lets
>you do this, but you could always use Emacs :-)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>bevan

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

Michael
---
	Dipl.-Inform. Michael Froehlich
	University of Bremen - Department of Computer Science
	PO-Box 330440, W-2800 Bremen 33, Germany
	Tel.: 	x49 421 218-4228
	e-mail: mfr@Informatik.Uni-Bremen.DE
				
I'm a recycled .signature virus. The characters of my source code
are 100% extracted from old foolish articles.

Newsgroups: comp.software-eng
From: mwu@orion.oac.uci.edu (Matt Wu)
Subject: looking for CASE tools
Newsgroups: comp.software-eng
Organization: University of California, Irvine
Date: 11 Nov 92 23:35:37 GMT

Howdy.  I was wondering if someone could give me suggestions as to where
to begin looking for CASE tools.  I'm particularly interested in specification
tools that can describe the functionality, user interface, and data
structures of existing programs (as well as new ones).

Thanks,

Matt
mwu@orion.oac.uci.edu
Newsgroups: comp.software-eng
From: marick@cs.uiuc.edu (Brian Marick)
Subject: Re: Productivity of a C programmer ?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 6 Nov 1992 03:11:54 GMT

rms@miles.com (Rob Schultz) writes:
>Did you by any chance try to correlate this data to Allan Albrecht's
>Function Points?

I did not, though it's on my list of things to do if I ever have the
time to finish analysing the experiment.  (Since the data is almost
two years old already, I wouldn't hold my breath.)

Speculation:  a large part of the difficulty/cost of test design is
driven by dependencies.
1. Dependencies between sections of the code.
2. Dependencies between areas of the specification.
3. Dependencies between (for want of a better term) areas in the
"requirements space".

If we had perfect code, specifications, and requirements analyses, I
think testing effort would be rather predictable (and pretty
pointless).  But we don't - in fact, a large part of testing is
finding the dependencies that weren't mentioned in any of those
documents.  (That is, finding faults of omission.)

There's something unpleasantly circular about using a specification
(or code) to predict the effort needed to find its own omissions --
how different is the estimation effort from the evaluation you're
estimating?  

For myself, I use rough-and-ready rules of thumb.  They work well in
practice.

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

Newsgroups: comp.software-eng
From: altizer@figaro (Robert Altizer)
Subject: Re: Tools to automate testing.
Reply-To: altizer@chdasic.sps.mot.com
Organization: Motorola SPS
Date: Thu, 5 Nov 1992 21:18:39 GMT

I have some info on Verilog (the French company, not the design language)
and a couple of others.  Come upstairs and see me.

-- Bob

---
#----------------------------------------------------------------------#
#      Robert Altizer - Motorola ASIC Software Quality Assurance       #
#  1300 North Alma School Road, M/S CH240, Chandler AZ 85224-8517 USA  #
#             Voice: (602) 821-4249 -- FAX: (602) 821-4167             #
# Internet: altizer@chdasic.sps.mot.com -- X.400: R10908@email.mot.com #
#----------------------------------------------------------------------#
#   Nature has neither kernel nor shell, she is everything at once.    #
#                                   -- Goethe                          #
#----------------------------------------------------------------------#
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.software-eng
Subject: Re: Terminal vs. workstations productivity
Date: 3 Nov 92 23:24:20 GMT
	<1992Oct30.000254.15144@den.mmc.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: richard@crowded-house.den.mmc.com's message of 30 Oct 92 00:02:54 GMT

In article <1992Oct30.000254.15144@den.mmc.com> richard@crowded-house.den.mmc.com (Richard Armstrong) writes:
   You should have been sitting here with me over the past two days trying to
   find a subtle bug in a C program on a Unix box telnetted across a network
   from a PC. I would have killed for an X-Terminal so that I could pull up
   xdb, or some other X-based debugger.  I would have been MUCH more productive
   in this situation alone.  Being able to cut and paste code with a mouse in
   vi could have saved me hundreds of hours in productivity during this past
   year. X-Terminals DO save time and increase productivity.

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.  Granted there isn't much software that lets
you do this, but you could always use Emacs :-)

bevan
Newsgroups: comp.software-eng
From: jov@styx.ornl.gov (Judd Jones)
Subject: SE going offshore?
Summary: Claim: US will lose software industry. Opinions?
Organization: Oak Ridge National Lab
Date: Fri, 13 Nov 1992 14:27:54 GMT


Yesterday, Rustum Roy, Professor of Materials Science at Penn State,
gave a lecture here entitled "Is American Science Policy the Enemy
of American Technology?" (He concluded that it is.)

One of his many claims was that just as the US has virtually lost
the DRAM industry (global market share down from 100% in 1976 to
15% today), it will also lose the software industry.

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.

What do you think?

(I note that even a 20:1 productivity differential cannot overcome
a greater than 20:1 cost differential, so greater per capita domestic
productivity may not be terribly relevant.)

judd jones -- oak ridge national laboratory -- jonesjp@ornl.gov
From: prspool@siemens.com. (Peter Spool)
Newsgroups: comp.software-eng
Subject: Defect Costs
Date: 5 Nov 92 21:51:20 GMT

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
Newsgroups: comp.software-eng