高清可复制 HB/Z 421-2014(2017) 民用飞机机载系统和设备软件合格审定保证指南

　　ICS 49.090 V 35

　　HB/Z 421-2014

　　民用飞机机载系统和设备软件合格审定

　　保证指南

　　Assurance guidance for software in airborne systems and equipment

　　certification for civil aircraft

　　2014-07-09 发布 2014-11-01 实施

　　中华人民共和国工业和信息化部 发 布

　　前 言

　　本指导性技术文件按照 GB/T 1. 1-2009 给出的规则起草。

　　本指导性技术文件由中国航空综合技术研究所归口。

　　本指导性技术文件起草单位：中国航空工业集团公司第六三一研究所、中国航空综合技术研究所。

　　本指导性技术文件主要起草人：张学宏、田莉蓉、朱晓飞、张臻鉴、孔德岐、黄永葵、李雪龙、席 平、母方欣。

　　民用飞机机载系统和设备软件合格审定保证指南

　　1 范围

　　本指导性技术文件规定了民用飞机机载系统和设备合格审定的软件保证和开发准则。

　　本指导性技术文件适用于民用飞机机载系统和设备中软件开发，发动机软件开发也可参考使用。

　　本指导性技术文件不包括软件运行方面的合格审定问题，也不包括申请人的组织结构、申请人与供应商的关系和职责划分、人员的资质等问题。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件， 仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　CCAR-25-R4 运输类飞机适航标准

　　GB/T 11457-2006 信息技术 软件工程术语

　　FAA AC 25. 1309-1A-1988 系统设计分析(System design analysis)

　　3 术语、定义和缩略语

　　3.1 术语和定义

　　GB/T 11457-2006 界定的以及下列术语和定义适用于本文件。

　　3.1.1

　　异常行为 anomalous behavior

　　与指定的要求不一致的行为。

　　3.1.2

　　申请人 applicant

　　寻求合格审定机构批准的人或组织。

　　3.1.3

　　批准 approval

　　表明赞同观点或给出正式或官方许可的活动或程序。

　　3.1.4

　　保证 assurance

　　为产品或过程满足给定需求提供足够信心和证据所必须的、有计划的和系统的活动。

　　3.1.5

　　基线 baseline

　　一个或多个配置项经批准的、有记录的构型， 作为进一步开发的基础，且只能通过更改控制规程才

　　允许更改。

　　3.1.6

　　合格审定(或认证) certification

　　由认证机构对某一产品、服务、组织或个人就符合要求的情况给出的合法承认。这种认证包括一系列对产品、服务、组织、人员的技术检查活动， 并通过颁发国家法律或规程所要求的证书、许可证、批文或其他文件，正式地承认其符合适用的规章和适航的要求。产品合格审定包括：

　　a) 取证申请人评估产品设计、向认证机构证明产品符合适用的规章以及该型产品所适用的标准，以证明其产品达到了认可的安全级别;

　　b) 为确保产品与所批准的型号设计相一致所进行的产品评估过程;

　　c) 认证机构寻找符合性证据、并依照国家法律要求颁布证书的过程，声明所发现的一致性和/或符合度与上述 a)或 b)的标准是一致的。

　　3.1.7

　　合格审定机构(或认证机构) certification authority

　　在某一地区或国家中，负责对要求的符合性进行合格审定的组织或个人。

　　3.1.8

　　合格审定的信任(或认证信任) certification credit

　　合格审定机构对过程、产品或演示满足合格审定要求的认可。

　　3.1.9

　　更改控制 change control

　　本术语包含两层意思：

　　a) 对正式建立标识的构型项或基线的更改进行记录、评估、批准/否决以及协调的过程;

　　b) 对批准的正式建立标识的构型项或基线的更改，进行系统的评估、协调、批准/否决以及实现。注：该术语在其他工业标准中可能称为构型控制(Configuration control)。

　　3.1.10

　　商用成品(COTS)软件 commercial off-the-shelf (COTS) software

　　货主在公开的产品目录清单上出售的商业应用软件。COTS 软件不定制或改进。按合同订购开发的特定应用软件不是 COTS 软件。

　　3.1.11

　　条件 condition

　　不含布尔运算符的布尔表达式。

　　3.1.12

　　条件/判定覆盖 condition/decision coverage

　　程序中每个入口和出口点至少执行一次，程序中一个判定的每个条件的所有可能结果至少发生一次，且程序中的每个判定的所有可能结果至少发生一次。

　　3.1.13

　　配置标识 configuration identification

　　配置标识可以是：

　　a) 指定系统中配置项并记录其特性的过程;

　　b) 定义一个配置项的已批准文件。

　　3.1.14

　　配置项 configuration item

　　配置项可以是：

　　a) 为了配置管理目的，作为一个单元对待的一个或多个硬件或软件部件;

　　b) 为了配置管理目的，作为一个单元对待的软件生存周期资料。

　　3.1.15

　　配置管理 configuration management

　　配置管理可以是：

　　a) 标识和定义系统的配置项、在软件生存周期中控制这些配置项的发布和更改、记录并报告配置项及其更改申请的状态、以及验证配置项的完整性和正确性的过程。

　　b) 用于对下列因素进行技术上和管理上的指导和监督的规定：

　　1) 标识并记录配置项的功能特性和物理特性;

　　2) 控制对以上特性的更改;

　　3) 记录并报告更改控制处理和实现状态。

　　3.1.16

　　配置状态纪实 configuration status accounting

　　有效管理某一配置所必需的信息的记录和报告，包括已批准的配置标识清单、所建议的配置更改的状态和已批准更改的实施状况。

　　3.1.17

　　控制耦合 control coupling

　　一个软件部件影响另一个软件部件执行的方式或程度。

　　3.1.18

　　覆盖分析 coverage analysis

　　确定所建议的软件验证过程活动对其目标满足程度的过程。

　　3.1.19

　　数据耦合 data coupling

　　一个软件部件对不完全受该软件部件控制的数据的依赖程度。

　　3.1.20

　　无效码 deactivated code

　　可执行的目标代码或数据，根据设计它们是：

　　a) 不打算执行的代码或不打算使用的数据，如以前开发软件部件的一部分;

　　b) 仅在目标机环境的某些配置中执行的代码或使用的数据，例如可通过硬件引脚选择或软件预设的选项使能的代码。

　　3.1.21

　　死码 dead code

　　因设计错误而存在的、在目标机环境的运行配置中不能执行的可执行目标代码或不能使用的数据。它们不能追踪到一个系统或软件需求。嵌入的标识符例外。

　　3.1.22

　　判定 decision

　　由条件和零或更多的布尔操作符组成的布尔表达式。没有布尔操作符的判定是一个条件。如果在一个判定中一个条件多次出现，那么每一个值都是一个不同的条件。

　　3.1.23

　　判定覆盖 decision coverage

　　程序中的每一个入口和出口点至少被执行一次，且程序中的每个判定所有可能的输出至少发生一次。

