软件可信性相关指南标准对比研究

于敏，杨春晖

(工业和信息化部电子第五研究所，广东广州 510610)

0 引言

可信性是需要时产品按要求执行的能力，是用于描述产品性能中与时间相关特性的集合性术语[1]。可信性是指在给定的使用和维修保障要求条件下的特性，包括可用性 (Availability)、可靠性(Reliability)、恢复性 (Recoverability)、维修性(Maintainability)和维修保障性 (Maintenance support)等，以及在某些情况下，诸如耐久性 (Durability)、安全性 (Safety)和安保 (Security)等其他特性。可信性描述了相信事物能像所期望的那样工作的程度。可信性能够建立信任和树立信心，并影响组织满足目标的能力，它可通过产品寿命周期内有效的策划及实施可信性活动来获得[2]。如果产品的可信性高，则表明该产品是值得信赖的，并且能够执行所需的服务以满足用户需求；差的可信性将严重地影响用户对于由组织开发或提供的产品价值的认知。

目前，随着计算机应用的不断发展，软件的应用范围越来越广泛，软件失效造成的后果也愈加严重，特别是在航空航天、金融保险、交通通信和工业控制等关系国计民生的重要领域，软件一旦失效就将造成重大的损失。同时，随着软件的规模越来越大，软件的开发、集成和维护工作越来越复杂，因此对软件的可信性提出了更高的要求。虽然软件可信性日益受到关注，但是，多年来，软件领域的标准主要集中在软件工程、软件过程管理和软件质量方面，很少有标准从可信性的角度来解决软件的问题。目前，软件可信性相关的指南标准，国际标准方面主要有IEC 62628：2012“Guidance on software aspects of dependability(《软件可信性指南》)”，国内标准方面主要有国军标GJB/Z 102A-2012《军用软件安全性设计指南》、GJB/Z 142-2004《军用软件安全性分析指南》、GJB/Z 157-2011《军用软件安全保证指南》和GJB/Z 161-2012《军用软件可靠性评估指南》。本文对上述5个标准进行了系统性的对比研究，以期为软件可信性领域标准的工程使用提供一定的参考。

1 软件可信性指南标准简介

1.1 IEC 62628： 2012标准

IEC 62628：2012标准是一个完整的软件可信性指南标准[3]。软件技术的发展和软件应用在行业实践中的快速适应，已经为全球商业环境的实际软件可信性标准提供了必要的条件。该标准确定了管理在软件可信性方面的影响，并提供了相关的技术过程来处理系统中软件的可信性问题。此外，该标准还提供了当前行业的最佳实践，并提出了相关的方法，以促进软件可信性的实现。

该标准解决了软件可信性问题，给出了受管理准则、设计过程和应用环境影响的软件可信性的指导；建立了关于软件可信性需求的通用框架，提供了用于系统生命周期的软件可信性过程，提出了软件可信性设计和实施的保证准则和方法，并提供了软件系统性能评估和可信性度量的实施方法。该国际标准适用于切实关心软件产品和系统可信性的开发人员、供应商、系统集成商、操作人员、维护人员和软件系统的用户，但并不适用于产品的合格评审或认证。

1.2 GJB/Z 102A-2012标准

根据可信性的定义，可靠性是可信性的一种重要特性，在某些情况下，安全性也是可信性的一种重要特性。在军用软件可靠性和安全性方面，1997年我国制定并发布了GJB/Z 102-1997《软件可靠性和安全性设计准则》，自其发布以来，软件可靠性和安全性工作越来越受到重视，目前，该标准已被广泛地应用于武器装备软件的设计过程中，并取得了良好的效果，为保证工程项目和型号的可靠性和安全性发挥了重要的作用[4]。但为了使GJB/Z 102-1997更加符合我国军用软件开发的实际，2012年完成了对该标准的修订，删除或修改了与当前实际情况不符的有关要求和准则，增加了国内外的最佳实践和经验教训，以便更好地指导军用软件的开发，提高武器装备的可靠性和安全性。

