当前位置: 首页 > 专利查询>扬州大学专利>正文

面向软件修改的风险分析方法技术

技术编号:14233488 阅读:125 留言:0更新日期:2016-12-20 23:53
本发明专利技术涉及面向软件修改的风险分析方法。本发明专利技术使用TF‑IDF算法提取出关键词并反馈给开发人员,修改提交信息和修复的bug信息角度对修改提交进行分析,为开发人员的修改提交提供了风险结果以及相应的风险解释,对修改提交进行了风险分析,结合了该开发人员的历史提交信息和bug中的评论信息,供开发人员的修改提交进行参考,并给出了缺陷产生的原因,形成风险特征说明,并给出相应的风险解释。本发明专利技术克服了过去并没有考虑到开发人员的开发历史以及相关bug评论中内容的缺陷。本发明专利技术给出了缺陷产生的原因,有效地提高软件维护质量,降低软件维护带来的风险。

Risk analysis method for software modification

The invention relates to a risk analysis method for software modification. The invention uses TF IDF algorithm to extract keywords and feedback to the developers to modify the bug angle of the information submitted information and repair to modify submitted for analysis, for developers to modify submitted provides results of risk and the corresponding risk, to modify the commit of risk analysis, combined with the development history of personnel information submitted and bug in the comments information for developers to modify submitted for reference, and gives the causes of the defects, the formation of risk characteristics, risk and gives the corresponding explanation. The invention overcomes the defects that the past has not been taken into account in the development history of the developer and the contents of the relevant bug comments. The invention provides the cause of the defect, effectively improves the quality of software maintenance, and reduces the risk of software maintenance.

【技术实现步骤摘要】