　　3.1.24

　　派生需求 derived requirements

　　在软件开发过程中产生的附加需求，这些需求不能直接追踪到较高层次的需求。

　　3.1.25

　　模拟器 emulator

　　与给定系统使用相同的目标码，接收同样的输入并产生相同输出的装置、计算机程序或系统。

　　3.1.26

　　等价类 equivalence class

　　程序输入域的分割区间，使得对一个类中典型值的测试等效于对这个类中其他值的测试。

　　3.1.27

　　错误 error

　　对软件而言，指在需求、设计或代码中的失误。

　　3.1.28

　　失效 failure

　　系统或系统部件不能在规定的限制内完成要求的功能。当遇到故障时，可能产生失效。

　　3.1.29

　　失效状态 failure condition

　　由于不正确的行为和环境条件导致的一个或多个失效，直接或间接地对飞机及其乘员造成的影响。失效状态是根据 FAA AC 25. 1309-1A-1988 中所定义的影响的严重程度来进行分类的。

　　3.1.30

　　故障 fault

　　软件中错误所表现出来的症状。一个故障如果发生，可能引起失效。

　　3.1.31

　　容错 fault tolerance

　　在出现有限次数硬件或软件故障的情况下，系统继续正确执行的固有能力。

　　3.1.32

　　形式法 formal methods

　　用于建立、开发和推导系统行为数学模型的描述性表示和分析方法。

　　3.1.33

　　硬件/软件集成 hardware/software integration

　　把软件集成到目标计算机的过程。

　　3.1.34

　　高层需求 high-level requirements

　　对系统需求、系统安全性相关的需求和系统结构进行分析，开发出来的软件需求。

　　3.1.35

　　独立性 independence

　　确保达到客观评价的目的所需要的职责分离。

　　a) 对软件验证过程活动，保证验证独立性可以将验证活动由被验证项目开发者之外的人完成，也可使用工具来代替人工验证活动;

　　b) 对软件质量保证过程，独立性也包括确保纠正措施得到落实的权力。

　　3.1.36

　　支持过程 integral process

　　协助软件开发过程及其他的支持过程并在整个软件生存周期内始终发挥作用的过程。支持过程包括软件验证过程、软件质量保证过程、软件配置管理过程及合格审定联络过程。

　　3.1.37

　　低层需求 low-level requirements

　　从高层需求、派生需求和设计约束导出的软件需求。基于这些需求， 无须进一步信息就可以直接实现源代码。

　　3.1.38

　　符合性方法 means of compliance

　　申请人准备使用的满足航空器或发动机合格审定基础中的规定需求的方法，例子包括说明、图纸、分析、计算、试验、仿真、检验和环境鉴定。如适用，可使用由合格审定机构颁发的咨询材料。

　　3.1.39

　　改进的条件/判定覆盖 modified condition/decision coverage

　　程序中的每一入口和出口至少已调用到一次，程序中判定的每一条件所有可能的输出至少发生一次，程序中的每一判定所有可能的输出至少发生一次，并且判定中每个条件都独立地影响判定的输出。当保持并固定所有其他可能的条件值时，通过仅改变某条件表明其能独立地影响判定的输出结果。

　　3.1.40

　　监控 monitoring

　　监控可以是：

　　a) [安全性]在系统中设计用来检测系统异常行为的功能能力。

　　b) [质量保证]对测试、检验或其他活动、或那些活动记录的被选实例进行目击或检查的活动， 以

　　保证活动是受控的且所报告的结果能代表期望结果。监控通常与在一个跨度很长的时间段内完成的活动有关，100%的目击(这些活动)被认为是不切实际的或是没必要的。监控允许证明所要求的活动是按计划完成的。

　　3.1.41

　　多版本非相似软件 multiple-version dissimilar software

　　分别开发的满足相同功能要求的两套或多套程序。具体到某个版本的软件错误可通过比较多路输出检测出来。

　　3.1.42

　　目标代码 object code

　　计算机程序的低级表示形式，通常不是一种目标计算机直接使用的形式，而是一种包括了重定位信息以及处理器指令信息的形式。

　　3.1.43

　　部件编号 part number

　　用来标识一个配置项的一组数字、字母或其他字符集合。

　　3.1.44

　　补丁 patch

　　对目标程序的更改。在该更改过程中， 省略了重新编译、重新汇编或重新连接等一个或多个预定步骤。但这种更改，不能改变嵌在软件产品中的标识符，如部件编号和校验和。

　　3.1.45

　　过程 process

　　在软件生存周期中产生确定输出或产品的活动的集合。

　　3.1.46

　　产品服务历史 product service history

　　指一个连续时间段，在此期间软件在已知环境中运行且所有失效均被记录。

　　3.1.47

　　正确性证明 proof of correctness

　　逻辑上可靠的论据，证明程序满足其需求。

　　3.1.48

　　发布 release

　　正式使可检索配置项可用和授权使用的行动。

　　3.1.49

　　逆向工程 reverse engineering

　　从源代码提取软件设计信息的方法。

　　3.1.50

　　健壮性 robustness

　　尽管接受到无效输入，软件能继续正确运行的程度。

　　3.1.51

　　仿真器 simulator

　　在软件验证期间使用的设备、计算机程序或系统， 它使用来自原始目标代码的目标码、接受同样的输入并产生与给定系统相同的输出。

　　3.1.52

　　软件更改 software change

　　对基线中源代码、目标码、可执行目标码或有关文档的修改。

　　3.1.53

　　软件集成 software integration

　　组装代码部件的过程。

　　3.1.54

　　软件分区化 software partitioning

　　为了隔离一个或多个软件属性，防止特殊的相互作用和交叉/耦合干扰而对软件进行分离的过程。

　　3.1.55

　　软件产品 software product

　　用于交付用户的一套计算机程序及其相关文档和数据。在本文档中， 这个术语表示预定用在机载应用中的软件及相关软件生存周期资料。

　　3.1.56

　　软件需求 software requirement

　　描述软件在给定输入和限制的情况下的产出。软件需求包括高层需求和低层需求。

　　3.1.57

　　源代码 source code

　　用源语言(如汇编语言和/或高级语言等)写成的代码，以机器可读的形式存在，作为汇编程序或编译程序的输入。

　　3.1.58

　　标准 standard

　　为指定活动或特定数据项内容提供指南和性能评估的规则或比较基础。

　　3.1.59

　　语句覆盖 statement coverage

　　程序中的每一条语句至少执行一次。

　　3.1.60

　　静态分析器 static analyzer

　　不执行程序而揭示程序某些特性的软件工具。

　　3.1.61

　　结构 structure

　　为构成整体，部件的特定排列方式和相互关系。

　　3.1.62

　　系统安全性评估 system safety assessment

　　对系统进行持续的、系统的、广泛的评估以表明与安全性有关的需求均已满足。

　　3.1.63

