After reading some literature on the subject (including research and conference papers), Magnus and I have tried to extract the important parts. Here, I'll try to recap what conclusions we've agreed upon.

Definition of Software Metrics

There are several ways to define software metrics, but all definitions more or less say the same thing. For example, we have found these quotations regarding the definition of Software Metrics:

”An objective, mathematical measure of software that is sensitive to differences in software characteristics. It provides a quantitative measure of an attribute which the body of software exhibits”

“Software metrics measue specific attributes of a software product or a software-development process. In other words, they are measures of success.”

“An attempt to quantify some aspect of a product generated during a software project.” (Note: product could mean source code as well as documentation)

”A measure of some property of a piece of software or its specifications”

NASAs definition: “Software metrics are measurements of software attributes. For example, Total Lines of Code is a measurement of the number of lines of code (executable statements, comments and blank lines) for a given module.”'

Our conclusion: Software Metrics are measurements, a quantification of an attribute that an artifact in a software project possesses.

The Purpose of Software Metrics

Some quotations found:

”Software metrics are computed for the purpose of evaluating certain characteristics of the software developed”

“[Software metrics are] indicating how well the software is designed and coded according to measurable quantifiable criteria. This is where “metrics” fit into software quality assurance. They should relate to software quality “attributes” or “factors” of interest acknowledged by the community of software developers and users.”

“Software metrics are used to obtain data to support the software goals for the project, for the divisions and, ultimately, the business goals of the corporation.”

“Metrics data collected during the project track the status and progress of the project. These actuals are compared with the estimates to indicate and avoid problems.”

“A goal of software metrics for the projects is to provide data to management for controlling software development”

“As applied to the software project, a software metric measures (or quantifies) a characteristic of the software.”

“You cannot control what you can’t measure”

"Measurement is important for three basic activities: Understanding, Controlling and Improving." We also found out that the purpose of the metrics differ depending on the role you have in a software project. For managers, the metrics serves the purpose of answering questions like:

• What does each process cost?
• How productive is the staff?
• How good is the staff?
• How good is the code being developed?
• How can we improve?

For engineers, the metrics serves the purpose of answering questions like:

• Are the requirements testable?
• Have we found all the faults?
• Have we met our product or process goals?
• What will happen in the future?
  

Conclusion: Software metrics servers several purposes. For example:

• Evaluate characteristics of an artifact in a software project
• Present a value on a defined quality factor of an artifact.
• Help the management (business management or project manager) to make the right decision so problems could be avoided (in other words: gives control over the project).
• Determine if you have reached your goals or nog.
• Learn from earlier projects to determine what went wrong and why, so you don't repeat the same mistakes again

All in all, software metrics provides understanding, control and a chance for improvement for a software project.

Classification

”Software metrics and Software metric attributes are classified into three broad categories:

• Metrics relating to the organization
• Metrics relating to the processes
• Metrics relating to products"

One author also differenced code metrics from functional metrics. Code metrics are metrics used to perform measurements on source code. Functional metrics are used to measure e.g requirement specifications.

NASA classifies their metrics with regards to object-oriented languages and non-object-oriented languages. Furthermore they have additional categories of metrics, such as Halstead metrics, complexity metrics, requirement metrics, error metrics and miscellaneous quantitative metrics.

Another article suggested that it didn't exist any metrics to measure data or information. The article also stated that there isn't any good metrics for measuring software/hardware hybrid projects. We haven't dug any deeper into the subject to see if this was correct or not. It may be the case that new metrics on these areas has been developed after the publish date on that article.

Pfleeger & Fenton mentions three classes to measure software in:

• Processes (collections of software related activities)
• Products (artifacts, deliverables or documents that are the results of a process activity)
• Resources (entities required by a process activity, for exampel staff)

In each of these three categories you differ between external and internal attributes.

Conclusion: Software metrics can de divided into three main categories:

• Metrics of the organization/resources
• Metrics of the processes
• Metrics of the products
  • Metrics on code (code metrics)
  • Metrics on documentation (functional metrics)

Each of these categories are then further divided into internal or external attributes.

Requirements on Software Metrics

The information provided by the metrics must satisfy three conditions to be of relevance to the project manager (so he can make the right decisions). The metrics must:

• Indicate its quality
• Indicate its generality
• Indicate its timeliness

Furthermore, the metrics must be measurable, and be related to one or several software quality factors.

Conclusion: (Those stated above).

Examples of Software Metrics

Here are some examples of software metrics:

Lines of Code | Fan-in | Executable statements | Blank lines | Lines of Comments | Cyclomatic Complexity | Error rate | Error Density | Cohesion | Weighted methods per class (WMC) | Depth of Inhertance tree (DIT) | Number of Children (NOC) | Coupling between object classes (CBO) | Response For Class (RFC) | Lack of Cohesion Metric (LCOM) | Change Counts | Effort | Degree of testing | Fault counts

etc. It should be noted that e.g maintenance is not a software metric. It is a quality factor.

That's it!