KR101691083B1 - System and Method for Bug Fixing Developers Recommendation and Bug Severity Prediction based on Topic Model and Multi-Feature - Google Patents

Abstract

The present invention relates to a bug-correcting developer recommendation and a bug severity prediction system and method based on a topic model and a multi-attribute, more particularly, to a bug-correcting developer capable of predicting the severity of a bug, ≪ / RTI >
In order to achieve the above object, a bug correction developer recommendation and a bug severity prediction system based on a topic model and multiple characteristics according to an embodiment of the present invention includes a first extracting unit, a prefixing unit, and a recommending unit.

Description

{System and Method for Bug Fixing Developers Recommendation and Bug Severity Prediction based on Topic Model and Multi-Feature}

The present invention relates to a bug-correcting developer recommendation and a bug severity prediction system and method based on a topic model and a multi-attribute, more particularly, to a bug-correcting developer capable of predicting the severity of a bug, ≪ / RTI >

The present invention is derived from research conducted as a part of the next generation information computing technology development project of the future creation science department and the Korea Research Foundation [assignment number: 2014050304, task name: SW engineering technique and tool source technology Development (Semantic-based test support technology with integrated monitoring).

Often, an error message is output or a device malfunctions in the process of using various software through a computer such as a PC (personal computer), a smart phone, or a video game machine. This phenomenon is caused by a simple device malfunction, but it is often caused by defects in the hardware or the software itself. This means that the contents of the program constituting the hardware and the software contain erroneous codes. A computer fault or malfunction caused by a program defect is called a bug.

Bugs occur more often in complex software, and bugs that occur are assigned to developers along with bug reports for correction. At this point, the new bug is assigned to the developer by the triager in the bug repository.

Conventional large-scale software is largely dependent on bug reports submitted for performing bug correction activities. However, despite the fact that many bug reports have been submitted in the past, it has not been possible to effectively correct the submitted bug reports because it was impossible to know how quickly each bug should be handled.

In addition, in the past, many bug reports have been frequently reallocated due to failure to allocate them to appropriate developers. This has increased the time and cost of bug correction and increased software development costs.

Korean Unexamined Patent Publication No. 2012-0069388 entitled " Automatic Static Defect Classification and Reporting Automation System and Method "thereof classifies classes according to types of bugs based on data extracted from one or more bug detectors, Bug check data extracted from the bug's precondition and bug detectors are cross-checked to give added points and the bug items according to the given scores are finally adjusted for each class, Among the reported bugs, it is easy to allocate items that are likely to be true alarms, and overall, it suggests techniques that can reduce the false alarm rate.

However, the prior art is merely a bug allocation technique for efficiently reviewing a vast amount of result data extracted from the bug detector and finding the bug of the target software in a short time. In order to correct the allocated bug, To developers in a more efficient manner.

That is, in the prior art, many bug reports are not allocated to appropriate developers and are reallocated. Accordingly, there is still a problem in that bug correction time and cost are increased and software development cost is increased. In addition, the prior art fails to efficiently correct the bug report to be submitted.

Korean Patent Publication No. 2012-0069388 (Publication date: June 28, 2012)

The present invention relates to a bug-correcting developer recommendation and a bug severity prediction system and method based on a topic model and a multi-attribute, more particularly, to a bug-correcting developer capable of predicting the severity of a bug, It is an object of the present invention to provide a recommended system and method.

The present invention aims at efficiently correcting a bug report submitted by predicting the severity of a submitted bug report.

The present invention aims at improving the quality of software and reducing the time and cost of development by recommending an appropriate bug correction developer to correct many bugs that occur in complicated software.

In order to achieve the above object, a bug correction developer recommendation and a bug severity prediction system based on a topic model and multiple characteristics according to an embodiment of the present invention includes a first extracting unit, a prefixing unit, and a recommending unit.

The first extracting unit identifies a new bug report and a corresponding topic received based on the modeled topic, extracts a past bug report having the identified topic, and the selecting unit specifies a developer to correct the new bug report The recommendation unit computes a recommendation rank of the candidate developer using the activity experience information of the selected candidate developer, and calculates the recommendation rank based on the calculated recommendation rank, To recommend the developer to correct the new bug report.

Also, the first extracting unit may identify the first bug report using the frequency of the topic term appearing in the new bug report. The selecting unit may include a first developer that includes a contact person and a commenter extracted from the past bug report, The candidate developer can be selected based on the second developer extracted from the bug report having the same characteristics as the report. At this time, the selection unit may extract the second developer using at least one characteristic information of the product, the component, the priority, and the severity included in the past bug report.

In addition, the recommendation unit may include, as the activity experience information, information on the number of comments and commits indicating the activity in which the candidate developer participated in the bug correction, assignments indicating the experience that the candidate developer participated in bug correction, Number of attachments and the number of attachments can be used. In this case, the recommendation unit determines that the recommendation rank of the candidate developers is higher as the number of comments, the number of commits, the number of assignments, can do.

The system of the present invention may further include a predicting unit for predicting the severity of the new bug report based on the past bug report extracted by the first extracting unit.

Here, the predicting unit may include a second extracting unit that extracts common bug reports having the same characteristics from the past bug reports extracted by the first extracting unit, and a second extracting unit that calculates text similarity between the extracted common bug report and the new bug report Wherein the predicting unit can predict the severity of the new bug report based on the calculated text similarity and using a K-nearest neighbor algorithm, The text similarity can be calculated using the new bug report and Kullback-Leibler divergence.

Meanwhile, the topic model and the multi-feature-based bug correction developer recommendation and bug severity prediction method according to an embodiment of the present invention identify a new bug report and a corresponding topic received based on the modeled topic, Selecting a candidate developer using the extracted past bug report to recommend a developer to correct the new bug report, selecting the candidate bug report based on the activity experience information of the selected candidate developer Calculating a recommendation rank of the candidate developer, and recommending a developer to correct the new bug report based on the calculated recommendation rank.

In addition, the step of extracting the past bug report may be identified using the frequency of the topic term appearing in the new bug report, and the step of selecting the candidate developer may include a representative and a commenter extracted from the past bug report And the second developer extracted from the bug report having the same characteristics as the past bug report. In this case, the step of selecting the candidate developer may extract the second developer using at least one characteristic information of the product, the component, the priority, and the severity included in the past bug report.

The step of recommending the developer may include the number of comments and commits indicating the activity in which the candidate developer participated in the bug correction and the experience of participating in the bug correction by the candidate developer, The number of assignments and the number of attachments may be used. In this case, the step of recommending the developer may include the step of recommending the developer that the number of comments, the number of commits, the number of assignments, It can be judged that the developer's recommendation rank is high.

In addition, the method of the present invention may further include predicting the severity of the new bug report based on the past bug report extracted at the step of extracting the past bug report.

The step of predicting the severity may include extracting a common bug report having the same characteristics from the past bug reports extracted at the extracting of the past bug reports, extracting a common bug report between the extracted common bug report and the new bug report, Estimating the severity of the new bug report based on the calculated text similarity and estimating the severity of the new bug report using a K-nearest neighbor algorithm, The step of calculating the text similarity may calculate the text similarity using the new bug report expressed by a vector and Kullback-Leibler divergence.

The present invention relates to a bug-correcting developer recommendation and a bug severity prediction system and method based on a topic model and a multi-attribute, more particularly, to a bug-correcting developer capable of predicting the severity of a bug, It is possible to provide a recommended system and method.

The present invention has the effect of efficiently correcting a bug report submitted by predicting the severity of a submitted bug report.

The present invention has the effect of improving the quality of software and reducing the development time and cost by recommending an appropriate bug correction developer for correcting many bugs occurring in complicated software.

The present invention proposes a more appropriate bug correction developer by using multiple features including a topic model of a bug report and products, components, priority, and severity of a bug report, and has an effect of predicting the severity of a bug report have.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram illustrating a bug correction developer recommendation and a bug severity prediction system based on a topic model and multiple characteristics according to an embodiment of the present invention.
FIG. 2 is a block diagram of a bug-correcting developer recommendation and a bug severity predicting system based on a topic model and multiple characteristics according to a second embodiment of the present invention.
3 is a view showing details of an Eclipse JDT bug report having a bug ID number of 36465. FIG.
4 is a diagram illustrating a framework for bug correction developer recommendation according to an embodiment of the present invention.
5 is a diagram illustrating a workflow for predicting the severity of a bug report according to an exemplary embodiment of the present invention.
FIG. 6 is a flowchart illustrating an operation of recommending a bug correction developer and a bug severity prediction method based on a topic model and multiple characteristics according to an exemplary embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear. In the following description of the embodiments of the present invention, specific values are only examples.

The present invention relates to a bug-correcting developer recommendation and a bug severity prediction system and method based on a topic model and a multi-attribute, more particularly, to a bug-correcting developer capable of predicting the severity of a bug, ≪ / RTI >

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram illustrating a bug correction developer recommendation and a bug severity prediction system based on a topic model and multiple characteristics according to an embodiment of the present invention.

Referring to FIG. 1, a bug correcting developer recommendation and bug severity predicting system 100 based on a topic model and multiple characteristics according to an embodiment of the present invention includes a first extracting unit 110, a selecting unit 120, (130).

The first extracting unit 110 identifies a new bug report and a corresponding topic received based on the modeled topic, and extracts a past bug report having the identified topic.

The first extracting unit 110 can identify the topic corresponding to the received new bug report using the frequency of the topic term shown in the received new bug report. At this time, the higher the frequency, the more the new bug report received matches the topic.

More specifically, the first extractor 110 may first model the topic to identify the corresponding new bug report and corresponding topic. At this time, the first extracting unit 110 extracts a predefined field (e.g., a "summary", "description", etc.) in the bug report, a word token ) To coreNLP. That is, the first extracting unit 110 fetches each new bug report to coreNLP in order to perform preprocessing to obtain a word token.

