Software Metrics

Measurement is a key factor for managing and improving software development. The purpose of the measurement process in software projects is to define and operate a context-specific set of metrics, and to describe the required guidelines and procedures for data collection and analysis. Software measurement generates quantitative descriptions of key processes and products, enabling us to understand behavior and result. Such descriptions can indicate the effort needed to complete the project, the product’s quality, estimated schedules and time-to-market, rework effort, estimated project costs, and distribution of resources and costs by project phases. Software measurement makes possible to compare the project a development team is currently working on, to similar projects in terms of budget, costs, productivity, quality, staffing, development processes, and technology used.

In order to operate a metrics program during a software development project, the project manager must enforce continuous measurement of relevant factors. These factors depend on the overall management goals of the measurement process. In that sense, one can differentiate between the following kinds of software metrics.

* Metrics for project size and team productivity – typical and most widely used representatives of this kind of metrics are source lines of code (SLOC) and function points; the SLOC metric can be converted relatively accurately and easily into the number of programer-months needed to
complete the project; function points are dimensionless numbers that indicate the application’s functionality from the user’s perspective, and can also be easily converted into the effort needed to complete the project or one of its parts.

* Metrics for schedules – these include the number of tasks completed on time, the number of tasks not completed on time, the number of tasks with changed schedules, and the number of postponed tasks.

* Metrics for requirements specification – the number of requests for change (RFC) in specification, the number of new requirements, and the RFC diagram (showing the dynamics of RFC over time).

* Metrics for software testing – these metrics are used to track the percentage of SLOC covered by the testing process; increasing that percentage reduces the number of errors to be discovered by the users and increases the product’s quality.

* Metrics for software quality – they typically show the fault density (the number of errors per 1 KSLOC) and fault arrival and closing rates, as a rule of thumb, the product’s quality is satisfactory if the fault density is lower than 0.25.

* Metrics for project risk – they measure confidence in the product’s readyto- deployment date (typically an S-shaped curve over time). The most widely used metrics models include COCOMO, which isbased on measuring SLOC, function points analysis, GQM(Goal-Question-Metrics, based on systematic translation of the company’s goals into the measurement process goals, and refinement by defining the concrete measurements to perform in order to support the goals), and Chidamber-Kemerer’s metrics suite for object-oriented software projects (specifying metrics for the number of methods per class, depth of inheritance tree...............