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

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

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.

Answer 2

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.