Page 74 - 《软件学报》2020年第11期
P. 74
3390 Journal of Software 软件学报 Vol.31, No.11, November 2020
证模型的有效性:一方面,通过和有关的专家进行讨论,确认模型是否符合实际情况,并对不符合的情况进行修
改;另一方面,根据 Sterman [13] 提出的 12 种用于系统动力学模型的检测方法,我们选择其中 11 种方法,通过实验
对模型进行检测.检测目的、步骤和结果见表 1.
Table 1 Model test in system dynamics
表 1 系统动力学模型检测
检测方法 [13] 检测目的 检测步骤/未检测原因 检测结果
确保模型中包含 从模型中移除重要的因果反馈环,看系统是否出现异常行为.
边界 重要的概念,评估 本文删除一个反馈循环图后,经过仿真运行后发现异常,如 模型通过
1 充分 模型边界是否与 处于“open”状态的 bug 数量为负导致模型行为出现异常, 边界充分
检测 检测
建模目的相符 不符合现实系统 bug 数量不能为负的取值范围设定
1. 检查模型中的方程,根据结果对变量的取值范围进行控制.
结构 确保模型 2. 检测模型对于输入非法值的响应是否符合要求. 模型通过
2 评估 符合质量 以需求变更管理子系统为例,对该系统中所有变量取极端 结构评估
检测 守恒物理定律 值−1,即取值范围之外的值,检测结果显示,在输入非法 检测
值的情况下,与现实系统中变量不为负的取值范围要求一致
1. 使用Vensim自带的“Units Check”功能对模型进行量纲检测.
量纲 检查每个 2. 人工逐个进行方程量纲检查. 模型通过
量纲
3 一致性 方程量纲 在第一次量纲检测时发现模型中存在4个量纲未赋值 一致性
检测 是否一致 或量纲不一致的错误,进行量纲修正后再次进行检测, 检测
所有模型符合量纲一致性
检查参数值 完成该项检测需使用统计学方法和细化模型.但由于
参数 是否与系统的 当前模型是软件需求变更管理过程是一个高度抽象,
4 评估 相关描述一致 细化模型需要更多的项目细节和项目人员参与, 未检测
检测
且取值一致 故该部分检测将在下一步工作中完成
极端 确保变量在输入 模型通过
5 条件 极端值的情况下, 1. 检查方程是否能处理极端输入值. 极端条件
2. 检测极端输入值模型的响应.
检测 每个方程仍然有意义 检测
通过缩短模型的时间单位间隔来进行检测,本文中将时间
时间单位选择 以“周”为时间
积分 应当合适, 间隔从以“周”为单位缩减为以“天”为单位来进行检测. 单位比以“天”
6 错误 且具有做够的 以质量管理子系统中“bug response rate”为例,以“周”为 为时间单位
检测 单位,能更直观、精确反映 bug 在分支的生命周期中的
灵敏度 更合适
响应数量的连续变化
R²的值越接近 1,
检查模型 使用 Matlab 2015b 中自带的逐点拟合
行为 说明回归直线对
7 重现 是否重新 工具对仿真结果与实际数据进行比较. 观测值的拟合程度
检测 系统中的 以变量“bug create rate”为例,将仿真数据同现实 越好,检测结果
2
重要的行为 数据进行逐点拟合分析,得到拟合优度 R =0.9716
表明拟合程度高
通过检查删除或
行为 修改关系时模型 采用回路中断分析进行行为异常检测,通过屏蔽模型中 模型通过
各回路所带来的影响,看模型是否有异常行为.
8 异常 是否出现异常 在模型中删除任意一个基于因果关系图的结构,都会 行为异常
检测 行为来确定 导致行为异常,所以这些变量都是不可屏蔽或删除的 检测
模型的重要关系
确定该模型 通过检测模型是否能生成在相同系统的
是否能够 其他例子中所观察到的现象来检测 模型在不同
家族 在与系统 本文除了对 Spring Framework 3.2.x 分支进行仿真建模外, 案例中能
9 成员 相同类的 还对 Hadoop 3.0.0 分支中的需求变更管理过程进行仿真 表现出
检测 其他实例中 建模,仿真结果表明,两个项目的多个变量均呈现不同的 不同的行为,
表现出 行为模式,说明模型具有能反映多种不同行为模式的能力, 具有多样性
不同行为 模型在所建模型的系统范围内具有一定的适用性
意外 检查模型中 研究及分析期间,
10 行为 是否有意外 意外行为的发生是偶然且不可预期的,故 未发现模型的
本文只有当意外行为发生时,才进行检测
检测 行为发生 意外行为