SLOC Estimation – How to Estimate Source Lines of Code for a New Project

cocomoestimationsource code

Recently, I've been getting familiar with COCOMO II model to calculate the effort (person-months) and duration (calendar time in months) required to develop a mobile application. To calculate the effort, the following formula should be used according to COCOMO II Model Definition Manual.

PM = A * Size^E * (Product of EMs)

In the equation, Size should be expressed in KSLOC (thousands of source lines of code). How am I supposed to know KSLOC of my mobile application when no single line of code has been written yet? Do people usually just make an educated guess or do they, for example, use similar projects as a basis for their estimation? Or are there some specific methods for estimating the SLOC in situations when you don't have any code yet?

Best Answer

The only way to get the SLOC input to COCOMO is to estimate that. There are different estimation approaches that you can use to try to come up with an estimate for the size of the software application under design. You can consider decomposition and recomposition, estimation by analogy, proxy-based estimates, and expert judgement in groups to estimate the size to use as an input into COCOMO.

The method you choose is likely to be determined by your environment. For example, if you don't have a group of knowledgable people, you really can't use expert judgement in groups. If you do, you can use any number of techniques (including the other ones that I mention) as an individual contribution to the group estimating effort.

If you have good historical projects, then you can use estimation by analogy or proxy-based estimates to compare with previous projects or components. If you have a previously made component that is similar in size and scope, then you can count that. However, if you are using a new programming language or don't have a good history of past estimates, then the best method would be to keep decomposing the work into smaller, easily estimated pieces, estimate those, and then roll the total back up.

Something else to consider would be to use function points in COCOMO II instead of SLOC. Given a set of requirements, it may be easier to count the number of function points rather than attempt to estimate the number of SLOC.

Related Topic