本专利技术属于软件维护领域,特别涉及面向软件修改的风险分析方法
技术介绍
由于软件工程的复杂性,软件开发与维护过程中常常会出现软件漏洞,这些漏洞导致大量的人力、物力的损失,因此软件质量问题就成为软件工程研究领域重要的分区之一。如今有很多研究着眼于软件质量的预测,许多软件分析和预测工作提出了关于软件度量、软件模型的方法,用来准确地分析和预测软件质量。但当前的分析和预测技术的采纳率非常低,针对软件质量的分析和预测仍是一个难题,因为缺乏相应的可以被实际操作的工具。另外,开发者在提交修改时,由于多方面的因素,可能会导致提交诱导出更多bug,从而造成开发人员的不断维护,增加了软件维护的成本。为了提高软件维护质量,降低软件维护带来的风险,目前软件维护研究领域出现了很多相关技术,这些技术主要都集中于研究如何更准确地分析和预测提交修改的风险,一般是通过相关的软件度量和软件模型对软件项目进行分析和预测,也有一些相关的工具给出了宏观的缺陷分布情况。但是,这些技术并没有考虑到开发人员的开发历史以及相关bug评论中内容,使得针对提交信息的分析并不完善,同时并没有提供直观的风险预测结果和缺陷产生的原因,开发人员并不能清晰地了解到当前修改提交出现风险的原因,还需要自行根据统计数据予以确定,缺少对整个软件提交的具体分析和解释,使软件维护的过程更加困难。
技术实现思路
本专利技术的目的就在于克服上述缺陷,研制面向软件修改的风险分析方法。本专利技术的技术方案是:面向软件修改的风险分析方法,其主要技术特征在于如下步骤:(1)使用TF-IDF算法提取出关键词并反馈给开发人员,用余弦函数对预处理后的提交信息与历史提交信息库和bug库进行相似度计算,识别与当前提交相似度较高的历史提交和bug,并根据提交信息和相关bug库,提取出bug编号、bug 相关状态、bug的严重性、与其他bug的联系等相关信息,形成一个修改提交,相关信息的对应列表,作为后续步骤的参考,以及bug可能出现reopen的风险性的一个考察;(2)在当前提交信息的开发人员的历史提交信息库中,通过统计,得出该开发者对于同一软件漏洞的多次修改的次数,以及修改的漏洞出现reopen的次数,与该项目所有开发者的对于同一软件漏洞的多次修改的次数,以及修改的漏洞出现reopen的次数平均值进行比较,记比较后的偏移量为p;若统计次数高于平均值且p>10%,开发者能力评估为低;统计次数高于平均值且p<10%,开发者能力评估为中;统计次数低于平均值,开发者能力评估为高;若开发者能力评估较低,则表明针对同一软件漏洞出现多次非计划性的修改提交和reopen记录,则表明该开发者可能经验不足,当前的提交信息具有较高的风险;(3)根据提交信息中的代码,查看提交信息中的代码变更,统计删除,增加的代码行数,查看修改涉及到的代码中的文件、类、方法的具体信息,形成代码更改的集合,规定一次修改提交文件、类、方法修改的次数的阈值分别为8,5,5,根据集合中的内容,统计一次修改提交文件、类、方法修改的次数,将修改的文件、类、方法的个数与阈值进行比较,若高于阈值,则说明该修改提交可能具有风险,且数值越高,风险性越大;统计它们在历史修改库中被开发人员重复修改的次数;如果被重复修改的次数过多,则说明该段代码的稳定性不高,而开发人员对此段代码的修改提交也具有较高风险;(4)利用主题模型提取历史相关bug中的评论,对评论中出现的bug报告评论中关键词进行分析,提取出一些主题特征;(5)将上述结果反馈给开发人员,根据bug可能出现reopen的风险,代码的不稳定性考察结果,开发者能力评估结果,bug报告的主题特征,形成风险特征说明,并给出相应的风险解释。附图说明图1——本专利技术流程示意图。图2——本专利技术相关修改提交信息示意图。具体实施方式本专利技术的技术思路是:本专利技术从开发人员的工作能力,修改提交信息和修复的bug信息角度对修改提交进行分析,为开发人员的修改提交提供了风险结果以及相应的风险解释。此方法不仅更准确地对修改提交进行了风险分析,而且结合了该开发人员的历史提交信息和bug中的评论信息,供开发人员的修改提交进行参考,并给出了缺陷产生的原因,有效地提高软件维护质量,降低软件维护带来的风险。如图1所示:本专利技术步骤如下:步骤(1).使用TF-IDF算法提取出关键词并反馈给开发人员,用余弦函数对预处理后的提交信息与历史提交信息库和bug库进行相似度计算,识别与当前提交相似度较高的历史提交和bug,,并根据提交信息和相关bug库,提取出bug编号、bug相关状态、bug的严重性、与其他bug的联系等相关信息。形成一个<修改提交,相关信息>对应列表,作为后续步骤的参考,以及bug可能出现reopen的风险性的一个考察。当前bug信息的对应列表就作为风险性的一个考察指标,开发人员通过了解相关的bug信息,知道提交修改中的不足,降低对软件漏洞的重复修复。例如:其中<bug_id>、<keywords>、<who>、<bug_status>被用来作参考。提取出的相关信息 <bug_id> 679494 <keywords> patch,review <who> birunthan <bug_status> RESOLVED FIXED 其中<bug_importance>、<bug_priority>、<component>、<dependson>、<blocks>、<reported_time>、<modified_time>被用为作为bug可能出现reopen的风险性考察上述TF-IDF算法:词频(TF)=某个单词在修改提交中出现的总次数/修改提交的总词数。逆文档频率(IDF)=log(修改提交总数/包含该单词的修改提交数+1)。TF-IDF权值w=TF*IDF权值高低说明关键词是否反映了修改提交的主题。步骤(2).在当前提交信息的开发人员的历史提交信息库中,通过统计,得出该开发者对于同一软件漏洞的多次修改的次数,以及修改的漏洞出现reopen的次数,与该项目所有开发者的对于同一软件漏洞的多次修改的次数,以及修改的漏洞出现reopen的次数平均值进行比较,记比较后的偏移量为p。若统计次数高于平均值且p>10%,开发者能力评估为低;统计次数高于平均值且p<10%,开发者能力评估为中;统计次数低于平均值,开发者能力评估为高。若开发者能力评估较低,则表明针对同一软件漏洞出现多次非计划性的修改提交和reopen记录,则表明该开发者可能经验不足,当前的提交信息具有较高的风险。通过对开发者能力的评估,得出当前提交信息具有风险性的可能,作为降低软件维护风险的一个指标。例如:对于同一软件漏洞的多次修改的次数的平均值为2.46,该开发者修改次数为2,能力评估为高。修改的漏洞出现reopen的次数平均值为3.19,该开发者的次数为4,P≈0.2025=20.25%>10%,开发者此项能力评估为低。步骤(3).根据提交信息中的代码,提取代码变更。统计删除,增加的代码行数本文档来自技高网...
面向软件修改的风险分析方法

