HDTenEightyP/NetNews huggingface dataset:
From: pgh@bnr.co.uk (Peter Hamer)
Newsgroups: comp.software-eng
Subject: Re: Lines of Code Metric
Date: 15 Apr 92 09:09:32 GMT
Reply-To: pgh@bnr.co.uk (Peter Hamer)
Organization: BNR Europe Limited, London Road, Harlow, Essex, GB

In the referenced article prspool@doritos.siemens.com (Peter Spool) writes:
>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) 

... and then goes on to give several good reasons.

Another reason is that a sensible organisation tends to give the harder coding
problems to the better programmers. Any fair comparison then needs to allow 
for this, difficult to do though.

But IMHO the real reason for avoiding using LOC etc to rate programmers is 
that a well-run organisation doesn't need to -- and it won't work in a poorly
run one. [By all means use LOC to rate the process.]

In a well run organisation there is sufficient peer review etc for ability to
be pretty evident to everybody. In a poorly run one all available metrics give
ample oportunity for cheating, and the cheat is the last person we should be
rewarding.

Besides most metrics correlate to complexity. A good programmer produces simple
code; allowing for problem complexity and corporate values [speed, error
handling, etc]. Why should a programmer be rewarded for producing complex
code, which needs to be maintained?

Regards, Peter
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 17 Apr 92 12:26:55 EST

In article <1992Apr16.193902.708@nmt.edu>, al@nmt.edu (Al Stavely) writes:
> 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.
> 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.
Apparently.
> 
> 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...

Those people who I know that use the model, have some calibrated empirical
methods for doing the SLOC estimation.  I guess that's where I was starting
from.  Then the model  provides a method of doing the fun and games with
staffing, etc.

George Kambic
standard disclaimer
From: huub@cwi.nl (Huub Bakker)
Newsgroups: comp.software-eng
Subject: Re: Lines of Code Metric
Keywords: LOC, Metric
Date: 6 Apr 92 07:37:40 GMT
Reply-To: Huub.Bakker@cwi.nl
Organization: CWI, Centre for Mathematics & Computer Science

This discussion is getting typical for the subject of software metrics:
weak definitions. I think LOC is a metric which quantifies the size
attribute of a piece of software. Productivity is an attribute of a
software development proces (in the terminology of Bush and Fenton)
which is also depending on the style and skills of the programmers
involved. If you want to use a metrics like LOC/day for measuring the
productivity of a programmer and judge this programmer on the basis of
your measurements, programmers will indeed change their styles to
increase their LOC/day (e.g. adding never called routines).
In this case you need a very fancy definition of LOC to calculate for
all this kind of cheating. I agree that 'wc' will not do this job.

If you want to measure the size of a program and you only want to
compare measures within one organisation (same programming-style
handbook, same programming language, same application domain etc.) most
LOC definitions will do the job.
So the definition you need depends very much on what you want to do with
your measurements results.

CWI, P.O. Box 4079 			Huub Bakker (huub@cwi.nl)
1009 AB Amsterdam
The Netherlands
Tel. 31 20 5924080
From: opaul@fatcity.cts.com (Paul Otto)
Newsgroups: comp.software-eng
Subject: Assembly Language Library
Date: Sun, 05 Apr 92 08:16:22 PDT
Organization: Fat City Software, San Diego, California

 Does anybody here have that assembly language library that was talked about 
in PC Magazine?  The program is called, "UCRSTDLIB".  If you have it, please 
UUENCODE it and post it on this newsgroup.  Thanks.

-- 
opaul@fatcity.cts.com (Paul Otto)
Fat City Software BBS -- (619) 268-9275
UUCP: ...crash.cts.com!fatcity!opaul  OR  ...telesoft.com!fatcity!opaul
From: clarker@cs.utexas.edu (Randal C. Clarke)
Newsgroups: comp.software-eng
Subject: SEI CMM Questionnaire
Date: 8 Apr 1992 11:52:31 -0500
Organization: U Texas Dept of Computer Sciences, Austin TX
Distribution: world
NNTP-Posting-Host: langtry.cs.utexas.edu

    Hello netters,
       I have a copy of the SEI CMM Questionnaire, 
    but I'm missing portions of the following:

    Question 1.2.2
    Question 2.4.11
    'process group' definition

    It seems that whoever photocopied this document
