HDTenEightyP/NetNews huggingface dataset:
From: bobd@zaphod.UUCP (Bob Dalgleish)
Newsgroups: comp.software-eng
Subject: Std 829-1983 Software Test Documentation
Date: 15 Apr 92 17:43:55 GMT
Organization: Develcon Electronics Ltd., Saskatoon, SK, Canada

A year ago, we (re)introduced into our company the use of the ANSI/IEEE
Std 829-1983 standard for software test documentation.  It augmented the
existing acceptance test process, and allowed our test personnel to be
very effective in identifying problems with a new product (a token-ring
bridge).  The resulting release of the product was smoother and easier
than previous products, and convinced the powers-that-be to commit more
resources to implementing the standard test processes in our
organization.

We have half-a-dozen implementors and a similar number of testers, with
roles changing occasionally.  Generally, experience ranges from a
minimum of two years of testing to a maximum of twenty-one years of
software development.

The areas that we are still having birth-pangs with are:

	o separating out the fundamental differences between test
	designs, cases, and procedures.

	o preventing the explosion in numbers of cases caused by
	combinations of inputs and outputs - generally data
	communications requires very large numbers of different inputs
	with potentially large numbers of different outputs.

	o writing the test designs, cases and procedures to be reusable
	across several product lines that have a common implementation base.

	o automating the recording of the test designs, cases and
	procedures in such a way that multiple test designers and
	implementors have access to a common database, while not bogging
	everybody down in paperwork and bureaucracy.

Does anybody else have experience with this or a similar standard that
they can share with me?  What rules of thumb do you use to "debug"
problems (1) and (2)?  How do you get to reuse test cases?  Is there
something better than FoxBase+ on Xenix for automating the process (I
know the answer to this one, but tell me yours)?

As always, I will summarize to the net.
-- 
-- * * * CFV: net.short.signatures * * *--
Bob Dalgleish	 zaphod!bobd@access.usask.ca     CompuServe: 70521,2011
From: prspool@doritos.siemens.com (Peter Spool)
Newsgroups: comp.software-eng
Subject: Re: Lines of Code Metric
Date: 14 Apr 92 15:18:22 GMT

David Masterson includes a suggestion about measuring the productivity/quality 
of INDIVIDUAL programmers.  There are important reasons for avoiding the use 
of measurements of any kind to RATE individuals! (One exception in point 3 below) 

Some of these reasons include:

1) Over what TIME FRAME are the measurements being pooled and averaged?
   Are we evaluating DAILY values, for instance?
   (SHORT TERM results are not worthwhile -- they too dependent on external
    events and random fluctuations)

2) Rating individuals is bad for morale.  The real major benefit to collecting
   and analyzing measurements is the guidance the results can give us
   in implementing improvements to the way THE WHOLE ORGANIZATION
   operates.

3) Rating individuals separately can often be MISLEADING.  
   Beyond a certain point, it is impossible to separate random differences
   in measurement results from statistically significant differences.
   Using results for individuals to FIRE people is therefore unjustified.
   If measurements of individual people are taken, it is important that they be
   used to HELP programmers IMPROVE their ability by such means as more advice
   from more experienced staff, or training classes in improved techniques.
Newsgroups: comp.software-eng
From: ewoods@hemel.bull.co.uk (Eoin Woods)
Subject: Re: SEI Process Maturity Model
Organization: Bull HN UK
Distribution: comp.softwareeng
Date: Tue, 7 Apr 92 11:52:10 GMT

gossain@uk.tele.nokia.fi (Sanjiv Gossain) writes:
>I'm trying to get hold of the SEI Process Maturity Model
>but don't really know who to contact. Can anyone help in this???
The papers can be FTPed from ftp.sei.cmu.edu
(Postscript and Apple WP formats I think)

Eoin.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Eoin Woods                         | Tel : +44 442 88-4467 (Fax 4570)     |
| Application Services Product Unit  | BVN : (UK) 773-4467                  |
| Bull HN Information Systems        |                                      |
| Maxted Road                        | E.Woods@hemel.bull.co.uk             |
| Hemel Hempstead, Herts HP2 7DZ, UK | ...!relay1.uu.net!uknet!brno!ewoods  |
Newsgroups: comp.software-eng
From: pattis@cs.washington.edu (Richard Pattis)
Subject: Seeking Citation
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Fri, 10 Apr 92 17:57:07 GMT

