![]() |
Measurement of the various aspects of software quality is considered to be an effective tool for the support of |
| control activities and the initiation of process improvements during the development and the maintenance | |
| phases. |
![]() |
These measurements apply to the functional quality, productivity, and organizational aspects of the project. |
![]() |
The software quality metrics can be classified as the following: |
![]() |
The first classification category distinguishes between life cycle and other phases of the software system: |
![]() |
Process metrics, related to the software development process. |
![]() |
Product metrics, related to software maintenance. |
![]() |
The second classification category refers to the subjects of the measurements: |
![]() |
Quality. |
![]() |
Timetable. |
![]() |
Effectiveness (of error removal and maintenance services). |
![]() |
Productivity. |
![]() |
Software process quality metrics may be classified into two classes: |
![]() |
Error density metrics. |
![]() |
Error severity metrics. |
![]() |
A-Error density metrics |
![]() |
This section describes six different types of metrics. Calculation of error density metrics involves two | |
| measures: |
![]() |
Software volume measures. Some density metrics use the number of lines of code while others apply | ||
| function points. |
![]() |
Errors counted measures. Some relate to the number of errors and others to the weighted number of | ||
| errors. Weighted measures that ascertain the severity of the errors are considered to provide more | |||
| accurate evaluation of the error situation. A common method applied to arrive at this measure is | |||
| classification of the detected errors into severity classes, followed by weighting each class. The weighted | |||
| error measure is computed by summing up multiples of the number of errors found in each severity class | |||
| by the adequate relative severity weight. |
![]() |
Example 1: This example demonstrates the calculation of the number of code errors (NCE) and the | |
| weighted number of code errors (WCE). A software development department applies two alternative | ||
| measures, NCE and WCE, to the code errors detected in its software development projects. |
![]() |
Three classes of error severity and their relative weights are also defined: |

![]() |
The code error summary for the department's Atlantis project indicated that there were 42 low severity | |
| errors, 17 medium severity errors, and 11 high severity errors. |
![]() |
Calculation of NCE and WCE gave these results: |

![]() |
Software process timetable metrics may be based on accounts of success (completion of milestones per |
| schedule) in addition to failure events (non completion per schedule). |
![]() |
An alternative approach calculates the average delay in completion of milestones. |
![]() |
The metrics presented here are based on the two approaches; |
![]() |
The TTO and ADMC metrics are based on data for all relevant milestones scheduled in the project plan. |
![]() |
In other words, only milestones that were designated for completion in the project plan stage are considered in |
| the metrics' computation. |
![]() |
Therefore, these metrics can be applied throughout development and need not wait for the project's |
| completion. |
![]() |
Software developers can measure the effectiveness of error removal by the software quality assurance system |
| after a period of regular operation (usually 6 or 12 months) of the system. |
![]() |
The metrics combine the error records of the development stage with the failures records compiled during the |
| first year (or any defined period) of regular operation. |
![]() |
This group of metrics includes "direct" metrics that deal with a project's human resources productivity as well |
| as "indirect" metrics that focus on the extent of software reuse. |
![]() |
Software reuse substantially affects productivity and effectiveness. |
![]() |
An additional term - "benchmarking software development productivity"- has recently entered the list of metrics |
| used to measure software process productivity (see Maxwell, 2001; Symons, 2001). |
![]() |
Product metrics refer to the software system's operational phase - years of regular use of the software system |
| by customers, whether "internal" or "external" customers, who either purchased the software system or | |
| contracted for its development. |
![]() |
In most cases, the software developer is required to provide customer service during the software's operational |
| phase. |
![]() |
Customer services are of two main types: |
![]() |
Help desk services (HD) |
![]() |
Software support by instructing customers regarding the method of application of the software and | ||
| solution of customer implementation problems. |
![]() |
Demand for these services depends to a great extent on the quality of the user interface as well as the | ||
| quality of the user manual and integrated help menus. |
![]() |
Corrective maintenance services |
![]() |
Correction of software failures identified by customers/users or detected by the customer service team | ||
| prior to their discovery by customers. |
![]() |
The number of software failures and their density are directly related to software development quality. |
![]() |
It is recommended that all software failures detected by the customer service team be recorded as | ||
| corrective maintenance calls to achieve the completeness of information and better control of failure | |||
| correction. |
![]() |
Commonly, all customer services - namely, HD and corrective maintenance services - are provided to |
| customers/users by a software support center. |
![]() |
It is expected that very few customer calls will be related to identify failures. |
![]() |
In other words, most of the software support center's customer calls will be "nonfailure" calls. |
![]() |
For those calls that deal with an identified failure and for cases where the maintenance team has detected a |
| failure, a failure report is expected. |
![]() |
The difference between the two types is that HD metrics are based on all customer calls while corrective |
| maintenance metrics are based on failure reports. |
![]() |
Generally product metrics rely on performance records compiled during one year (or any other specified period |
| of time). |
![]() |
This policy enables comparisons of successive years in addition to comparisons between different units and |
| software systems. |
![]() |
The array of software product metrics presented here is classified as follows: |
![]() |
HD quality metrics |
![]() |
HD productivity and effectiveness metrics |
![]() |
Corrective maintenance quality metrics |
![]() |
Corrective maintenance productivity and effectiveness metrics. |
![]() |
It should be remembered that software maintenance activities include: |
![]() |
Corrective maintenance - correction of software failures detected during regular operation of the software. |
![]() |
Adaptive maintenance - adaptation of existing software to new customers or new requirements. |
![]() |
Functional improvement maintenance - addition of new functions to the existing software, improvement of | |
| reliability, etc. |
![]() |
In the metrics presented here we limit our selection to those that deal with corrective maintenance. |
![]() |
For other components of software maintenance, the metrics suggested for the software development process |
| (process metrics) can be used as is or with minor adaptations. |