## 3 Proposed Theoretical Framework for the Identification of Deficient Source Code  
Based on the presented challenges we propose a novel approach for identifying deficient source code with a combination of software metrics and by applying the majority function. The main steps of the proposed approach are presented in Figure 1 in the colored shape, joined with other commonly used activities performed within the identification of deficient source code. After setting the criteria, i.e., determining the quality aspects and selecting the individual software metrics, the proposed approach starts by deriving the threshold values for the selected software metrics. Then the actual values of selected software metrics are gathered for all the program entities. Figure 1: Identification of deficient program entities including steps of the proposed identification approach. The evaluation and quality rating of program entities is done next, based on the gathered software metrics values and the derived thresholds. The last step of our proposed approach is the identification of entities that potentially include deficient source code, after which the identification of deficient entities may continue by manually reviewing the identified potentially deficient entities, providing a final list of assuredly deficient program entities. Although the first two and the last two steps are not a part of the proposed approach itself, they contribute to overall understanding of the identification approach. The proposed approach arises from challenges connected to the identification of deficient program entities based on an individual software metric. The challenge was also recognized by [PERSON] et al. (2009) and [PERSON] and [PERSON] (2009). If software metrics are used in isolation, it is difficult to characterize the software as a whole since each metric evaluates only a certain aspect of software ([PERSON] and [PERSON], 2009). As they noted, a balanced overview of the current state of software can be achieved by combining multiple metrics ([PERSON] and [PERSON], 2009). Consequently, it makes sense to combine related single metrics into categories, expressing different quality aspects. Finally, all these categories, each representing a special quality aspect of a software, can be combined into a single quality score. This division constitutes a starting point for the proposed approach. After the determination of quality aspects that need to be covered during the evaluation, the appropriate software metrics are selected and assigned to each aspect. In general, the selection of software metrics and their division into quality aspects are not fixed and can be tailored to one's needs. Specific software metrics could be added and/or existing metrics could be changed for the purpose of evaluating different aspects of software. After a set of specific software metrics is determined, their threshold values are derived which serve as a measure of whether a program entity can be considered as potentially deficient regarding a specific metric. With the selected set of software metrics, divided into certain quality aspects, the identification of deficient source code can begin. After gathering software metrics values for program entities we want to evaluate, they are compared to the derived thresholds. If an actual value of a single software metric for a program entity exceeds the derived threshold, the entity is considered to be potentially deficient with regard to this single metric. The combined quality rate of each quality aspect, which is composed of several single metrics, is determined by the use of the majority function, based on the majority voting principle. The majority function is defined by Equation (1):  
\[Majrity_{y_{j}}=\left[\frac{(\sum_{i=1}^{n}x_{i})}{n}\right],x_{i}\in(0,1) \tag{1}\]  
where \(x_{i}\) stands for a single component value, contributing to a combined measure \(y_{j}\).