　　系统安全性评估过程 system safety assessment process

　　证明符合适航要求及有关指南材料的活动，如 FAA AC/JAAAMJ 25. 1309。在这个过程中主要的活动包括功能危害度评估、初步系统安全性评估及系统安全性评估。这些活动的严格程度依赖于系统的危险程度、复杂度、新颖性和有关使用历史。

　　3.1.64

　　任务 task

　　从控制程序的角度来看，是工作的基本单元。

　　3.1.65

　　测试用例 test case

　　为特定目的开发的测试输入、执行条件及预期结果的集合， 例如为了执行特定的程序路径或验证对指定需求的符合性的测试用例。

　　3.1.66

　　测试 testing

　　执行系统或系统部件以验证它满足规定要求并检测错误的过程。

　　3.1.67

　　测试规程 test procedure

　　一套指定的测试用例的测试准备和测试执行、测试结果评价的详细说明。

　　3.1.68

　　工具鉴定 tool qualification

　　软件工具在特定的机载系统的环境下获得合格审定置信度所必需的过程。

　　3.1.69

　　可追溯性 traceability

　　项目之间关联关系的证据，如过程输出之间、输出与其产生过程之间、或需求与其实现之间关系的证据。

　　3.1.70

　　转换准则 transition criteria

　　在软件策划过程中定义的满足进入一个过程的最低条件。

　　3.1.71

　　确认 validation

　　确定需求是否正确和完整的过程。系统生存周期可在系统确认中使用软件需求及派生需求。

　　3.1.72

　　验证 verification

　　对需求实现的评估，以确定需求得到满足。

　　3.2 缩略语

　　下列缩略语适用于本文件。

　　BIT——机内自测试(built in test)

　　SQA——软件质量保证(software quality assurance)

　　SCI——软件配置索引(software configuration index)

　　SECI——软件生存周期环境配置索引(software enviroment configuration index)

　　4 与软件开发有关的系统方面

　　4.1 系统和软件生存周期过程之间的信息流

　　4.1.1 概述

　　系统生存周期过程和软件生存周期过程之间安全性方面的信息流见图 1。由于系统的安全性评估过程和系统设计过程是相互依赖的，所以本条所描述的信息流动是反复迭代的。

　　图 1 在系统和软件生存周期过程之间与系统安全性有关的信息流

　　4.1.2 从系统过程到软件过程的信息流

　　系统安全性评估过程要确定系统的失效状态并对之进行分类。在系统安全性评估过程中， 通过对系统设计的分析定义与安全性有关的要求，这些要求要详细规定对这些失效状态期望的免疫力及期望的系统响应。对软件和硬件规定的这些要求要排除或限制故障的影响，并可提供故障检测和故障容错能力。当在硬件设计过程和软件开发过程中做出各种决策后，系统安全性评估过程要分析最终的系统设计以验证它是否满足与安全性有关的要求。

　　与安全性有关的要求是输入到软件生存周期过程的系统需求的一部分。为了确保与安全性有关的需

　　求在整个软件生存周期中正确地实现，系统需求通常包括：

　　a) 系统描述和硬件定义;

　　b) 合格审定要求，包括适用的适航规章;

　　c) 分配给软件的系统需求，包括功能要求、性能要求和与安全性有关的要求;

　　d) 软件等级及确定其软件等级、失效状态及其类别、分配给软件的有关功能的资料;

　　e) 安全性策略和设计限制，包括设计方法，如划分、非相似性、冗余或安全性监控;

　　f) 当该系统是另一个系统的一个部件时，那个系统的、与安全性有关的要求和失效状态。

　　系统生存周期过程可能为软件生存周期过程规定一些需求，以帮助系统的验证活动。

　　4.1.3 从软件过程到系统过程的信息流

　　系统安全性评估过程利用软件生存周期过程提供的信息来确定软件设计和实现对系统安全性的影响。这些信息包括故障限制边界、软件需求、软件体系结构和在软件设计过程中通过使用工具或其他方法检测或消除的软件结构中的错误源。系统需求与软件设计数据之间的追踪性对系统安全性评估过程是很重要的。

　　对软件的修改可能会影响到系统的安全性，所以，必须标识这种修改并向系统安全性评估过程提供以便进行评估。

　　4.2 失效状态和软件等级

　　4.2.1 概述

　　系统失效的类别是通过失效状态对航空器及其乘客的危害度来确定的。软件错误可能引起导致失效状态的故障，因此，安全运行所需的软件的完整性水平与系统的失效状态有关。

　　4.2.2 失效状态状态类别

　　失效状态可分为：

　　a) 灾难性的：妨碍航空器继续安全飞行和着陆的失效状态。

　　b) 危险的：严重降低航空器的性能，或降低机组人员克服不利运行情况的能力的失效状态。这些不利运行状态所达到的程度将是：

　　1) 大大降低了安全裕量或功能能力;

　　2) 导致机组人员身体不适或处于较高工作负荷的状态， 以至于不能准确或完整地完成其任务;

　　3) 对乘客的不利影响，包括对部分乘客严重的或潜在的致命伤害。

　　c) 重大的：显著降低航空器的性能或降低机组人员扭转不利操纵状态能力的失效状态。这些不利操纵状态达到的程度是，如较大地降低了安全裕量或功能能力;较大地增加了机组人员的工作负荷或降低机组人员工作效率，或造成乘客不舒服或受伤。

　　d) 轻微的：轻微降低航空器安全性及机组人员在其能力范围内尚能很好应对的失效状态。次要的失效状态可能包括稍微减少安全裕量或功能能力;稍微增加机组人员的工作量，如更改飞行计划;或给乘客带来某些不方便。

　　e) 无影响的：不影响航空器的工作性能或不增加机组人员工作负荷的失效状态。

　　4.2.3 软件等级定义

　　软件等级是根据在系统安全性评估过程中确定的软件对潜在失效状态的影响来定义的。软件的等级是依据不同的失效状态类别，软件所应付出的、证明其符合合格审定要求的努力程度。软件等级的定义是：

　　a) A 级：软件的异常行为可能引起或导致系统功能失效进而引起航空器灾难性的失效状态。

　　b) B 级：软件的异常行为可能引起或导致系统功能失效进而引起航空器危险的失效状态。

　　c) C 级：软件的异常行为可能引起或导致系统功能失效进而引起航空器重要的失效状态。

　　d) D 级：软件的异常行为可能引起或导致系统功能失效进而引起航空器次要的失效状态。

　　e) E 级：软件的异常行为可能引起或导致系统功能失效，但不会影响航空器的工作性能或增加飞行员工作负荷。一旦软件由合格审定机构确定为 E 级，本标准不再提供适用的指南。

　　4.2.4 软件等级确定

　　系统安全性评估过程，首先在不考虑系统设计的情况下，确定特定系统中软件部件的软件等级，同时要说明其功能丢失或发生故障带来的影响。

