Is LOC correct parameter for project estimation? [closed]

Question

Is LOC correct parameter for project estimation?

there are so many scenarios where complexity takes much more time for a single line of code, other than LOC what could be the suggested parameter for project estimation?

As peoples are talking about functional point of program does it mean for use case related information?

i am trying to find out any solid base for full software developement estimation which can consist analysis, design, testcase preparation, and coding, please suggest?

Hyetograph

Answer 1

Steve McConnell in Rapid Development (Microsoft Press, 1996):

Because different programming languages produce such different bangs for a given number of lines of code, much of the software industry is moving toward a measure called "function points" to estimate program sizes. A function point is a synthetic measure of program size that is based on a weighted sum of the number of inputs, outputs, inquiries, and files. Function points are useful because they allow you to think about program size in a languageindependent way.

Google "Function Point" for more information.

Gullah

Answer 2

Seeing as developers are likely to* spend most of their time trying to test changes, lines-of-code is never a good indicator of size of a problem.

Let's suppose you have an existing large application - changing a single line of code may seem trivial, but the test planning and execution could take weeks.

Likewise, adding a relatively large amount of code in a single limited-scope module which is easily testable might be only a few days.

* they should do, at least. If they're spending more time writing code than testing it, it is probably full of bugs. And I mean BEFORE it reaches your dedicated QA team.

Chiefly

Answer 3

Only if you use it in the inverse.

-- Edit

But no. It isn't. It's a mostly useless measure, and generally harmful. As you note, less code is almost always better.

Other things to check? Well, what are you trying to measure? What result do you want to see from a change in the things that you would be checking? What sort of decisions will you be making on the basis of these changes?

Saxtuba

Answer 4

LOC is one proxy measure for measuring the problem size.

LOC estimate can be used, and LOC count is relatively cheap to measure from historical projects. But LOC can be problematic if used for anything else than a proxy for problem size, as already pointed out by other answers.

Problem size is rather constant given the requirements. From a size estimate you can go to effort, schedule and cost estimates. It depends on your planning drivers such as cost or schedule. From the historical data you can find correlation how problem size translates to effort and how other planning drivers further influence the outcome. So you need to measure size measure and effort vs. other parameters and keep on fine-tuning your estimation process. There are some LOC-to-effort measures available in the literature, but they are not very accurate in your domain, using the technology you are using, and the team you have.

Other proxies for problem size are function points and story points. My experience on function points is that they are rarely worth the effort. On the other hand, story points in agile methods work very well since they are deliberately abstract (thus avoiding a lot of problems with with LOC) and measured on a sprint-by-sprint basis, with instant feedback into following sprints.

Unmitigated

Answer 5

No, it isn't. The reason is simple: if you produce a new line of code during your development, are you one step closer to a solution? If you estimated 1000 lines of code to complete a task, are you now 0.1% complete with that task?

Lines of code can be used as a metric but only in the negative sense: for a greater number of lines of code, it is reasonable to assume that you have a greater number of bugs. Based on historical data, there is generally a linear correlation between lines of code and bug count.

Here are some useful and measurable factors that are worth considering:

1. Hours of labor.
2. Dollars spent: this is a good one because it strongly enforces the reality that you'd rather find bugs at the developer's desktop than in the hands of a tester or customer).
3. Milestones met: is the system available for the customers on the right date?
4. Requirements completed: this can be a funny one - what if you discover a new customer need during the project?

In short, lines of code is very nearly the worst possible metric you could ever use.

Pastypat

Answer 6

The only way to get any reasonable estimate on project duration is to COMPLETELY implement and deliver some subset of the final requirements. Then you can estimate the remaining requirements by comparing their complexity against the completed work.

Leap