GJB/Z 102A-2012是关于军用软件安全性设计的实施指南[5]，是GJB/Z 102-1997的修订标准，修订时将标准名称改为 《军用软件安全性设计指南》。修订后的标准规定了军用软件安全性设计的实施指南，其适用范围涉及军用软件需求分析、设计和实现时的软件安全性设计要求。需要特别说明的是，软件可靠性设计也可参考GJB/Z 102A-2012标准。可靠性和安全性分属于两门不同的工程学科，存在着较大的区别，即：一般在安全性研究中用 “事故”来描述事件，关心的是人员和设备财产的损失程度；而在可靠性研究中用 “故障”来描述事件，关心的是任务未执行的程度。但可靠性和安全性又密切相关，可靠性和安全性的联系是，当系统的可靠性下降时，发生故障的概率提高，当故障出现后，不仅会造成系统的性能下降，而且发生事故的概率会提高，即系统的安全性会下降；反之，当有事故发生时，系统可能会停止运转，此时的事故从可靠性角度来讲就是故障。因此，软件安全性和软件可靠性既有区别又紧密相关，在设计层面上有着广泛的交集，GJB/Z 102A-2012中的许多设计要求既是软件安全性设计准则，也是软件可靠性设计准则，实际工程中有时将其统称为软件可靠性安全性设计准则。GJB/Z 102A-2012标准修订时名称中去掉了 “可靠性”一词，主要是缘于软件安全性支撑标准体系建设的需求，并非是因删除了GJB/Z 102-1997中的可靠性内容所致[6]。

1.3 GJB/Z 142-2004标准

GJB 900A-2012《装备安全性工作通用要求》的600系列提出了针对软件的安全性顶层工作要求，包括 “工作项目601：外购与重用软件的分析与测试”“工作项目602：软件安全性需求与分析”“工作项目603：软件设计安全性分析”“工作项目604：软件代码安全性分析”“工作项目605：软件安全性测试分析”和 “工作项目606：运行阶段的软件安全性工作”[7]。支持GJB 900A-2012具体工作项目实施的软件安全性下层次支撑标准，除了有指导软件安全性设计工作的GJB/Z 102A-2012标准外，还有用于指导软件安全性的分析工作的GJB/Z 142-2004《军用软件安全性分析指南》标准。GJB/Z 142-2004标准给出了在软件生存周期中实施软件安全性分析的指南[8]，适用于安全相关软件的获取、供应、开发、运行和维护，可被安全相关软件的需方、供方、开发者、维护者和独立的评价者使用。

1.4 GJB/Z 157-2011标准

根据可信性的定义，在某些情况下，安保也是可信性的一种重要特性。在军用软件安全保证方面，2011年我国制定并发布了GJB/Z 157-2011《军用软件安全保证指南》[9]。该标准规定了获取软件安全保证的一般过程和对安全保证过程的技术要求，适用于具有安保要求的军用软件的开发、运行和评估。该指导性技术文件适用于军用软件的管理部门、用户、开发方和独立的评估机构。

1.5 GJB/Z 161-2012标准

GJB/Z 161-2012《军用软件可靠性评估指南》是军用软件可靠性评估的指导性技术文件[10-11]。该指南规定了军用软件可靠性评估的基本要求和规程，并给出了软件可靠性评估模型。对于有可靠性定量要求的软件，该指南可用于指导在软件可靠性增长测试过程中对软件可靠性进行评估和预测，从而为测试管理提供依据，也可以在使用中对软件的可靠性进行评估。本标准的适用范围是 “软件开发过程中计算机软件配置项测试、系统测试，以及软件运行和维护阶段进行软件可靠性增长预计和评估”。因此，该指南可用于在软件开发测试阶段的后期进行可靠性的增长预计和评估，以评价是否达到预期的软件可靠性指标要求，预测为达到预期的指标要求还需要开展的测试工作量；也可以在运行维护阶段对软件的可靠性进行评估。