I recall reading something recently about a one line code patch that was not
tested, but instead put into immediate service (the phone company)? The patch
just set the value of identifier, but the name was mistyped (something like
Rl instead of R1). I cannot remember the source, but would like to cite it.
The error did something drastic

Rich Pattis
-- 
------------------------------------------------------------------------------
  Richard E. Pattis			"Programming languages are like
  Department of Computer Science	 pizzas - they come in only "too"
    and Engineering			 sizes: too big and too small."
From: al@nmt.edu (Al Stavely)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 16 Apr 92 19:39:02 GMT
Article-I.D.: nmt.1992Apr16.193902.708
Organization: New Mexico Tech, USA


In article <1992Apr16.115248.7815@iccgcc.decnet.ab.com> kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) writes:
>But that's the whole point of prediction and measurement.  IMHO you seem to be
>saying that we should not be making estimations because they are not correct. 
>It is only by measurement and feedback that models constructed by Boehm and
>others can be corrected and hopefully eventually converge.
>> 
>George Kambic
>standard disclaimer

I think you missed my point.  It doesn't matter how correct a model is, if
what it gives you is cost as a function of SLOC.  That doesn't help at all in
predicting cost AHEAD OF TIME if you have no way of predicting SLOC
AHEAD OF TIME.

Let's take some numbers.  Boehm claims (_Software Engineering Economics_, p.
495) that his Detailed COCOMO model estimated development effort within 20% of
actual 70% of the time.  Never mind that this was on data from 63 projects, 56
of them being the ones that provided the data that he curve-fitted to get the
model in the first place!  Let's ignore this, and also make the (unlikely)
assumption that his formulas will be just as accurate on projects at our site
as on aerospace projects at TRW.

Now suppose that we can improve his model so that it gives accuracy within 10%
70% of the time.  Does this help much?

Maybe, if our SLOC estimates are really good.  But how many of us can estimate
total SLOC within 20%, say, at the time we are just planning the project?  Can
I see a show of hands?  (Or can anyone cite data on how accurate people really
are at guessing SLOC ahead of time?)

If the best we can do is guess SLOC within a factor of 2, which I suspect is
more representative of the real situation under most circumstances, then the
extra 10% improvement in the model isn't going to help -- the cost prediction
won't be more accurate than a factor of 2 anyhow.

If we had a magic way of getting the SLOC numbers before we start the project,
models like Boehm's would be really valuable.  Sure, it would be great to know
the cost of a project within 20% before we have to make a go/no-go decision!
But with models like these we can't do any such thing, no matter how accurate
they are.

That's all I was trying to say.  If you find models like Boehm's interesting
for reasons other than real prediction, don't let me discourage you...

-- 

	- Allan Stavely, New Mexico Tech, USA
From: steven@monu6.cc.monash.edu.au (Steve Stergakis)
Newsgroups: comp.software-eng
Subject: INFO NEEDED on OOA Methodologies
Date: 12 Apr 92 07:05:27 GMT
Organization: Monash University, Caulfield Campus


NOTE: this message has been posted for persons that either use, teach 
or have some opinion regarding current OOA methodologies being 
used...

THIS MESSAGE HAS BEEN CROSS POSTED TO MANY NEWS GROUPS.  PLEASE 
DISREGARD IT IF HAS BEEN POSTED TO AN INCORRECT AREA.

i am a postgraduate student who is currently studying OOA and 
would greatly appreciate any information regarding experience
you have had with object oriented methodologies

as i am about to write a critical review of the current OO methodologies i 
would appreciate if you could tell me which approach you prefer.. or if
you know of any article that have compared current OOA methods, that would
also be greatly appreciated...

i am especially interested in persons who use such methodologies 
in practice.. their extent of their use in your work area.. 
the type of work you do.... and your opinion!

PLEASE feel free to comment on any of the above questions.. if you do
not wish to relate specific information pertaining to your work /
work environment, then leave it out

NOTE: if possible please reply directly to me 

thanks in advance

+------------------------------------------------------------+
| Steven Stergakis      steven@monu6.monash.cc.edu.au        |
|                                                            |
|                       (Post Graduate)                      |
|                       Faculty of Computing and Information |
|                       Technology                           |
|                                                            |
|                       Monash University - Australia        | 
+------------------------------------------------------------+
From: gossain@uk.tele.nokia.fi (Sanjiv Gossain)
Newsgroups: comp.software-eng
Subject: Oberon
Date: 6 Apr 92 13:55:39 GMT
Distribution: comp.software-eng
Organization: cpd


