# Techniques for Calculating Software Product Metrics Threshold Values: A Systematic Mapping Study
## 5 Discussion
Predicting faulty classes based on threshold values received attention in these research papers to improve the quality of the class design (i.e., 16 studies). Additionally, threshold values have been used to isolate non-faulty classes from other classes that have risky classes. Some papers focused on detecting bad smells to be used as a methodical approach to classifying problematic classes (i.e., 9 studies). There are a considerable number of studies that have not validated thresholds on quality attributes (i.e., 12 studies) [3; 7; 13; 22; 23; 27; 36; 39; 49; 50; 56; 57]. Collecting quality data is a time-consuming activity and open-source systems do not provide enough information to find, for example, the fault-prone modules. The refactoring of code is not systematic in most systems and depends greatly on efforts available for refactoring. The developers do not publish enough information on code refactoring and software processes. Therefore, collecting information about faults and code refactoring is not plausible, but the consideration of mixed models that depends on two or more quality attributes is not studied as shown in the selected studies. The results of threshold derivation have shown different metric values for the same techniques and for different systems. These results indicate inconsistencies among techniques and among different software systems. There are factors that affect consistency in threshold derivation. For example, threshold techniques for more than one quality attribute are potential future research that may give accurate or consistent thresholds for software metrics. * Q3 (Metrics categories):  
Answering Q3 shows that a well-known suite of metrics (CK) has been used in most research papers [25; 35; 62]. Among 300 metrics found in literature, most studies proposed and validated the CK metrics as opposed to other metrics such as the LOC as a size measure by [PERSON] et al. [80]. The authors in the study by [PERSON] and [PERSON] [81] observed that metrics are an important factor for both currently developed software and also, for the future improvement of the software. To measure different quality factors, these metrics,such as complexity, are applied. Some papers only focused on applying one of these factors, like cohesion. In addition to CK metrics, [PERSON]'s metrics, [PERSON]'s complexity, [PERSON]'s, and [PERSON]'s metrics also have been used in some studies [2; 39; 41]. There is a number of studies that have not considered the CK metrics at all [14; 24; 52]. These studies derived thresholds for non-object-oriented systems. However, [PERSON] et al. [17] used 12 metrics in different categories, including CK metrics, [PERSON]'s metrics [20], and [PERSON]'s [4] metrics. There are inconsistencies in threshold values identified for the same metric for different software systems and using different metrics analysis tools. The definition of some metrics is not used consistently in different tools. The researchers considered different tools, which affect the consistency of derived thresholds for the same system. There is a need to compare metric thresholds using the same analyzer for several systems to know whether the inconsistencies come from the metric definition and collection or the technique itself. In addition, a large number of metrics exist in research and are not considered for threshold derivation, which is also potential future research. Threshold derivation techniques should be compared and validated on the same software and using the same tool. * Q4 (The types of studies):  
The result of this question was as expected because the object-oriented metrics thresholds are practical areas, which are based on calculations and experimentation. Consequently, most of the papers included in this research have empirical nature [7]. However, the type of study also includes empirical and theoretical studies, supported by [PERSON] and [PERSON] [27].