　　如果软件部件的异常行为能引起多个失效状态，那么该部件所引起的最严重的失效状态的类别决定该软件部件的软件等级。在系统设计演进过程中， 不同的体系结构策略，如在 4.3 中描述的那些，可能会导致软件等级的更改。

　　一个系统功能可以分配到一个或多个已隔离的软件部件中。并行实现是一个系统功能分别由多个软件部件实现，这样只有多个部件出现异常才可能产生系统功能的失效状态。对并行实现， 至少有一个软件部件具有与该系统功能最严重的失效状态类别相应的软件等级。其他部件的软件等级用与该功能丧失相对应的失效状态类别来确定。这种实现的例子见 4.3.3 和 4.3.4。

　　串行实现是一个系统功能用多个软件部件来共同实现，这样任何部件出现异常都会产生失效状态。在这种实现中，任何软件部件应具有与系统功能的最严重的失效状态类别相对应的软件等级。

　　软件开发到某一等级并不意味着对该软件分配失效率。软件等级或基于软件等级的软件可靠度不能像硬件失效率那样在系统安全性评估过程中使用。

　　采用不同于本条的其他策略确定软件等级，则需要通过系统安全性评估过程证明其合理性。

　　4.3 系统结构考虑

　　4.3.1 概述

　　如果系统安全性评估过程确定系统结构已排除了软件的异常状态导致系统最严重失效状态的情形，则软件的等级要根据系统结构未能排除的、可能引起系统其他剩余的最严重失效状态的类别来确定。系统安全性评估过程对系统结构设计决策进行评价，以确定它们是否影响软件等级或软件的功能性。本条提供了几种结构方法，它们可限制错误影响或利于检测错误和对某些错误提供可接受的系统响应。这些系统结构技术不能认为是最佳或必需的解决方案。

　　4.3.2 分区化

　　分区化是一种在功能上独立的软件部件之间提供隔离的技术，以容纳和/或隔离故障，进而减少软件验证过程的工作量。如果通过分区隔离方式提供了保护， 那么每一个隔离部件的软件等级，可用与该部件相关的最严重的失效状态类别来确定。

　　当设计分区隔离保护时，应考虑系统的下列方面，以确定它们违犯这种保护的潜在可能性：

　　a) 硬件资源：处理器、存储设备、输入/输出设备、中断和定时器;

　　b) 控制耦合：对外部访问的脆弱性;

　　c) 数据耦合：共享或反复存取的数据，包括堆栈和处理器的寄存器;

　　d) 与该保护机制关联的硬件设备失效模式。

　　软件生存周期过程应表明软件部件分区隔离的设计考虑，包括隔离的部件之间允许的交联的程度和范围，这种保护是通过硬件实现的还是通过软件和硬件的组合来实现的。

　　如果分区隔离保护涉及到软件，那么该软件应被赋予与被隔离的软件部件的最高等级相对应的软件等级。

　　4.3.3 多版本非相似软件

　　多版本非相似软件是系统设计技术，它涉及到产生两个或更多的软件部件。这些部件以可在部件间避免某些共同错误源的方式提供同样的功能。多版本非相似软件也称为多版本软件、非相似软件、 N 版本程序设计或软件多样性。

　　在非相似性引入开发之前已完成的或已启动的软件生存周期过程可能保留了潜在的错误源。系统需求可能为执行多版本非相似软件规定一个硬件构型。

　　非相似的程度及其能提供的保护程度通常是不可度量的。就与这些非相似软件版本相应的安全性监控功能检测实际发生的错误或经历超越比较器门限(阈值)的瞬变来说，系统功能丢失的可能性(概率)将会增加。因此， 非相似软件版本常被用作第 8 章介绍的软件验证过程目标达到之后所提供的一种附加保护手段。如果可以证明， 所产生的潜在系统功能丢失的水平是在系统安全性评估过程确定的、可以接受的范围内，那么非相似软件的验证方法可以从验证单个版本软件所用的那些方法中简化。

　　多版本非相似软件的验证见 14.3.4。

　　4.3.4 安全性监控

　　安全性监控是通过直接检测可能引起失效状态的功能失效而避免特定失效状态的一种手段。监控功能可通过硬件、软件或硬/软件组合的方式实现。

　　通过使用监控技术，被监控功能的软件等级可以降低到与其相关的系统功能丧失的失效状态类别所对应的软件等级。为了允许这个等级的降低，应确定监控器三个重要的属性：

　　a) 软件等级：安全性监控软件应赋予被监控功能的最严重的失效状态类别相对应的软件等级;

　　b) 系统故障检测覆盖：监控器的系统故障检测覆盖评估应保证，监控器的设计和实现能够确保在所有必要的条件下要检测的故障均能检测得到;

　　c) 功能和监控器的独立性：监控器和防护措施不能因为引起危害的同一失效而不能工作。

　　4.4 系统对用户可修改软件、带选项软件和商用成品软件的考虑

　　用户修改的潜在影响由系统安全性评估过程确定，并在开发软件需求和软件验证过程的活动中予以考虑。在 7.3.4 中，进一步讨论用户可修改软件的设计。影响到不可修改的软件、它的保护或可修改软件的边界的更改应视为软件更改。在本标准中， 可修改部件是软件中允许用户修改的软件部件，不可修改部件是不允许用户修改的软件部件。

　　一些机载系统和设备可能包括可选的功能，这些功能通过软件编程选项进行选择，而不是通过目标机的连接器引脚来选择。带选项的软件功能用于在目标机中选择特定的配置。对无效码的规定见 7.5.4。

　　系统对用户可修改软件、带选项软件和商用成品软件的考虑应包括下列指南：

　　a) 用户可修改软件，如果系统需求中提供了用户修改(需求)，那么用户可在修改限制范围内修改软件，而无需经过合格审定机构的评审。

　　b) 系统需求应规定保护机制，防止用户的修改对系统安全性造成影响，无论它们是否被正确的实现。为用户修改提供保护的软件应与可修改部件中受保护的功能具有相同的软件等级。

　　c) 如果系统需求未规定用户修改的方法，除非能证明更改符合本标准，否则软件不得由用户更改。

　　d) 在用户修改时，用户要对用户可修改软件的所有方面负责，包括软件配置管理、软件质量保证和软件验证。

　　e) 带选项软件，当软件中包括预设的选项时，应提供措施确保在安装环境中目标机不可能选择到未经批准的配置。

　　f) 商用成品软件，包括在机载系统或设备中的商用成品软件应满足本标准的要求。

　　g) 如果在商用成品软件的软件生存周期数据中存在缺项，那么应补充数据，以满足本标准的要求。

　　4.5 系统设计对外场可加载软件的考虑

　　外场可加载机载软件是无需拆装系统或设备即可装人的软件或数据表。与软件数据加载功能相关的有关安全性的要求是系统需求的一部分。如果无意中使能软件数据加载功能会引起系统失效状态， 那么对于软件数据的加载功能，应在系统需求中规定其与安全性有关的要求。