2 软件可信性指南标准技术比较

2.1 标准关注的软件性能特性不同

可信性是用于产品与时间相关性能特性的集合性术语，国际标准IEC 62628：2012考虑的是软件可信性，即考虑了软件包括可用性、可靠性、恢复性、维修性、维修保障性、耐久性、安全性和安保等各方面特性在内的可信性。国家军用标准针对的则是软件可信性的某一方面，其中：GJB/Z 102A-2012考虑的是软件的安全性和可靠性，GJB/Z 142-2004则仅考虑了软件的安全性，GJB/Z 157-2011考虑的是软件的安保特性，GJB/Z 161-2012考虑的是软件的可靠性。因此，IEC 62628：2012更具有一般性和通用性；而国家军用标准考虑的是软件可信性的某一方面，更具有针对性。

2.2 标准所适用的软件生命周期阶段不同

在GB/T 11457-2006《信息技术 软件工程术语》中，“软件生存周期”的定义为：“当软件产品从构思开始至软件不再可用结束的时间周期。软件典型的生存周期包括需求阶段、设计阶段、实现阶段、测试阶段、安装和验收阶段、操作和维护阶段，有时还包括退役阶段[12]”。

本文考虑的几个标准，适用的软件生存周期阶段也有所不同。其中：IEC 62628：2012提供了软件全生存周期实现软件可信性的指南，GJB/Z 142-2004给出了在软件全生存周期中实施软件安全性分析的指南，GJB/Z 157-2011主要用于具有安保要求的军用软件全生存周期获取软件安全保证的指南，这3个标准都可用于软件的全生存周期。其他两个标准则适用于软件的部分生存周期阶段，如：GJB/Z 102A-2012主要用于软件需求阶段、设计阶段和实现阶段，规定了军用软件需求分析、设计和实现时的软件安全性设计要求；GJB/Z 161-2012主要用于测试阶段和操作维护阶段，在这两个阶段对软件的可靠性进行评估。

2.3 标准内容比较

2.3.1 IEC 62628：2012标准的主要内容

IEC 62628：2012标准建立了关于软件可信性需求的通用框架，提供了用于系统生命周期的软件可信性过程，提出了软件可信性设计和实施的保证准则和方法，并提供了软件系统性能评估和可信性度量的实施方法。具体的内容如下所述。

a)软件可信性概述，对软件和软件系统、软件可信性和软件组织、软件和硬件可信性的关系、软件和硬件的交互几个方面进行了说明。

b)软件可信性工程和应用，明确了软件可信性工程和应用的几个方面，包括：系统生命周期框架、软件可信性项目实施、软件生命周期活动、软件可信性属性、软件设计环境、建立软件需求、软件可信性目标、软件故障的分类和软件可信性实施策略，具体包括以下几个方面的内容。

1)系统生命周期框架，应建立一个系统生命周期框架来指导产品开发和系统实施，框架用于定义系统寿命周期并管理系统寿命周期过程，IEC 60300-3-15标准描述了系统可信性工程和生命周期实施[13]。

2)软件可信性项目实施，在设计周期和系统生命周期的使用生命周期中，软件工程活动应该与它们的硬件设备一起进行规划、协调和管理，标准推荐了软件项目实施时实现软件可信性的程序。

3)软件生命周期活动，规定了软件生命周期应包括以下活动，即：需求定义、需求分析、架构设计、详细设计、实现、集成、验收、操作和维护、软件升级/提高、退役。

4)软件可信性属性，软件可信性属性是软件设计中固有的特性，主要的软件可靠性属性或内在的软件可信性特性有助于系统的可信性目标的实现，应包括可用性、可靠性、维修性、恢复性和完整性、特定的应用程序相关性能属性有助于系统可信性目标的实现，应包括但不局限于安保、安全性、可操作性、可重用性、保障性和可移植性。

