Skip to content
Related Articles

Related Articles

Improve Article

Inspection Metrics in Software Engineering

  • Last Updated : 11 Sep, 2020

Monitoring inspection process is very essential and important to simply get early estimate of software’s quality, assess staff’s conformance to inspection procedures, and identify status of inspection process. Metrics generally provide subjective assessment of total number of faults or defects that are remaining in code after inspection. Inspection quality status is basically long-term metric of company’s or division’s being accumulated inspection experience.

Inspection quality status will usually depict characteristics of inspection in long term when software quality and inspection raw data explain and define the status of particular inspection. Data that is usually collected during software process is simply required to compute set of metrics.

These metrics support evaluation and improvement of process along with quality of planning and tracking. Metric that is computed during such process must be explained and defined by requirements of organization that too in quality manual. Collection of data and calculation of metrics for no reason is simply considered as waste of time. Inspection quality status is generally composed of two different types of metrics i.e.

  • Average Quality Metrics :
    It can be characterized in terms of time used, number of inspectors that are participating, and number of defects that are being detected.
  • Maturity Metrics :
    It describes extent of inspection adoption. It is also new metric.

During Inspection Process, there are several metrics that can be calculated. Some of them are given below :



  1. Total number of major and minor defects being found : It is usually found by reviewer.
  2. Number of major defects that are found to total found : It proportion of minor defects to major defects is much greater, then moderator might request to reviewer to repeat review and focus on major defects much prior to commencing logging meeting.
  3. Size of the artifact : It can be pages, LOC, or other size measures.
  4. Rate of review : It represents size of reviewed artifact that is divided by time i.e. expressed in hours. Example, 14 pages/hour.
  5. Defect detection rate : It represents total number of major defects that are found per review hour.

Number of Defects Found and Defects Density :

  1. Number of Defects :
    Total number of defects that are found is sum of total number of defects that are found by every reviewer, minus number of defects found that are common.

    For example, consider instance, for two reviewers, metric is computed by :

  2. Defect Density :
    It is the ratio of total number of defects found to size of artifact. In simple words, it is defined as total number of confirmed defects that are detected in software during period of development, divided by size of software. It simply helps us to decide whether or not piece of software is ready to be released. It also allows us to compare relative number of defects in various software components that further helps in finding candidates for additional testing or inspection. It is expressed as :

Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.

 

My Personal Notes arrow_drop_up
Recommended Articles
Page :