　　与外场可加载软件有关的系统安全性考虑应包括：

　　a) 对不可靠的或只有部分软件被加载情况的检测;

　　b) 对加载不合适软件的影响的确定;

　　c) 硬件/软件兼容性;

　　d) 软件/软件兼容性;

　　e) 航空器/软件兼容性;

　　f) 外场加载功能的偶然使能;

　　g) 软件配置标识显示的丢失或不可靠。

　　对外场可加载软件应考虑：

　　a) 除非系统安全性评估过程已证明其合理性，否则用于部分或不可靠软件加载的检测机制应赋予的失效状态或软件等级，应与使用该软件加载的功能所赋予的最严重失效状态或软件等级相同;

　　b) 如果一个系统，在加载了不合适的软件或数据时，有一个缺省模式，那么对该系统的每个已隔离部件，应明确规定在此模式下运行的安全性相关要求，以处理潜在的失效状态;

　　c) 软件加载功能(包括支持系统和程序)，应包括检测不正确的软件和/或硬件和/或航空器组件的手段，并提供对该功能失效状态合适的保护;

　　d) 如果软件是机载显示装置的一部分，目的是为确保航空器符合一个已批准的合格审定配置，则该软件一般按照被加载软件的最高级别来开发，或由系统安全性评估过程证明该软件配置项自加载介质至安装过程的验证检查的完整性是恰当的。

　　4.6 系统需求对软件验证的考虑

　　应根据系统运行要求和系统安全性评估过程所产生的与安全性有关的要求来开发系统需求。系统需求对软件验证的考虑包括：

　　a) 机载软件的系统需求应为软件确定两个方面的特性：

　　1) 软件应完成系统需求中定义的指定功能。

　　2) 软件不应呈现系统安全性评估过程确定的特定异常状态。应为消除这些异常状态产生附加的系统需求。

　　b) 这些系统需求随后应开发成软件的高层需求，这些高层需求应在软件验证过程的活动中得到验证。

　　4.7 系统验证中的软件考虑

　　系统验证的指南在本文件中不作规定。但是， 软件生存周期过程是有助于系统验证过程的，并且与系统验证过程是有相互影响的。与系统功能有关的软件设计细节应提供给系统验证过程， 以帮助进行系统验证。

　　系统验证可以提供有意义的代码结构覆盖。系统验证测试的覆盖分析可用来帮助软件验证中各种不同测试活动实现覆盖目标。

　　5 软件生存周期

　　5.1 软件生存周期过程

　　软件生存周期过程包括：

　　a) 软件策划过程 即定义并协调一个项目的软件开发和支持过程活动的过程。

　　b) 软件开发过程 即生产软件产品的过程。这些过程是软件需求过程、软件设计过程、软件编码过程和软件/硬件集成过程。

　　c) 支持过程 即确保软件生存周期过程及其输出正确、受控和可信的过程。支持过程包括软件验证过程、软件配置管理过程、软件质量保证过程和合格审定联络过程。支持过程贯穿整个软件生存周期并与软件开发过程并发执行。

　　5.2 软件生存周期定义

　　通过为每一个过程选择活动、规定活动的顺序和分配活动的责任， 一个项目可以定义一个或多个软件生存周期。

　　对一个具体项目，应根据其特点确定这些过程的顺序。项目特点如系统功能性和复杂性、软件规模和复杂性、需求稳定性、以前开发结果的使用、开发策略和硬件可用性。软件开发过程的一般顺序是软件需求、软件设计、软件编码和软件/硬件集成。

　　图 2 表明了具有不同软件生存周期的单个软件产品的几个部件的软件开发过程的顺序。

　　注：为简单起见，未示出软件策划和支持过程。

　　图 2 使用四种不同开发顺序的软件项目

　　部件 W，通过开发软件需求，使用这些需求来确定软件设计，将设计转化为源代码，并且把软件部件集成到硬件中去，从而实现一系列系统需求。

　　部件 X，使用以前开发的软件，该软件已用在经批准的航空器或发动机型号中。

　　部件 Y，使用简单的、已隔离的功能，该功能可以直接根据软件需求进行编码。

　　部件 Z，使用原型策略。通常，开发原型的目的是为了更好地理解软件需求并减少开发和技术风险。原型法以初始需求为基础实现一个原型，这个原型在代表被开发系统的预定的使用环境中进行评估，评估结果被用来进一步细化需求。

　　软件生存周期过程可反复迭代，即进入和再进入。迭代的时机和程度取决于系统功能开发的增量规模、复杂性、需求开发、硬件可用性、对已完成过程的反馈和项目的其他特征。

　　所选软件生存周期的不同部分与增量集成过程和软件验证过程活动紧密联系在一起。

　　5.3 过程之间的转换准则

　　转换准则用来确定过程是否可以进入或再进入。每个软件生存周期过程执行基于输入产生输出的活

　　动。一个过程可对其他过程产生反馈并从其他过程接受反馈。反馈的定义包括接受反馈的过程如何识别、控制和处理反馈信息，例如问题报告机制。

　　转换准则的选取依赖于软件开发过程和支持过程的预定顺序，且可能会受到软件等级的影响。

　　注：转换准则可定义为：软件验证过程的评审已经完成，或输入是已标识的配置项，或对输入的追踪性分析工作已完成。

　　如果为过程确定的转换准则已得到满足，过程的每个输入在过程开始前不必都是完整的。

　　如果过程开始是基于部分输入开展活动，应对照检查过程的后续输入，以确定先前的软件开发和软件验证过程的输出仍然有效。

　　6 软件策划过程

　　6.1 概述

　　软件策划过程产生指导软件开发过程和支持过程的软件计划和标准。附表 A. 1 中列出了各级软件的软件策划过程的目标和输出。

　　6.2 软件策划过程目标

　　软件策划过程定义产生满足系统需求并提供与适航要求相一致的置信度水平的软件方法。软件策划过程的目标是：

　　a) 定义处理系统需求和软件等级的软件生存周期开发过程和支持过程的活动(见 6.3);

　　b) 确定软件的生存周期，包括过程之间的内部关系、它们的顺序、反馈机制和转换准则(见第 5章);

　　c) 选择软件生存周期环境，包括用于每个软件生存周期过程活动的方法和工具(见 6.5);

　　d) 如果必要，第 14 章规定的其他考虑应得到处理;

　　e) 定义与待开发软件的系统安全性目标一致的软件开发标准(见 6.6);

　　f) 编制符合 6.4 和第 13 章要求的软件计划;

　　g) 软件计划的开发和修订是协调一致的(见 6.4)。

　　6.3 软件策划过程活动

　　有效的策划是开发满足本标准要求的软件的决定因素。软件策划过程活动的指南包括：

　　a) 应在软件生存周期的确定点上按时制定软件计划，以便为执行软件开发过程和支持过程的人员提供及时地指导。符合性方法及策划参见 11.2 的要求。