for me accidentally cropped those parts out.  I 
would really appreciate it if someone could e-mail
me those parts or (better yet!) point me to an
electronic version of the document.

  Thanks.

Newsgroups: comp.software-eng
From: medley@sun44.synercom.hounix.org (Bert Medley)
Subject: Re: "Lines of Code" Metric
Organization: Synercom Technology, Inc., Houston, TX
Distribution: na
Date: Fri, 10 Apr 1992 13:19:18 GMT

In article <1992Apr8.151718.1@mdcbbs.com> ivler@mdcbbs.com (J.M. Ivler    ivler@mdcbbs.com) writes:
>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

Are there in references describing this product?  Thanks.

-- 
Bert Medley				medley@synercom.hounix.org 	[work]
					bert@medley.ssdl.com		[home]
Newsgroups: comp.software-eng
From: jmoore@ssd.kodak.com (James H. Moore 726-0322)
Subject: Heterogeneous Platforms, and Software Engineering
Summary: How does a mixed environment work?
Organization: Eastman Kodak
Date: Wed, 8 Apr 92 19:06:28 GMT

This may sound naive, and a bit too practical, but a major technology
hurdle in software development is that when the whole software 
development project team is considered (from systems admins, to 
developers, to managers, to tech writers, to secretaries) we often
end up with a lot of different systems, and applications.  Recently,
someone asked me if a calendar manager existed for Unix, Mac, and PC.
A small thing, but we shouldn't have to resort to the telephone, or
email to try to set up meetings.  

Some of it gets worse from there.  I know that there is a "Groupware"
conference, but does anyone know if they have a process/software development
focus.

I often find that some prople will want to sell you something, but
process effects won't be considered.  Others sometimes lose site of the
software that is being developed (and its bottom line of being THE product)
in looking at the process.

Pointers, bibliographies, etc would be welcomed.

Thanks in advance!!

					Jim


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - James H. Moore, The Software Warehouse, Eastman Kodak Co. 726-0322  -
- -  jmoore@ssd.kodak.com, PROFS: DDTC12(JMOORE)  VMS: DDTC12::JMOORE - -
- -  May your Easter be filled with communion and fellowship with Jesus - -
From: bonsig@gemini.cs.nps.navy.mil (Joseph Bonsignore)
Newsgroups: comp.software-eng
Subject: FOLLOW-UP INFO on SPIN
Keywords: SPIN
Date: 17 Apr 92 12:22:48 GMT
Reply-To: bonsig@cs.nps.navy.mil (Joseph Bonsignore)
Organization: Naval Postgraduate School, Monterey CA

process Improvement Network (SPIN), here is what I've found:

1.  There is a SPIN in the Washington, D.C. are with others starting
in L.A. and Cal Irvin.

2.  The D.C. SPIN usually meets th1st and 2nd Wed. of each month.

3.  The next D.C. meeting will be May 5th 7:30-9:30 pm at CRC.

I will post more info as I find out.

Semper Fi,
Jb
Newsgroups: comp.software-eng
From: smp@iti.org (Stanley M. Przybylinski)
Subject: Re: MCC STP -- Generic Model Paper?
Organization: Industrial Technology Institute
Date: Tue, 7 Apr 1992 12:24:48 GMT

In article <10111@goanna.cs.rmit.oz.au> rds@goanna.cs.rmit.oz.au (Rowan David Stevens) writes:
>
>In the 1989 International Software Engineering Conference proceedings a
>paper by Colin Potts titled "A generic model for representing design methods"
>was published.
>
>Does anyone have this author's e-mail address?
>
>Ta muchly.
>_____________
>Rowan Stevens, e-mail: rds@goanna.cs.rmit.oz.au
>RMIT, Dept. Computer Science. GPO BOX 2476V Melbourne, VIC. Australia 3001.
>Phone: +61 3 660-2348; Fax: +61 3 662-1617
>-----------------------------------------------------------------------------


