Measuring many of the quality factors described in quality models is dependent on subjective ratings. In order to supress variability those performing rating should be made aware of the need for consistency.Software quality mesurement using the decomposition approach reqires careful planning and data collection in order to keep down the extra costs involved. One solution is to look at quality as the lack of defects and thus concentrate on recording errors, faults, and failures.
A de facto standard measure of software quality is defect density. Defects can be classified as known defects and latent defects. Then defect density can be defined as:
defect density = # known defects / product size. The variation in defect density can be considerable, see Figure 9.6.
For using defect density in decision making the following should be noted:
- The terminology differs widely: fault rate, fault density, and failure rate are used almost interchangeably.
- Defect rate is dependent on time and defect density on size.
- Remember that size can be measured in many different ways.
- Defect finding is also dependent on the efficiency of the testing process.
- Even if our mesurement otherwise are OK, you should remember that defects are not equally serious, and that the faults which eventually lead to failures is also affected by the specific users.
Despite these problems defect density is an important quality measure. In Chapter 15 we will examine several empirical models for predicting defect densities.
In Table 9.2 measurement data, including defect density, from three projects of a company are given.
Defect densities reported show great variation, 10-0.13 defects per KLOC.