　　b) 应规定或选择用于项目的软件开发标准。

　　c) 应选择在软件开发过程中能够预防错误的方法和工具。

　　d) 应协调软件开发和支持过程，以保证软件计划中策略的一致性。

　　e) 应规定随项目进展修订软件计划的方法。

　　f) 如在系统中使用多版本非相似软件，应选择满足系统安全性目标所必需的避免错误或进行必要检测的方法和工具。

　　g) 为了软件策划过程的完整性，软件计划和软件开发标准应通过评审并且更改受到控制。

　　h) 如果计划使用无效码，应规定如何定义、验证和处理无效码(选择的选项、飞行试验)， 以达到系统安全性目标。

　　i) 如果有用户可修改代码，在软件计划和标准中应详细说明满足 7.3.4 目标的过程、工具、环境和数据项。

　　如果计划和规程对具体的过程活动是可用的，那么这些过程可在软件策划过程完成之前启动。

　　6.4 软件计划

　　软件计划的目的是定义满足本标准目标的方法、规定将执行这些活动的机构。软件计划包括：

　　a) 软件合格审定计划(见 13.2)，为征得合格审定机构对建议的开发方法的同意而与其进行联络的主要手段，并且定义符合本标准的方法;

　　b) 软件开发计划(见 13.3)，定义软件生存周期和软件开发环境;

　　c) 软件验证计划(见 13.4)，定义满足软件验证过程目标的方法;

　　d) 软件配置管理计划(见 13.5)，定义满足软件配置管理过程目标的方法;

　　e) 软件质量保证计划(见 13.6)，定义满足软件质量保证过程目标的方法。

　　对软件计划的指南包括：

　　a) 软件计划应符合本标准。

　　b) 软件计划应定义软件生存周期过程之间的转换准则，内容包括：

　　1) 过程的输入，包括从其他过程的反馈;

　　2) 需要对这些输入进行的任何支持过程的活动;

　　3) 需要的工具、方法、计划和规程。

　　c) 软件计划应规定，软件在用于已批准的航空器或发动机之前实施软件更改的规程。这种更改可能是其他过程反馈的结果，并且可能引起软件计划的变更。

　　6.5 软件生存周期环境策划

　　6.5.1 概述

　　软件生存周期环境策划的目的是定义用于开发、验证、控制和产生软件生存周期数据(见第 13 章)和软件产品过程中所使用的方法、工具、规程、程序设计语言和硬件。所选择的软件环境如何有利于机载软件开发的例子如去强制标准执行、进行错误检测、实施错误预防和容错方法等。软件生存周期环境是导致失效状态的一个潜在错误源，它的组成可能会受系统安全性评估过程所确定的与安全性有关的要求的影响，如非相似、冗余部件的使用。

　　错误预防方法的目的是在软件开发过程中避免引入可能引起失效状态的错误。基本原则是， 选择需求开发和设计方法、工具和程序设计语言， 以限制引入错误机会;选择验证方法，确保已经引入的错误能被检测出来。容错方法的目的是在软件设计或源代码中包含安全性特征， 确保软件对输入数据错误进行正确响应，并防止输出和控制错误。对错误预防和容错方法的要求由系统需求和系统安全性评估过程决定。

　　上述考虑可能影响到：

　　a) 用于软件需求过程和软件设计过程的方法和表示法;

　　b) 用于软件编码过程的程序设计语言和方法;

　　c) 软件开发环境工具;

　　d) 软件验证和软件配置管理工具;

　　e) 工具鉴定要求(见 14.2)。

　　6.5.2 软件开发环境

　　软件开发环境是产生高质量软件的重要因素，可能对机载软件生产的方方面面产生不利影响。例如编译程序因译码出错而引入软件错误、链接程序未能暴露存储器分配错误等。软件开发环境方法和工具的选择指南包括：

　　a) 在软件策划过程中，选择的软件开发环境应尽可能降低最终机载软件的潜在风险。

　　b) 应选择使用已鉴定的工具或工具组合与软件开发环境部件，达到必要的置信度，以使一个部件引入的错误能被另一个部件检测到。多个部件能协调一致地使用，就是一个可接受的环境。

　　c) 应定义软件验证过程的活动或软件开发标准(包括对软件级别的考虑)，使潜在的与软件开发环境有关的错误减至最少。

　　d) 如果要寻求对工具组合使用的合格审定置信度，那么工具操作的顺序应在有关计划中规定。

　　e) 如果在项目中使用软件开发工具可选的功能选项，那么应检查选项的影响并在有关计划中详细说明。

　　注：这点对工具能直接生成部分软件产品的情形至关重要。编译器就符合这种情形， 可能是这种情形下需要考虑的最重要的工具。

　　6.5.3 语言和编译程序

　　只有在成功地完成了软件产品的验证后，对该产品来说编译器才被认为是可接受的。为证明编译器的有效性，软件验证过程活动应考虑编程语言和编译器的特性。软件策划过程在选择编程语言和对验证进行策划时，应考虑这些特性。对语言和编译程序的指南包括：

　　a) 一些编译器有专门用来优化目标代码性能的特征。如果测试用例给出了与软件级别要求一致的覆盖，那么不需要验证优化的正确性，否则，这些优化特征对结构覆盖分析的影响应按照 8.5.5.3指南进行确定。

　　b) 为了实现某些特征，某些语言的编译器可能会产生一些不能直接追踪到源代码的目标代码，例如初始化、内置错误检测或异常处理(见 8.5.5.3 b))。软件策划过程应提供检测这些目标代码、保证验证覆盖的方法，并在相应计划中定义这些方法。

　　c) 在软件生存周期中，如果引入了一个新的编译程序、连接程序或加载程序版本， 或者更改了编译器的选项，那么先前的测试和覆盖分析可能不再有效。验证计划应提供重新验证的方法， 以符合第 8 章和 14.1.4 的要求。

　　6.5.4 软件测试环境

　　软件测试环境策划的目的是定义用于测试集成过程输出的方法、工具、规程和硬件。测试可使用目标机、目标机模拟器或宿主机仿真器来完成。指南包括：

　　a) 模拟器或仿真器可能需要按 14.2 规定进行鉴定。

　　b) 应考虑目标机和模拟器或仿真器之间的差异，以及这些差异对检测错误和验证功能的能力的影响。应提供那些需要由其他软件验证过程活动提供验证的错误的检测， 并在软件验证计划中规定。

　　6.6 软件开发标准

　　软件开发标准是为软件开发过程定义规则和限制。软件开发标准包括软件需求标准、软件设计标准和软件编码标准。软件验证过程使用这些标准作为评估过程实际输出与预期输出符合性的基础。对软件开发标准的指南包括：

　　a) 软件开发标准应符合第 13 章的要求;

　　b) 软件开发标准应确保给定软件产品或相关配套产品的软件部件得以一致的设计和实现;