The first extractor 110 then connects the word tokens from each bug report to the Stanford TMT to generate terms for each topic, Plugs the characteristics of the device. The first extractor 110 uses a word token to identify a new bug report and a corresponding topic received.

Table 1 below shows the terms for each topic in Eclipse extracted from TMT.

That is, the system 100 of the present invention may store data as shown in Table 1 as a modeled topic. Referring to Table 1, Topic-1 includes fields of predefined bug reports , "Text", "help", etc.) may be included in the topic 2 (Topic-2) , And word tokens such as "import "," export ", and "jar " may be included in Topic-3.

Accordingly, when a new bug report arrives, the first extracting unit 110 identifies and selects a topic that matches the new bug report received in the pre-stored modeled topic.

At this time, when the first extracting unit 110 selects a topic to be matched with the received new bug report, the first extracting unit 110 can select the topic word by calculating the frequency of the topic term appearing in the new bug report. If the frequency is highest, a given new bug report can be considered as belonging to the topic. For example, if a new bug report is preprocessed, words such as "context", "text", and help "included in topic 2 will appear in the new bug report as" import "and" export " The bug report can be determined to belong to the topic 2.

Then, the first extracting unit 110 extracts past bug reports belonging to the same topic as the received new bug report, in order to recommend an appropriate developer to correct the given new bug report and to predict the seriousness of the new bug report. That is, when the received new bug report belongs to the topic 2, the first extracting unit 110 extracts all the past bug reports belonging to the topic 2. That is, the present invention may store past bug reports corresponding to each modeled topic.

