ICS 49.090 V 35
HB/Z 400-2013
民用飞机航空电子软件管理指南
Guidance for civil avionics software management
2013-04-25 发布 2013-09-01 实施
中华人民共和国工业和信息化部发布
前言
本指导性技术文件按照 GB/T 1.1-2009 给定的规则起草。
本指导性技术文件由中国航空综合技术研究所归口。
本指导性技术文件起草单位：中国航空无线电电子研究所、中国航空综合技术研究所、中国航空工业集团公司第六三一研究所。
本指导性技术文件主要起草人：缪万胜、盛春玲、黄永葵、阮玉平、马晋、李胜江、陆荣国、张起睿、朱占奎、叶宏、朱晓飞。
民用飞机航空电子软件管理指南
1 范围
本指导性技术文件规定了民用航空电子软件的成本控制、软件管理、软件开发、用户可更改软件、认证后的软件更改等方面的基本要求。
本指导性技术文件适用于民用航空电子软件产品。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GB/T 11457-2006 信息技术软件工程术语
GJB 2786-1996 武器系统软件开发
HB/Z 295-1996 机载系统和设备合格审定中的软件考虑
3 术语和定义、缩略语
3.1 术语和定义
GB/T 11457-2006 界定的以及下列术语和定义适用于本文件。
3.1.1
验收测试 acceptance test
确定系统是否符合其验收准则，使用户能确定是否接收该系统的正式测试。
3.1.2
构建 build
软件产品的一个工作版本，其中包含成品将拥有的能力的一个规定的子集。
3.1.3
更改控制 change control
在正式确定配置项的配置标识之后对配置项的配置，或在基线确定后对基线进行系统评估、协调、批准或不批准以及批准更改的实施。
3.1.4
配置管理 configuration management
确定和定义系统内配置项的过程，在整个系统生存周期内对这些项目的发布和更改进行控制，记录并报告项目配置的状态以及更改要求，并验证配置项目的完整性与正确性。
3.1.5
仿真器 emulator
执行仿真的硬件、软件或固件。
3.1.6
容错 fault tolerance
在有限的硬件或软件故障发生时，系统仍可持续正确运行的内在能力。
3.1.7
软件分区 software partition
为了隔离一个或多个软件属性，防止特殊的相互作用和交叉/耦合干扰而对软件进行分离的过程。 3.1.8
用户可更改软件 user-modifiable software
在设计、实现和认证中已保证特定部分可由用户更改而不需重新进行需求验证的计算机程序。特定部分更改后的安全和适航性在最初认证时就已确定。
3.1.9
软件问题报告 software problem report
软件未能满足规定需求或未能执行预定功能的报告。
3.1.10
验证 verification
评定软件开发活动的产品与作为输入提供给该活动的产品及标准是否正确和一致的过程。
3.1.11
确认 validation
对软件进行评价，以确定其是否符合规定要求的过程。
3.1.12
过程转换准则 process transition criteria
由软件计划过程定义的满足进入一个过程的最低条件。
3.2 缩略语
下列缩略语适用于本文件。
BIT——built in test，机内测试;
CASE——computer aided software engineering，计算机辅助软件工程;
CDR——critical design review，关键设计评审;
COTS——commercial off-the-shelf，商用货架产品;
CSC——computer software component，计算机软件部件;
CSCI——computer software configuration item，计算机软件配置项;
CSU——computer software unit，计算机软件单元;
FCA——functional configuration audit，功能配置审核;
FQR——formal qualification review，正式合格性评审;
GSE——ground support equipment，地面支持设备;
HWCI——hardware configuration item，硬件配置项;
ID——identifier，标识符;
LRU——line replaceable unit，航线可更换单元;
LRM——line replaceable module，航线可更换模块;
MTBF——mean time between failure，平均无故障间隔时间;
MTBR——mean time between removal，平均修复时间;
PCA——physical configuration audit，物理配置审核;
PDR——preliminary design review，概要设计评审;
SCM——software configuration management，软件配置管理;
SDR——system design review，系统设计评审;
SDRL——supplier data requirements list，供应方数据需求清单;
SQA——software quality assurance，软件质量保证;
SRR——system requirements review，系统需求评审;
SSR——software specification review，软件规格评审;
STC——supplement type certificate，补充型号认证;
TC——type certificate，型号认证;
TRR——test readiness review，测试就绪评审;
TSO——technical standard order，技术标准指令;
URR——user requirements review，用户需求评审。
4 成本控制
4.1 概述
航空电子软件的成本可分为下列三大类：
a) 用户的成本;
b) 设备供应方的开发及维护成本;
c) 飞机供应方的系统集成成本。
4.2 用户的成本
4.2.1 概述
用户应推荐软件开发和维护的明确要求，因为软件成本最终会由用户承担。
建议用户建立严格的 SQA 标准，并应由供应方实施，因为对于最终发布的软件产品的任何软件更改，无论大小，用户都要承担同样的费用。
4.2.2 MTBF/MTBR 产生的成本
用户应根据预期的 MTBF/MTBR 制定计划。计划包括(但不局限于)下列内容：
a) 测试需求;
b) 余量需求;
c) 维修时间。
4.2.3 交付后的更改
飞机投入使用后的更改经常需要增加备件的数量。同时维护人员和飞行机组人员会因为这些更改而需要额外的培训。因此，交付后任何软件更改都需要由用户的工程部门批准，并记录此更改。
4.2.4 涉及硬件的更改
当软件更改涉及到硬件的改变，会增加额外的成本。如改变飞机布线要求飞机处于非服务状态， 这将损失收入，并增加飞机库存时间。因此，应充分考虑并严格控制软件的更改。
4.2.5 用户可选项的更改
当系统操作中有用户可选项时，选择和改变这些选项的方法应既简单又安全。可使用在个人电脑或类似的小型机上运行的配置工具，这样就无需重新编译或重新生成飞行软件。也可使用传统的 GSE。
4.2.6 容错设计
软件应具有容错设计，以避免设备拆卸引起的故障。BIT 软件应慎重设计和编码。BIT 软件的集成度应大于或等于设备的集成度。设计能够对可预期和不可预期的异常进行容错处理的系统软件和 BIT软件，将尽可能地减少设备拆卸。
4.2.7 交付后支持
应建立一个有效的供应方-用户支持网络，以便新软件的发布、更改和升级。这将为用户提供咨询和直接评论的机制。
4.2.8 可配置软件的成本
在用户可配置系统中，用户应考虑下列重复和非重复成本，这些成本影响到设备的成本。
a) 测试/验证;
b) 配置管理;
c) 质量保证;
d) 培训;
e) 系统开发;
f) 系统管理;
g) 工具。
4.2.9 飞行模拟器相关的成本
飞行模拟器开发可能增加航空电子软件开发方面的额外限制和需求，如额外的文档、协调、技术支持、特殊的软件更改和硬件更改。这些额外的限制和需求应包括在初始工程计划中。如果未能合理安排，有可能延迟模拟器开发，也可能降低培训的有效性，这样就会增加用户的成本。
4.3 设备供应方的开发成本和维护成本
4.3.1 项目管理
4.3.1.1 开发进度表
应制定可行的、可管理的进度表， 以有效控制开发成本。用户和供应方都应严格控制进度， 否则可能超出预算，或导致交付产品质量差。
4.3.1.2 冻结需求
在设计过程初期应冻结需求，否则可能影响项目的进度和最终工程方案的有效性。
4.3.1.3 用户/供应方的关系
用户和供应方之间的关系对项目的成功至关重要。用户对于项目执行上的需求应在一开始就明确，供应方也应询问用户所有需要考虑的信息。
双方应相互理解、支持，共同控制项目风险，并使用通用的或兼容的工具，便于信息沟通。
4.3.2 产品相关因素
4.3.2.1 复杂性和规模
随着任务的复杂性和规模增加，软件开发的成本显著增加。主要是因为：
a) 为了维护系统完整性而增加的设计需求和更改控制的需求;
b) 由于更加繁重的设计和验证活动而增加的工作量;
c) 由于要管理大量的工程人员和大型软件系统的配置产生额外的成本。
4.3.2.2 目标硬件设计
应选择成熟且使用周期长的目标处理器。这样能够避免正在开发的处理器相关软件开发过程中的潜在风险和成本。它还将降低硬件改变对软件产生的影响， 以及在软硬件集成过程中，降低故障隔离的难度。
4.3.2.3 内存及吞吐量限制
产品应具有合适的吞吐量和内存大小。一旦处理时间和内存不足，就需要进行代码优化或改变设计，从而增加了开发软件的成本。
4.3.2.4 已有软件的重用
在新软件产品开发中，对已有软件包的使用将降低软件开发成本。为了实现对软件重用的最佳效费比，应建立必要的基础设施，如可重用的软件库、设计、验证和文档标准等等。
4.3.2.5 使用商用货架产品
COTS 软件是从第三方供应商采购的软件。COTS 软件的主要优点在于：
a) 降低开发成本;
b) 减少开发时间;
c) 提高产品完整性。
应根据技术和经济效益，确定是否使用 COTS 软件，并分析相关的认证成本。如果已对包含 COTS软件的系统提前认证过，那么认证将适用于使用相同的 COTS 软件完成相同功能的新系统。在这种情况下，新应用程序的关键级别就不会高于先前的实现。在某些情况下，不可避免地要使用 COTS 软件。因此，准确地估计验证和评估第三方软件的额外成本是非常重要的。
4.3.2.6 软件关键级别
软件开发成本随着软件关键级别的提高而增加。
按 HB/Z 295-1996 中 4.2.1 失效状态类别定义下列五个软件关键级别：
a) A 级：灾难性的;
b) B 级：危险的/严重的;
c) C 级：较重的;
d) D 级：较轻的;
e) E 级：无影响。
4.3.3 开发工具的使用
4.3.3.1 需求分析和设计
使用支持需求分析和设计的工具，可节约成本，并减少错误。
4.3.3.2 验证
软件验证可分为两部分：测试和保证。
测试应证明系统是符合设计的且完成了其预期功能。
测试可能非常详细，而且在不同层次上执行：
a) 部件/单元;
b) 软件集成;
c) 软硬件集成;
d) 系统集成。
保证应证明开发过程的实施方式与声明的要求保持一致，保证不仅仅针对过程的工作产品，还针对过程的活动。该活动通常生成大量证明文档。
使用辅助执行测试和保证任务的工具，可有效地降低成本。在维护阶段需要根据修改项或需求变更重新验证。
4.3.3.3 文档工具
使用辅助文档生成和维护的工具，可有效地节约成本，并提高文档的格式统一性和内容一致性。
4.3.3.4 软件配置管理
SCM 的目的包括以下几个方面：
a) 保证配置项可用性、一致性和有效性;
b) 以可控的方式实施更改;
c) 提供用于配置状态描述和审核的信息。
SCM 工具应能支持同一工程的系列产品和不同工程的软件包重用。
4.3.3.5 宿主机
大部分的航空电子软件开发在宿主机上进行，应合理确定宿主机的数量。宿主机过多或不足会对项目进度和开发人员工作效率产生不利的影响。
4.3.3.6 软件测试和集成工具
应提供软件的测试和集成以及软件问题跟踪的工具，通常包括软件调试工具、仿真器、以及其他相关的接口硬件和支持软件。为了使软件能够在开发或调试环境中运行， 也可能需要对目标硬件作一些特定的修改。
除了确定工具之外，对这些工具进行维护和使用也会产生人力成本。
4.3.3.7 工具采用
应考虑采用新工具的成本，包括以下几个方面：
a) 对新员工和老员工的培训;
b) 在初始阶段的咨询服务;
c) 新工具引起的额外软件支持和硬件支持。
新工具引起的与现有规程的差异，可能导致更大的成本。然而，若不在新的方法和工具上进行投资，由于竞争力的持续下降，损失会更大。
4.3.3.8 工具鉴定
工具鉴定由合适的验证管理机构执行。工具鉴定应按 HB/Z 295-1996 第 14 章要求执行。 4.3.4 人力因素
4.3.4.1 概述
推荐使用熟悉航空电子、具有实时计算机和软件设计经验的人员。应对新接触航空工业的软件工程师进行航空领域知识、软件生存周期、故障的影响以及标准的培训。与技术院所(如大学、研究组织)的联系也是培训的一个重要途径。
4.3.4.2 人员的能力
应拥有一支熟悉相关设计、工具和技术的专家队伍， 该专家队伍应具有应用程序、编程语言、目标处理器以及支持工具方面的经验。
4.3.4.3 多点开发
推荐多点同时进行软件开发，这比单点开发更好。
4.3.4.4 人员的连续性
在开发过程中，应保持人员的连续性，这对于一个高效费比的项目非常重要。人员的变化会增加工程的成本。
4.3.4.5 使用转包工程师
对短期的或特定的人员需求，建议雇用转包工程师，这是一种提高效费比的方法。
但是，长期雇用转包劳动力将增加成本。
4.4 飞机供应方的集成成本
4.4.1 总则
飞机供应方的活动成本与系统设计阶段或者系统集成阶段相关。这里的“系统”是指专用于特定飞机功能的设备(如飞行控制系统)。
4.4.2 功能规格说明的确立
系统设计的第一阶段应基于功能的安全目标来确立系统体系结构，第二阶段应详细说明系统的每个组件，并用文档描述每个组件的功能规格说明。
应使用工具来管理整个系统的文档，以对配置管理、自动或人工检查、规格说明确认或仿真提供保证。系统规格说明的质量和精确度是软件开发的基础。
整个开发周期成本的降低取决于在设计阶段所付出的努力。在本阶段完成的仿真和验证减少了软件开发的工作量，尤其减少了系统集成测试活动。
4.4.3 供应方监督
4.4.3.1 概述
为了满足进度和质量要求，飞机供应方应建立工程管理组织。专门负责供应方关系的小组应保证飞机供应方的功能规格说明和质量需求成功实现。
当系统/设备发生更改时，上述活动都应继续，从而保证集成性和适航性保持同一水平。
4.4.3.2 工程管理
这项任务应考虑整个项目的不同限制，如：
a) 用于实验室测试、地面测试或飞行测试的设备的可用性;
b) 系统交互的管理;
c) 整个认证限制以及供应方关系的考虑。
工程管理包括技术会议、计划会议、交流方法和工具。
4.4.3.3 软件质量保证
SQA 对于确保高质量、可验证的产品是必需的。应在开发过程的开始阶段就在合同中写明质量条款，并在开发过程中通过审查、审核或评审等方式对软件工作产品进行检查。这些活动的报告将由认证机构来审核。
本过程应贯穿整个产品的生存周期。
4.4.4 系统集成成本
4.4.4.1 概述
系统集成过程是一个重复仿真整个飞机环境的过程。
应具有管理报告机制和相应的工具，以跟踪系统集成问题及其处理过程。
4.4.4.2 地面测试
在地面测试中，系统集成测试应由飞机供应方在设备级来执行。其目标是验证在系统设计阶段所做的功能规格说明。该测试过程可能是一个局部测试，该过程中设备的功能是仿真的。
测试一般是“黑盒”测试。测试设备可能用于设备调试， 从而检测出在技术规格说明或实现上的潜在错误。对于实现上的错误，应将相关信息提交给供应方以寻求解决方法。
应在集成的更高层次使用飞机模型、仿真器或者飞机继续进行地面测试。系统集成工具允许使用实际的飞机组件，包括电源发生器、机械设备等等。仿真器可为特定系统(如飞行控制或自动驾驶)定制。
除了集成测试，还可能执行一些在真实飞机上无法执行的测试，以便在特定故障情况下观察飞机的行为。尽管仿真器作为一种符合规则的工具使用，认证过程中仍然需要进行一些飞行测试。
这些测试的成功将保证设备/系统的飞行测试。
4.4.4.3 飞行测试
飞机供应方可能使用一些用于开发的飞机来执行飞行测试。这些测试要求使用电子通信、错误跟踪和记录的特定设备。尽管该行为结束了飞机开发过程，获取适航证仍然需要其他飞行。
应在最少的时间内来执行所需的修改，以降低飞行测试的成本。
建议通过在系统需求和设计阶段中增加活动，如全面检查、原型仿真， 这可降低整个系统集成过程的成本。
4.4.5 认证过程
认证的一个通用原则是安全保证及建立在规则上的过程。每个申请者应能够证明与验证机构的一致性。HB/Z 295-1996 提供了软件开发和系统验证的指导。
认证过程应包括以下内容：
a) 与认证机构相关的会议和评审;
b) 用于描述和论证的文档;
c) 对测试方法达成一致;
d) 特定故障条件仿真器上的特定飞行;
e) 在开发用飞机上的特定飞行。
每实现一个更改，都要重新考虑认证限制。对一个修改的分析和证明的成本可能很高，而且与更改类型相关。
4.5 成本分布
与软件相关的成本分布由多个因素决定。软件设计、文档、编码、测试、验证、确认、认证、交付
和支持的成本，都随着系统复杂性的增加和关键级别的提高而增加。在多个产品间的成本分配， 受到软件关键级别、新软件的数量以及软件重用技巧使用的影响。使用可重用软件可减少很多成本， 但如果供应方计划重用软件，以满足一系列的新需求，则应检验 SDRL 中的各项是否适用于新用户。
5 软件管理
5.1 软件开发过程
5.1.1 概述
民用航空电子设备研制的系统生存周期通常分为七个阶段，见图 1。
图 1 系统生存周期
在系统开发阶段应定义、设计、实现或重用软件。
系统/软件开发过程如图 2 所示。
软件开发基本过程有自己的活动边界，通常软件生存周期模型由基本过程组成。软件生存周期模型参见附录 A。软件基本过程包括： 软件计划过程、软件需求过程、软件设计过程、编码过程、集成过程。
系统定义过程严格意义上不只包括软件过程，还包括硬件过程。本指导性技术文件主要关注系统定义过程中关于软件工作的内容，正是在系统定义过程将系统需求分配给软件，因此将其纳入基本过程进行描述。
综合性过程不同于软件基本过程，综合性过程通常贯穿整个软件生存周期，有时甚至超出软件生存周期。综合性过程包括：合格审定联络过程、SQA 过程、SCM 过程、软件验证过程。
图 2 系统/软件开发过程
5.1.2 基本过程
5.1.2.1 概述
软件开发是一个软件基本过程迭代的过程。迭代可以是两个相邻的过程， 也可以是三个或四个过程的迭代。迭代的数量及其效果受所选择的软件生存周期模型(参见附录 A)的影响。
5.1.2.2 系统定义过程
系统定义过程分为两个单独的活动：系统需求分析和系统设计。
系统需求分析应包括对系统规格的审查以消除缺陷(如二义性、遗漏和不兼容)。
系统设计应将系统需求分配给硬件、软件。该阶段将系统分为硬件、软件，也可能包括人工操作。同时应定义系统/软件接口和为系统集成与验证提供的输出。
系统安全需求应具有源代码的可追踪性和说明。
系统安全需求可通过两种途径(在设计中防止不安全因素，或通过验证发现漏洞)来满足。所有软件的安全需求都应以软件需求的形式形成文档。软件安全需求还应制定软件关键级别。
其他考虑包括：
a) 为了满足用户的理解需要，系统定义可能包括额外功能定义，这超出了必需需求的范围;
b) 在系统设计中，为了降低开发成本可能采取权衡的做法，使成本最小，并为将来升级提供可维护性;
c) 为了重用现有的硬件和软件，可更改系统需求/设计。
5.1.2.3 软件计划过程
在实际开发开始前，建议制定项目计划。计划应包括建立标准、选择编程语言、确定应编制的文档
以及获得管理和执行项目必需的标准、方法和工具。项目框架应在该阶段建立。
软件计划过程有三个主要活动：
a) 定义所遵循的软件生存周期模型(参见附录 A)。该信息应写入软件开发计划文档。
b) 资源分配，通过估计进度表中任务所需的必要资源来完成，涉及人员、设备和进度规划。
c) 定义过程转换准则。这些过程转换准则通常根据待开发软件的类型以及成品的成熟度确定。
软件计划阶段还应包括用户可更改软件和用户维护软件(可由用户维护的软件)的计划。
5.1.2.4 软件需求过程
5.1.2.4.1 输入
应根据以下系统输入来定义软件的需求：
a) 系统接口;
b) 操作描述;
c) 精度分析和故障预计;
d) 性能分析、时间和内存空间限制;
e) 方案的分析依据;
f) 软/硬件接口;
g) 系统组件(硬件和软件);
h) 分配给软件的系统需求;
i) 安全/危险分析;
j) 分析结果的局限性;
k) 分配给软件的操作需求;
l) 软件外部接口需求;
m) 分配给软件的系统需求分析;
n) 高层软件体系结构;
o) 接口设计(内部和外部);
p) 需求分析的方案;
q) 系统测试计划和软件验证计划;
r) 对用户需求的功能跟踪。
5.1.2.4.2 活动
该过程的活动应包括：
a) 确保软件需求能实现;
b) 分析每个需求及其对系统操作的影响;
c) 分析并确定软件组件之间所需的信息流和控制流;
d) 分析并确定已在以前软件项目中实现的、可能有利于当前项目的需求;
e) 确保软件需求对于启动设计过程而言是足够完整的。
5.1.2.5 软件设计过程
5.1.2.5.1 概述
软件设计的目标是开发出一致的、组织良好的、能满足需求的软件描述。该过程应首先从软件组件的功能和结构着手，然后再将重点放在软件组件中的数据结构和算法上。这是一个从高层软件体系结构到详细设计的持续过程。
有序的软件开发的一个重要因素是尽早建立设计原则，使软件可追踪、可测试、可维护、可理解。
其具体形式取决于成品的应用和复杂性。建议选择一种设计原则并将其形成文档，使软件设计过程成为重要的、统一的软件开发与维护过程。
5.1.2.5.2 输出
该过程的输出包括：
a) 对结构和分区的描述;
b) 数据流的描述或图表;
c) 程序控制流的描述或图表;
d) 软件模块之间以及软硬件之间的控制接口描述;
e) 算法描述;
f) 定时目标;
g) 内存布局和大小的目标;
h) 按优先次序列出的程序中断。
5.1.2.5.3 评审
该过程应包括对下列各项的评审：
a) 体系结构设计和详细设计;
b) 状态监控和报告;
c) 风险应急预案;
d) 文档标识的分配;
e) 对输出文档的控制;
f) 对软件设计标准一致性和过程一致性的保证。
5.1.2.6 软件编码过程
编码过程通过生成源代码和适当的注释来实现详细设计。代码应组合为汇编语言单元或高级语言单元。在汇编和编译过程中发现的语法错误应在该过程完成之前加以改正。
该过程的输出为带注释的源代码和可执行的目标文件。
该过程完整的活动还应包括：
a) 代码走查和评审;
b) 测试用例评审;
c) 对源文件和目标文件的标识;
d) 评审保证;
e) 所遵循标准和过程的保证;
f) 使用合适的工具(如里程碑表或平衡图)来完成跟踪和报告，并执行所有必要的风险应急预案。
5.1.2.7 集成过程
5.1.2.7.1 概述
该过程的输入为软件集成计划、软硬件集成计划及其相关的测试规程。输出应包括用户可用的集成测试报告。建议对测试报告进行评审，以保证其覆盖范围和正确性，推荐对问题报告活动进行监控。
5.1.2.7.2 软件集成
软件集成应首先计划如何将软件单元/部件按一定顺序组合成为整个系统。
软件集成过程应将编码过程产生的独立软件单元/部件组合起来建立成更大的部件，直到最终成为能完全实现软件需求的可执行程序。
该过程应通过完整的验证过程执行测试用例，从而覆盖基于需求和结构的覆盖条件。同时应执行更改控制活动。
5.1.2.7.3 软硬件集成
除了软件集成中提到的活动外，还应将软件加载到目标系统，以进行软硬件集成。该过程中可能会发现问题并报告、分析和解决问题。该过程中发现的问题可能导致先前过程的重新执行。但是， 该活动的结果应产生完全满足系统需求的系统。
有些验证活动只能在软硬件集成之后完成。其中有些涉及到时钟、中断、输入/输出以及系统测试。因此，更改控制活动应持续贯穿整个活动过程中。
5.1.3 综合性过程
5.1.3.1 合格审定联络过程
民用飞机及其系统的认证，目的在于证明并记录整个飞机适用于民用航空运输且是安全的。认证机构应对申请者的技术和资源进行认证，确定其认证计划是否可行。对于新飞机和改型的飞机， 计划应考虑所要求的、可接受的安全等级，并考虑如何证明认证之后的更改不会降低整体的安全。
认证的最终结果是批准飞机的功能和安全等级。目前大多数软件认证都是作为设备或子系统认证的一部分实施的，在飞机 TC 级、STC 级或 TSO 级执行。
合格审定联络过程应按 HB/Z 295-1996 第 11 章要求执行。
5.1.3.2 软件质量保证过程
SQA 过程应在项目的初始阶段启动。
首先应详细说明将要遵循的质量保证策略。还要确定是否需要质量度量程序。如果需要， 则要规定度量方法、数据采集方法和分析方法。该过程应提供反馈， 并报告项目质量目标，同时在报告中针对质量提出过程改进建议。
SQA 过程应按 HB/Z 295-1996 第 10 章要求执行。
5.1.3.3 软件配置管理过程
SCM 确保识别和跟踪软件实体，这些软件实体应包括模块、子功能程序、可运行程序和文档。该过程应管理这些实体的更改，并对其进行跟踪，以便随时都可查到软件产品的配置。应保存历史文件，以确定更改原因。
该过程的报告可包含：更改次数、发布版本的数量以及最新的配置项版本和修订标识符等信息。 SCM 过程应按 HB/Z 295-1996 第 9 章要求执行。
5.1.3.4 软件验证过程
软件验证过程对软件开发过程中的所有评审、审核、测试和评估制定计划并执行。该过程应由项目开发人员之外的人员执行。可用工具代替人工验证。每个过程的产品都应符合该过程的验证准则。
该过程的输出可由下列部分组成：
a) 软件验证计划;
b) 单元、功能、系统的测试计划;
c) 测试报告;
d) 被验证的可执行代码，这是该过程的主要输出。
软件验证应按 HB/Z 295-1996 第 8 章要求执行。
5.1.4 软件开发后期的相关活动
实际操作中可能遇到软件生存周期过程中没有考虑到的一些情况或事件，可根据需要定义另一个过程。
建议记录所有的问题，可在将来的产品更新中进行解决。产品更新时， 建议重新运用完整的生存周期。
5.2 软件生存周期模型改进
软件生存周期的各阶段都是为了保证为最终用户交付合格和安全的产品。
在系统定义阶段，涉及到系统功能和系统中提供灵活性、可更改性的其他方面， 可给生存周期增加一个系统体系结构设计阶段。在该阶段，应定义灵活性和可更改性的种类和限制。
还需要考虑生存周期内的过程和阶段，这些阶段并不都是必需的。在完成阶段目标的同时， 可考虑还有哪些不同的事情可做，可重新组合这些过程。如使用代码生成技术可合并详细设计阶段和编码及单元测试阶段。
5.3 用户和供应方的关系
建议用户和供应方应在系统生存周期的初始阶段建立紧密的工作关系并在整个生存周期内维持这样的关系，该关系的核心就是交流通信。
供应方应在整个系统生存周期内定期告知用户有关项目状态和开发的情况，应包括下列活动：
a) 软件开发计划;
b) 软件需求分析;
c) 软件开发和设计评审;
d) 提交阶段状态报告;
e) 建立技术合作会议;
f) 监控进度。
5.4 软件开发管理
5.4.1 概述
民用航空电子软件具有两个主要设计目标，即安全性和效费比。安全目标反映了对系统安全的需求。而效费比目标则反映了对整个软件生存周期内成本的控制需求。本节主要举几个方面的例子说明如何在控制成本的前提下提高安全性。
5.4.2 软件设计的权衡
软件开发计划过程应首先确定要采用的软件生存周期模型，然后确定将要提供的文档、将要采用的验证和确认级别、保证严格遵守计划的方法。
民用航空电子软件开发必须满足基于软件关键级别的基本要求。软件关键级别取决于在系统中遗留的软件错误的潜在危害。该需求提供了与适航认证机构讨论之后确定的文档、验证和确认的最低级别，以及保证。其详细规定见 HB/Z 295-1996 中的规定。
其他的考虑包括：
a) 如果软件可能在其生存周期内被更改或在类似的产品中重用，那么软件设计应标识更改范围并提供补充文档;
b) 对大多数情况下进行更改可能增加开发的成本，但能使错误减少。
5.4.3 复杂性和成本的关系
开发软件的成本随着复杂性的提高而明显增加。如在设计阶段需要考虑更多接口和选项， 在测试过程中，有更多条路径、更多个接口条件需要测试。推荐采用新的设计方法和工具以降低成本。
5.4.4 软件开发工具
选择合适的工具能降低成本，并成倍降低开发的工作量，便于发现一些潜在错误。但若选择不合适的工具，则会适得其反。
如果选择新工具，建议对软件工程师进行培训，以充分发挥该工具的作用。
5.4.5 软件人员
任何软件产品的成本和质量都应由设计、开发和验证产品的人员能力来决定。
在项目中提高生产率的建议包括：
a) 为工程师提供质量反馈信息。如定期更新错误检查单、对错误率进行跟踪。
b) 提供有关生产率的量化反馈。
c) 提供可行的时间表。
d) 提供培训机会，使工程师更新知识并能最有效地利用工具。
5.4.6 进度
5.4.6.1 进度规划
在设计和实现过程中不连贯的进度可能给整个项目的成功带来严重的负面影响。进度应是现实可行的，并应严格遵守。产品交付的延迟或提前都可能产生不可预料的结果，并可能阻碍整个项目的进程。
为了提供一个现实可行的进度规划，以下几点值得考虑：
a) 确保产品按时交付，即时保证可用的人员数量。在评估进度时， 人力资源和物质资源都要充分考虑。
b) 在更快的开发周期中增加额外劳动力常常使项目进度变缓。因为新加入的成员常常需要得到现有成员的培训。
c) 在计划没有评估效果之前，就提前于进度安排完成节点是不必要的。
d) 应用于软件开发的生存周期模型决定了活动形式基本是固定的。试图超越一个开发阶段并不利于实际生产，反而可能需要更多的时间。
5.4.6.2 对成本的影响
为了保证成本最小化，应考虑以下几点：
a) 延期交付将会打乱整体进度，并增加其他方面的成本。
b) 增加额外成员，将会导致成本的增加，且不一定能在短期内实现目标。
c) 如果开发周期的关键时间没有合适的人力资源，会对关键功能缺乏足够的考虑，可能出现错误并增加不必要的风险，从而产生额外的成本。在初期出现的错误将随着项目的进展而需要付出的代价也会增加。
d) 对开发人员产生过大压力的进度安排将会使开发人员降低开发文档的质量。这样就会产生错误。
5.4.7 小项目管理
5.4.7.1 概述
有一些项目相对简单，或只需要少数人在较短的时间内就可完成。一般的软件管理指南只是指出大项目的需求，小项目的特殊需求也需要考虑。简单系统应使用合适的开发方法和流程。
很难以代码的行数、函数的数量和类似的参数来量化一个简单系统。一个小型系统一般提供简单、目标明确的功能。对这些项目， 整个的开发代价通常少于三人年，其中包括需求、设计、实现、测试和文档的总时间。
小项目与大项目的差异，在于每天的项目活动、最终的文档包、对系统的测试、软件体系结构不同。但这并不是说不需要遵守良好的工程设计原则。大项目的很多设计原则也适合于小型或简单的项目。
如果用户试图将大项目控制方法用于小项目，或试图在大项目上使用小项目方法，都会浪费巨额的经费和时间。
5.4.7.2 体系结构方面的权衡
在大项目中，应充分考虑模块化、功能分区、逻辑设计。而在小项目中， 可不考虑或少考虑这些方面。
在大型系统中，重新测试可能花费六个月的时间，而在小型系统中，完整的重新测试可能只需两天。软件更改后，即使存在良好的分区，也不一定能显著地缩短重新测试的时间。因此， 在小型系统中对增加功能分区和系统其他特性之间的折衷就不如在复杂系统中有效。
与大型系统相比，小型系统中对内存的限制更多。这时应在内存方面进行折衷， 而不是写出易于理解或维护的代码。
5.4.7.3 评审与保证
评审、走查、记录保持、行动项跟踪和类似的活动是良好的软件项目控制的体现。这些活动可包括在用户的合同中。在大项目中， 这些活动可加速开发进程，而在小项目中，有些活动常常是多余的，甚至是有害的。因为这些会增加成本，却没有提高安全性、维护性以及生产率。
对于任何一个具有高危险功能的系统，都应分别进行设计评审和测试评审。
5.4.7.4 测试
测试是一项成本很高的活动。对于较小或较简单的项目， 有时候可使用相当完善的测试技术，但这对于较大的项目则很难执行。因此， 需要考虑到这些特殊的情况。对于小项目的测试， 针对所有输入的组合，测试其输出是可能的。这对于大型的系统可能并不现实。在大型系统中应通过样本测试用例、等价类划分等方法进行模块测试。
5.5 软件文档
应向用户提供必要的、有意义的文档。按照 HB/Z 295-1996 生成的文档应具有预见性，且是协调一致的。文档应描述开发计划、设计需求、设计的实现、所执行的集成与测试， 以及测试结果。这些文档应同时满足内部使用者与外部使用者的需求。
文档的适时产生对任何产品的成功开发都是尤其重要的。开发计划、需求以及设计文档将在整个生存周期内维护。在生存周期的后期， 这些文档的历史记录应保存生存周期内的信息，从项目的开始，贯穿整个开发过程，直到项目完成。
软件文档应提供完整的项目历史记录和跟踪能力，包括早期的策划、软件历史版本等。所有的文档在逻辑上应相互一致，且集中保存、随时可查。软件文档的生成与产品过程应保持一致。否则会造成成本增加。
以上这些过程应采用自动化工具，以降低成本。
文档管理的责任是保证文档和开发任务的一致性，并独立于供应方的组织结构或项目的生存周期。应在产品开发之前建立所要求文档的标准。这些标准应包括用于支持文档生成的配置控制工具。
内容正确、完整的文档是软件重用的基础。文档的内容应足以使开发人员和用户无需其他帮助就能找到其所需的信息。足够的文档内容对于软件维护活动也相当重要。
供应方应提供软件文档，这对产品的操作是重要的。
一些项目要求多级设计文档和维护文档。它们可有一层或两层系统和软件需求，多层设计描述、复杂的可追踪文档，以及多个测试文档等。
有些项目可能会要求将文档组合起来，从而节省时间和成本。如系统和软件需求的文档可组合在一起。概要设计和详细设计可组合在详细的设计文档中。软件集成与软硬件集成测试可组合在同一文档内。良好的文档能降低产品生存周期内的总成本。
软件文档管理应按 HB/Z 295-1996 第 13 章要求执行。
5.6 用户可更改软件的管理
5.6.1 概述
用户可更改软件管理由两部分组成：
a) 事先计划的更改;
b) 不可预见的且要求一定程度重新认证的更改。
用户可更改软件的开发应遵循与其他软件相同的管理方法。供应方应建立开发框架， 并提供更改方法。
使用用户可更改软件，用户有责任遵循供应方定义的更改过程。所有管理现有软件更改的参与者应理解管理用户可更改软件的目标。设备供应方应为用户提供必要的管理工具，从而执行这些更改。
5.6.2 管理目标
用户可更改软件的管理目标如下：
a) 确保系统更改过程的有效性;
b) 允许通过简单的更改过程，适应因系统差异而引起的外部系统更改;
c) 维护已更改的软件的系统性，从而保持关键级别;
d) 对用户进行培训，确保更改过程的可靠性。
5.6.3 工具可用性
用户能通过合适的工具简化供应方定义的软件更改过程。建议供应方给用户提供工具并在文档中清晰地描述工具。
建议供应方考虑以下几点：
a) 提供测试设备和调试工具以验证所有的更改都是正确的，包括在向飞机加载软件之前进行测试的方法;
b) 提供跟踪软件更改的工具和更改的历史记录，并追踪到最初的系统;
c) 提供功能测试工具来验证更改之后软件功能的有效性。
5.6.4 被更改软件的完整性
建议对用户可更改软件的应用制定计划，从而提供用户可更改软件的验证方法。在软件开发过程中，建议：
a) 对软件进行分区，保证用户可更改软件能被更改而无需重新认证。
b) 提供对不可更改软件完整性的验证方法(如校验和)。
c) 在更改过程中对可更改项表中所有项的限定进行验证。
d) 为通过 GSE 实施的软件更改设置密码。
e) 提供加载到飞机上的软件的自识别。通过输入程序来控制加载， 从而检查由编译器程序生成的匹配代码。
f) 为用户方工程师提供培训，使其获得在更改、验证、确认和文档方面的经验。
g) 为更改软件建立配置控制和文档系统。同时提供软件标识计划和软件介质的标签系统。
5.6.5 用户培训
建议对用户方工程师进行培训。通常， 用户规定的初始更改应与用户合作进行，并作为培训和支持的一部分。在该阶段，可示范如何使用软件生成和跟踪工具。
描述用户更改过程的完整文档应与软件一起提供。
供应方应提供：
a) 样本文档或文档模版，描述供应方是如何进行内部更改并完成文档的;
b) 完成文档的指南。
5.7 软件信息安全
5.7.1 概述
应使用软件信息安全技术保护基于软件的系统，以防止其受到来自内部和外部的威胁。需警惕计算机病毒、木马程序和其他软件入侵。更大的外部威胁来源于对计算机网络和分布式系统的依赖， 以及外界的软件代码和数据指令。一个信息安全的系统可用多个步骤来抗衡这些威胁和恶意行为。
航空电子软件及数据的易破坏性程度依赖于对工具和设备的物理访问限制、对系统过程和信息的电子访问控制、软件验证、人员筛选和培训。
对直接面向三大系统资源(软件、服务和数据)的外部威胁举例如下：
a) 软件——操作系统、应用程序代码和 COTS 包;
b) 服务——监控飞行功能、显示气象数据和过程监视数据;
c) 数据——密码、飞机状态和飞行计划。
如果对信息安全方法使用不当，这些资源可能丢失、失效或误用。
除自然灾害和环境因素外，可能引发资源的丢失的其他因素还包括雇员、外部人员和意外事件。
信息安全威胁可分为服务拒绝、数据或软件丢失、对数据或软件未授权的更改和对数据、软件或工具的未授权使用。该类威胁包括数据污染、代码模块的损坏和系统过载。
推荐的信息安全防护手段包括加密、信息安全测试与检查、访问控制以及用硬件而不是软件来实现编码。
应使用合适的软件检查与测试方法，以防止在开发、运行或维护过程中的未授权访问和恶意的软件更改。
建议重视外部威胁，如未授权的访问、物理介质的失效、由恶意外部源引起的数据完整性丧失， 以及由于计算机病毒导致的服务拒绝或降级。恶意的设计缺陷由计算机系统中可信任的部分来解决。外部威胁一般都是从系统可疑的部分(如输入介质、非法用户或未授权的软件更新)到系统可信的部分(如操作系统、控制访问的数据库)。
5.7.2 计算机的信息安全
5.7.2.1 概述
应从以下三个方面保护计算机的信息安全：
a) 采用有效的管理与组织措施;
b) 确保人员忠实和可靠;
c) 采用传统的物理防护机制和环境防护机制。
建议采取对硬件、软件、通信和网络的保护措施。
5.7.2.2 薄弱环节
在分布式计算机系统中的主要薄弱环节是处理器、内存设备、远程通信、网络工具、用户控制面板、用户和系统人员。应对这些环节采取信息安全防护措施。
5.7.2.3 可预防的损失
大多数信息安全损失一般是由粗心所致。本指导性技术文件主要针对预防由可疑用户或恶意的设计失误所导致的损失提出指导意见。
5.7.2.4 服务拒绝
服务拒绝是最大的单项威胁。服务拒绝通常是软件或硬件故障导致的结果，大多数由意外原因引起。如操作系统崩溃、程序循环、系统重启以及粗心导致的数据删除。
5.7.2.5 防护机制
首要的防护机制应基于系统的信息安全机制。系统的信息安全是在系统内部保护信息(数据和代码)，建议通过下列手段防止未授权的访问：
a) 确认授权用户;
b) 在受保护信息周围建立障碍;
c) 通过预先建立的访问规则控制访问方式。
5.7.3 信息安全策略
5.7.3.1 概述
计划、开发和管理计算机信息安全的关键步骤应与软件项目活动标准相一致。
应对计算机系统内易受损坏的范围进行评估，以便针对外部威胁采取相应措施。
5.7.3.2 威胁评估
下列项目应成为威胁评估的一部分：
a) 确定资源清单;
b) 确定威胁源;
c) 将威胁源与资源匹配;
d) 考虑可能的方法;
e) 构造威胁情景;
f) 执行效果分析;
g) 评价可靠性;
h) 评估威胁。
5.7.3.3 外部威胁
应对外部威胁作出评估，内容应包括：
a) 服务拒绝;
b) 数据丢失;
c) 软件丢失;
d) 未授权的数据更改;
e) 未授权的软件更改;
f) 未授权的数据使用;
g) 未授权的软件使用;
h) 未授权的软件解密;
i) 未授权的工具使用。
5.7.4 处理外部威胁
5.7.4.1 软件完整性保护
在保护计算机系统内的软件完整性方面，可采用下列方法：
a) 多重密码和密码确认。
b) 对文件的大小变化实施持续监控。大部分破坏形式是在文件的开始或结尾增加代码。
c) 通过使用校验和与加密进行完整性检查。
d) 内存保护。
代码和数据的信息安全都依赖于操作系统。对系统的随机访问路径(后门)可能导致系统失效。很多系统中断都是由于未预料的用户对操作系统的偶然访问造成的。
5.7.4.2 数据保护
信息安全的一个重要部分是保证数据完整性。达到该目标的方法包括对授权用户的访问限制、在使用输入数据之前进行确认、在数据计算过程中执行错误检查。
应在所有的范围内执行数据的信息安全流程。计算机系统的大多数弱点都可归因于没有实施流程或出于对工作人员的方便性考虑，经常对数据的信息安全流程进行更改。如未严格执行软件更改控制流程。
5.7.4.3 其他保护
建议关注能增强信息安全的系统特征。网络管理员应能确定异常或可疑情况。建议不间断地对软件信息安全进行验证测试，以验证信息安全的检查过程没有受到干预。访问控制能通过分层密码和密码加密的方法来完成。
5.7.4.4 病毒防护机制
常用的防护机制如下：
a) 给信息安全系统发送更改消息;
b) 与第二份备件比较;
c) 选择部分比较;
d) 文件长度比较;
e) 检查最后一次正式更改的日期和时间;
f) 检查校验和;
g) 加密。
在设计和实现过程中，针对木马程序和后门的信息安全防护可通过第三方验证获得。
5.7.5 对软件信息安全的建议
5.7.5.1 未授权的访问
建议通过软件测试验证密码保护的代码和流程。用于密码处理的初始代码应独立完成(如密码数据库的编码和数据库查询操作的编码分别由不同的人完成)。该访问控制代码作为可信软件的一部分，应完整地测试和验证。可通过周期性重复这些测试来实现信息安全防护。
5.7.5.2 输入介质防护
应对系统和数据完整性加以保护。建议：
a) 检查所有的输入数据，应确认所有的输入数据在使用前有效;
b) 对系统过载执行自动测试;
c) 加密的校验和与介质标签也能提供防护。
5.7.5.3 运行时的软件信息安全验证
运行时对软件信息安全的验证可通过以下方法来完成：
a) 对代码和数据完整性的运行时测试。包括与备份文件比较、文件长度比较以及校验和比较。
b) 关键的软件模块必须加密。如果绕过运行时解密模块，则代码不可运行。
5.7.5.4 恢复措施
可通过恢复措施来防止服务拒绝。通常启动备份和恢复处理过程来处理紧急情况。
建议以合适的时间间隔，测试系统和工作人员的能力，以便仅使用备用资源来恢复预设服务的最低级别，并在运行期间维护信息安全。所有这些测试应包括恢复措施启用时的恢复测试、过载之后的负荷卸载和服务重启的测试。
5.7.5.5 信息安全管理
5.7.5.5.1 概述
建议采用基于计算机信息安全的三条软件项目管理原则，即多人监控原则、有限使用原则和任务分解原则。
5.7.5.5.2 多人监控原则
建议两个或更多的专业人员监控涉密的活动，并登记姓名作为证明。
5.7.5.5.3 有限使用原则
不应使任何人在涉及信息安全的位置上停留过长的时间，防止其认为该位置是其独占的，或该任务完全是可预测的。
5.7.5.5.4 任务分解原则
不应使任何人参与到超过其任务范围的涉密活动中。至少， 对涉及信息安全的软件的设计、实现和更改以及任何其他涉及信息安全的功能都应由不同的个人或不同的小组来执行。
5.7.5.6 检测与监督
试图对信息安全的侵入可能在系统日志或监控器探头下产生可疑的迹象。应从这些源收集证据， 以支持事后的调查，并可通过痕迹检查的方法来确定责任。在系统范围内的首要防护机制是威胁监控、趋势分析、事件调查。
5.7.6 容错与信息安全
5.7.6.1 概述
对于由软件或用户的未授权行为所引发的问题，应使用类似于容错系统的方法来处理系统故障。主要的防护就是在容错软件中增加故障检测和恢复预防措施。
软件容错和计算机信息安全的目标是一致的，两者都关注如下事项：
a) 开发可靠的软件、硬件和计算机系统;
b) 处理设计缺陷;
c) 使用技术和策略进行故障容错。
设计缺陷通常是发生在软件或硬件中的、偏离需求规格设计的人为错误(如编码或判断错误)。
对恶意的设计缺陷的容错策略，与无意的设计缺陷的容错策略相类似。故障容错与故障避免不同，故障避免是通过使用非失效组件、正式验证过的软件、对环境的完全控制以及类似的方法， 来防止故障的发生，从而保证系统的可靠。
恶意的设计缺陷不一定会导致系统失效。简单、不易发现的错误可能引发临时、少见或不可重现的故障。
5.7.6.2 容错技术
可用于提高信息安全的软件容错技术包括：
a) 内置断言测试，可用于检测异常或未预料的行为。
b) 健康监控子系统可通过故障隔离或从故障中恢复来处理局部异常情况。
c) 网络管理软件可对任何网络节点到预先设定的资源集合的访问进行限制。
d) 严重的系统入侵使主网络不可运行时，可访问备份网络。
e) 监视器和控制操作台可用于信息安全问题的显示或事件警告。控制操作台还可处理校正干预。应把容错技术和策略应用于软件完整性保护。容错技术是确保软件信息安全的诸多动态技术之一。
容错技术是对故障避免和故障排除的补充，构成了第二层防护。一些在测试阶段未检测到的或在系统运行后引入的设计缺陷，可被限制并防止其导致系统故障或服务拒绝。
6 软件开发
6.1 软件开发环境
为了能让用户或第三方完全维护软件，建议在开发初始阶段使用完整的软件开发环境或一个等价的开发环境。
每个供应方都应为其产品选择最好的环境。建议使用最新的技术， 目前的环境可能随着技术更新而淘汰。
航空电子设备供应方通常使用唯一的、专用的软件开发工具集。典型的工具集包括：
a) 系统分析工具;
b) 软件设计工具;
c) 软件编码工具;
d) 软件验证工具;
e) 软硬件集成测试工具;
f) 文档工具;
g) 编译器/汇编器;
h) 连接器/加载器;
i) 软件检查工具;
j) SCM 工具。
软件开发的趋势是，将这些基本的开发工具功能以多种方式结合起来，提供一个综合的软件开发环境。CASE 工具建立了这种综合环境，将一个软件阶段活动的输出作为下一阶段的输入。这是非常有效的，并避免了由于两次输入同一信息到软件开发系统中可能导致的错误。CASE 工具同样能让个人工作于大型系统，并共享通用的设计数据库，从而防止项目人员使用过时的信息而导致错误。
在软件开发过程中，这些工具可用于软件生成和验证。还可用于 TSO 文档生成或航空电子系统认证。SCM 工具应能用来维护这些文档。这些工具的大部分可被航空电子设备供应方用来证明先前配置的可追踪性。这样就可生成必要的文档。除了处理器的仿真器/调试器系统，还可使用一些特殊设备对测试系统的接口进行仿真。这些设备通常模拟飞机的动态输入， 并产生输出。因此， 只需少数设备就足够为供应方软件的认证和验证需求提供服务。
这些工具中的大部分在宿主机上执行，而不是在目标机上执行。经常使用宿主机可提高软件开发的效率，并允许软件开发与目标计算机开发并行进行。宿主机可能是大型机、小型机或个人计算机。建议根据最佳效费比的开发工具选择宿主机。
6.2 软件设计考虑
6.2.1 一般考虑
6.2.1.1 使用高级语言
推荐使用高级语言实现软件设计，从而增加可移植性和可读性。
6.2.1.2 模块化
应将每个软件功能设计为一个或多个相关的模块。建议有最小规模的数据和控制， 并与系统内其他功能或模块连接。与硬件直接连接的输入和输出应作为参数传送或在单一模块内执行。模块只能有单一的入口和单一的出口。
模块内部使用的数据应声明为局部数据。与系统内其他模块交换的数据应声明为全局数据。数据应通过名称直接引用，而不是使用内存偏移指针。数据的特点应写入文档。
6.2.1.3 设计的一致性
建议建立软件设计的标准和规程，从而提升组织内部设计过程的一致性。
通常应包括下列标准和规程：
a) 程序设计语言标准;
b) 命名约定;
c) 控制和数据流约定;
d) 编码限制和头文件格式。
6.2.1.4 软件关键级别的设计
根据软件组件对飞机飞行安全性的影响，本文档定义了软件关键级别如 4.3.2.6 定义。尽管HB/Z 295-1996 只是标准，所有的机载软件应根据该标准在严格的软件管理和质量保证下进行开发。
6.2.1.5 吞吐量
建议充分利用可重用软件。可重用软件通常比专用软件需要更多的处理时间， 但软件重用在软件开发、文档和测试方面所节约的成本远高于使用高速处理器所节约的成本。
6.2.1.6 内存大小
与专用软件相比，可重用软件在使用内存方面的效率较低。这可能是由下列原因导致的：
a) 额外的操作代码;
b) 不必要的标准接口的初始化;
c) 在内存中保存额外的参数。
在大多数应用中，额外内存的持续增加带来的成本，要远低于新软件开发和测试的成本。不过， 建议在硬件设计周期的初始阶段分配足够的内存，以解决可重用软件使用内存效率低的问题。因为硬件重新设计的成本可能会超过软件重新设计的成本。
6.2.1.7 文档
建议在设计过程开始之前确定设计文档的标准。文档应使熟悉初始设计的人员在无需额外信息的条件下，能读懂需求、实现和接口。文档还应设计为模块的形式， 这样就能作为独立包的一部分应用于将来的项目中。
文档编制应遵循 HB/Z 295-1996 中的规定。
6.2.1.8 验证的考虑
软件测试能发现软件的缺陷，并验证软件的功能。测试程度应与软件预计的关键级别水平保持一致。
测试文档应包括在文档包中。