　　c) 软件开发标准不允许采用其输出无法验证或与安全性需求不相符的结构或方法。

　　注：在编制标准的过程中，可以借鉴以往的经验，可以包括能控制复杂度的开发、设计、编码方法的规则和限制，也可以考虑能提升健壮性的防御性程序设计方法(defensive programming)。

　　6.7 软件策划过程的评审和保证

　　进行软件策划过程的评审和保证的目的是，确保软件计划和软件开发标准符合本标准要求，并提供执行这些计划和标准的方法。指南包括：

　　a) 所选择的方法应能使本标准的目标得以满足;

　　b) 软件生存周期过程能够协调一致地应用;

　　c) 每个过程应提供证据证明其输出能追踪到过程活动和输入，并表明活动的独立性程度、所使用的环境和方法;

　　d) 软件策划过程的输出是一致的，且符合第 13 章要求。

　　7 软件开发过程

　　7.1 概述

　　软件开发过程应按软件策划过程产生的软件计划来执行。附表 A.2 列出了按软件等级划分的软件开发过程的目标和输出。软件开发过程包括：

　　a) 软件需求过程;

　　b) 软件设计过程;

　　c) 软件编码过程;

　　d) 软件/硬件集成过程。

　　软件开发过程产生一个或多个层次的软件需求。高层需求直接通过对系统需求和系统体系结构的分析产生。通常情况下， 这些高层需求在软件设计过程中进一步开发产生一个或多个较低层次的需求。如果源代码直接基于高层需求产生，则高层需求也被视为低层需求。对低层需求的指南也同样适用于这些高层需求。

　　软件体系结构的开发包括对软件结构所做的决策。在软件设计过程中， 定义软件体系结构，并开发低层需求。低层需求是那些不用进一步的信息即可直接开发源代码的软件需求。

　　每个软件开发过程都可能产生派生需求。派生需求是那些不能直接追踪到较高层需求的软件需求。

　　注：一条派生需求可以是需要为选定的目标机开发中断处理软件。高层需求可包括派生需求， 低层需求也可包括派生需求。派生需求对与安全性有关的要求的影响由系统安全性评估过程确定。

　　7.2 软件需求过程

　　7.2.1 概述

　　软件需求过程使用系统生存周期过程的输出来开发软件高层需求。这些高层需求包括功能、性能、接口和与安全性有关的需求。

　　7.2.2 软件需求过程目标

　　软件需求过程的目标是：

　　a) 开发出软件的高层需求;

　　b) 向系统安全性评估过程反馈派生的高层需求。

　　7.2.3 软件需求过程活动

　　软件需求过程的输入，包括来自系统生存周期过程的系统需求、硬件接口和系统结构， 包括来自软件策划过程的软件开发计划和软件需求标准。当满足计划规定的转换准则时， 这些输入就被用来开发软件的高层需求。

　　该过程的主要输出是软件需求数据(见 13. 10)。

　　当软件需求过程的目标和与之有关的支持过程的目标都得到满足时，即完成了软件需求过程。软件需求过程的指南包括：

　　a) 应分析分配给软件的系统功能和接口需求，以便澄清不明确、不一致和未定义的条件;

　　b) 所发现的软件需求过程输入的不充分或不正确之处应报告并反馈到输入的源过程进行澄清或

　　纠正;

　　c) 分配给软件的每一条系统需求应在高层需求得到细化;

　　d) 应定义软件的高层需求，处理分配给软件的、用于排除系统危险的系统需求;

　　e) 高层需求应符合软件需求标准，并且是可验证的和一致的;

　　f) 适用时，高层需求应当用具有容差的定量术语来陈述;

　　g) 除了规定的和合理的设计限制外，高层需求不应描述设计或验证的细节;

　　h) 分配给软件的每条系统需求应能追踪到一条或多条软件高层需求;

　　i) 除派生的需求外，每条高层需求应能追踪到一条或多条系统需求;

　　j) 派生的高层需求应提供给系统安全性评估过程。

　　7.3 软件设计过程

　　7.3.1 概述

　　软件的高层需求在软件设计过程中通过一次或多次迭代，逐步细化并开发成软件的体系结构和用于实现软件代码的低层需求。

　　7.3.2 软件设计过程目标

　　软件设计过程的目标是：

　　a) 基于高层需求已开发出软件体系结构和低层需求;

　　b) 派生的低层需求已提供给系统安全性评估过程。

　　7.3.3 软件设计过程活动

　　软件设计过程的输入包括软件需求数据、软件开发计划和软件设计标准。当满足计划规定的转换准则时，高层需求就被软件设计过程用来开发软件体系结构和低层需求，可能会产生一个或多个较低层次的需求。

　　软件设计过程的主要输出是包括软件体系结构和低层需求的软件设计文档(见 13. 11)。

　　当软件设计过程目标和相关支持过程目标满足时，即完成了软件设计过程。

　　对软件设计过程的指南包括：

　　a) 在软件设计过程中所开发的低层需求和软件体系结构应符合软件设计标准，并且是可追踪、可验证和一致的。

　　b) 派生需求已定义并经过分析，以确保派生需求不妨碍较高层次的需求。

　　c) 软件设计过程活动可能将某些失效模式引入软件，或排除了某些失效模式。在软件设计中采用分区化或其他体系架构方法，可能会改变对某些软件部件的软件等级分配。在这些情况下， 应定义附加数据作为派生需求，并把这些数据提供给系统安全性评估过程。

　　d) 当与安全性有关的要求有规定时，应监控控制流和数据流，如看门狗定时器、合理性检查和交叉通道比较。

　　e) 对失效状态的响应与安全性有关的要求一致。

　　f) 在软件设计过程中发现的不充分或不正确的输入，应反馈给系统生存周期过程、软件需求过程或软件策划过程，予以澄清或纠正。

　　7.3.4 用户可修改软件的设计

　　对设计用户可修改软件的指南包括：

　　a) 应保护不可修改部件的安全运行，以防止可修改部件的干扰。这种保护通过硬件、软件、用于修改的工具，或三者的组合来实现。

　　b) 应能表明由申请人提供的方法是更改可修改部件的唯一方法。

　　7.4 软件编码过程

　　7.4.1 概述

　　在软件编码过程中，由软件体系结构和低层需求实现源代码。

　　7.4.2 软件编码过程目标

　　软件编码过程的目标是，保证开发出的源代码是可追踪的、可验证的、 一致的，且正确地实现了低层需求。

　　7.4.3 软件编码过程活动

　　软件编码过程的输入是软件开发计划、软件编码标准以及来自软件设计过程的低层需求和软件体系结构。当满足计划规定的转换准则时， 软件编码过程可以进入或再进入。由这个过程产生的源代码基于软件体系结构和低层需求。

　　软件编码过程的主要输出是源代码(13. 12)和目标代码。