In the present invention, in order to recommend an appropriate developer to correct a given new bug report and to predict the severity of a new bug report, a multi-feature of the bug report as well as a topic model of the bug report described above do.

Hereinafter, the concept of the multi-characteristic utilized in the present invention will be described.

Bug reports are free-form text content, and bug reports typically include a default value (defeauts) that appears in the source code file. The bug report consists of predefined "Bug ID", "Title", "Component" and so on.

3 is a view showing details of an Eclipse JDT bug report having a bug ID number of 36465. FIG.

3, the bug report of FIG. 3 was submitted by Jason Sholl and the current status is "CLOSED" and "FIXED ", and the Eplipse product product) is classified as "JDT" and the component is "Core". In addition, the bug report has been assigned to a developer named Philipe Mulet to be modified.

At the bottom of the bug report, a bug description, an attachment (e.g., a patch, a test case, etc.), a commenter (i.e., a comment, Commenters, etc.) are provided. Note that commits information is not shown in the bug report at this time.

In practice, commits are stored in the history log of the bug repository. If the developer changes the code line, the developer must send a message declaring the code change. Thus, the present invention can improve the experience verification of developers correcting bugs through the features of such bug reports.

That is, the bug report has important meta-fields such as "Product", "Component", "Priority", "Severity" In the present invention, such an important meta-field is adopted as a multi-feature.

Among the multi-features, "Product" represents the first category that develops customer requirements, such as "JDT" and "PDE" in Eclipse. "Component" represents a sub-category belonging to a specific product, such as "Debug" and "UI." "Priority" and "Severity" It is a scale factor that indicates the degree to which a given new bug report is urgent or not.

Also, "Priority" indicates a priority for correcting a bug, and includes five steps from P1 to P5, where P1 indicates the highest priority and P5 indicates the lowest priority. For example, the bug report 36465 of FIG. 3 has the highest priority, P1, which means that the bug report should be corrected as soon as possible.

"Severity" refers to the degree of severity of a bug, and in a general way "Severity" can be divided into seven stages (eg Blocker, Critical, Major, (Normal), Minor, Trivial, Enhancement). Among the severities, the enhancement step is not a necessary bug for the new function, but the present invention includes it in the severity prediction.

Among the seven steps above, the Blocker, Critical, and Major stages represent serious problems in the program such as crashes, loss of data, and memory leaks. The Normal, Minor, Trivial, and Enhancement steps represent minor errors, cosmetic problems, and minor loss of function.

In particular, Blocker indicates the type of bug with the highest severity, and Trivial indicates the type of the bug with the lowest severity. For example, the bug report 36465 of FIG. 3 is labeled "Blocker ", which is the most serious error.