As far as I know Colin is still at MCC.  Try potts@mcc.com.
-- 

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: dave@digicomp.com (Dave Bulatek)
Newsgroups: comp.software-eng
Subject: Re: 3rd Reverse Engineering Forum
Date: 10 Apr 92 12:51:33 GMT
Organization: DIGICOMP RESEARCH CORPORATION

>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???
>
>thanks
>
>sanjiv gossain
>
>gossain@uk.tele.nokia.fi
>
It looks like you are looking for info on SEI's Capability Maturity Model
for Software. It deals with the software process improvement. According
to one of SEI's documents that I have, the info can be received from:

   CMM Info
   Software Process Program
   Software Engineering Institute
   Carnegie Mellon University
   Pittsburgh, PA  15213-3890
   (412) 268-7700
   Internet: cmm-info@sei.cmu.edu

Electronic versions of their docuemnts are available through the Internet.
If you have Internet access, you may obtain these files using 
anonymous ftp by entering the following:

   ftp ftp.sei.cmu.edu
   login: anonymous
   password: <your user id or any string>
   cd pub/cmm
   get <files>
   quit

The instructions for obtaining these files is contained in READ.ME. The 
primary electronic version is a set of Mac Word 4.0 files, which have been 
compressed and formatted for net distribution using StuffIt Classic (TM)
and BinHex. Other formats, including ASCII text and Postscript, are also
available.

...Dave


-- 
Dave Bulatek
Digicomp Research Corp.
Internet e-mail: dave@digicomp.com
From: bohly@tpki.toppoint.de (Jens Bohlmann)
Newsgroups: comp.software-eng
Subject: Search for Dev.Tools
Date: 15 Apr 92 16:06:42 GMT
Organization: Toppoint Mailbox e.V.

Wir  wollen mit einem Entwicklerteam von 5 bis 6 Leuten Standard
( - Branchen)  Software entwickeln.  Da wir  uns nicht auf ein
spezielles Betriebssystem  / eine Oberflaeche festlegen wollen,
suchen wir Entwicklungswerkzeuge, mit denen man  fuer die
verschiedensten Systeme Software entwickeln kann ohne auf die
Vorteile grafischer Oberflaechen voellig zu verzichten.
Insbesondere sind wir interessiert an :

 - Werkzeuge Zur  Erstellung von Bildschirmmasken
 -  Einbindung unterschiedlicher Datenbanken mittels
    SQL
 -  Versions - und Sourcenmanagement
 - entwicklungsbegleitende
     Dokumentationswerkzeuge

     Als Zielbetriebssysteme kommen in Frage:

 - DOS / NOVELL
 - UNIX
 - VMS (Vax)

 In der Wahl des Entwicklungssystemes sind wir zur
 Zeit noch nicht festgelegt.


 Jens Bohlmann

 fuer
 AMIC Datenservice Kiel
 Wrangelstrasse 16
 D - 2300 Kiel 1
 Germany
 
			   
-- 
---------------------------------------+-------------------------------------
Jens Bohlmann	bohly@tpki.toppoint.de ! Ich lerne zu entscheiden, das Heute
2300 Kiel	                       ! zu einer vergnueglichen Erfahrung zu
---------------------------------------+ machen. ----------------------------
From: peterc@suite.sw.oz.au.sw.oz.au (Peter Chubb,x114,6982322,3982735)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 14 Apr 92 23:13:40 GMT
Organization: Softway Pty Ltd
Originator: peterc@suite.sw.oz.au

From article <36650049@hpopd.pwd.hp.com>, by daves@hpopd.pwd.hp.com (Dave Straker):
>>The problem with the Lines of Code metric is really "what is a line of code"?
>>...
>>John
> 
> I would take a step back from this, and ask,
> 
>      "What is the purpose of measuring lines of code?"

We measure lines of code, comments and all (using wc -l).  We find
that that is a measure that has significant correlation to number of
bugs exposed at reviews and during testing, and this is its main use.

I think the reason for this is that the house coding style is adhered
to by all our programmers, so things of similar complexity end up with
similar numbers of lines (more compact representations need bigger
comments -- leading to similar overall lines of code).  We're
programming in C, but have found similar behaviour for lines of design
(English text, slightly modified IEEE 1016 format, troff input)
correlating with problems in the design.

The lines-of-xxx metric has three major advantages -- it's easy to
measure, is applicable to things other than code, and enables us to
estimate numbers of bugs.