　　当满足软件编码过程目标和相关支持过程目标时，即完成了软件编码过程。

　　软件编码过程的指南包括：

　　a) 源代码应实现了低层需求并符合软件体系结构;

　　b) 源代码应符合软件编码标准;

　　c) 源代码应可追踪到软件设计文档;

　　d) 在软件编码过程中发现的不充分或不正确的输入，应反馈给软件需求过程、软件设计过程或软件策划过程，予以澄清或纠正。

　　7.5 集成过程

　　7.5.1 概述

　　在集成过程中，使用目标计算机、来自软件编码过程的源代码和目标代码，以及连接和加载数据，开发出集成的机载系统或设备。

　　7.5.2 集成过程目标

　　集成过程的目标是把可执行目标代码加载到目标硬件中完成软/硬件集成。

　　7.5.3 集成过程活动

　　集成过程包括软件集成和硬件/软件集成两部分。

　　当满足计划规定的转换准则时，可以进入或再进入集成过程。集成过程的输入是来自软件设计过程的软件体系结构和来自软件编码过程的源代码和目标码。

　　集成过程的输出，是可执行目标码(见 13. 13)及连接和加载数据。当集成过程目标和有关支持过程目标满足时，即完成了集成过程。

　　集成过程的指南包括：

　　a) 可执行目标代码应产生自源代码和连接加载数据;

　　b) 为了软件/硬件集成的目的，将软件加载到目标计算机;

　　c) 在集成过程中发现的不充分或不正确的输入，应反馈给软件需求过程、软件设计过程、软件编码过程或软件策划过程，予以澄清或纠正。

　　7.5.4 无效码和软件补丁的考虑

　　机载系统或设备在设计时可能包括几种配置(或称为构型)，但在每一个应用中并不打算使用所有的

　　配置。这种情况可能会产生不被执行的无效码或不被使用的数据，但它们不同于死码(见 3.22 和 8.5.5.4)。对无效码和补丁的指南包括：

　　a) 应提供证据，证明无效码在其非预期环境中已被禁止。无效码在系统异常状态下的非预期激活与有效码的非预期激活一样，也应禁止。

　　b) 处理无效码的方法应符合软件计划。

　　c) 对提交供已批准的航空器或发动机使用的软件，不得使用软件补丁，用来实现需求或体系结构的更改，或实现软件验证过程所发现问题的更改。补丁仅可用于受限的具体实例中， 例如，解决软件开发环境中的已知缺陷(如一个已知的编译器问题)。

　　d) 当使用补丁时，应具备下列条件：

　　1) 已确认软件配置管理过程能有效地追踪补丁;

　　2) 已进行回归分析提供证据，证实补丁与按正常方法开发的软件一样满足软件的所有目标;

　　3) 已在软件总结中说明使用补丁的理由。

　　7.6 可追踪性

　　可追踪性的指南包括：

　　a) 应提供系统需求和软件需求之间的可追踪性，以便能够验证系统需求实现的完整性，并提供派生需求的可见性;

　　b) 应提供低层需求和高层需求之间的可追踪性，以便提供在软件设计过程中产生的派生需求和体系结构设计决策的可见性，并能验证高层需求实现的完整性;

　　c) 应提供源代码和低层需求之间的可追踪性，以便能够验证不存在没有文档依据的源代码，并能验证低层需求实现的完整性。

　　8 软件验证过程

　　8.1 概述

　　软件验证是对软件开发过程和软件验证过程两者结果的技术评估。软件验证过程按在软件策划过程和软件验证计划中的定义执行。

　　注：验证不仅仅是测试。测试通常不能表明没有错误。由于软件验证过程的目标是典型的评审、分析和测试的组合，

　　故本章采用术语“验证”而不用“测试 ”。

　　附录 A 中表 A.3～表 A.7 中按软件等级列出了软件验证过程的目标和输出。

　　对较低的软件等级，对下列条款可不作要求：

　　a) 低层需求的验证;

　　b) 软件体系结构的验证;

　　c) 测试覆盖的程度;

　　d) 验证规程的控制;

　　e) 软件验证过程活动的独立性;

　　f) 重叠的软件验证过程活动，即有多个验证活动，每个验证活动都可能检测到相同类别的错误;

　　g) 健壮性测试;

　　h) 对错误预防或检测有间接影响的验证活动，如对软件开发标准的符合性。

　　8.2 软件验证过程目标

　　软件验证过程是检测和报告在软件开发过程中引入的错误。消除这些错误是软件开发过程的活动。软件验证过程的目标是验证：

　　a) 分配给软件的系统需求已开发成满足这些系统需求的软件高层需求。

　　b) 软件高层需求已开发成满足这些高层需求的软件体系结构和低层需求。如果在高层需求和低层需求之间有一个或多个层次的软件需求，那么每一个较低层次的需求应满足其相邻的较高层次的需求。如果直接从高层需求产生代码，本条不再适用。

　　c) 软件体系结构和低层需求已开发成满足低层需求和软件体系结构的源代码。

　　d) 可执行目标代码满足软件需求。

　　e) 满足上述目标的方法对所定的软件等级在技术上是正确的和完整的。

　　8.3 软件验证过程活动

　　软件验证过程的目标通过综合使用评审、分析、测试用例和规程开发与执行等方法来实现。评审和分析为软件需求、软件结构和源代码的准确性、完整性和可验证性提供评估。测试用例的开发可为需求的内部一致性和完整性提供进一步的评估。测试规程的执行可提供符合需求的证明。

　　软件验证过程的输入，包括系统需求、软件需求和体系结构、可追踪性数据、源代码、可执行目标码和软件验证计划。

　　软件验证过程的输出记录在软件验证用例和规程(13. 14)，以及软件验证结果(13. 15)中。

　　对需求可验证的要求，一旦要在软件中实现，就会对软件开发过程增加额外的要求或限制。

　　验证过程提供软件需求的实现和这些需求的验证之间的可追踪性：

　　a) 通过基于需求的覆盖分析提供软件需求和测试用例之间的可追踪性;

　　b) 通过结构覆盖分析提供代码结构和测试用例之间的可追踪性。

　　对软件验证活动的指南包括：

　　a) 高层需求以及追踪到这些高层需求的追踪性数据应经过验证;

　　b) 追踪性分析以及基于需求和结构的覆盖分析结果应表明每条软件需求能追踪到实现它的代码，也能追踪到验证它的评审、分析或测试用例;

　　c) 如果所测试的代码与装机软件不同，那么这些差异应详细说明，并说明理由;

　　d) 如果在现实的测试环境中不可能通过运行软件验证某些特定的软件需求，则应提供其他验证手段，并将它们满足软件验证过程目标的理由在软件验证计划或软件验证结果中进行说明;

　　e) 在软件验证过程中发现的缺陷和错误，应报告给软件开发过程，以便澄清和纠正。

　　8.4 软件评审和分析

　　8.4.1 概述

　　评审和分析适