Metric for Program Size

Question

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:

• ASP.NET Web Forms Based C# App
• Tiered architecture
• All database interaction through stored procedures

Answer 1

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.

Answer 2

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.