It may be that other analysis methods are better for one or other of
these, but on one project we tried to analyse recently, using a
variety of complexity measures, the correlation with bugs found was no
worse for lines of code than it was for the other methods tried,
and lines of code was much easier to calculate.

So, what do other people use Lines of Code for?


			Regards,

				- Peter Chubb

Softway Pty Ltd, P.O. Box 305, Strawberry Hills, NSW 2012, AUSTRALIA
Phone: +61 2 698 2322;       Fax: +61 2 699 9174;     Telex: AA27987
Internet: peterc@softway.oz.au	   UUCP: ...!uunet!softway.oz!peterc

#include <std/disclaimer>
From: rds@goanna.cs.rmit.oz.au (Rowan David Stevens)
Newsgroups: comp.software-eng
Subject: MCC STP -- Generic Model Paper?
Date: 7 Apr 92 01:51:36 GMT
Article-I.D.: goanna.10111
Organization: Comp Sci, RMIT, Melbourne, Australia


In the 1989 International Software Engineering Conference proceedings a
paper by Colin Potts titled "A generic model for representing design methods"
was published.

Does anyone have this author's e-mail address?

Ta muchly.
_____________
Rowan Stevens, e-mail: rds@goanna.cs.rmit.oz.au
RMIT, Dept. Computer Science. GPO BOX 2476V Melbourne, VIC. Australia 3001.
Phone: +61 3 660-2348; Fax: +61 3 662-1617
-----------------------------------------------------------------------------
From: rms@Miles.COM (Rob Schultz)
Newsgroups: comp.software-eng
Subject: Separation of Software testing from System Testing
Date: 6 Apr 92 21:06:31 GMT
Organization: Miles Inc., Diagnostics Division, Elkhart, IN


Hello, all 

I am involved in a discussion regarding the roles of a Software Testing
group and a Software Quality Assurance Group.  The discussion centers
around how much involvement the Software Test Group should have in the
Systems Testing for an embedded instrument.  The basic disagreement is 
whether Software System Testing should be a separate stage of testing or 
if it should be a part of the System Testing performed on the instrument.

The two sides of the issue are summarized as follows:

Software System Testing should be a part of System Testing for the
instrument, since there is so much overlap between the two.  Many of
the software functions cannot be adequately tested without some hardware
intervention (primarily since the System Specification never made a clear
distinction between the hardware operations and the software operations -
there is no clear interface).  Therefore, let's just skip the Software
System Testing since it will all be handled during the Instrument System
Testing anyway.

The other side is that Software System Testing should NOT be a part of the
System Testing, since System Testing targets a much broader type of errors
than Software System Testing.  The fear here is that if the Software 
System Testing phase is skipped, then an entire class of errors may be 
missed or masked out by the hardware or systems issues.

The response to this is that it really doesn't matter, since the system
testing will prove out the instrument's functionality.  After all, we are
building a system that consists of Mechanical, Optical, Chemical, Electrical,
and Software Components.  The end result is more than just a software
product.

Both sides in this debate have good points.  My problem is to determine which
approach to take for this project.  Can anyone provide some additional 
insights for me?

I know that there will be a lot of opinions on which of these two approaches
is the more appropriate.  Feel free to email responses or post them (a good
debate is always nice for a while), and I will try to summarize all of the 
responses in about a month.

Thanks in advance -
     rms

-- 
Rob Schultz  At work: rms@miles.com             At Home:  rms@andria.miles.com
      {uunet|iuvax}!nstar!miles!rms       {uunet|iuvax}!nstar!miles!andria!rms
                    +1 219 262 7206                            +1 219 262 2412
From: song@siam.ics.uci.edu (Xiping Song)
Subject: Re: INFO NEEDED on OOA Methodologies
Newsgroups: comp.software-eng
Reply-To: song@ics.uci.edu (Xiping Song)
Organization: Univ. of Calif., Irvine, Info. & Computer Sci. Dept.
Date: 13 Apr 92 03:52:49 GMT

In article <1992Apr12.070527.26187@monu6.cc.monash.edu.au> steven@monu6.cc.monash.edu.au (Steve Stergakis) writes:
>
>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
>
Hi,

  I have done quite a number of methodology comparisons in the past
