Software Metric

Software metric:

A software metric is a measure of some property of a piece of software or its specifications. It is used to measure schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments.Common software measurements include:

• Errors per line of code
• Code coverage
• Cohesion
• Comments per line
•  software components
• Coupling
• Cyclomatic complexity (McCabe's complexity)
• DSQI (design structure quality index)
• Function point analysis
• Halstead Complexity
• Instruction path length
• Number of classes and interfaces
• Number of lines of code
• Number of lines of customer requirements
• Program execution time
• Program loading time
• Program size

n  MEASURE:

It provides a quantitative indication of the extent, amount, dimension, capacity or size of some attribute of a product or process.

n  METRIC:

A Quantitative measure of the degree to which a system, component or process possesses a given attribute.

n  INDICATOR:

It is a metric or combination of metrics that provide insight into the software process, a software project or the product itself.

Direct Measures:-In case of software engineering process, include cost and effort applied. Direct measures of product include lines of code produced execution speed and memory size.

Indirect Measures:-Of the product include functionality quality, complexity, efficiency and   reliability.

Types of Metrics:

       1. Product Metrics: It includes the following:

·         Code metrics

·         Lines of code LOC

·         Design metrics – computed from requirements or design documents before the system has been implemented

·         Object oriented metrics- help identify faults, and allow developers to see directly how to make their classes and objects more simple.

       2.Process metrics : It includes the following:

·         Measure the process of software development

·         Commonly used by management to check the budget and office procedures for efficiency

·         Evaluate and track aspects of the software design process like:

a.        Human resources

b.        Time

c.        Schedule

d.        Methodology

·         Private process metrics (e.g. defect rates by individual or module) are only known to by the individual or team concerned.

·         Public process metrics enable organizations to make strategic changes to improve the software process.

3.Project metrics enable project manager to

·         Assess status of ongoing project

·         Track potential risks

·         Uncover problem are before they go critical

·         Adjust work flow or tasks

·         Evaluate the project team’s ability to control quality of software wrok products

Size Metrics or Size Oriented Metrics

·         This metric is very popular due to the fact that it is very simple to use.

·         The simplest measure of problem size is lines of codes.

·         This metric measures the number of source instructions required to solve a problem.

 A set of simple size oriented metrics that can be developed

·         Errors per KLOC

·         Defects per KLOC

·         Page of documentation per KLOC

Size oriented metrics are not universally accepted as the best way to measure the process of software development:

·         LOC relies heavily on the programming style of individual programmers.

·         LOC correlates poorly with the quality and efficiency of the code.

·         LOC can be computed only at the end of the project.

SIZE

·         Size is a primary factor. There are two common ways to measure software size:-

Lines of code and function points.

·         Lines of codes

The most commonly used measure of source code program       length is the number of lines of code (LOC) (Fenton,1997)

KLOC is used to denote thousands of lines of code.

·           Function points

Function point measure size in terms of the amount of functionality is a system. Function points are computed by first calculating an unadjusted function count.

Halstead Theory for Complexity Measures

Halstead complexity measures are software metrics introduced by Maurice Howard Halstead in 1977. Halstead makes the observation that metrics of the software should reflect the implementation or expression of algorithms in different languages, but be independent of their execution on a specific platform. These metrics are therefore computed statically from the code.
Halstead's goal was to identify measurable properties of software, and the relations between them. This is similar to the identification of measurable properties of matter (like the volume, mass, and pressure of a gas) and the relationships between them. Thus his metrics are actually not just complexity metrics.

For a given problem, Let:

• = the number of distinct operators
• = the number of distinct operands
• = the total number of operators
• = the total number of operands

From these numbers, several measures can be calculated:

• Program vocabulary:
• Program length:
• Calculated program length:
• Volume:
• Difficulty :
• Effort:

The difficulty measure is related to the difficulty of the program to write or understand, e.g. when doing code review.

The effort measure translates into actual coding time using the following relation,

• Time required to program: seconds

Halstead's delivered bugs (B) is an estimate for the number of errors in the implementation.

• Number of delivered bugs : or, more recently, is accepted.