5)软件设计环境，依赖于一个有组织的过程，可促进良好的设计实践，实现无错误的代码生成，最小化需求定义中的错误，并确保软件发布的测试验证。软件设计环境和实践原则应包括在组织策略中，以建立和实现可信性的使命和目标。

6)软件需求和可信性目标，应该是整个软件产品规格的一部分，与软件需求相关的可信性活动具有特定的应用。在整个软件生命周期中实现相关可信性活动的系统方法将确保可靠性目标的实现。标准说明了软件开发中应考虑的影响可信性实现的因素。

7)软件故障分类，提供了一种捕捉和分组相关软件故障信息的手段，分类过程帮助软件设计者发现不寻常的故障模式并进行整改。软件故障可以被分为规范故障、设计故障、编程故障、编译器插入错误或软件维护期间引入的故障。同时，标准对软件工程中软件故障 (缺陷)数据分析常用的正交缺陷分类 (ODC)进行了说明。

8)软件可信性实施策略，一般包括软件故障避免和软件故障控制，标准推荐了软件故障规避策略，包括故障预防和故障消除；推荐了软件故障控制策略，包括容错和故障/失效预测。

c)软件可信性应用方法，包括实现可信性的软件开发实践、软件可信性度量和数据收集、软件可信性评价和软件可信性提高，具体包括以下几个方面的内容。

1)实现可信性的软件开发实践，建议了在软件开发过程中采用的故障避免和故障控制技术。

2)软件可信性度量和数据收集，其中：软件可信性度量是软件系统可信性特性的测量，以下软件度量标准实际上是应用程序的行业标准，可用于软件系统可信性评估，包括可用度、失效频率、失效前时间、恢复时间、故障密度、功能点、代码覆盖率、故障消除率、残余的软件故障和软件发布时间，以及软件复杂性等；在软件生命周期因各种原因应使用多种度量，为方便数据收集，将软件度量分为3类，即：故障数据度量、产品数据度量和过程数据度量。

3)软件可信性评价，软件可信性过程实现的目标是确保软件系统开发的成熟度和可信性的实现。评估过程是一种使能机制，确保软件需求验证和系统性能结果中软件可信性的确认。根据行业实践，可信性评估过程应结合重要的软件工程活动，并推荐了软件可信性评估过程，包括：确定用户需求和系统性能目标，形成可信性规范；建立软件操作剖面；分配适用的可靠性属性；进行可信性分析和评估，以确定可能的解决方案；进行软件测试和测量；进行软件验证和软件系统确认；执行软件可靠性增长和预测改善趋势；评估评价结果并进行回馈。标准描述了上述软件可信性评价过程中的具体活动。

4)软件可信性的提高，可以通过在软件设计方面的改进、可靠性增长测试，或者通过包括软件提高在内的、为客户提供的支持服务来实现。其中，软件设计目标主要集中在以下方面：可测试性，有利于软件功能的验证；模块化，有利于故障隔离和控制；维修性，有利于软件生命周期的修改。为了软件的提高和实施，标准提供了与软件可信性设计和推荐技术相关的实用方法，包括以下几个方面：软件复杂性简化，复杂性又可分为结构复杂性和功能复杂性；软件故障容错，包括故障隔离、故障检测、故障恢复、设计多样性；软件互操作性；软件复用；软件维护和提高，软件维护又可分为修正性维护、适应性维护、改善性维护和预防性维护；软件文档，包括结构和设计文档、技术文档、用户文档和营销文档；自动化工具；技术支持和用户培训等。

d)软件保证，是指计划性和系统性的活动，确保软件生命周期过程和产品符合需求、标准和规程。软件保证一般包括质量、可靠性、安全性和安保，连同软件产品开发和系统运行相关的技术准则。软件保证利用风险评估、验证、确认测试、文档化和维护审计记录作为客观证据，并利用相关的基于项目的度量数据来监控软件产品和相关过程，以实现可能的改进。同时，标准提供了软件保证相关的剪裁过程、技术影响和最佳实践。