years. A paper I coauthored with Dr.Osterweil will appear in the
May issue of IEEE Software. This paper discusses the comparisons
of design methodologies. It also gives a list of references you might
find interesting.

Xiping Song
From: puckett@orion.NoSubdomain.NoDomain (Robert Puckett 283-4017)
Newsgroups: comp.software-eng
Subject: Heuristic programming techniques
Date: 10 Apr 1992 16:50:14 GMT
Organization: nasa-jsc


Does anyone know of any sources or references describing programming techniques
using heuristics to help define/develop software models?


Thanks for the help

Robert
Newsgroups: comp.software-eng
From: amnon@robsv3.uucp (Amnon Lotem)
Subject: Test Coverage Analysis Tool
Organization: ROBCAD Software Ltd. Herzelia - ISRAEL
Date: Thu, 9 Apr 1992 16:33:55 GMT



Hi,

1. I am searching a tool for test coverage analysis. 
   I have heard about the following tools:

   a) STW/COV of Software Research Inc.

   b) Hindsight of Advanced Software Automation Inc. 

   c) LOGISCOPE of Verilog

2. I would like to get information about experience of users in working
   with these tools (for performing test coverage analysis). 

3. I would also be glad to hear about other products in this field. 

4. Does somebody know about test coverage analysis which run on SGI?

5. Please send answers directly to me:
      email:  INTERNET: amnon%robcad@uunet.uu.net
                  UUCP: uunet!robcad!amnon
  
   I will summarize the answers at the end of this process.

Thanks in advance,

Amnon Lotem
Robcad Technologies Ltd 
Israel

Newsgroups: comp.software-eng
From: hart@zeus.franklin.edu (Drew Hart)
Subject: Request for info on Taguchi Variance Analysis applied to Software
Organization: Franklin University
Date: Sat, 11 Apr 1992 18:05:32 GMT




   Does anyone know where I might find research material on applying Taguchi's
methods to software and/or using his methods in conjunction with Software
Configuration Management?

   Please send your replies to hart@zeus.franklin.edu. I would appreciate
replies before Thursday, April 16th, 1992, as the computer at Franklin
University will be down for at least two weeks after that date.

   Thanks,

   Drew R. Hart
From: risingl@gtephx.UUCP (Linda Rising)
Newsgroups: comp.software-eng
Subject: Thanks for locating Linger
Date: 6 Apr 92 17:37:18 GMT
Organization: AG Communication Systems, Phoenix, Arizona

Thanks to Terri L. Thomas at IBM for helping me reach
Rick Linger.  I tried replying to your message but it
came back "user unknown" so I'm resorting to this approach.

Thanks!


-- 
Linda Rising, AG Communication Systems, Phoenix, AZ
UUCP: ...!{ncar!noao!asuvax | att}!gtephx!risingl
Internet: gtephx!risingl@asuvax.eas.asu.edu
voice: (602) 582-7617        fax:   (602) 581-4022
From: bhides@tekig1.PEN.TEK.COM (Bhide Sandhiprakas)
Newsgroups: comp.software-eng
Subject: OO testing/metrics methodology and tools
Date: 17 Apr 92 06:48:12 GMT
Organization: Tektronix, Inc., Beaverton,  OR.

I am interested in finding out about OO (c++) testing methodologies
and tools?  I am also intrested in finding out if there are some standard
metrics (OO) that people use.  In case of request #1, I am asking I guess
as to how do you test OO programs.

Any help is appreciated.  I will post the summary to the net if there is
an interest.  If there is FAQ on this, please let me know.

Sandhi
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 8 Apr 92 08:32:08 EST

In article <7APR199214170281@adpdp2.lanl.gov>, 105126@adpdp2.lanl.gov (John Curtis) writes:
> 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"?

The LOC metric is one metric among many.  (we're actually
discussing this again?).  You must achieve _agreement_ from the developers on
what an LOC means, how the metric will be used, or if, when, and by whom, and
then measure its compliance.  LOC can be used or misused like anything else. 
If you really want it to be measurable, then the program style must be peer
enforced.

George Kambic
standard repetitious disclaimer