The present invention provides techniques for predicting the seriousness of a bug, recommending a suitable developer to correct a new bug by using a topic model and multi-characteristics.

On the other hand, the selection unit 120 selects a candidate developer using the extracted past bug report to recommend an appropriate developer to correct the received new bug report. In this case, the candidate developer can select from a set of developers using the topic model and a set of developers using the feature information.

The selection unit 120 may include a first developer (that is, a set of developers extracted using the topic model) that includes assigners and commenters extracted from the past bug reports, The candidate developer can be selected based on the second developer extracted from the bug report having the same characteristics (i.e., the set of developers extracted using the multi-characteristic).

At this time, the selection unit 120 may generate at least one of Multi-Feature information of Product, Component, Priority, and Severity included in the past bug report. The second developer can be extracted.

More specifically, when the first extracting unit 110 extracts a past bug report having the same topic as the new bug report, the selecting unit 120 extracts, from the extracted past bug report, all The developer (the participating developer at this time is the first developer, which may include assigness and commenters), as well as extracting characteristics such as the extracted past bug report (i.e., Developers who have participated in correcting the bug report from a bug report that has a multi-feature that includes product, component, priority, and severity And the participating developer means the second developer).

The selection unit 120 can extract the first developer and the second developer and then select the intersection of the first developer and the second developer as candidate developers. At this time, a list of candidate developers to correct a new bug can be generated by Equation (1). Equation (1) below represents a process of intersection of candidate developers.

In Equation (1), D represents a set of candidate developers who have contributed to correcting a bug report. These bug reports include the same topic, product, same component, same priority, (severity). That is, the selection unit 120 uses a developer extracted from a bug report having multi-characteristics different from a new bug report, as well as a developer extracted from a past bug report having a topic such as a new bug report, Can be selected.

