Software Metrics in Software Engineering

Once measures are collected they are converted into metrics for use. IEEE defines metric as ‘a quantitative measure of the degree to which a system, component, or process possesses a given attribute.’ The goal of software metrics is to identify and control essential parameters that affect software development. Other objectives of using software metrics are listed below.

• Measuring the size of the software quantitatively.
• Assessing the level of complexity involved.
• Assessing the strength of the module by measuring coupling.
• Assessing the testing techniques.
• Specifying when to stop testing.
• Determining the date of release of the software.
• Estimating cost of resources and project schedule.

Software metrics help project managers to gain an insight into the efficiency of the software process, project, and product. This is possible by collecting quality and productivity data and then analyzing and comparing these data with past averages in order to know whether quality improvements have occurred. Also, when metrics are applied in a consistent manner, it helps in project planning and project management activity. For example, schedule-based resource allocation can be effectively enhanced with the help of metrics.

Difference in Measures, Metrics, and Indicators

Metrics is often used interchangeably with measure and measurement. However, it is important to note the differences between them. Measure can be defined as quantitative indication of amount, dimension, capacity, or size of product and process attributes. Measurement can be defined as the process of determining the measure. Metrics can be defined as quantitative measures that allow software engineers to identify the efficiency and improve the quality of software process, project, and product.

To understand the difference, let us consider an example. A measure is established when a number of errors is (single data point) detected in a software component. Measurement is the process of collecting one or more data points. In other words, measurement is established when many components are reviewed and tested individually to collect the measure of a number of errors in all these components. Metrics are associated with individual measure in some manner. That is, metrics are related to detection of errors found per review or the average number of errors found per unit test.

Once measures and metrics have been developed, indicators are obtained. These indicators provide a detailed insight into the software process, software project, or intermediate product. Indicators also enable software engineers or project managers to adjust software processes and improve software products, if required. For example, measurement dashboards or key indicators are used to monitor progress and initiate change. Arranged together, indicators provide snapshots of the system’s performance.

Measured Data

Before data is collected and used, it is necessary to know the type of data involved in the software metrics. Table lists different types of data, which are identified in metrics along with their description and the possible operations that can be performed on them.

                                                      Type of Data Measured

• Nominal data: Data in the program can be measured by placing it under a category. This category of program can be a database program, application program, or an operating system program. For such data, operation of arithmetic type and ranking of values in any order (increasing or decreasing) is not possible. The only operation that can be performed is to determine whether program ‘X’ is the same as program ‘Y’.
• Ordinal data: Data can be ranked according to the data values. For example, experience in application domain can be rated as very low, low, medium, or high. Thus, experience can easily be ranked according to its rating.
• Interval data: Data values can be ranked and substantial differences between them can also be shown. For example, a program with complexity level 8 is said to be 4 units more complex than a program with complexity level 4.
• Ratio data: Data values are associated with a ratio scale, which possesses an absolute zero and allows meaningful ratios to be calculated. For example, program lines expressed in lines of code.

It is desirable to know the measurement scale for metrics. For example, if metrics values are used to represent a model for a software process, then metrics associated with the ratio scale may be preferred.

Guidelines for Software Metrics

Although many software metrics have been proposed over a period of time, ideal software metric is the one which is easy to understand, effective, and efficient. In order to develop ideal metrics, software metrics should be validated and characterized effectively. For this, it is important to develop metrics using some specific guidelines, which are listed below.

• Simple and computable: Derivation of software metrics should be easy to learn and should involve average amount of time and effort.
• Consistent and objective: Unambiguous results should be delivered by software metrics.
• Consistent in the use of units and dimensions: Mathematical computation of the metrics should involve use of dimensions and units in a consistent manner.
• Programming language independent: Metrics should be developed on the basis of the analysis model, design model, or program’s structure.
• High quality: Effective software metrics should lead to a high-quality software product.
• Easy to calibrate: Metrics should be easy to adapt according to project requirements.
• Easy to obtain: Metrics should be developed at a reasonable cost.
• Validation: Metrics should be validated before being used for making any decisions.
• Robust: Metrics should be relatively insensitive to small changes in process, project, or product.
• Value: Value of metrics should increase or decrease with the value of the software characteristics they represent. For this, the value of metrics should be within a meaningful range. For example, metrics can be in a range of 0 to 5.