【技术保护点】
面向软件修改的风险分析方法,其特征在于如下步骤:(1)使用TF‑IDF算法提取出关键词并反馈给开发人员,用余弦函数对预处理后的提交信息与历史提交信息库和bug库进行相似度计算,识别与当前提交相似度较高的历史提交和bug,并根据提交信息和相关bug库,提取出bug编号、bug相关状态、bug的严重性、与其他bug的联系等相关信息,形成一个修改提交,相关信息的对应列表,作为后续步骤的参考,以及bug可能出现reopen的风险性的一个考察;(2)在当前提交信息的开发人员的历史提交信息库中,通过统计,得出该开发者对于同一软件漏洞的多次修改的次数,以及修改的漏洞出现reopen的次数,与该项目所有开发者的对于同一软件漏洞的多次修改的次数,以及修改的漏洞出现reopen的次数平均值进行比较,记比较后的偏移量为p;若统计次数高于平均值且p>10%,开发者能力评估为低;统计次数高于平均值且p<10%,开发者能力评估为中;统计次数低于平均值,开发者能力评估为高;若开发者能力评估较低,则表明针对同一软件漏洞出现多次非计划性的修改提交和reopen记录,则表明该开发者可能经验不足,当前的提交信息具有较高的风险;(3)根据提交信息中的代码,查看提交信息中的代码变更,统计删除,增加的代码行数,查看修改涉及到的代码中的文件、类、方法的具体信息,形成代码更改的集合,规定一次修改提交文件、类、方法修改的次数的阈值分别为8,5,5,根据集合中的内容,统计一次修改提交文件、类、方法修改的次数,将修改的文件、类、方法的个数与阈值进行比较,若高于阈值,则说明该修改提交可能具有风险,且数值越高,风险性越大;统计它们在历史修改库中被开发人员重复修改的次数;如果被重复修改的次数过多,则说明该段代码的稳定性不高,而开发人员对此段代码的修改提交也具有较高风险;(4)利用主题模型提取历史相关bug中的评论,对评论中出现的bug报告评论中关键词进行分析,提取出一些主题特征;(5)将上述结果反馈给开发人员,根据bug可能出现reopen的风险,代码的不稳定性考察结果,开发者能力评估结果,bug报告的主题特征,形成风险特征说明,并给出相应的风险解释。...

【技术特征摘要】
1.面向软件修改的风险分析方法,其特征在于如下步骤:(1)使用TF-IDF算法提取出关键词并反馈给开发人员,用余弦函数对预处理后的提交信息与历史提交信息库和bug库进行相似度计算,识别与当前提交相似度较高的历史提交和bug,并根据提交信息和相关bug库,提取出bug编号、bug相关状态、bug的严重性、与其他bug的联系等相关信息,形成一个修改提交,相关信息的对应列表,作为后续步骤的参考,以及bug可能出现reopen的风险性的一个考察;(2)在当前提交信息的开发人员的历史提交信息库中,通过统计,得出该开发者对于同一软件漏洞的多次修改的次数,以及修改的漏洞出现reopen的次数,与该项目所有开发者的对于同一软件漏洞的多次修改的次数,以及修改的漏洞出现reopen的次数平均值进行比较,记比较后的偏移量为p;若统计次数高于平均值且p>10%,开发者能力评估为低;统计次数高于平均值且p<10%,开发者能力评估为中;统计次数低于平均值,开发者能力评估为高;若开发者能力评估较低,则表明针对同一软件漏洞出现多次非...

【专利技术属性】
技术研发人员:孙小兵郭虹静李斌李云
申请(专利权)人:扬州大学
类型:发明
国别省市:江苏;32

网友询问留言 已有0条评论
  • 还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。

1