1、空工HB/Z 295-96 几4AE A吐口1996一09一13发布1997一01-01实中国航空工业总公司批准主题内容与适用范围引用标准术语4 与软件开发有关的系统情况4. 1 系统和软件生存周期过程之间的信息流4.2 失效状态和软件等级4.3 系统结构考虑- - . . . . . . -. . . . . . . . . . . (5 ) 4.4 系统对用户可修改软件、可选择项软件和商用成品软件的考虑. (6) 4.5 系统设计对外场可加载软件的考虑-. . . . . . . (7) 4.6 4.7 系统验证中的软件考虑5 软件生存周期5.1 软件生存周期过程5.2 软件生存周期定义5
2、.3 过程之间的转换准则6 软件计划过程6.1 软件计划过程目标6.2 软件计划过程活动6.3 6.4 6.5 6.6 7 7. 1 7.2 7.3 7.4 7.5 8 8.1 8.2 8.3 8.4 9 目次-E气J，句3( 1 ) (1) ( 1 ) (3) (3) (3) 系统需求对软件验证的考虑. . . . . . . . . . . . . . . . . . . . . . . . (8) 软件计划. . . . . . . . . 软件生存周期环境计划. 软件开发标准. . . . 软件计划过程的评审和保证. . . 软件开发过程. . . . . . . . 软件需求过程.
3、. . . 软件设计过程. 软件编码过程u软件/硬件综合过程可植踪性软件验证过程. 软件验证过程目标软件验证过程活动软件评审和分析. 软件测试过程-软件配置管理过程. ) QOQOOOGOQJ07070，。taqhq-7飞d句JA吨F3瓦U瓦UAU瓦U寸OY句3/飞/飞/飞，飞/飞/飞/飞/飞EtAtit且且ESE-EEt且titAtAt1-且?(1 9. 1 软件配置管理过程目标. . . . . . . 9.2 软件配置管理过程活动-. . . . . . . . . . 9.3 资料控制类. . . . . . . . . . . . . . . . 10 软件质量保证过程10.1 软件
4、质量保证过程目标. 10.2 软件质量保证过程活动. . . . . . . . . . . 10.3 软件符合性评审. . . . . . 11 合格审定联络过程. . . . . . . . . . . . . . 11.1 符合性方法和计划. 11. 2 符合性证明E11. 3 提交给合格审定机构的最少软件生存周期资料-11. 4 与型号设计有关的软件生存周期资料12 航空器和发动机合格审定. . . . . . . . 12. 1 合格审定基础. . 12.2 软件的合格审定. . . . . . . . 12.3 符合性确定13 软件生存周期资料. 13.1 软件合格审定计划-13.
5、2 软件开发计划13.3 软件验证计划. 13.4 软件配置管理计划13.5 软件质量保证计划. . . . . . . 13.6 软件需求标准. 13.7 软件设计标准. 13.8 软件编码标准13.9 软件需求文档. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.10 软件设计文档. 13.11 源代码. 13.12 可执行目标代码13.13 软件验证用例和规程. 13.14 软件验证结果13.15 软件生存周期环境配置索引13.16 软件配置索引. . . . . . . . 13.1
6、7 问题报告. 13.18 软件配置管理记录. . . . . . 13.19 软件质量保证记录13.20 软件实施概要. . . . . . . 2 ) 刀刃约刀纽约mmmm刻到mmmmmm到Mnnn刀MUMUM觅觅充充充Ymymtmzm好刀刃( 14 其它考虑. . . . . . 14.1 以前开发软件的使用. . . . . . . . 14.2 工具鉴定14.3 替代方法. 附录A(37) (37) (39) (41) (46) 3 中华人民共和空工业标准中几1 主题内容与适用范围统和设备合格审定中的软件考虑本标准规定了机载系统和设备中软件的开发准则。HB/Z 295-96 本标准适
7、用于航空器和发动机上所用机载系统和设备中软件的合格审定c2 引用标准GBf 11457 软件工程术语3 术语除以下给出的术语外，其它术语见GB/T11457 c 3. 1 更改按制a在配置项的配置标识正式确定之后对配置项或在基线确定后对基线的记录、评估、批准或不批准和协调更改的过程b在正式确定配置项的配置标识之后对配置工贞的配置或在基线确定后对基线进行系统评估、协调、批准或不批准以及批准更改的实施。3.2 商用成品(TS)软件由货主在公开的产品目录清单上出售的商业应用软件。:rrs软件不定制或改进。披具体应用开发的合同订购的软件不是COTS软件c3.3 配置状态纪实记录并报告有效管理配置必要的
8、信息，包括批准的配置标识清单、配置更改的状态和批准更改的实施情况。3.4 控制精合一个软件部件影响另一个软件部件执行的方式或程度。3.5 鼓据藕合软件部件对不仅仅依赖于该软件部件的控制之下的数据。3.6 无效码设计的可执行目标代码(或数据)是:a不打算执行的代码或不打算使用的数据，如以前开发软件部件的-部分;中国航空工业总公司1996-09-13发布1997-01-01实施HB/Z 295-96 b.仅在目标机环境的某一配置中执行的代码或使用的数据，例如可通过硬件引脚选择或软件可编程的选项使能的代码c3.7 死码在目标机环境的运行配置中不能执行的可执行目标代码或不能使用的数据。它不能追踪到一个
9、系统或软件需求c嵌入的标识符例外c3.8 判别覆盖范围程序中的每一个人口和出口点至少执行一次，且程序中的每一判别至少在所有可能的输出上发生一次。3.9 语旬覆盖范围程序中的每一个语句至少执行次c3. 10 覆盖范围分析确定的软件验证过程活动满足其目标程度的过程c3. 1 1 等效级程序输入区域的划分，以使这个级的典型值的测试等效于这个级的其它值的测试。3. 12 形式法与建立、开发和推导系统行为特性有关的数学模型的描述性表示和分析方法。3. 13 硬件A软件综合把软件组合到目标计算机中的过程。3. 14 软件需求软件应完成什么的描述。软件需求包括高级需求和低级需求。3. 15 高级需求根据系统
10、需求、与安全性有关的要求反系统设计结构分析而开发的软件需求。3 16 低级需求来自高级需求、派生需求及无需进一步信息就能直接实现源代码的设计限制的软件需求c3 17 派生需求软件开发过程产生的附加需求，它不可以直接追踪到高级需求。3. 18 独立性确保完成目标评估的责任分工ca对软件验证过程活动，验证活动应由被验证的项目的开发者之外的人完成。也可使用工具来验证。b对软件质量保证过程，独立性也包括确保纠正措施的权力。3. 19 多版本非相似软件分别开发两套或多套程序，以满足同样的功能要求c对一个版本的错误可通过多重输出的比较来检奇。3.20 软件划分为了隔离一个或多个软件属性，防止特殊的相互作用
11、和交叉销合干扰而对软件进行分离的过程c2 HB/Z 295-96 3.21 系统安全性评估对系统进行深入的、系统的、泛的评估以表明与安全性有关的需求均已满足c3.22 系统安全性评估过程证明符合适航要求及有关指南材料的活动。在这个过程中主要的活动包括功能危害度评估、最初系统安全性评估及系统安全性评估c3.23 转换准则由软件计划过程定义的满足进入J个过程的最低条件4 与软件开发有关的系统情况4. 1 系统和软件生存周期过程之间的信息流系统生存周期过程和软件生存周期过程之间的安全性方面的信息流见图1。由于系统的安全性评估过程和系统设计过程是相互关联的，所以本条所描述的信息流是重叠的。4. 1.
12、1 从系统过程到软件过程的信息流系统安全性评估过程要确定系统的失效状态并对之进行分类。在系统安全怕评估过程中，系统设计分析要定义避免这些失效状态的与安全性有关的要求及系统对这些失效状态的响应。对软件和硬件规定的这些要求要清除或限制故障的影响，并可提供故障检测和故障容错。当在硬件设计过程和软件开发过程中做这些决策时，系统安全性评估过程要分析最终的系统设计以验证它是否满足与安全性有关的要求。与安全性有关的要求是作为软件生存周期过程的输入的系统需求的-部分。为了确保在整个软件生存周期中合理地实现与安全性有关的要求，典型的系统需求应包括:a系统描述和硬件定义;b合格审定要求，包括适用的适航规章;c分配
13、给软件的系统需求，包括功能要求、性能要求和l与安全性布关的要求;d软件等级及确定其软件等级的资料、失效状态及其类别、分配给软件的有关功能;e安全性策略和设计限制，包括设计方法，如划分、非相似性、冗余或安全性监控;f当该系统是另个系统的部分时，那个系统的与安全性有关的要求和失效状态。系统生存周期过程可以规定对软件生存周期过程的要求，这样有助于系统的验证活动。4. 1.2 从软件过程到系统过程的信息流系统安全性评估过程可利用软件生存周期过程提供的信息来确定软件设计和实施对系统安全性的影响。这些信息包括故障限制范围、软件需求、软件体系结构和在软件设计过程中通过使用工具或其它方法检测或消除的软件结构中
14、的错误源。对软件的修改可能会影响到系统的安全性，所以必须明确系统安全性评估过程，以便进行评估。4.2 失效状态和软件等级系统失效的类别是通过失效状态对航空器及其乘客的危害度来确定的。软件错误J能引起导致失效状态的故障，因此，安全运行所需的软件的完整性水平关系到系统的失效状态。3 适航性要求系统运行要求HBIZ 295-96 系统生存周期过程系统安全性评估过程分配给软件的系统需求软件等级设计限制硬件定义软件生存周期过程故障限制范圄标明的/的错误源软件需求和体系结构图l在系统和软件生存周期过程之间与系统安全性有关的信息流4. 2. 1 失放状态类别失效状态时分为:a灾难性的阻止航空器继续安全飞行和
15、着陆的失效状态。b危险的/严重的降低航空器的性能或机组人员克服不利操纵状态的能力的失效状态。这些不利操纵状态达到的程度是:大大降低了安全裕量或功能能力。身体疲劳或高负荷使飞行机组人员不能准确或完整地完成他们的任务。对乘客的不利影响，包括对少数乘客严重的或潜在的致命伤害。c较重的可能降低航空器的性能或机组人员克服不利操纵状态的能力的失效状态。这些不利操纵状态达到的程度是较大地降低安全裕量或功能能力;较大地增加了机组人员的工作量或削弱机组人员工作效率的状态，或造成乘客不舒服，可能包括伤害。d较轻的不会严重降低航空器安全性及有关机组人员的活动在他们的能力内能很好完成其活动的失效状态。较轻的失效状态可
16、能包括稍微减少安全裕量或功能能力;稍微增加机组人员的工作量，如更改航线飞行计划或给乘客带来某些不方便等。e无影响不影响航空器的工作性能或不增加机组人员工作量的失效状态。4.2.2 软件等级定义4 HBIZ 295-96 软件等级是根据在系统安全性评估过程中确定的软件对潜在失效状态的影响来定义的:a. A级可能引起或导致系统功能失效进而号|起航空器灾难性失效状态的异常状态的软件。这种异常状态可通过系统安全性评估过程来表明:b. B级可能引起或导致系统功能失效进而引起航空器危险的/严重的失效状态的异常状态的软件。这种异常状态可通过系统安全性评估过程来表明;c. C级可能引起或导致系统功能失放进而引
17、起航空器较重失效状态的异常状态的软件。这种异常状态可通过系统安全性评估过程来表明;d. D级可能引起或导致系统功能失效进而引起航空器较轻失效状态的异常状态的软件。这种异常状态口I通过系统安全性评估过程来表明:e. E级可能引起或导致系统功能失效的但它不会影响航空器的工作性能或驾驶员工作量的异常状态的软件。这种异常状态时通过系统安全性评估过程来表明。年且软件山合格审定机构定为E级，本标准就不再提供进一步的指南。4.2.3 软件等级确定系统安全性评估过程首先要确定与特定系统中的软件部件有关的软件等级，而不考虑系统设计。当确定软件等级时，必须表明失效的影响(无论是功能丢失还是故障)。如果软件部件的异
18、常状态引起多个失效状态，那么该部件的最严重的失效状态类别决定了该软件部件的软件等级。在系统设计评估过程中，如在第4.3条巾规定的那些，存在可能导致软件等级被更改的结构方法。系统功能可以分配到一个或多个己划分的软件部件中。并行实施是用多个软件部件来实现一个系统功能。这样只有多个部件的异常状态才能产生个失效状态。对并行实施，至少有一个软件部件具有与该系统功能最严重的失效状态类别相应的软件等级。其它部件的软件等级用与该功能丢失有关的失效状态类另IJ来确定。这种实施的伊H见第4.:，.2条和第4.3.3条。一个系统功能亦可用多个软件部件来串行实施。这样任何部件的异常状态都能产生失效状态。在这种实施中，
19、软件部件向具有与系统功能的最严重的失效状态类别相应的软件等级开发某一等级的软件并不意味着对那个软件失效率的分配。软件等级或基于软件等级的软件可靠率(reliabilityrates)不能象硬件失放率那样在系统安全柯:评估过程中使用。如果采用其它方法确定软件等级，则需要通过系统安全性评估过程来证明是1正确的4.3 系统结构考虑如果系统安全性评估过程确定系统结构叫消除nJ能导致系统最严重失效状态的软件的异常状态，那么要根据软件异常状态引起的未消除的失效状态的最严重类别来确定软件等级。系统安全性评估过程考虑了结构设计方法，以确定它们是沓影响软件等级或软件的功能性。本条提供了几种结构方法，它们可限制错
20、误影响或利于检测错误初对某些错误提供可接受的系统响应。4. 3. 1 划分划分是在功能上独立的软件部件之间提供隔离的技术，以确定和/成隔离故障，并潜在地减少软件验证过程的工作量。如果通过划分提供了保护，那么对每个划分部件的软件等缀，5 HBIZ 295-96 可用与该部件相关的最严重的失效状态类别来确定。当设计了划分保护时，应考虑系统的下列方面，以确定它们是否防碍了那个保护:a硬件资源处理器、存储设备、输入输出设备、中断和定时器;b控制搞合外部存取易损性;c数据搞合共享或重复占位数据，包括堆钱和处理器寄存器，d 与保护机制相关的硬件设备的失效模式。软件生存周期过程应表明软件部件是如何划分的，包
21、括划分的部件之间允许的交联的程度和范围，无论保护是通过硬件还是通过软件和硬件的组合来实现的。如果划分保护涉及到软件，那么该软件的等级要与划分的软件部件的最高等级相对成。4.3.2 多版本非相似软件多版本非相似软件是系统设计技术，它可产生两个或更多的软件部件，这些部件提供同样的功能，并可在部件间避免某些共源错误。在非相似性引人之前完成的或进行的软件生存周期过程，可能保留了潜在的错误源。系统需求为执行多版本非相似软件规定了硬件配置。非相似的程度进而防护的程度通常是不可度量的。系统功能丢失的概率将增大到与非相似软件版本相关的安全性监控能检测到实际的错误或经受超过比较器门限的瞬变。所以，通常使用非相似
22、软件版本作为某等级的软件在其验证过程目标被满足之后提供附加保护的手段。如果I相似软件验证方法，通过系统安全性评估过程能确定最终潜在的系统功能丢失是可以接受的，那么它可以减少验证单4版本软件时所用的那些方法。多版本1相似软件的验证见第14.3.3条。4.3.3 安全件监控安全性监控是通过直接检测nJ能引起尖效状态的功能失效而防止具体失效状态的种于段。监控功能nJ通过硬件、软件戎硬件相软件的组合来实现。通过监控技术的使用，所监控的功能的软件等级可以降低到与其相关的系统功能的失效相应的等级。为r允许这个等级的降低，应确定监控器三个重要的属性:a软件等级安全性监控软件的软件等级要勺被监控功能的最严重的
23、失效状态类别相对应;b系统故障检测覆盖范围监控器的设计和实施应确保安检测的故障在所有必要的条件下均能得以检测;c功能和监控器的独立性对造成危害的|叶失效状态，监控器和防护措施均应E作。4.4 系统对用户可修改软件、可选择项软件和商用成品软件的考虑用户修改的潜在影响由系统安全性评估过程确定，并在开发软件需求和软件验证过程的活动中予以考虑。在第7.2.3条中，进一步讨论用户可修改软件的设计。如果修改影响到不再修改的软件、某保护或可修改软件界限，那么这样的修改是种软件更改，见第14.1.1条。在本标准中，可修改部件是允许用户修改的软件部件，不可修改部件是不允许用户修改的软件部件。4些机载系统和设备可
24、包tIi选择性的功能。它是由软付编程来选I页，而不是通过硬件连白HBIZ 295-96 接器引脚来选择。可选择选项的软件功能用于在目标机中选择特定的配置。对无效码的规定见第7.4.3条。系统对用户口I修改软件、可选择选项软件和商用成品软件应考虑如下因素:a用户可修改软件如果系统需求中提供了用户修改，那么用户可在修改限制范围内修改软件，而无需经过合格审定机构的评审:b.系统需求应规定防止用户修改影响到系统安全性而没有正确实施修改的方法。为用户修改提供保护的软件应具有与防修改部件出错的功能软件一样的等级;c如果系统需求未规定用户修改的方法，除I能证明更改符合本标准，否则软件不得由用户更改。d在用户
25、修改时，用户要对用户可修改软件的所有方面负责。例如软件自己置管理、软件质量保证和软件验证;e口I选择选项软件当包括编程选项的软件时，庇提供措施确保在安装环境中的目标机不会偶然选择到未经批准的配置;f.商用成品软件包括在机载系统或设备中的商用成品软件应满足本标准的要求:g.如果在商用成品软件的软件生存周期资料中存在缺项，那么成增加资料，以满足本标准的要求。4.5 系统设计对外场可加载软件的考虑外场可加载机载软件是无需拆装系统或设备即可装人的软件或数据表。与软件数据加载功能相关的有关安全性的要求是系统需求的部分。如果软件数据加载功能偶然使能会引起系统失效状态，那么对于软件数据的加载功能，与安全件有
26、关的要求应在系统需求中规定。与外场白I加载软件有关的系统安全性考虑应包括:a不可靠的或部分1m载的软件的检测;b. 1m载不合适软件的影响的确定;c硬件A软件兼容性;d软件/软件兼容性;e航空器/软件兼容性;f外场加载功能的偶然使能;E软件配置标识，Ii!爪的丢失或不可靠。对外场可加载软件应考虑:a除非由系统安全性评估过程证明是正确的，仔则部分或不可靠软件加载的检测机制要有与使用软件加载功能有关的最严重的失效状态或软件等级一样的失效状态或软件等级;b如果当不合适的软件或数据加载时系统有一个缺省模式，那么这个模式麦明的潜在失效状态中，系统的每一个划分部件应有为运行规定的与安全性有关的要求。c包括
27、支持系统和程序的软件加载功能成包括检测不正确的软件和/或硬件和/或航空器组件的手段，并提供对功能的失效状态合适的保护。d如果软件是确保航空器符合合格审定配置的机载设备显示方法的部分，那么该软件应按被加载软件的最高等级来开发，或者系统安全性评估过程M说明软件配置标识的完格性7 HB/Z 295-96 检查。4.6 系统需求对软件验证的考虑根据系统运行要求和由系统安全性评估过程产生的与安全性有关的要求来开发系统需求。应考虑，a机载软件的系统需求要确定软件的两个特性;软件完成r系统需求中定义的指定功能，软件没有呈现出系统安全性评估过程确定的具体的异常状态。为了消除异常状态，要求增加系统需求。b这些系
28、统需求进而发展到由软件验证过程活动验证的软件高级需求。4.7 系统验证中的软件考虑软件生存周期过程可帮助系统验证过程并与系统验证过程相互作用。与系统功能性相关的软件设计细节也可用于帮助系统验证。系统验证可提供代码结构的主要覆盖范围。系统验证测试的覆盖范围分析可用来实现软件验证中说明的各种不同测试活动覆盖范围的目标。5 5. 1 软件生存周期过程软件生存周期过程包括a软件计划过程定义并协调一个项目的软件开发和综合过程的活动;b软件开发过程生产软件产品的过程，这些过程是软件需求过程、软件设计过程、软件编码过程和软件/硬件综合过程，c综合过程确保软件生存周期过程及其输出正确、受控和可信。综合过程是软
29、件验证过程、软件配置管理过程、软件质量保证过程和合格审定联络过程。5.2 软件生存周期定义通过选择每一个过程的活动、规定活动的顺序和分配活动的责任，一个项目可以定义一个或多个软件生存周期。对个具体项目，由项H的特性来确定这跑过程的顺序，如系统功能性和复杂性，软件大小和复杂性;需求稳定性;以前开发结果的使用;厅发策略和硬件可用性。整个软件开发过程的般顺序是软件需求、软件设计、软件编码和l软件/硬件综合。图2表明了具有不同软件生存周期的单个软件产品的几个部件的软件开发过程的顺序。通过开发软件需求，部件W实施一系列系统需求，使用那些需求来确定软件设计，将设计转化为源代码，并且把软件部件综合到硬件中去
30、。部件X是对在已经合格审定的航空器或发动机中使用的以前开发的软件的使用说明。部件Y说明了利用能从软件需求直接编码的简单的、划分的功能。部件Z说明了使用原型策略。通常，原型的目标是更好理解软件需求并减少开发和技术风院。用初始需求作为开发原型机的基础。这个原琐机在代表被开发系统的预定的使用环境中进行评估。评估结果被用来改进需求。软件生存周期过程可反复迭代，即进入和再进入。迭代的时机和程度随系统功能、复杂8 HBIZ 295-96 性、需求开发、硬件可用性、对以前过程的反馈和项目的其它特征的进步开发而变化。5.3 过程之间的转换准则使用转换准则来确定一个过程是否i可以进入或再进入。每一个软件生存周期
31、过程完成输入到产生输出的活动。一个过程时对其他过程产生反馈并从其他过程接受反馈。反馈的定义包括接受反馈的过程如何识别、控制和处理信息。一个反馈定义的例子是问题报告。转换准则将取决于软件开发过程和综合过程的预定顺序，并且可能会受到软件等级的影响。如果为过程确定的转换准则是满意的，那么过程的每个输入不必在过程开始前完成。如果个过程对部分输入起作用，那么应检查过程的后续输入以确定软件开发布l软件验证过程的以前的输出仍然有效。6 软件计划过程软件计划过程产生指导软件开发过程和综合过程的软件计划初标准。表A1中列出r各级软件的软件计划过程的目标和输出。6. 1 软件计划过程目标软件计划过程是定义产生满足
32、系统需求并提供与适航要求相致的置信度水平的软件方法。软件计划过程的目标是:a.定义表明系统需求和软件等级的软件生存周期的软件开发过程和综合过程的活动;b确定软件生存周期，包括过程之间的内部关系、它们的顺序、反馈机理和l转换准则;c选择软件生存周期环境，包括用于每一个软件生存周期过程活动的方法和E具;d如果必要，可考虑第14章中的规定，e.定义与被生产软件的系统安全目标相符的软件汗发标准;f.编制符合第6.3条和第13章的软件计划;g协调软件计划的开发和修订。6.2 软件计划过程活动软件计划过程的活动包括:a及时地在软件生存周期的某一点开发软件计划，以便为完成软件开发过程和综合过程的人员提供指导
33、;b应规定或选择用于项目的软件开发标准;c应选择在软件开发过程中防止错误的h法和工具;d应协调软件开发和综合过程，以保证在软件计划中策略之间保持一致;e应规定随项目进展修订软件计划的方法:f在系统中使用多版本书相似软件时，选择满足系统安全性目标所必需的避免错误或进行必要检测的方法和工具;g软件计划和软件开发标准应处在更改控制之下并进行它们的评审;h如果使用无效码，应规定怎样定义验证和处理无效码(选择的选项、飞行试验)，以达到系统安全性目标:1.如果使用用户可修改代码，在软件计划和标准中应规定用户可修改软件设计的过程、9 HBIZ 295-96 工具、环境和数据项。如果计划和方法对具体的过程活动
34、是可用的，那么其它软件生存同期过程可在软件计划过程完成之前开始。分配给软件的系统需求软件都件:R-D-C-I 部件W. . . . . R-I 部件X. . . . . R-C白I部件Y. . . . . 部件ZR-C-I-C-I-R-D-C-I 代号R需求C编码D设计I二综合软件产品注:为了简单，并未表明软件计划和综合过程。图2使用四种不同开发顺序的软件项目的例子6 3 软件计划软件计划是确定满足本标准的方法。它们规定将完成那些活动的组织机构。软件计划是:a软件合格审定计划为征得合格审定机构对建议的开发方法的同意而与其进行联络的主要手段，并且定义了符合本标准的方法;b软件开发计划定义软件生存
35、周期和软件开发环境;c软件验证计划定义满足软件验证过程目标的方法;d软件配置管理计划定义满足软件配置管理过程目标的方法ze软件质量保证计划定义满足软件质量保证过程目标的方法。软件计划应考虑a软件计划应符合本标准;10 HBIZ 295-96 b软件计划应定义规定的软件生存周期过程之间的转换准则:过程的输人，包括从其它过程的反馈;可能需要的对这哩输入起作用的任何综合过程的活动;工具、方法、计划和规程的可用性。c在合格审定的航空器戎发动机上使用之前，软件计划应表明用于实施软件更改的规程。这种更改可能是由于其它过程反馈的结果，且可能引起软件讨划的更改。6.4 软件生存周期环境计划软件生存周期环境计划
36、是定义在开发、验证、控制及编制软件生存周期资料和软件产品过程中所使用的方法、工具、规程、程序设计语言和l硬件。应选择有利于机载软件开发的软件环境，包括执行标准、检测错误、防止错误和实施故障容错方法。软件生存周期环境是一个可能引起失效状态的潜在的错误源。该环境的构成可能受在系统安全性评估过程中确定的与安全性有关的要求的影响。防止错误方法的目标是在软件开发过程中避免可能引起失守党的错误。基本原则是选择需求开发和限制号|入错误机会的设计h法、E具和程序设计语言以及确保能检测到引人错误的验证方法。故障容错方法的目标应包括软件设计或源代码中的安全特性，以确保软件正确地响应输入数据错误，并防.It输出错误
37、和控制错误。用系统需求和系统安全性评估过程来确定对防止错误或故障容错方法的要求。上述考虑可能影响到2a软件需求过程和软件设计过程中所!tl方法和表At法;b软件编码过程使用的程序设tt语言和方法:C.软件开发环境工具;d软件验证和软件配置管理E具e工具鉴定要求。6.4. 1 软件开发环境软件开发环境可能对机载软件的生产产生不利影响，选择软件开发环境的方法和工具应考虑:a在软件tt划过程中，选择的软11开发环境应把最终机载软件的潜在风险减主最小;b应选择使用已鉴定的工具或工具组合以及软件开发环境部件，以便由一个部件检测到另一部件引人错误的置信度能达到必要的水平。吁两部件一起使用时，能产牛个可接受
38、的环域:c定义的软件验证过程活动或软件厅发标准，包括软件等级的考虑，应使与软件开发环境有关的潜在错误减至最少;d对组合工具的使用，如果寻求合格审定置信度，那么E具操作的顺序应在有关计划中规定;e如果在项目使用中选择f软件开发工具的可选择特性，那么应检查选项的影响并在街关计划中规定。6.4.2 语言和编译程序只有成功地完成了软件产品的验证时，编译程序对该产品才是可接受的。为了确认这一11 HB亿295-96点，软件验证过程活动应考虑编程语言和编译程序的特性。当选择编程语言和计划验证时，软件计划过程应考虑这些特性:a一些编译程序具有优化目标代码性能的特征。如果测试用例给出的覆盖范围与软件等级一致，
39、那么不需要验证优化的正确性，否则这些特征对结构覆盖范围分析的影响应按第8.4.4.2条的要求来确定:b为f实施某些特征，也语言的编译程序可能产生不能直接追踪到源代码的目标代码，例如初始化、机内错误检测或异常处理。软件计划过程应提供检测这个目标代码的方法，以确保验证的覆盖范围并在有关计划中定义了这些方法，c.如果引人了一个新的编译程序、连接编程序或加载程序版本或者在软件生存周期中更改了编译程序的选项，那么以前的测试和覆盖范围分析可能不再有效。验证计划应提供与第8章和第14.1.3条的要求相符的重新验证的方法。6.4.3 软件测试环境软件测试环境计划是定义将用于测试综合性过程输出的方法、工具、规程
40、和硬件。测试可使用目标计算机、H标计算机的仿真器或宿主机模拟器来完成。应考虑:a仿真器或模拟器可能需要按第14.2条规定进行鉴定:b.在日标机和仿真器或模拟器之间的差异以及这些差异对检测错误和验证功能的能力的影响。那也错误的检测应由其它的软件验证过程活动提供并在软件验证计划中规定。6.5 软件开发标准软件开发标准是为软件开发过程定义规则和限制。软件开发标准包括软件需求标准、软件设计标准和软件编码标准。软fj验证过程使用这些标准作为评估过程实际输出与预定输出符合性的墓础。对软件开发标准应考虑:a软件开发标准应符合第13章，b.软件开发标准应确保某给定的软件产品或相关的一套产品的软件部件的设计和实
41、施是致的;c软件开发标准不允许使用产生不能验证或与安全性奋关的要求不相符的输出的结构或方法。6.6 软件计划过程的评审和保证要进行软件计划过程的评审和保证，以确保软件计划和软件开发标准符合本标准要求，并提供执行它们的方法。应考虑:a选择的方法应能够满足本标准的目标;b适用于软件生存周期过程;c每一过程产生其输出能追溯到它们的活动和输入的证据，并表明活动、环境和所用方法的独立程度;d.软件计划过程的输出是一致的，且符合第13章要求。7 软件开发过程软件开发过程由软件计划过程和软件开发计划来定义。表A2JlJ:l1 r按软件等级划分的12 HB亿295-96软件开发过程的目标和输出。软件开发过程包
42、括:a软件需求过程;b软件设计过程;c.软件编码过程;d.软件川硬件综合过程。软件开发过程产生一个或多个等级的软件需求。高线需求直接通过系统需求和系统结构的分析产生，并在软件设计过程中进步开发。这样，可能产生一个或多个较低级需求。如果源代码在接从高级需求产生，高级需求也被视为低级需求。软件体系结构的开发涉及到对该软件结构所做的决策。在软件设计过程中，要定义软件体系结构并开发低级需求。低级需求不用进一步信息即可直接实现源代码。每一个软件开发过程可能产生派生需求。派生需求不能直接追溯到更高级需求。高级需求可包括派生需求，低级需求也可包括派生需求。派生需求对与安全性有关的要求的影响由系统安全性评估过
43、程确定。7. 1 软件需求过程软件需求过程使用系统生存周期过程的输出来开发软件高级需求。这些高级需求包括功能、性能、接口和安全性有关的要求。7. 1. 1 软件需求过程目标软件需求过程的目标是开发高级需求:并在系统安全性评估过程中明确派生的高级需求。7. 1.2 软件需求过程活动软件需求过程的输入包括来自系统生存周期过程的系统需求和在系统需求中未包括的硬件接口和系统结构，也包括来自软件计划过程的软件开发计划和软件需求标准。当规定的转换准则满足时，这些输入用于开发软件高级需求。这个过程的主要输出是软件需求文档。当软件需求过程的目标和与之有关的综合过程的目标满足时，即完成了软件需求过程。这个过程应
44、考虑:a对不明确、不一致和未定义的条件，应分析分配给软件的系统功能和接口要求，b应报告软件需求过程中发现的不充分的或不正确的输入，并反馈到输入的源过程以澄清或纠正;c应在高级需求中规定分配给软件的每一个系统需求:d.应定义分配给软件的减小系统危害性的系统需求的高级需求:e高级需求应符合软件需求标准，并且是可验证的和致的;f若适用，高级需求应当用具有容差的定量术语来说明;g除了规定的和合理的设计限制外，高级需求不应详细描述设计和验证细节.h分配给软件的每一个系统需求应能追溯到一个或多个软件高级需求:1除派生的需求外，每个高级需求应能追溯到个或多个系统需求;应为系统安全性评估过程提供派生的高级需求
45、。7.2 软件设计过程13 HBiJ: 295 - 96 在软件设计过程巾，通过-次或多次选代，逐步完善软件高级需求，以开发软件体系结构相低级需求。7.2. 1 软件设计过程目标软件设计过程的目标是根据高级需求开发软件体系结构和低级需求，并为系统安全性评估过程提供派生的低级需求。7.2.2 软件设计过程活动软件设计过程的输人是软件需求文档、软件开发计划和软件设计标准。当规定的转换准则已满足时，在设计过程中即可使用高级需求来开发软件体系结构和低级需求。这可能涉放到一个或多个较低级的需求。这个过程的主要输出是软件体结构和低级需求的软件设计文档。当软件设计过程的目标和与之有关的综合过程的目标满足时，
46、即完成了软件设计过程。对这个过程应考虑:a在软件设计过程中，开发的低级需求和软件体系结构应符合软件设计标准，并且是可追踪、可验证和致的。b应定义和分析派生的需求，以确保不与较高级需求相抵触。c软件设计过程的活动能引人可能的失效模式到软件中，戎相反地于扰其他的软件。在软件设计中采用划分或其他结构方法可改变某些软件部件的软件等级的分配。在这些情况下，应定义附加资料作为派生需求，并把这些资料提供给系统安全性评估过程。d当规定与安全性有关的要求时，应监控控制l流和数据流，如看门狗定时器、合理性检查和交叉通道比较。e对失效状态的响应应与安全性有关的要求-敛。f在软件设计过程中发现的不充分的或不正确的输入
47、应提供给系统的生存周期过程、软件需求过程或软件iI划过程，作为澄清或纠正的反馈。7.2.3 用户可修改软件的设计用户liJ修改软件在复杂程度上是可以变化的。例如用来选择两设备选项中之一的单个存储位、信息表，或者为了航空器的维护功能叫进行编程、编译和连接的存储区域。任何等级的软件能包括一个可更改的部件。对用户可修改软件的设计应考虑:a非修改部件应加以保护，以防止非修改部件在安全运行中受到更改部件的干扰。这种保护可用硬件、软件租用于修改的工具或三者的组合来实现;b由申请人提供的方法应是更改可修改部件的唯方法。7.3 软件编码过程在软件编码过程中，由软件体系结构和低级需求实现源代码。7. 3. 1
48、软件编码过程目标软件编码过程的目标应保证开发的源代码是可追踪的、可验证的、致的且正确地实现F低级需求。73.2 软件编码过程活动14 E面IZ295-96 软件编的过程的输入是软件开发计划、软件编码标准以及来自软件设计过程的低级需求和软件体系结构。当规定的转换准则满足时，软件编码过程可以进入或重新进入。f1这个过程产生的源代码取决于软件结构和低级需求。这个过程的主要结果是源代码和目标代码。当软件编码过程的目标和与之有关的综合过程的目标满足时，即完成f软件编码过程。这个过程应考虑:a源代码应实现低级需求并符合软件体系结构;b源代码应符合软件编码标准;c源代码对软件设计文档来说应是可追踪的;d在软件编过程中发现的不充分的戎不正确的输入应提供给软件需求过程、软件设计过程或软件计划过程，以作为澄清或纠正的反馈。7.4 软件A硬件综合过程使用目标计算机和来自软件编码过程的源代码和目标代码，在软件/使件综合过程中对数据进行连接和加载，以开发综合的机载系统或设备。7. 4. 1 软件领件综合过程日标该过程的目标是把口I执行目标代码加载到软件领件综合的目标硬件中。7.4.2 软件J硬件综合过程活动该过程由软件综
