| ·更改控制： | a. 在配置项的配置标识正式确定之后对配置项或在基线确定后对基线的记录、评估、批
准或不批准和协调更改的过程。
b. 在正式确定配置项的配置标识之后对配置项的配置或在基线确定后对基线进行系统
评估、协调、批准或不批准以及批准更改的实施。 |
| ·商用成品(COTS)软件： | 由货主在公开的产品目录清单上出售的商业应用软件。COTS 软件不定制或改进。按具
体应用开发的合同订购的软件不是 COTS 软件。 |
| ·配置状态纪实： | 记录并报告有效管理配置必要的信息，包括批准的配置标识清单、配置更改的状态和批准
更改的实施情况。 |
| ·控制耦合： | 一个软件部件影响另一个软件部件执行的方式或程度。 |
| ·数据耦合： | 软件部件对不仅仅依赖于该软件部件的控制之下的数据。 |
| ·无效码： | 设计的可执行目标代码(或数据)是：
a. 不打算执行的代码或不打算使用的数据，如以前开发软件部件的一部分；
b. 仅在目标机环境的某一配置中执行的代码或使用的数据，例如可通过硬件引脚选择或
软件可编程的选项使能的代码。 |
| ·死码： | 在目标机环境的运行配置中不能执行的可执行目标代码或不能使用的数据。它不能追踪
到一个系统或软件需求。嵌入的标识符例外。 |
| ·判别覆盖范围： | 程序中的每一个入口和出口点至少执行一次，且程序中的每一判别至少在所有可能的输
出上发生一次。 |
| ·语句覆盖范围： | 程序中的每-个语句至少执行-次。 |
| ·覆盖范围分析： | 确定的软件验证过程活动满足其目标程度的过程。 |
| ·等效级： | 程序输入区域的划分，以使这个级的典型值的测试等效于这个级的其它值的测试。 |
| ·形式法： | 与建立、开发和推导系统行为特性有关的数学模型的描述性表示和分析方法。 |
| ·硬件∕软件综合： | 把软件组合到目标计算机中的过程。 |
| ·软件需求： | 软件应完成什么的描述。软件需求包括高级需求和低级需求。 |
| ·高级需求： | 根据系统需求、与安全性有关的要求及系统设计结构分析而开发的软件需求。 |
| ·低级需求： | 来自高级需求、派生需求及无需进一步信息就能直接实现源代码的设计限制的软件需求。 |
| ·派生需求： | 软件开发过程产生的附加需求，它不可以直接追踪到高级需求。 |
| ·独立性： | 确保完成目标评估的责任分工。
a. 对软件验证过程活动，验证活动应由被验证的项目的开发者之外的人完成。也可使用
工具来验证。
b. 对软件质量保证过程，独立性也包括确保纠正措施的权力。 |
| ·多版本非相似软件： | 分别开发两套或多套程序，以满足同样的功能要求。对一个版本的错误可通过多重输出
的比较来检查。 |
| ·软件划分： | 为了隔离一个或多个软件属性，防止特殊的相互作用和交叉/耦合干扰而对软件进行分离
的过程。 |
| ·系统安全性评估： | 对系统进行深入的、系统的、广泛的评估以表明与安全性有关的需求均已满足。 |
| ·系统安全性评估过程： | 证明符合适航要求及有关指南材料的活动。在这个过程中主要的活动包括功能危害度评
估、最初系统安全性评估及系统安全性评估。 |