The recommendation unit 130 may be configured to determine a recommendation rank (i.e., ranking) of the candidate developer using the activity experience information (e.g., the number of comments, the number of commits, the number of assignments, And recommends a developer to correct the new bug report based on the calculated recommendation ranking.

The recommendation unit 130 may include activity experience information of the selected candidate developers, which includes the number of comments and commits indicating the activity in which the candidate developer participated in the bug correction, and the number of commits that the candidate developer has participated in bug correction The number of assignments and the number of attachments indicating the number of attachments.

At this time, the recommendation unit 130 can determine that the recommendation rank of the candidate developers is higher as the number of comments, the number of commits, the number of assignments, and the number of assignments of attachments are lower. This is explained in detail as follows.

The recommendation unit 130 may consider activity information (e.g., comments and commit activities) of the candidate developers via the social network in order to recommend an appropriate developer to correct a new bug. That is, the recommendation unit 130 may first collect the activity of the candidate developers by parsing the XML file from the repository of Eclipse, Mozilla and Netbeans, etc., in order to analyze the behavior (or activity) of the candidate developers . At this time, parsing means a method of converting data stored in another format into data of a desired format.

In addition, in the present invention, the recommendation unit 130 is an element for improving the developer recommendation performance as appropriate, considering not only the number of comments and commits, but also the number of assignments and the number of attachments .

Then, the recommendation unit 130 obtains the recommendation rankings of the candidate developers through Equation (2) based on the activity experience information (e.g., the number of comments, the number of commits, the number of assignments, That is, ranking). Equation (2) represents a calculation method for calculating a recommendation rank (i.e., a ranking score) of candidate developers.

Where Dev _assignments represents the number assigned to developer Dev for bug correction and Dev _attachments represents the number of _attachments (e.g., uploaded patch files, etc.) in the bug report assigned to Dev. Dev _commit indicates the number of commits sent by the Dev (for example, changes to the history of the bug report), and Dev _comment indicates the number of comments run by Dev. n represents the number of topics.

Referring to Equation (2), the present invention considers the number of assignments and the number of attachments in addition to the number of comments and commits posted by candidate developers in the social network in order to more clearly distinguish developers' experience in bug correction.

In this case, the more empirical aesthetics the higher the number of assignments, the more experience developers can have. Also, like the number of allocations, the number of commits can be used to demonstrate the developer's experience.

On the other hand, according to Hooimeijer and Weimer (Hooimeijer and Weimer), according to the article "Modeling bug report quality," Proceedings of IEEE / ACM Inlernational Conference on Automated Software Engineering 2007, , Because the bug is likely to be corrected, which means that the bug allocated is more of a user's interest. They also found that the number of attachments is negative, because the presence of attachments represents an increased cost to fix bugs.

Accordingly, the recommendation unit 130 of the present invention assigns Dev _assignments , Dev _commit , Dev _comment as a numerator, and Dev _attachments as a denominator in Equation (2) to calculate a recommendation rank of candidate developers. That is, the recommendation unit 130 can determine that the recommendation rank of the candidate developers is high as the number of comments, the number of commits, the number of assignments, and the number of assignments of the attached files are low. The recommendation unit 130 may calculate the recommendation rank (i.e., ranking) of the candidate developer by calculating the DRScore of each candidate developer, and may calculate an appropriate developer to correct the new bug report based on the calculated recommendation rank Recommended.

4 is a diagram illustrating a framework for bug correction developer recommendation according to an embodiment of the present invention.

Based on the contents described in detail above, a framework for bug correction developer recommendation according to an embodiment of the present invention will be briefly described below.

Referring to FIG. 4, in order to recommend an appropriate developer to correct a received new bug report, the system 100 of the present invention firstly extracts, from the model 1 through the first extracting unit 110, Identifies a topic corresponding to a new bug report received based on the topic, and extracts a past bug report having the identified topic.

Then, in Step 1, the selection unit 120 selects a candidate developer using the extracted past bug report. At this time, the candidate developer may include a first developer (a developer using a topic model) including assigners and commenters extracted from past bug reports, and a first developer (a developer using a topic model) extracted from bug reports having the same characteristics as the past bug reports And may be selected based on the second developer (developer using multi-characteristics). This is described in detail above, and will be referred to here.

In step 2, the activity information of each candidate developer can be extracted through the recommendation unit 130 to calculate the recommendation rank of the candidate developers. At this time, as the activity experience information of the candidate developers, the number of comments and commits indicating the activity in which the candidate developer participated in the bug correction and the number of assignments indicating the experience that the candidate developer participated in the bug correction And the number of attachments can be extracted.

Finally, in Step 3, the recommendation unit 130 calculates the recommendation rank (i.e., ranking ranking) of the candidate developer based on the activity experience information of the candidate developers extracted in Step 2, And recommend a developer to correct the new bug report based on the calculated recommendation rank. The description thereof has been described above in detail, so that reference will be made thereto.

FIG. 2 is a block diagram of a bug-correcting developer recommendation and bug severity prediction system based on a topic model and multiple characteristics according to a second embodiment of the present invention.

Referring to FIG. 2, a bug-correcting developer recommendation and bug severity prediction system 100 based on a topic model and multiple characteristics according to a second embodiment of the present invention includes a first extracting unit 110 and a predicting unit 140 can do. The prediction unit 140 may include a second extraction unit 141 and a calculation unit 142. First, the role of each configuration will be briefly described as follows.

Since the description of the first extracting unit 110 has been described in detail above, the following description is omitted. The predicting unit 140 predicts the severity of the new bug report based on the past bug report having the identified topic extracted by the first extracting unit 110.

The second extracting unit 141 extracts common bug reports having the same characteristics from the past bug reports having the identified topics extracted by the first extracting unit. That is, the second extracting unit 141 may form a collection of bug reports having the same characteristics based on the past bug reports having the identified topic, and extract the intersection of the formed sets as a common bug report .

The calculation unit 142 calculates text similarity between the extracted common bug report and the new bug report. At this time, the calculation unit 142 may calculate the text similarity using the new bug report (i.e., smoothed UM) and KLB (Kullback-Leibler divergence) represented by a vector.

The predicting unit 140 may predict the severity of the new bug report based on the text similarity calculated by the calculating unit 142 and using a K-nearest neighbor algorithm.

This will be described in more detail as follows. 1, in order to recommend an appropriate developer to correct a new bug report, the "Product", "Component", "Priority", "Severity" Quot ;, but in the following embodiments, in order to predict the severity of a new bug report, " product ", "component ", "Quot;, " Component ", and "Priority ".

The system 100 of the present invention can be used to predict the severity of a received bug report based on a multi-attribute, including "Product," "Component," "Priority, feature to filter the bug report and generate a potential bug report. The system 100 of the present invention calculates the similarity between the new bug report and the past bug report through KL divergence and applies the similarity measure to the KNN to predict the severity of the new bug, Severity can be predicted. This will be described in more detail with reference to FIG.

5 is a diagram illustrating a workflow for predicting the severity of a bug report according to an exemplary embodiment of the present invention.

Referring to FIG. 5, the system 100 of the present invention can use a topic model and a multi-characteristic in order to predict the severity of a received new bug report, as in the embodiment of FIG.

First, as shown in step 1 of FIG. 5, the first extracting unit 110 first identifies a topic to which the received new bug report belongs, and outputs a past bug report including the identified topic, that is, Extract past bug reports with the same topic as the new bug report.

In step 1, the second extracting unit 141 extracts common bug reports having the same characteristics from the extracted past bug reports. At this time, the second extracting unit 141 extracts bug reports having the same characteristics (e.g., product, component, priority) based on the past bug report extracted from the first extracting unit 110 Form a set. And the intersection of sets formed by each property is a common bug report. Equation (3) below represents the intersection process of the bug report set.

Referring to Equation (3), the second extracting unit 141 extracts a set of bug reports having the same "product" property, the same " A set of bug reports having a " component "property, and a set of bug reports having the same" priority " Then, the second extracting unit 141 can obtain the filtered bug report B (i.e., the finally extracted bug report) from the intersection of the sets.

Next, in step 2, the calculator 142 calculates the difference between the new bug report and the filtered bug report B acquired by the second extracting unit 141, using the smoothed UM and KL divergence (Kullback-Leibler divergence) Calculate text similarity.

Here, the smoothed UM and KL divergence will be described in detail.

The smoothed UM (smoothed unigram model) means a smoothed unigram model, which measures the probability of occurrence of a specific word in the entire collection of documents in order to prevent the occurrence probability of a probability vector for a specific document from becoming zero Which makes the unigram model smoothed. By using smoothed UM, the present invention can calculate text similarity between filtered bug report B and new bug report.

The unigram of each document can be represented as a vector (i.e., a probability vector) composed of two or more random variables on the vector space.

However, if a word does not occur in one document, the probability of occurrence of the probability vector for this document becomes zero, and this phenomenon can cause problems in the probability expression. Thus, to solve this problem, the first unigram model makes the unigram model smoothed by using a collection model that measures the probability of occurrence of a particular word in the entire collection of documents.

Equation 4 defined below represents the smoothed UM of the Kth document, the second part of which expresses the collection model. In other words, the second part of equation (4) is to use a smoothed UM model to avoid a probability of occurrence of zero if a particular word did not occur at all in the bug report, it means. Equation (4) represents smoothed UM.

는 k 리포트의 가중치 벡터(weight vector)를 의미한다.

는 k 리포트 안에 단어 수를 의미하며, ω_k(n)은 k 리포트 안에 n번째 출현 빈도를 나타낸다. K는 리포트의 총 개수를 의미하며, μ는 수학식 1에서 두 부분의 서로 다른 가중치를 의미한다.In this case,? Denotes a term,

Denotes a weight vector of the k-th report.

Denotes the number of words in the k-report, and ω _k (n) denotes the n-th occurrence frequency in the k-report. K denotes the total number of reports, and μ denotes different weights of the two parts in Equation (1).

On the other hand, the calculation unit 142 can calculate the text similarity between the filtered bug report B and the new bug report by using KLB (Kullback-Leibler divergence).

KL divergence is a function used to calculate the similarity between a new bug report and a filtered bug report B (ie, a past bug report), which is used to calculate the difference between two probability distributions. At this time, the higher the KL divergence, the lower the similarity.

That is, Equation (5) represents a method of calculating the degree of similarity using KL divergence.

는 쿼리 q에서 용어 ω가 나타나는 확률을 의미하고,

는 버그 리포트 k에서 용어 ω가 나타나는 확률을 의미한다.At this time,

Denotes the probability that the term? Appears in the query q,

Means the probability that the term ω appears in the bug report k.

Accordingly, the calculator 142 can calculate the text similarity between the new bug report and the filtered bug report using the smoothed UM and KL divergence (Kullback-Leibler divergence). That is, the system 100 of the present invention can measure the text similarity between bug reports by using the KL divergence according to Equation (5) above.

Lastly, in step 3, the predicting unit 140 obtains the text similarity value as described above, thereby generating Blocker, Critical, Major, Normal, Minor, Trivial, Or KNN executed in the R language in order to predict the severity of the new bug report in one of the enhancement or enhancement.

That is, the system 100 of the present invention uses KNN to retrieve past bug reports similar to the top k with multi-characteristics that are the same as the given new bug report, when the new bug arrives, Can consider the severity labels of the new bug by considering the severity labels of the K-nearest neighbor algorithm.

KNN represents a non-parametric delayed learning algorithm, which means a technique for finding upper K objects similar to a given instance (where the instance is an individual element in a set) .

More specifically, KNN is a technique for determining what data belongs to which clusters over a distance based on the labeled data. After checking all the K data at the closest distance to the newly added data, The labeling of new data with the label showing the most characteristics in K data.

Accordingly, the prediction unit 140 can easily predict the severity of the new bug by analyzing the severity status of the bug report received based on the KNN.

Hereinafter, an operational flow diagram of the present invention will be briefly described based on the details described above.

FIG. 6 is a flowchart illustrating an operation of recommending a bug correction developer and a bug severity prediction method based on a topic model and multiple characteristics according to an exemplary embodiment of the present invention.

Referring to FIG. 6, a bug correcting developer recommendation and a bug severity predicting method based on a topic model and multiple characteristics according to an embodiment of the present invention are first performed by a first extracting unit 110 of the system 100, (Topic) corresponding to the received new bug report based on the topic, and extracts a past bug report having the identified topic (S610).

At this time, the first extracting unit 110 can identify the topic corresponding to the received new bug report using the frequency of the topic term appearing in the received new bug report. The higher the frequency, the more the new bug report received matches the topic. This has been described in detail above and will be referred to here.

Next, in order to recommend a suitable developer to correct the new bug report, the system manager 100 selects a candidate developer using the extracted bug report (S620).

In this case, the candidate developer can select from a set of developers using the topic model and a set of developers using the feature information.

More specifically, the selection unit 120 selects a first developer (that is, a set of developers extracted using the topic model) that includes assigners and commenters extracted from the past bug report, The candidate developer can be selected based on the second developer extracted from the bug report having the same characteristics as the past bug report (i.e., the set of developers extracted using the multi-characteristic). At this time, Feature information using at least one of a product, a component, a priority, and a severity included in the past bug report, Can be extracted. This has been described in detail above and will be referred to here.

Next, the recommendation unit 130 of the system 100 acquires the recommendation information of the candidate developer using the activity experience information (e.g., the number of comments, the number of commits, the number of assignments, the number of attached files, etc.) (I.e., ranking), and recommends a developer to correct the new bug report based on the calculated recommendation rank (S630).

At this time, the recommendation unit 130 may include activity experience information of the selected candidate developers, including the number of comments and commits indicating the activity in which the candidate developer participated in the bug correction, and the number of commits, You can use the number of assignments and the number of attachments that represent your experience. The recommendation unit 130 may determine that the recommendation rank of the candidate developers is higher as the number of comments, the number of commits, the number of assignments, and the number of assignments of attachments are lower. This has been described in detail above and will be referred to here.

Next, the system 100 of the present invention predicts the severity of the new bug report based on the past bug report having the identified topic extracted by the first extracting unit 110 by the predicting unit 140 (S640).

At this time, in order to predict the severity of the new bug report, the second extracting unit 141 in the predicting unit 140 extracts a past bug report having the identified topic extracted by the first extracting unit 141 It is possible to extract a common bug report having the same characteristics. The second extracting unit 141 may form a collection of bug reports having the same characteristics based on past bug reports having the identified topic, extract an intersection of the formed sets as a common bug report, This has been described in detail above and will be referred to here.

In step S640, the calculation unit 142 in the predicting unit 140 can calculate the text similarity between the extracted common bug report and the new bug report. The calculator 142 may calculate the text similarity using the new bug report (i.e., smoothed UM) and KL (kullback-leibler divergence) represented by a vector, which is described in detail above. .

In step S640, the prediction unit 140 may predict the severity of the new bug report based on the text similarity calculated by the calculation unit 142 and using a K-nearest neighbor algorithm . This has been described in detail above and will be referred to here.

Accordingly, the topic model and multi-attribute based bug correction developer recommendation and bug severity prediction system and method of the present invention can be applied to a multi-feature including a topic model of a bug report and a product, a component, priority and severity of a bug report It is possible to recommend a more suitable bug correction developer and to predict the severity of the bug report.

The bug correction developer recommendation and the bug severity prediction method based on the topic model and the multi-characteristic according to an embodiment of the present invention can be implemented in a form of a program command which can be executed through various computer means and recorded in a computer readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions recorded on the medium may be those specially designed and constructed for the present invention or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Magneto-optical media, and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

As described above, the present invention has been described with reference to particular embodiments, such as specific elements, and specific embodiments and drawings. However, it should be understood that the present invention is not limited to the above- And various modifications and changes may be made thereto by those skilled in the art to which the present invention pertains.

Accordingly, the spirit of the present invention should not be construed as being limited to the embodiments described, and all of the equivalents or equivalents of the claims, as well as the following claims, belong to the scope of the present invention .

100: Fixes bug based on topic model and multiple attributes Developer recommendation and bug severity prediction system
110: first extracting unit 120:
130: Recommendation part 140: Prediction part
141: second extracting unit 142: calculating unit

Claims (19)

A first extracting unit for identifying a new bug report received based on the modeled topic and a corresponding topic, and extracting a past bug report having the identified topic;
A selecting unit for selecting a candidate developer using the extracted past bug report to recommend a developer to correct the new bug report;
A recommendation unit for calculating a recommendation rank of the candidate developer using the activity experience information of the selected candidate developer and recommending a developer to correct the new bug report based on the calculated recommendation rank; And
A predictor for predicting the severity of the new bug report based on the past bug report extracted by the first extracting unit;
Lt; / RTI >
The predicting unit
A second extracting unit for extracting a common bug report having the same characteristics from past bug reports extracted by the first extracting unit; And
A calculation unit for calculating text similarity between the extracted common bug report and the new bug report;
Lt; / RTI >
Based on the calculated text similarity, a topic model for predicting the severity of the new bug report using a K-nearest neighbor algorithm, a bug correction based on multiple characteristics, a developer recommendation and a bug severity prediction system . The method according to claim 1,
The first extracting unit
Using the frequency of the topic term appearing in the new bug report
Bug fix based on topic model and multiple characteristics Developer recommendation and bug severity prediction system. The method according to claim 1,
The selecting unit
A first developer including a contact person and a commander extracted from the past bug report and a second developer extracted from a bug report having the same characteristics as the past bug report
Bug fix based on topic model and multiple characteristics Developer recommendation and bug severity prediction system. The method of claim 3,
The selecting unit
Extracts the second developer using at least one characteristic information of the product, the component, the priority, and the severity included in the past bug report
Bug fix based on topic model and multiple characteristics Developer recommendation and bug severity prediction system. The method according to claim 1,
The recommendation section
Wherein the activity experience information includes a number of comments and commits indicating an activity of the candidate developer participating in the bug correction and a number of assignments indicating an experience in which the candidate developer participated in bug correction and an attachment file attachment
Bug fix based on topic model and multiple characteristics Developer recommendation and bug severity prediction system. 6. The method of claim 5,
The recommendation section
It is determined that the recommendation rank of the candidate developers is high as the number of comments, the number of commits, the number of assignments, and the number of assignments of the attached files are low
Bug fix based on topic model and multiple characteristics Developer recommendation and bug severity prediction system. delete delete The method according to claim 1,
The calculation unit
The text similarity degree is calculated using the new bug report and Kullback-Leibler divergence represented by a vector
Bug fix based on topic model and multiple characteristics Developer recommendation and bug severity prediction system. Identifying a new bug report and a corresponding topic received based on the modeled topic, and extracting a past bug report having the identified topic;
Selecting a candidate developer using the extracted past bug report to recommend a developer to correct the new bug report;
Calculating a recommendation rank of the candidate developer using the activity experience information of the selected candidate developer and recommending a developer to correct the new bug report based on the calculated recommendation rank; And
Predicting the severity of the new bug report based on the past bug report extracted in the extracting of the past bug report;
Lt; / RTI >
The step of predicting the severity
Extracting a common bug report having the same characteristics from past bug reports extracted at the step of extracting the past bug reports; And
Calculating text similarity between the extracted common bug report and the new bug report;
Lt; / RTI >
Based on the calculated text similarity, a topic model for predicting the severity of the new bug report using a K-nearest neighbor algorithm, a bug correction based on multiple characteristics, a developer recommendation, and a bug severity prediction method . 11. The method of claim 10,
The step of extracting the past bug report
Using the frequency of the topic term appearing in the new bug report
Fixed bug fixes based on topic model and multiple attributes Developer recommendation and bug severity prediction method. 11. The method of claim 10,
The step of selecting the candidate developer
A first developer including a contact person and a commander extracted from the past bug report and a second developer extracted from a bug report having the same characteristics as the past bug report
Fixed bug fixes based on topic model and multiple attributes Developer recommendation and bug severity prediction method. 13. The method of claim 12,
The step of selecting the candidate developer
Extracts the second developer using at least one characteristic information of the product, the component, the priority, and the severity included in the past bug report
Fixed bug fixes based on topic model and multiple attributes Developer recommendation and bug severity prediction method. 11. The method of claim 10,
The step of recommending the developer
Wherein the activity experience information includes a number of comments and commits indicating an activity of the candidate developer participating in the bug correction and a number of assignments indicating an experience in which the candidate developer participated in bug correction and an attachment file attachment
Fixed bug fixes based on topic model and multiple attributes Developer recommendation and bug severity prediction method. 15. The method of claim 14,
The step of recommending the developer
It is determined that the recommendation rank of the candidate developers is high as the number of comments, the number of commits, the number of assignments, and the number of assignments of the attached files are low
Fixed bug fixes based on topic model and multiple attributes Developer recommendation and bug severity prediction method. delete delete 11. The method of claim 10,
The step of calculating the text similarity
The text similarity degree is calculated using the new bug report and Kullback-Leibler divergence represented by a vector
Fixed bug fixes based on topic model and multiple attributes Developer recommendation and bug severity prediction method. A computer-readable recording medium having recorded therein a program for executing the method according to any one of claims 10 to 15 and 18.

Images