I have been asked to give a metric as to the size of a corporate application. The application in question is a web based application and I am not sure how to quantify its size. Obvious but not useful metrics would be lines of code, number of files etc. What are some suggested means of determining the size of an application that will provide real meaning?
Notes on application:
Number of "pages" or "areas" that the users will have access to
Problem: This can be fudged by separating parts into different pages or sections when it would make much more sense to consolidate them into a single "control center" interface.
Number of classes
Problem: This does not take into account the complexity (or simplicity) of some classes in comparison to others. You may have a single class which contains two properties and a method, while another class can be hardcore.
Number of non-lookup tables
Problem: This will not take into account the complexity of your software, only the data layer that it rests on top of. Some of the same problems associated with number of classes can also be applied here in terms of some tables being more complex then others.
Lines of code
Problem: This is a fairly standard metric, but it puts a lot more positive connotation on programs with lots of lines, instead of encouraging more efficient and elegant code.
How many man hours it took to develop
Problem: No two developers have the same skillsets and no two developers will likely take the exact same amount of time (or follow the same path) when it comes to creating a piece of software. So it may take a single developer the same amount of time it takes a team of 3 less skilled/experienced developers to bang out the same amount of code. Also, the entire "Mythical Man Month" can start to rear its head if you start applying more people to a problem than is really necessary.
Overall I think the biggest problem with metrics is that they try and measure some quantifiable property of the software, when in reality software is about quality instead of quantity, and that is where metrics really fail.
What are some suggested means of determining the size of an application that will provide real meaning?
If you ever find a really good answer to this, please write it up properly, ok?
Code metrics nearly universally suck, in my experience. A few of them manage to be merely bad.
[addendum]
To be fair, the problem isn't so precisely that "code metric suck", after all they are just measurements (hopefully well defined ones); the problem is that they never seem to measure what people want them to measure but are used as if they did. Blaming the numbers for this abuse isn't really fair.
SLOC (Source Lines of Code) is a generally accepted measure of size.
Your question only ask about size, but I bet that you're being asked to come up with these metrics so that management can scope the level of effort necessary to support this application. In that case I would look at the complexity of the code as well.
You might want to download a trial version of Understand it works with many programming languages, will give you the metrics you need and the free trial will last you long enough to get the numbers that management needs.
As for metrics here is what I would take a look at:
Cyclomatic Complexity V(G) is a good measure of complexity.
SEI Maintainability Index is good for looking at how difficult it will be to maintain the codebase.
Code to comment ratio of at least 15% and other necessary high level and low level design documents. Realize that most of these will be out of date, but they still help your people to get started.
Test Coverage would also be something else to look at. Do they have unit test at all? Code is easier to maintain when you have a nice unit test suite that you can run to give yourself a "reasonable" sense that you didn't break anything. 80% test coverage is usually the minimum.
A metric can only provide real meaning if you know what it's used for. Do you know the purpose for measuring size? If not, ask.
The Function point analysis method, which I think is suited for medium to large scale applications, independent of the programming language:
http://en.wikipedia.org/wiki/Function_point_analysis
The result of the analysis is a function point value which can be used to estimate the implementation time. This method is quite easy to understand and implement (using a simple spreadsheet), however it requires some experience because some key factors in the calculation are variable.