How to determine the size of a project (lines of code, function points, other)

Question

How would you evaluate project size?

Part A: Before you start a project.

Part B: For a complete project.

I am interested in comparing unrelated projects. Here are some options:

1) Lines of code.

• I know that this is not a good metric of productivity but is this a reasonable measure of project size?
• If I wanted to estimate how long it would take to recreate a project would this be a reasonable way to do it? How many lines of code should I estimate a day?

2) Function Points.

• Functions points are defined as the number of:
  • inputs
  • outputs
  • inquires
  • internal files
  • external interfaces
• Anyone have a veiw point on whether this is a good measure?
• Is there a way to **actually do this?

Does anyone have another solution? Hours taken seems like it could be a useful metric but not solely. If I ask you what is a "bigger program" and give you two programs how would you approach the question?

I have seen several discussions of this on stackover flow but most discuss how to measure programmer productivity. I am more interested in project size.

Answer 1

Part A It's difficult to completely measure a project before you begin. If you've ever been on any reasonably large software project (which it sounds like you have been), the requirements do in fact change over time. But, I think story points are a good way of measuring software size if you are working in an agile environment. At the beginning of the project, you won't have all of the details but you should have enough to give an estimate. The cone of uncertainty http://www.construx.com/Page.aspx?hid=1648 gives a nice visualization of how accurate/precise you are likely to be.

Part B You can use story points as well here. After the project is complete, you should know how many story points you completed. You will also be able to measure your team's velocity (story points divided by some period).

One of the keys here is that your teams are using a similar measure of story points, so one team's task that takes 2 story points is equivalent to your other team's 2 point story.

Answer 2

Part A:

IMHO, agile methods provide the best way to evaluate project scope a-priori. You have to have a team with a known velocity, a first cut at a release backlog and have sized stories in the same way for the projects in which the team established their velocity. There's a good slide deck at http://www.rallydev.com/learn_agile/agile_planning/release_planning/ if you're interested.

Agilists will point out that you are actually choosing to vary scope versus date/quality. So technically you are not estimating the size of the project. Rather you are prioritizing your backlog to fit into a fixed period of time. Still, an experienced team with established velocity can give you a reasonable idea of what will be delivered when.

Part B:

I think the key part of your question is "unrelated". IMO these metrics only hold if you're comparing similar projects - in terms of team, expertise, development environment, application domain, etc. The more "unrelated" the projects, the more difficult it is to compare project size. The KLOC and Function Point metrics seem to be the most widely used.

There's a company called QSM Associates (http://www.qsma.com/tools.html) that has a large database of comparison projects. You might want to check out their site for resources.

Answer 3

I am not sure if this qualify as an answer, but my reputation is too low to comment.

Your question is very, very broad. There are a lot of books out there trying to answer your concerns with diverse luck.

Trying to resume a whole field in a few lines is (at least) misleading.

I suggest to start here: http://www.itmpi.org/ wich is a good site, full of links and appropriate bibliografy.

Answer 4

How would OP measure project size ? I mean, what units of measurement would OP use ? In your answer, be careful to suggest measurements of project size rather than of (computer) program size.

In answer to part A, I would use time and effort. Time measured in days (or hours if it's a small enough project), effort measured in persons. This then gives cost = time x person-cost. In project planning it is also vital that any estimates of measure (of whatever) are accompanied by estimates of the variation of those estimates, eg $2M(+/-$0.2M).

I might use measures of computer program size such as LOC or function-points in making estimates for the programming parts of a project. But I wouldn't use such estimates and a multiplier (say) for estimating a program's cost and duration. I mean, I wouldn't use an estimate of 100 days programming plus a factor of 2.5 to get a project size of 250 days.

Of course, at the outset, when all you have is a two-line description of the project then all you'll get is a vague estimate with large error bounds. As you refine the plan, and identify sub-tasks, you can estimate with more accuracy.

Once the project is complete I'll want my statistics in the same form as my original estimates, for comparability, so time and effort and cost. I'm not sure I'd ever use LOC as a measure of productivity, even retrospectively, I'd be much more inclined to use some measure of functionality delivered, though the standard approaches such as function-point analysis don't work terribly well in the domain I'm working in at the moment, complex scientific and technical codes.

EDIT: my suggestion of time, effort and cost as the appropriate measures is, in part, based on my experiences as a project manager dealing with non-IT stakeholders such as customers, managers, etc. Project management is a business activity, and talking LOC and function-points to, say, the chief accountant or the sales and marketing team, is not the right way to go.

Answer 5

Can I recommend a truly excellent book on the topic - Rapid Development by Steve McConnell. This is by the same guy that wrote Code Complete and is IMHO a far, far better and more important book. It will tell you everything you need to know about project estimation and measurement.

Answer 6

We use "man-day" to mesure the cost of a project. In how many day a single average man will complete the project. (well, how many years sometimes)

Lines of code are not the best but not the worst unit, but exclude the 'libraries'.

A study estimate that a developper can write ten lines/day which remains in the final programm. (but he will also make the conception, documentation, management project, etc...)

For example, check Ohloh project which analyse some open-source project, they estimate the cost with the COCOMO algorithm (online calculator). The base is lines of code.