I'm trying to get some references on the
Oberon language. Could someone please
email me any deatils of relevant references 
on this topic. Any help in this appreciated.

Thanks

Sanjiv Gossain
NOKIA Telecommunications

Email: gossain@sjclus.tele.nokia.fi
       gossain@uk.tele.nokia.fi
Newsgroups: comp.software-eng,news.answers
From: smp@iti.org (Stanley M. Przybylinski)
Subject: Re: What is _Software Process_?
Organization: Industrial Technology Institute
Date: Fri, 17 Apr 1992 12:02:12 GMT

In article <1992Apr15.154629.7194@demon.co.uk> Trevor Jenkins <tfj@cix.compulink.co.uk> writes:
>In the comp.software-eng reading materials FAQ (readmsg) there is
>a topic on _Software Process_. One of the cited references is
>from the proceedings of the 4th Int'l Software Process Workshop.
>I have read the proceedings and have to admit that I was none the
>wiser for doing so. Either the concept is so simple that I missed
>the point or I really do not understand it all. Perhaps somebody
>could provide me with a succinct definition of the idea and/or
>recommend an introductory text.
>

The idea is to apply the notion of process from manufacturing to the
creation and evolution of software.  There are different flavors, of course,
but much of the current emphasis stems from the work of my former employer.
Try to get your hands on "Managing the Software Process" by Watts Humphrey,
Addison-Wesley.  I can't promise you'll be any wiser from reading that
either but you should get enough to understand what people mean by the term.

>-----------------------------------------------------------------
>"RE: deemed!"
>email: tfj@cix.compulink.co.uk            radio: G6AJG
>mail: 134 Frankland Rd, Croxley Green, RICKMANSWORTH, WD3 3AU
>phone: +44 (0)923 776436


-- 

Stan Przybylinski, Sr Member of the Technical Staff - Technology Transfer
Industrial Technology Institute, P.O. Box 1485, Ann Arbor, MI 48106
(313) 769-4517   FAX: (313) 769-4064
From: soppe@pttrnl.nl (Soppe M.)
Newsgroups: comp.software-eng
Subject: Metrics tool
Date: 9 Apr 92 14:34:32 GMT
Organization: PTT Research


Dear Netters,

I have a question for you about metrics. We are looking for a tool that
can analyze C and/or dBase systems (on a PC) and produce metrics from it.
The tool should be able to do more than LOC, Halstead and McCabe.
A.o. we would like to see the Henry and Kafura metrics. The tool
should not be expensive (under $ 500,-). There is no need for beautiful
pictures as output, plain text will do fine.

Who can help us?

Best regards,

Margareth Soppe
M.M.Soppe@research.ptt.nl
Newsgroups: comp.software-eng,news.answers
From: ajackson@csr.UVic.CA (Ann  Jackson)
Subject: Re: Lines of Code Metric
Reply-To: ajackson@csr.UVic.CA (Ann  Jackson)
Organization: University of Victoria
Date: Fri, 10 Apr 92 16:55:16 GMT

In article <CIMSHOP!DAVIDM.92Apr9174047@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>
>Off hand, I could think of two approaches:
>
>1.  Don't tell your programmers that you are measuring LOC.  This will allow
>you to measure their standard LOC with less chance for abberations.
>
>2.  Tell *ALL* your programmers that you are measuring LOC.  If they want to
>artificially increase their LOC, it will still average out because everyone is
>increasing their LOC.
>
Approach 2 assumes a uniform (and low) standard of programmer integrity.
Fortunately, this seems unrealistic.
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
From: ivler@mdcbbs.com (J.M. Ivler    ivler@mdcbbs.com)
Date: 8 Apr 92 15:17:18 GMT
Organization: M&E (Division of EDS), Cypress CA
Nntp-Posting-User: ivler

Would you as a General Contractor to estimate the cost of building you a home 
on how many nails it will take?

I thought not. How is that differnt than lines of code. Issues such as the
complexity of the software, is it real-time, batch, cpu intensive, hooked into 
the OS? All of these things have to be taken into account.

