Re: Automated Ada Physical Source Lines Counter

Re: Automated Ada Physical Source Lines Counter

[Joe Hildebrand]

>> "timothy" == timothy shimeall <shimeall@cs.nps.navy.mil> writes:

   timothy> This code was developed for US Government purposes (MS
   timothy> Thesis study) by US Government personnel, and as such is
   timothy> uncopyrighted. Source code (in Ada and Ada-generating-tool
            ^^^^^^^^^^^^^
   timothy> input files) is included in the distribution.  The tool is
   timothy> distributed in "as is" condition, with no warantee stated
   timothy> or implied (see the file READ_ME for more explicit
   timothy> disclaimers and limits of availability).

Doesn't this mean that anyone can take your work, copyright it, and
prevent you from distributing it?  Are you sure that is what you want?

>From the READ_ME file:

  READ_ME> Installation of this software is hereby forbidden where
  READ_ME> disclaimers of warantee are void or limited with respect to
  READ_ME> the agreement stated above.

How can you enforce this with NO copyright?

I might suggest GNU copyleft as a model for your copyright/disclaimer
policy.

I'm not trying to be hostile... these are just things you might like
to think about.

--

----------
Joe Hildebrand                          Fuentez Systems Concepts
hildjj@fuentez.com                      11781 Lee-Jackson Hwy, Suite 700
Software Engineer                       Fairfax, VA 22033
                                        Phone: (703)273-1447   
                                        Fax:   (703)273-2972

Standard disclaimers apply

Re: Automated Ada Physical Source Lines Counter

[agate!doc.ic.ac.uk!uknet!mcsun!sun4nl!tedux.hobby.nl!mo.hobby.nl!compi.ho]

>> On Wed, 15 Sep 1993 20:46:00 GMT, shimeall@cs.nps.navy.mil (timothy
>> shimeall) said:

  ts> This message announces the availabilty of the prototype Automated Ada
  ts> Physical Source Lines Counter.  This tool, described at a presentation
  ts> during the most recent SEI Software Engineering Symposium, allows the
[...]

  ts> This code was developed for US Government purposes (MS Thesis study)
  ts> by US Government personnel, and as such is uncopyrighted. Source code
[...]

  ts> 2120024 Sep 15 13:11 count.tar.Z - compressed tar image of the
  ts> distribution

Is this a joke? 2.1M for counting source code lines? It must have been
written in ada itself. What is wrong with 'wc *.ada', where 

-rwxr-xr-x   1 root     root         4712 May 10 21:53 /bin/wc

of 4K is used?

Who needs number of lines as a metric anyway. Completely useless IMHO
and only used to impress managers who don't know a thing on software
development.
-- 
_______________________________________________________________
Peter Mutsaers, Bunnik (Ut), the Netherlands.

Re: Automated Ada Physical Source Lines Counter

[agate!tully.CS.Berkeley.EDU!hilfingr]

In article <MUTS.93Sep17095542@compi.hobby.nl>, muts@compi.hobby.nl (Peter Muts
aers) writes:
> 
> Who needs number of lines as a metric anyway. Completely useless IMHO
> and only used to impress managers who don't know a thing on software
> development.

This issue is discussed periodically on the software engineering
bulletin board.   The really annoying thing seems to be that despite all the
perfectly-reasonable QUALITATIVE arguments about why LOC should NOT
be a useful measure of anything (notably effort), it appears
to have some rather strong EMPIRICAL correlation with effort.  That
is, if one can estimate LOC, one can estimate effort to within 10k%
for small k, at least within a given organization.  Don't ask me why;
I don't pretend to know.

P. Hilfinger

Re: Automated Ada Physical Source Lines Counter

[agate!spool.mu.edu!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mkso]

In article <27ga4t$13m@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU writes:
>In article <MUTS.93Sep17095542@compi.hobby.nl>, muts@compi.hobby.nl (Peter Mut
saers) writes:
>> 
>> Who needs number of lines as a metric anyway. Completely useless IMHO
>> and only used to impress managers who don't know a thing on software
>> development.
>
>This issue is discussed periodically on the software engineering
>bulletin board.   The really annoying thing seems to be that despite all the
>perfectly-reasonable QUALITATIVE arguments about why LOC should NOT
>be a useful measure of anything (notably effort), it appears
>to have some rather strong EMPIRICAL correlation with effort.  That
>is, if one can estimate LOC, one can estimate effort to within 10k%
>for small k, at least within a given organization.  Don't ask me why;
>I don't pretend to know.

This is a very important point.  LOC as the basis for software estimation
WORKS, when used within an organization that has taken the trouble to
calibrate the estimating process.  Depending on how it is done, it works
somewhere between fairly well and very well.  At least one large company
routinely bets the company bottom line on software estimates based off of
a LOC estimate.

Exercise for those who have time for exercises:  Derive a software metric
that is easily measured, easily estimated, useful for software estimating,
and is NOT strongly correlated to LOC.  That last requirement is the sticking
point: most of the usual alternative metrics have been shown to be strongly
correlated to LOC.

Re: Automated Ada Physical Source Lines Counter

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!ov]

At the risk of cutting off a potentially-interesting thread, let me
point out one aspect: the automated Ada physical source lines counter
is not a project estimation tool.  It lacks the databasing and
project-description facilities that such a tool would need.  What this
tool is designed for is project TRACKING -- that is, once we HAVE made
an estimate, how is the project progressing in comparison to that
estimate.  The tool will allow you to enter your estimate
(instrumenting the code with that estimate) and to generate reports
that break out estimated vs. actual values as the project progresses.
(This purpose, by the way, is explicitly included in the SEI Technical
reports on which this tool is based.)  In tracking the software, if 
measured values vary widely from estimated values, then this can serve
as a indication to management that one of three things is going on:
  + The estimation process is inadequate;
  + Portions of the product are being overemphasized or
overimplemented;
  + Production schedule is overambitious or overgenerous;

Then the management can further examine the project to see which of
the above is true.

I, as distributor of this tool, do not want to claim that this tool
will meet all of your project estimation and tracking needs -- in
fact, I know very well that it won't completely meet those needs.  
But I do think that an automated means of calculating explicitly-
defined size measures of software is useful -- and that is the function 
of this tool.  If others want to provide similar functionality for 
other measures, I would only applaud their efforts.
				Tim