IEC 62628：2012标准的显著特点应为标准的“全面性”，这里的全面性主要体现在以下5个方面：可信性特性的全面性，标准考虑了包括可用性、可靠性、恢复性、维修性、维修保障性、耐久性、安全性和安保等各方面特性在内的所有可信性特性；软件生存周期阶段的全面性，标准考虑了软件的全寿命周期阶段，包括需求阶段、设计阶段等全部生存周期阶段；软件可信性相关概念的全面性，标准对软件、软件系统、软件可信性、软件组织、软件生命周期活动、软件可信性属性、软件故障分类和软件可信性度量，以及软件度量等都进行了定义或描述；实现软件可信性方法的全面性，标准提供了包括软件可信性工程和应用、软件可信性应用方法和软件保证在内的比较全面的实现软件可信性的方法。综上，IEC 62628：2012标准是一个完整的软件可信性指南标准，其应作为软件可信性的基础性标准。

2.3.2 GJB/Z 102A-2012标准的主要内容

GJB/Z 102A-2012主要用于军用软件安全性设计，规定了软件安全性设计的一般要求和详细要求。具体的内容如下所述。

a)一般要求包括了软件安全性工作的通用要求 (包括软件安全性工作贯穿于软件生存周期全过程等)、外购 (协)或重用软件的要求 (外购或外协软件应按标准要求进行管理并进行安全性分析和评价，重用软件应分析其适用性并分析其安全性影响)、工具的验证要求 (安全的关键软件开发过程中使用的影响可执行代码的软件工具应经过安全性验证)。

b)详细要求则提供了软件需求分析、软件设计和软件实现时的软件安全性设计指南，具体包括以下内容。

1)软件需求分析阶段，明确了软件安全性需求的来源 (专用的安全性需求、通用的安全性需求)，规定了需求规格说明中应明确标识软件安全关键功能 (简单的软件可采取简单的分析方法，对于比较复杂的软件可利用FTA、FMECA等方法找出软件安全的关键功能)，针对安全的关键功能应重点分析 (包括：安全运行模式、运行状态与安全条件、容错和容失效、危险命令处理、接口、数据、定时、吞吐量和规模等)，并提出了安全保证措施要求 (包括采用冗余、降级处理、故障处理与恢复和降级运行等)。

2)软件设计阶段，通过设计消除已标识的危险或降低相关的风险，明确了安全性设计的基本考虑 (包括：功能分配、程序接口、故障检测、恢复和安全保护、继承的或重用的软件和现货软件、性能和余量、可追踪性、可测试性等)，以及配合硬件或系统设计、容错和容失效的设计、接口设计(与硬件相关的接口软件设计、软件模块间接口设计和人机界面设计)、通讯设计、数据安全性设计、中断设计、模块设计、定时吞吐量和规模的余量设计、防错设计、自检查设计、异常保护设计应考虑的事项。

3)软件实现阶段，为了保证软件实现的安全性，要求软件编制时应遵循相应的编制规范，并规定了软件编程的通用要求，包括：编程语言通用要求、软件复杂性控制、注释要求与方法、指针使用、多作物的处理和其他要求等；编制完成后应进行代码验证工作，验证软件正确地实现了经过验证的设计且不违反安全性需求，代码验证的方法包括代码逻辑分析，代码数据分析，代码接口分析，未使用代码分析，中断使用分析，定时、吞吐量和规模分析，以及代码审查等方法。

GJB/Z 102A-2012标准的侧重点是软件的 “安全性设计”，标准中的许多设计要求，都是以惨痛的教训甚至是血的教训换来的，被要点释义为具体的设计准则，并结合以往出现的典型案例，在实际工程中广泛地应用并发挥着重要的作用，标准的执行是否到位将直接影响着软件安全性水平的高低。

2.3.3 GJB/Z 142-2004标准的主要内容

