Software Best Practices

I'm using both Steve's book and Estimate 2.0.  I know the product being developed will consist of approximately 25,000 LOC.  Does Estimate or COCOMO II use that number to infer lines of test code that need to be written.  Should I give Estimate a starting number of 25K + Test LOC in order to get a better estimate?

Another take on the same question:  Look at table 21-4 on page 236.  The 25 KLOC project shows a System Test effort allocation at 23%.  I think this refers to executing the tests.  If I'm going to try and create automated regression tests, it seems like I should add the estimated LOC for those to the LOC of the product code itself in order to get a good estimate.

Thanks for any help.

Lines of code in all cases refer to the "delivered lines of source code" -- test code isn't used as input. However, the effort estimate you get by using delivered lines of source code includes the test effort, including the effort to write the lines of test code.

In general, delivered lines of source code are simply used as the most commonly available, most commonly "best" proxy for the overall scope of the project. Thus you estimate all other effort on a project (analysis, documentation, defect corrections, talking to customers, project management, etc.) using that one "lines of code" number as input. Obviously documentation isn't actually performed in terms of "lines of code," but the size of the project in lines of code can give you an idea of how much effort is needed, including documentation effort. Test effort is the same. Size in delivered lines of code gives a good proxy for test effort. The fact that the specific test activity happens to also generate lines of code is just a coincidence, and doesn't need to be considered in creating the estimate. Thus the 23% number you mention from Table 21-4 includes *all* the test effort -- writing test code, executing test code, reviewing and correcting test code, etc.

Bottom line is you should use 25 KLOC as the input.

 Hope this helps!

Hey Steve,

First of all, you are awesome.

But, this LOC thing really bugs me. Doesn't this vary wildly depending on the technology stack? It seems to me the size of the project is not remotely measureable by LOC, but the amount of logic in the system.

Although this is not good either, as a rules engine can dramatically reduce the code load as well. Heck, I don't know, I have measured projects by picking up the requirements binder and dropping it on the table. It really comes down to experience building systems.

Anyone who wants a definitive answer about any large scale system size is fooling themselves. The whole point of Agile thiat we don't know, we just know enough to start. Please say hi to Karl for me.

Daniel Philpott

Daniel,

The estimate will be affected by the technology stack (to some degree) and even more by the kind of software that's being built.

It's possible to be able to make much better predictions about large scale systems than your comment suggests. It's a significant amount of work and requires some specialized expertise in software estimation. I don't really agree with the Agile comment. It's true that we don't know. In a few cases it's because we can't know; in most cases it's because we haven't done the work that would allow us to know.

Hope that helps.

We can make better guesses. We are in agreement there. I was joking(a bit)

I have to say that it comes down to a business decision sometimes, as the amount of money spent to get the better estimate may not be poilitcally feasible. I've run into that more than once.

It is possible to do all sorts of things which make sense to an engineering professional, but often we don't hold the checkbook.

There are lots of drivers here many of them business-based. Just my .02 cents.:)

I'm not saying we should roll over, just find clients who get it.

Just to update the story ...  Using LOC and the quantitative estimates from Estimate created the most positive dialogue I have ever had with senior management.  It changed a conversation that normally resembles the first one on p. 5 to a discussion about what additional resources could be made available within the budget and the remaining risk associated with the fact that we can't staff according to the quantitative estimates.  There is no way around it: customers need some kind of quantitative estimate.

You are right. I suppose I'm was being too literal and not taking into account the negotiating value of LOC. I suppose the geek in me was shouting "Do the Java/.NET/Spring/etc APIs/Frameworks count?"

 Thanks for the help!