Ada productivity in LOC/hour

Ada productivity in LOC/hour

[Mike Bates]

I raise this topic with a great bit of trepidation; nearly every word
in the subject line can be (and has been) nitpicked to death.  (E.g.,
What is an Ada line of code?  Is it a valid measure of productivity?)

My question is simple: What is the current conventional wisdom on
typical Ada productivity expressed as source line of code per
man-hour?  Are there any recent studies of productivity that could
substantiate such a rule of thumb?

I am aware of the CTA, Inc., study of several years ago that pegged
Ada productivity at about 10 LOC/8 man-hours.  Has this been
superseded?

To narrow the question a bit, let me define the purpose of the
measure, the application domain and the terms.

My purpose in requesting this information is to have a rule of thumb
for estimating schedule and hours when the approximate size of the
final product is known.  Don't bother telling me that this is a
useless measure.  It doesn't matter; I need to be able to talk about
productivity in these terms.

The domain is hard-realtime, mission-critical software, developed
under DOD-STD-2167A for the DOD.

Man-hours would include requirements analysis, design, coding, unit
test, integration, and acceptance test -- the whole software effort
from specification to acceptance.

You can define "line of code" any way you like.  "Line of code" should
definitely include declarations as well as executable code.  (I usually
define line of code as any source line that isn't a comment or empty.
Provided that a programmer doesn't go overboard with formatting, there
shouldn't be much difference between that measurement and counting
semicolons -- not enough difference to skew the productivity numbers
significantly.)

Thanks for any help.




--
------------------------------------------------------------------------------
Mike Bates               FlightSafety International, Simulation Systems Div.
Principal Engineer       2700 North Hemlock Circle
Computer Systems Group   Broken Arrow, Oklahoma 74012
mikeb@ssd.fsi.com        918-251-0500 ext. 462 <-------------- new extension
------------------------------------------------------------------------------

Re: Ada productivity in LOC/hour

[CONDIC]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: Ada productivity in LOC/hour
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



>
>Mike Bates <mikeb@SSD.FSI.COM> writes:
>[snip]
>My question is simple: What is the current conventional wisdom on
>typical Ada productivity expressed as source line of code per
>man-hour?  Are there any recent studies of productivity that could
>substantiate such a rule of thumb?
>[snip]
>
I can't give you a comprehensive number on this, but let me give
you the benefit of what I've got:

We build embedded control systems for jet engines, programmed in
Ada under 2167a. By counting the hours spent *strictly in the
programming group* on various projects, and by using *raw lines
of code impacted per release* as the unit of work, we seem to
have maintained a rolling average of between 20 and 55 SLOCs per
hour. This does not count labor up front doing the design work or
the labor at the back doing the integration testing and
verification. Just the labor to translate diagrams to Ada, code
read, unit test, image building, configuration managing, hacking
development tools, collecting statistics, goofing off on the job,
etc. YMMV

I can caveat this *to death* with all the usual disclaimers about
problem space, what you choose to count, tools you have at your
disposal, "is this the only measure of productivity", etc., but
I'm sure you already know this. It's at least a credible number
that I can back up with almost three years of measurement. Feel
free to contact me (see my trailer) if you want more details.

BTW: I did another study on a body of Ada code (approx 250,000
SLOCs) wherein I compared raw carriage returns, semicolons,
Halstead doohickeys, non-comment, non-blank SLOCs and modules.
The statistical correlation between each unit was *soooo close*
that I concluded that you could count whatever you want and get a
conversion factor to any of the others. My advice: Be consistent
and keep it simple. We went with raw carriage returns - easy to
compute and easy to compare against Fortran or C or whatever (for
whatever *that* worth!)

Pax Vobiscum,
Marin


Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
    "I've never had a problem with drugs; I've had problems with the
    police."

        --  Keith Richards
===============================================================================