A "better mousetrap" was proposed by Steven Colborne and Dr. Hannes Callison of 
Magnavox Advanced Products and Systems Company in Torrance, CA. This system was 
called SAFE, for Syntatical Analysis For Estimation. It was mildly based one B. 
Bohems work in cost modeling as well as the strict definitions that are 
required in DOD requirements documents.

jmi
ivler@mdcbbs.com
From: chris@chinook.atd.ucar.edu (Chris Webster)
Newsgroups: comp.software-eng
Subject: Re: HOW Should academics teach SE????
Date: 8 Apr 92 16:08:13 GMT
Reply-To: chris@chinook.atd.ucar.edu
Organization: Research Aviation Facility, NCAR, Boulder, CO


At University of Colorado we had to take a 1 year software engineering
course.  Industry submitted projects to the school.  The students
(in groups of 3-4) then picked a project.  We went through all the
phases of Functional Spec, Design, Prototyping, implementation, debugging,
and documentation (Users manual, Reference Manual, Tutorial).  Obviously
each project varied in what was needed (i.e. my project only needed man
pages for the Reference Manual).  A pre-requisite was a Scientific writing
course.  I found the whole process most enlightening.

--Chris
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 10 Apr 92 19:39:16 GMT
Organization: /theta/theta5/unc/martinc/.organization
In-reply-to: tfj@cix.compulink.co.uk's message of 6 Apr 92 20:45:03 GMT

In article <1992Apr06.204503.337@demon.co.uk> tfj@cix.compulink.co.uk (Trevor Jenkins) writes:


   In his message <2APR199214265586@adpdp2.lanl.gov> 105126@adpdp2.lanl.gov
   (John Curtis) says,

   >>  I don't like using this metric, but management seems insistant
   >>  that we use it for a while (until something better can be fully
   >>  implemented).

   Why not ask management for a scale balance and weigh the listings? This
   has the advantage of being independent of source language. Assuming that
   you are comparing like with like, eg compiler listings or straight print
   file, and that you use the same weight paper on all printer there will be
   high correlation between the lines of code and the weight of the listing.
   If they will not buy you the scale then ask for a ruler and measure the
   depth of paper again there will be a high correlation between lines of
   code and listing height.

   By this time management should have seen the stupidity of using this
   metric and you can then persuade them of the efficacy the metric that
   you think should be used instead.

   None of the above is my work, why work when you can plagiarise? :-)

Remember why God made your eyes!  But remember please, always to call it
research. 

At the risk of restarting the SLOC vs other measures debate again, can
someone point out to me a single study that shows SLOC are less
effective in practice than other measures?  I recall reading an article
(and find it fits with my experience) that SLOC and other measures are
about equally predicitive.  In fact, I believe it has been shown that
SLOC counts and Halstead (among others) correlate at about the 90
percent level in high-level languages.

Of course, since SLOC and pages of listings also correlate highly, we'd
conclude that other measures and pages of listings correlate highly as
well; so the ruler on the listings might just be applicable.

--
Charles R. Martin/(Charlie)/martinc@cs.unc.edu/(ne crm@cs.duke.edu) 
O/Department of Computer Science/Sitterson Hall/UNC/Chapel Hill, NC 27599
H/3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
The universe is full of magical things patiently waiting for our wits to
grow sharper.  -- Eden Phillpot, I'm told.  Anyone have a better reference?
From: 105126@adpdp2.lanl.gov (John Curtis)
Newsgroups: comp.software-eng
Subject: "Lines of Code" Metric
Date: 7 Apr 92 21:17:00 GMT
Article-I.D.: adpdp2.7APR199214170281
Organization: Los Alamos National Laboratory, EMVAX
News-Software: VAX/VMS VNEWS 1.41

The problem with the Lines of Code metric is really "what is a line of code"?
If five different programmers can accomplish the same action using five
different types of commands, how do you count that? Or better yet, what happens
when you can "stack" commands on a line OR (in the same program) put commands
on separate lines? Do you have to enforce a programming (coding) standard and
make all you programmers write their code in the same "style"?

John
Newsgroups: comp.software-eng
From: mat@mole-end
Subject: Re: Software Engineering Queries
Keywords: cheating
Organization: :
Date: Mon, 6 Apr 1992 00:13:48 GMT

In article <1358@sheoak.bcae.oz>, olle@sheoak.ucnv.edu.au (John Olle) writes:
> i899435@sheoak.ucnv.edu.au (I COUROULIS) writes:
> 
> >Hi all, I just have a few questions I was wondering someone out
> >there could answer for me:
 
