Page 82 - 《软件学报》2020年第11期
P. 82

3398                                Journal of Software  软件学报 Vol.31, No.11, November 2020
















                                   (c) bug 创建率                            (d) 软件质量(缺陷率)














                                                      (e)  项目持续时间
                                        Fig.19    Simulation results for no_triage (Continued)
                                        图 19   无需求变更请求筛选及分类的仿真结果(续)

                 2.2.4    改进仿真结果对比分析
                    本节针对上述 3 种改进策略的仿真结果,通过分析 Spring Framework 采用 3 种策略所需的成本以及对应的
                 改进有效性,提出改进建议.在提高相同软件质量,即减少相同缺陷率情况下,采取 3 种策略所需的人力、时间成
                 本见表 3.
                                           Table 3    Cost comparison for improvements
                                                    表 3   改进花费对比
                                               改进策略             人力成本      时间成本
                                            增加代码评审环节               高         高
                                          激励开发人员的动机强度             一般        一般
                                        增加需求变更请求筛选和分类              少         少
                    通常情况下,采取 3 种改进策略分别需要花费不同的人力成本以及时间成本.如若采用增加代码评审环节
                 的改进策略,在需求变更数量较多时,因为需要对代码进行审阅,需要较多人力来进行代码评审,有可能使得增
                 加代码评审环节需要花费比较多的人力成本和时间成本.而采用激励开发人员动机强度的改进策略时,通常开
                 源软件项目均会采用如第 2.2.2 节描述的方式来提高其人员的动机强度,与其他两种改进策略相比,需要花费的
                 人力和时间成本处于中间水平.当然,需要注意的是,采取这类改进策略提高开发人员的动机强度时,应充分考
                 虑策略可能会无效甚至起反作用,使得开发人员的动机强度降低.而对于增加需求变更请求筛选和分类策略,由
                 于当前大中型开源软件大多都使用 issue tracking  system 进行需求变更管理,工具本身可以提供一定的变更请
                 求筛选和分类能力,相对而言,此项策略需要花费的人力成本和时间可能较少,故该策略也被大多数的开源软件
                 项目组所采用.
                    在 Vensim 中,采用上述 3 种改进策略对项目的进度影响进行仿真分析,仿真结果如图 20 所示.在图 20 中,
                 右图是左图放大后的局部细节.左图中:灰色的线表示没有采取需求变更请求筛选和分类的项目所需持续时间;
   77   78   79   80   81   82   83   84   85   86   87