错误跟踪系统(BTS)是用于数据驱动决策的综合数据源。它的各种bug属性可以轻松识别BTS。它导致无标签,模糊,和嘈杂的错误报告,因为其中一些参数,包括严重性和优先级,是主观的,而是由用户或开发人员的直觉选择,而不是遵循正式的框架。本文提出了一种混合的,基于模糊的多准则,和多目标进化算法实现bug管理自动化的方法。拟议的方法,以一种新颖的方式,解决了支持多准则决策的权衡(a)收集关于错误报告的决定性和明确的知识,开发人员当前的工作负载和Bug优先级,(B)使用专业知识构建用于计算开发人员能力得分的指标,性能,和可用性(c)构建相对bug重要性分数的指标。五个开源项目的实验结果(Mozilla,Eclipse,净豆,Jira,和免费桌面)证明,通过提出的方法,与现有方法相比,大约20%的改进可以用谐波平均精度来实现,召回,f-measure,准确率为92.05%,89.04%,90.05%,91.25%,分别。当开发人员数量或bug数量发生变化时,可以以最低的成本有效地实现bug吞吐量的最大化。建议的解决方案解决了以下三个目标:(i)提高错误报告的分类准确性,(ii)区分活跃和不活跃的开发者,(iii)根据开发人员当前的工作量确定开发人员的可用性。
A bug tracking system (BTS) is a comprehensive data source for data-driven decision-making. Its various bug attributes can identify a BTS with ease. It results in unlabeled, fuzzy, and noisy bug reporting because some of these parameters, including severity and priority, are subjective and are instead chosen by the user\'s or developer\'s intuition rather than by adhering to a formal framework. This article proposes a hybrid, multi-criteria fuzzy-based, and multi-objective evolutionary algorithm to automate the bug management approach. The proposed approach, in a novel way, addresses the trade-offs of supporting multi-criteria decision-making to (a) gather decisive and explicit knowledge about bug reports, the developer\'s current workload and bug priority, (b) build metrics for computing the developer\'s capability score using expertise, performance, and availability (c) build metrics for relative bug importance score. Results of the experiment on five open-source projects (Mozilla, Eclipse, Net Beans, Jira, and Free desktop) demonstrate that with the proposed approach, roughly 20% of improvement can be achieved over existing approaches with the harmonic mean of precision, recall, f-measure, and accuracy of 92.05%, 89.04%, 90.05%, and 91.25%, respectively. The maximization of the throughput of the bug can be achieved effectively with the lowest cost when the number of developers or the number of bugs changes. The proposed solution addresses the following three goals: (i) improve triage accuracy for bug reports, (ii) differentiate between active and inactive developers, and (iii) identify the availability of developers according to their current workload.