故障处理 软件 需求_如何根据GJB 102A开展软件安全性分析 —— 下篇

前言

在中，我们介绍了GJB 102A的现状、解读、建议等。今天，我们继续介绍GJB 102A应用详细步骤。

上  篇

1、GJB 102A的型 应用现状

2、GJB 102A与其他标准的关系

3、GJB 102A的不足

4、GJB 102A的使用建议

下  篇

5、GJB 102A应用的详细步骤

第一步，分析软件特点，确定适用条款

第二步，根据适用条款，形成细化准则

第三步，根据分析准则，选取失效模式

第四步，根据失效模式，评估影响后果

第五步，根据影响后果，形成安全需求

6、增量步骤 证明自己的软件符合GJB 102A

第六步，过程举证，结果举证，列出举证矩阵

第七步，根据举证矩阵，回溯标准条款，得到安全结论

5    GJB 102A应用的详细步骤 第一步，分析软件特点，确定适用条款

GJB 102A的全部条款约350项。对于不同特点的软件不能全部套用，需要从标准条款中选择出适用的部分。

选择的原则是根据软件特点剪裁不适用的要求。例如，对于一个不含界面的嵌入式软件，“5.3.4.3 人机界面设计”不适用；而对于状态场景多的软件，“5.2.2.2 安全运行模式、运行状态与条件”则更为适用。

如何分析软件“特点”呢/p>

并没有通用的定义，软件特点可以是软件固有特性，例如，

军用软件测评实验室分类的嵌入式软件与非嵌入式软件；

按照软件使用特点可分为机电软控制类、数据处理类、信息系统类等等；

按照软件规模可以分为大、中、小等；

按照软件领域可分为机载、弹载、星载、船载、车载等等；

按照软件接口可分为传感器、数字总线、数字开关等等。

也可以是比较主观的特点，例如，

软件某类功能、某个接口易出问题(需着重分析)；

某功能涉及安全关键；

某功能属于迭代开发等等。

以下是一些进行软件特点分析的示例： 

1

— 领域特点 —

依据软件所在的航空、航天、船舶、兵器等领域特点，分析应考虑的安全性要求。例如，航空领域的安全关键软件通常包含冗余设计、BIT自测试等，那么适用的标准条款如“5.2.2.3 容错和容失效—冗余设计”、“5.3.3 容错和容失效的设计—b)机内测试”就应该作为重点对标条款。

示例1  下面是某机载关键级软件的一个安全性适用条款选择片断。

软件特点包括：设备级冗余设计、软件功能级冗余设计、BIT自测试功能、状态场景多等。

因此，选择了：

“5.2.2.3 容错和容失效—冗余设计”

“5.2.2.3 容错和容失效-冗余管理/转换逻辑”

“5.3.3 容错和容失效的设计—b)机内测试”

“5.2.2.2 安全运行模式、运行状态与条件”等等。

3

— 软件项目阶段 —

软件安全性工作是可以迭代、阶段性推进的，划分工作阶段，每个阶段选择不同的标准条款，作为首轮、二轮、…、回归阶段的安全性目标。

示例3  下面是某信 处理软件的一个安全性适用条款选择片断。

信 处理软件功能依靠大量软件外部接口输入输出完成，软件接口数量多，因此将软件安全性分析划分为三个阶段：

阶段一  接口安全性分析；

阶段二  功能安全性分析；

阶段三  迭代与总结。

在阶段一，进一步将软件接口分为“驻留设备接口、外部输入接口、外部输出接口、接口通信、人机交互接口、软硬件交互接口”等类别，分别选择适用标准条款。

运动停止位置

当前位置

机械限定位置

历史经验中，这些要素发生过哪些失效规律结出哪些失效模式数据/p>

经过失效模式的积累，建立软件失效模式数据库，在软件项目中持续复用、迭代失效模式数据，逐步扩充经验数据，也是支撑标准实施的有效手段。

第四步， 根据失效模式，评估影响后果

针对软件失效模式，由失效模式触发的软件功能出发，分析对软件配置项级功能、软件所处的设备以及系统、乃至系统功能的影响。从系统运行安全与任务完成的角度，识别软件失效可能导致的系统危险。

此外，还要考虑软件向系统的反馈，软件失效有可能影响与之交互的其他硬件设备、系统，也有可能影响软件所在的上级系统、直至整机。

因此，分析软件失效影响时尽可能多考虑：

• 软件失效是否会导致系统失效导致哪些系统失效/p>

• 软件失效会不会影响人员操作导用户…

• 软件失效引起的后果是否会导致危险/p>

• 并进一步评估，软件导致的系统危险，系统是否已经通过自顶向下的方式识别，并分配了软件安全性需求，如果没有，是否需要迭代至系统安全性分析过程，例如故障树分析过程…

• 等等。

至此，实现了选择标准条款、制定细化准则、使用失效模式数据、形成安全需求的过程。软件安全性分析结果的示意如下(灰色是原始软件需求，红色是安全性分析出的软件失效，蓝色是针对软件失效获取的安全性需求)：

第七步， 根据举证矩阵，回溯标准条款，得到安全结论

软件研制人员完成举证矩阵之后，给出符合标准条款的证据。接下来，对这些证据进行验证的人员登场，给出软件项目是否符合标准的结论。

验证角色可以是：研发组织内部的独立验证人员、外部的专家或验证机构、用户委托验证代表等等，视不同领域工程实际情况而定。比如在某些军用软件领域以评审会的方式进行审查验证，在民用领域则开展了更为规范的委任代表审定或是认证咨询机构审定等等。

根据第六步的输出，通过资料审查、过程复现、质询访谈等方式，回溯第一步输出的适用标准条款是否都得到了符合：

至此，下篇内容结束。

结束语

需要特别说明的是，任何标准都有很多实施途径，标准本身必须具有足够的通用性，不能被任何一种具体实施途径所限制。特别是安全性类标准属于“逆向”思维模式，更应该鼓励发散思维而不是僵化思维。

所以，对于实施途径一定要正确理解：它不是僵化的死板步骤，更不意味着“充分性”，而是在对标准实践的过程中一个推荐性和“保底”作用的指南，随着理解和应用的不断提升，会出现和掌握越来越多的灵活性。“有招”是“无招”的必由之路。

相关资源：按软件服务对象的范围划分-软件工程课件-专业指导文档类资源-CSDN…