Re: Estimating projects (was AS/400 Gasping For Air ??)

Hello Denis,

No one who knows me would say I was patient.  I don't suffer fools and 
sometimes it shows.  I do not consider 
you in that number.  Motion to bring this meeting of the mutual admiration 
society to a close and answer the 
questions.

I am not sure I understand your comment about "using it in fact".  It is 
certainly used in estimating, 
planning, and scheduling.  Note that the actual number can vary according to 
what is being developed and the 
language in which it will be developed.  2 KLOC is about right for systems 
development, you could reasonably 
use 4 KLOC for an application system but I chose the lower number in my 
original comments because it 
represented a worst case.

You are correct that most of the project time goes in design and testing.  My 
percentages are: 40% design, 
45% testing, and 15% coding. (I tend to be a bit particular about design.)

Brooks (see below) uses a 1/3 for design, 1/6 for coding, 1/4 for component 
test, and 1/4 for systems test.

Regardless of how much of the design, and documentation for the original system 
still exists it will not be 
rewritten in 9 months.  Besides, what would be the point in simply redoing the 
old system?  Shouldn't you 
take advantage of the exercise and re-design some of it?  I would bet the users 
would like things done 
differently if they had a chance.

Some figures to substantiate my earlier comments.  These come from "The 
Mythical Man Month" by 
Frederick P. Brooks.  Note that the best case is 10 KLOC/man-year.  If you are 
interested I'll try and dig up 
some figures for OO projects for comparison -- although OO projects usually 
don't show a great return on the 
first foray, the benfits come later once some experience is gained and classes 
exist to reuse.

"A programming systems product takes about nine times as much effort as the 
component programs written 
separately for private use.  I estimate that productizing (sic - with apologies 
to Paul M. who will be 
equally offended by that word) imposes a factor of three; and that designing, 
integrating, and testing 
components into a coherent system imposes a factor of three; and that these 
costs are essentially independent 
of each other."

"Data for building isolated small systems are not applicable to programming 
systems projects."

"Aron's IBM data show productivity varying from 1.5 KLOC to 10 KLOC/man-year as 
a function of the number of 
interactions among system parts."

"Harr's Bell Labs data show productivities on operating system type work to run 
about 0.6 KLOC/man-year and 
on compiler type work about 2.2 KLOC for finished products."

"Brooks' OS/360 data agrees with Harr's: 0.6-0.8 KLOC/man-year on operating 
systems and 2-3 KLOC/man-year on 
compilers.

"Carbato's MIT Multics data show productivity of 1.2 KLOC/man-year on a mix of 
operating system and 
compilers, but these are PL/1 LOC, whereas all the other data are assembler."

"Programmer productivity may be increased as much as 5 times when suitable high 
level language is used."


Regards,
Simon Coulter.

//--------------------------------------------------------------
// FlyByNight Software         AS/400 Technical Specialists
// Eclipse the competition - run your business on an IBM AS/400.
// Phone: +61 3 9419 0175      Mobile: +61 0411 091 400
// Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au
// 
// Windoze should not be open at Warp speed.
//--- forwarded letter -------------------------------------------------------
> X-Mailer: Microsoft Outlook Express 4.72.3155.0
> Date: Sun, 10 Jan 99 23:36:04 -0500
> From: "Dennis Lovelady" <dennis@lovelady.com>
> To: MIDRANGE-L@midrange.com
> Reply-To: MIDRANGE-L@midrange.com
> Subject: Re: AS/400 Gasping For Air ??

> 
> Hi, Simon:
> 
> >12 years is too low.  Much of the code in OS/400 came from the
> >System/38.  That's why OS/400 is known as XPF
> >internally.  eXtended control Program Facility -- many of you
> >will remember the OS for the S/38 was called
> >CPF.  The new lads and lassies have just learned something --
> >does that make me a geezer or do I have to
> >remember toggling in the bootstrap code in Octal before
> >I qualify?  So lets average over 20 years.
> 
> Yes, these make for much more reasonable numbers or workers on the project of
> O/S.  What I was trying to resolve, is whether IBM uses that number in fact,
> or only in estimating a project (I believe that the LOC estimate came from
> the IBM consulting group, unless I misremember).  The original comments were
> stating that a project was going to take a certain amount of time, because of
> the 2000 LOC/year/person, so I used a roundabout way of getting a
> demonstration of those numbers in practice.  Thank you for doing so, Simon.
> As it turns out, the numbers would seem to be at least palpable, given your
> explanation of the "project" at hand.  I have no doubt of your expertise in
> this area - you and I go back a ways.  :^)
> 
> Of course, a very large portion of that (or any) project would be in design,
> information gathering, "how to," user discussions, organization, file
> layouts, database design, process structure, goal definition, documentation,
> redesign, etc.  Probably, this is on the order of more than 50% of the
> project.  (Out of curiosity, what's a reasonable % for this sort of
> overhead?)  Given that the original question had to do with replacing an
> existing system, I still have to wonder if the estimate was not tremendously
> overstated, since most of that work has already been done (assuming that the
> new product will be an exact or near emulation of the original).  Still, the
> budgeted amount of the time would seem to be much too small for the project
> at hand.
> 
> Thanks for your patience, Simon.
> --
> Dennis Lovelady                    Simpsonville, SC
> mail: dennis@lovelady.com
> URL:  http://lovelady.piedmont.net
> ICQ:  5734860
> --
> I just forgot my whole philosophy of life!!!
> 
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
> 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---