## 2 Research Background and Related Works  
Software metrics are functions that use software data as an input, provide independent numeric values as an output and can be interpreted as the level at which software suits the chosen quality attribute [13]. The measurement of software metrics is carried out within a quality assurance process [14] and constitutes a key component in successful software engineering [15]. In the latter case, it is recommended to follow the prescribed guidelines and by using software metrics it is possible to control the achieved level of software product quality [16]. Different types of metrics quantify different aspects of software development [16]. [PERSON] et al. [17] list several object-oriented software metrics collections, like Chidamber and Kemerer (CK) metrics, Lorenz and Kidd metrics and MOOD software metrics. A variety of software metrics is used in practice and it is essential to know the connection between each metric and different software quality aspects. Furthermore, the meaningful use of software metrics is possible only with reliable threshold values [16; 18]. The more reliable the thresholds are, the more accurately the quality can be evaluated. Evaluating quality with software metrics thresholds is a known and accepted strategy [19]. The main motivation of deriving threshold values is to identify those program entities that can represent a potential risk [20; 21; 22]. In the literature, many different approaches are proposed for deriving metrics thresholds. The majority of studies identify threshold values with the goal of finding errors, such as in [23; 24; 25; 26; 27]. Only some of them, like the study by [PERSON] et al. [8], focus on finding code smells. Among methods that are used for calculating metrics thresholds there are also approaches that derive thresholds based on software metrics values acquired from benchmark data. Those approaches are used in [8; 10; 16; 20; 28; 29; 30] and as a result offer concrete threshold values that can be used in the process of software quality evaluation. Furthermore, with derived threshold values, it is possible to find and evaluate code smells adequately [8]. The detection of deficient program entities is a commonly discussed topic, but usually in the context of finding errors, like in [23; 24; 25; 31]. Studies that identify code smells based on exceeding threshold values of software metrics can be found; however, they mostly detect code smell types presented by [PERSON] and [PERSON] [16] with the use of code smell detection rules. Code smells are detected in a study by [PERSON] et al. [8], where also the calculation of threshold values for selected software metrics is presented. Identification is done with detection rules which are presented in [16] and no validation of acquired results is presented. [PERSON] and [PERSON] [10] present the detection of code smells for software product lines. [PERSON] et al. [18] identify poor classes within the context of experimental validation of the proposed threshold values. They also combine derived metrics within identification and point to a decreasing number of detected classes. However, no rules or more detailed proposal are available. Other papers presenting code smell detection strategies are listed by [PERSON] and [PERSON] [7]. Among the classified detection methods there are also strategies based on software metrics, like [32; 33; 34; 35]. However, again, studies focus on the identification of code smells using manually defined code smell detection rules. Among the most known code smells are Brain Class, God Class, Brain Method and Feature Envy presented by [PERSON] and [PERSON] [16]. They also present identification rules and some of them are implemented in Jdeodorand [36] and JSpIRIT [34]. The results of the conducted identification presented in [12], shows that the intersection between identified entities, using different detection methods and/or tools, is very small.