Page 77 - 《软件学报》2020年第11期

康燕妮 等:软件需求变更管理的系统动力学仿真建模 3393

(a) 项目持续时间 (b) 软件质量(缺陷率)

(c) 开发人员动机
Fig.13 Baseline simulation results 3
图 13 基线仿真结果 3

从需求变更对软件进度的影响方面,根据图 12(a)、图 12(b)与图 13(a)、图 13(b),在该需求变更管理过程中,
随着时间的变化,处理软件需求变更所需的持续时间先降低后逐渐增加.处理软件需求变更所需的持续时间是
由待完成的需求变更请求数量除以实际人员的平均生产力计算得到的,在分支前期,需求变更请求数量较少且
开发人员的生产力快速上升,使得处理软件需求变更所需的持续时间降低;但在分支中期至后期,需求变更请求
数量急剧增加,而开发人员平均生产力上升速度相对缓慢,使得处理软件需求变更所需的持续时间不断增加.这
就造成分支的进度压力不断上升,从而使得开发人员动机强度逐渐下降(如图 13(c)所示),并近一步导致软件的
代码质量缓慢下降(图 13(b)中软件缺陷率上升表示软件质量下降).需要说明的是,在 310 周时,版本 3.2.10 发布,
bug 的报告率减少,故在 310 周后,软件的缺陷率变化较为平缓.
图 14(a)是需求变更管理子系统的仿真结果,表示已完成的需求变更请求 issue 数;图 14(b)是需求变更实现
子系统的仿真结果,表示需求变更代码量占总代码行数的百分比.
从需求变更对软件规模的影响方面,根据图 14(a)和图 14(b),在该需求变更管理过程中,随着完成的需求变
更数量的增加,软件变更的总代码行数不断上升,软件需求变更使得软件的规模扩张,增加了代码维护管理的难
度;同时,需求变更所造成的代码变更百分比也随需求变更数量不断上升,代码的频繁变更和大范围变更也会造
成软件的代码质量缓慢下降,如图 13(b)所示.另外需要说明的是,在 244 周后,版本 4.0 发布,此后项目组将大部分
精力投入到了新版本 4.0.x 的开发中去.故在 244 周之后,项目的需求变更完成减少,代码的变化量也趋于平缓.
图 15(a)和图 15(b)都是需求变更管理子系统的仿真结果.图 15(a)表示接受的需求变更请求所占百分比,可
以看出,该项目对用户提出的需求变更请求接受度均在 90%以上,因此该项目对于用户提出的需求变更有积极
响应,对于吸引用户的增加有积极的作用.图 15(b)反映了无效、被拒绝的需求变更请求数量占总需求变更请求
总数的百分比随时间的变化过程.在整个软件生命周期中,无效、被拒绝的需求变更请求在 10%的范围内.在项
目分支前期,无效、被拒绝的需求变更请求百分比呈总体快速上升趋势;从项目分支中期开始,需求变更请求百