GJB/Z 142-2012给出了在软件生存周期中实施软件安全性分析的指南。软件安全性分析的目的是通过获取和评估软件安全性的相关信息，保证系统安全性质量。标准规定了软件安全性分析的应用原则和剪裁准则、软件安全性分析的组织、软件安全性分析的支持、软件安全性分析准备、软件安全性分析任务和软件安全性分析报告6个方面，具体包括以下内容。

a)软件安全性分析的应用原则，明确了软件安全性分析是系统安全性分析的组成部分，应与系统安全性分析密切结合、协调一致等；关于剪裁准则，则说明了安全完整性级别应作为剪裁的主要依据等。

b)软件安全性分析的组织，规定了软件安全性分析在管理、基础设施、改进和培训4个方面的要求。

c)软件安全性分析的支持，提出了软件安全性分析在文档编制 (文档的内容、文档的形式)、配置管理、质量过程 (质量过程的配置、质量过程的独立性)和问题解决4个方面的要求。

d)软件安全性分析准备，是进行软件安全性分析前对软件所在的系统进行初步的分析，明确了作为软件安全性分析的准备，应包含如下任务：概念分析和系统范围确定、初步危险和风险分析、系统需求安全性分析、系统安全性需求分配、软件的安全性需求分配。

e)软件安全性分析任务，明确了软件安全性分析任务应包括以下7个方面：软件需求安全性分析、软件结构设计安全性分析、软件支持工具和编程语言安全性分析、软件详细设计安全性分析、软件编码安全性分析、软件测试安全性分析和软件变更安全性分析，并规定了各个任务的具体的工作项目。

f)软件安全性分析报告，规定了软件安全性分析报告应包括安全性环境、软件安全性保证、软件安全性证据、软件残留风险及控制4个方面，并对各个方面应包括的内容提出了具体的要求。

GJB/Z 142-2004认为软件安全性分析是对和软件安全性相关的特定信息进行的系统而有序的获取和评价过程，给出了在软件全生存周期中实施软件安全性分析的指南。

2.3.4 GJB/Z 157-2011标准的主要内容

GJB/Z 157-2011规定了获取软件安全保证的一般过程和对安全保证过程的技术要求，包括5个方面，具体的内容如下所述。

a)安全保证框架 (SAF)，包括框架模型、框架的描述结构和框架的应用。组织良好的软件过程更容易产生可重复的安全保证，在软件生存周期中应持续积累保证证据和建立保证举证，这些安全保证活动应以一个有序的活动框架组织起来。标准提出的软件SAF包含了为获取软件安全保证需要完成的安全保证活动，描述了提供安全保证的过程应具有的特征，SAF由获取安全保证需要考虑的4个过程类及其所包含的11个过程组成。

b)风险评估过程类 (CRA)，由于风险是由威胁、脆弱性和影响3个必要部分组成，因此CRA包括评估威胁、评估脆弱性、评估影响和评估安全风险4个过程。

c)开发过程类 (CDV)，包括确定安全需求和设计实现安全控制两个过程。使用CRA所描述的风险过程的信息和关于软件系统需求、相关法律、政策的其他信息，安全组人员就可以与用户一起来确定安全需求。一旦该需求被确定，就可以确定和跟踪特定的安全需求。为了满足特定的安全需求，设计实现安全控制一般包括确定可能选择的方案，然后评估决定哪一种方案更能被接受。一旦确定特定的安全解决方案，就可以开始进行相应安全控制的软件实施。

d)实施过程类 (CCO)，包括实施安全控制和监视安全状况两个过程。软件开发后，首先，应保证将其完整地、不被修改地交付给用户；其次，在软件交付后，应根据识别出来的风险来适当地配置软件，以确保开发的安全控制有效地实施，并且不会引入新的风险导致软件运行处于不安全状况。在实施安全控制的同时，还应不断地监视安全状况，分析安全变化和突发事件，并进行响应。如有必要，可再次启动风险分析和开发过程，从而对安全控制进行更新。