> >1.  What are the origins of software engineering ?
> >    (The need, the beginning, the disciplines used, etc)

> Please do not provide him with direct answers to these questions as
> it is his task to research them HIMSELF.  Cheating will not be 
> condoned.
 
> Good try, Ian
 
> John Olle, his lecturer

Would it be research for him to look up the past discussions on this
topic, some of which have actually generated a little light?  I
believe a few of them made it into FAQ'd list of available files.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
From: chandran@comp.lancs.ac.uk (M. Ramchandran)
Newsgroups: comp.software-eng
Subject: List of US Universities and Companies interested in SE research.
Date: 13 Apr 92 10:26:24 GMT
Organization: Department of Computing at Lancaster University, UK.

Dear Netters,
Could anyone send me a list of US and Canada Universities and companies
interested in SE/ software reuse research?

List of top specilaist in SE/reuse?

All with email/fax/phone numbers will be more helpful. This is for a friend
who is interested in doing some survey/questionaire for his research.

chandran
Email: chandran@vax.livpol.uk.ac
From: dise@vector.uoregon.edu (David Ellsworth-Casti)
Newsgroups: comp.software-eng
Subject: Software Management Conference
Keywords: software management legal uo issues
Date: 9 Apr 92 21:21:18 GMT
Organization: University of Oregon Network Services

UO EVENT

For Immediate Release

Contact: 	Kassia Dellabough
		503-346-3537

Software Management Conference:  
Defining the Gray Zones in Software Copyright
May 17 & 18, 1992


The University of Oregon will be hosting a Software Management Conference on
May 17 &18, 1992 at the Portland Red Lion Hotel - Jantzen Beach.  The theme of
the conference, software copyright, will address pressing issues in software
management and licensing.  
Information systems managers, lab managers (all levels), system users, and
desktop publishers will find this conference of benefit in enhancing their
current knowledge of software and copyright laws and clarifying what legal
status is.  The conference will feature pre-conference sessions Sunday, May 17
for more in-depth exploration of specific issues such as, interpreting site
license agreements, System 7 and copyright issues, self audits, scanning,
photocopy and the law and managing upgrades. Large and small software companies
will be making mini-presentations to clarify licensing agreements. Monday, May
18 will feature general sessions on software development trends, implementing
solutions and issues in training site software management and audit analysis. 
Speakers include; Karen Billings - Claris Corporation, Dave Frohnmayer - UO Law
School Dean, Ken King - President Educom, Sharon Tate - Executive Director,
National Microcomputer Management Association, Domenick Vetri - UO Law School,
Ken Wasch -  Executive Director, Software Publishers Association and David
Dailey, Williams College. A panel debate between developers and users will be
featured and audience participation will be encouraged.

For further information please contact conference director: Kassia Dellabough,
UO Continuation Center, 503-346-3537, inside Oregon 1-800-824-2714, FAX
503-346-3509
From: rh@smds.UUCP (Richard Harter)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 15 Apr 92 05:01:49 GMT
Organization: SMDS Inc., Concord, MA

> In the referenced article jerry@ajones.austin.ibm.com writes:

> |More to the point, how do you count modified lines of code?  In a development
> |shop that goes through mulitple releases of the same software, counting lines
> |of code becomes a tricky exercise.  Obviously in the first release you count
> |lines of code because its all new.  In subsequent releases what do you count?
> |Obviously you can't just count total lines of code because that gives an 
> |unrealistic (IMHO) number as to the amount of coding that was done.

If you have any sort of version control you can get the number of lines
added and deleted as a function of time.  If your development process is
normal you will find that, at any particular time, 80% of the code is original
code, 20% is modified code, and about 10% has been deleted.  The interesting
thing is that these figures tend to be fairly stable across projects and
across time.  [The 80% includes all code that is unaltered once it is
added.]  The inferences are:

a)	Modification over time proceeds principally by adding new code
	rather than by reworking old code.

b)	The rework percentage is 10-25 percent.

c)	Most files become quiescent and are never altered again after
	initial rework; a small percentage are reworked heavily.

d)	To the first order LOC is just as good a measure as modified LOC.

-- 
Richard Harter: SMDS Inc.  Net address: rh@smds.com Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742.    Fax: 508-369-8272
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.