e)保证获取过程类 (CAA)，主要涉及到与安全相关证据的产生，包括验证和确认安全、协调和支持保证、建立保证举证3个过程。安全验证和确认在建立软件的保证证据中起着主要的作用。SAF中其他所有的过程提供的工作产品可作为证据或证据的一部分。协调和支持保证一方面对其他过程起到协调和支持的作用，同时也提供间接的安全保证证据。建立保证举证过程的主要作用是积累保证证据以建立软件安全保证举证。

在软件系统中，安全功能和安全保证是安全性的 “一体两面”。对于在安全方面有特殊要求的软件，在实现安全功能时，不应忽视安全保证。为了提升软件的安全性，应将一系列的保证活动有机地集成到软件开发者通常使用的软件过程中。GJB/Z 157-2011是为了让用户确信软件已满足了其安保特性要求，这正是软件安全保证需要解决的问题。

2.3.5 GJB/Z 161-2012标准的主要内容

GJB/Z 161-2012主要用于军用软件可靠性评估，规定了软件可靠性评估的一般要求、软件可靠性评估规程，给出了3类软件可靠性模型，推荐了7个典型的模型。具体的内容如下所述。

a)软件可靠性评估的一般要求，包括以下6项：评估目的、评估时机 (测试阶段、使用阶段)、评估规程建立、评估数据要求 (数据包括失效时间数据和失效计数数据)、评估结果 (失效率、MTTF等)、评估结果的有效性确认 (失效数据的有效性、模型预计的有效性)。

b)软件可靠性评估规程，包括以下9个步骤(可根据项目的具体情况合并或剪裁)：失效定义、运行环境特性描述、测试、数据收集、失效数据趋势分析、软件可靠性模型选择、模型参数估计、模型确认、可靠性估计和预计。

c)软件可靠性模型，给出了3类软件可靠性模型，推荐了7个典型的模型，包括：指数型NHPP模型类，推荐模型为Schneidewind模型、广义指数模型和Jelinski/Moranda模型 (为广义指数模型的代表)；非指数型NHPP模型类，推荐模型为Musa/Okumoto对数泊松执行时间模型、Duane模型和Yamada的S形模型；贝叶斯模型类，推荐模型为Littlewood/Verrall模型。

IEC 62628：2012标准的第6.3节给出了关于软件可信性评估的一般性的方法，同时，在标准的附录H中给出了几种常用的软件可靠性模型的选择和应用方法。GJB/Z 161-2012标准仅适用于软件可靠性评估，给出了专用针对软件可靠性评估的基本要求和具体规程，以及软件可靠性评估模型等，为军用软件在软件配置项测试、系统测试及运行和维护中收集失效数据、开展软件可靠性评估提供了指南。需要特别指出的是，在研制阶段对软件进行有效的可靠性评估，通常需要开展软件可靠性测试，即基于操作剖面的软件测试，根据软件可靠性测试得到的软件失效数据应用合适的软件可靠性模型进行软件可靠性评估。

3 结束语

本文对常用的软件可信性领域的指南标准进行了分析比较，主要从标准所关注的软件性能特性、标准所考虑的软件生命周期阶段和标准的技术内容等几个方面进行了比较，其中：IEC 62628：2012考虑的是软件的可信性，即考虑了软件可信性各个方面的特性，建立了关于软件可信性需求的通用框架，提供了用于系统生命周期的软件可信性过程，提出了软件可信性设计和实施的保证准则和方法，并提供了软件系统性能评估和可信性度量的实施方法，但该国际标准目前国内尚未采标，为了使该标准给国内软件可信性工程提供参考，建议应尽快开展标准的国内采标工作。关于软件安全性、安保和可靠性某方面的特性已有一些专门的标准，但尚缺少关于软件的可用性、恢复性、维修性和维修保障性等方面的指南标准；另外，从标准所关注的软件生命周期阶段来看，部分标准考虑了需求阶段、设计阶段、实现阶段、测试阶段和操作维护阶段的软件可信性，但关于软件退役阶段的可信性则少有考虑，建议可开展该类标准的研究工作。