功能安全之软件变更管理要素分析

在安全软件的管理活动中，软件变更是软件质量管理的一个环节，也是功能安全认证的重要审核项。特别是当安全软件已经在现场进行部署后，对其的变更控制应更为谨慎。从提出一个软件变更请求，需要经过提出变更、问题分析、影响分析、批准变更、更改实施、变更验证，最后到变更发布，涉及到项目中不同的角色：CCB、PM、Developer、Safety、Tester、Verifier、Validator、QA。用流程图表示软件的变更过程和每个过程有关的角色如下，在不同的组织中，每个过程实施的角色可能存在差异，中间也会存在迭代反复的过程，以下是一个简化版的变更过程流程图。

• 确定软件变更所在的软件模块，例如系统/软件配置标识符或组件及其版本的列表-软件版本、系统配置/设置、已安装的选项/组件、硬件配置；处理嵌入式系统开发时，硬件版本号、FPGA版本号、仿真设备版本号等;为PC开发时，重要的配置信息包括品牌/制造、辅助卡和安装的驱动程序；
  
• 变更要解决的问题，对解决问题的具体描述：产生软件缺陷问题的步骤，输入数据，预期的结果，实际运行的结果，需要进行的更改，包括变更的相关具体内容用来解释更改的原因，一项变更中可以解决多个问题，因此对应多个问题报告；
• 识别与变更问题的安全有关影响：对功能、性能、内外部接口产生的影响；
  
• 软件变更请求/问题报告的提出者：提出者的姓名，部门和联系方式；
• 问题提出者对问题优先级或严重度的分析：问题/报告划分为紧急，重要，中等、轻微或任何其他定义的分类级别；
• 为解决缺陷问题或分析和评估所采取的纠正措施，更改的软件配置项，时间表，花费成本，产品或测试： 描述用于解决变更请求或问题报告的更改的描述；描述任何相关的问题分析，例如影响分析；更改的配置项列表，包括要修改的源代码，和有关的测试文档，需求文档，设计文档和其他项目文档；
• 提出变更发生所处的项目阶段：原型设计阶段，维护阶段，或需求阶段，设计阶段，开发/实施阶段，测试阶段等；
• 批准或不批准软件变更请求：来自变更控制委员会CCB组对变更请求的处理意见，如紧迫性类别，处置日期，优先程度（高，中，低），严重程度（引起不便，造成停机，safety问题，security问题）等其他详细信息；
• 验证修改后软件的实施和发布——单元测试、集成测试、系统测试运行以验证更改及其各自的结果，验证人，验证日期，包含变更的已发布软件版本，发布日期；
• 问题产生的时间-变更申请的日期或问题首次发生的日期；
• 变更问题的当前状态：提出/待分配/分析中/修改中/测试中/已关闭，随着变更请求的处理和问题或更改的处理进度而更新；
• 在开发或测试更改时可以使用的任何解决问题的方法：在更改问题时保持系统正常运行而不触发问题的步骤。

• 变更请求，问题报告的编号/标识符，具有唯一性；
• 变更请求，报告的简要标题或说明；
• 提交日期，提交报告的日期；
• 如果多个项目的变更请求，问题报告在同一个变更管理系统中，添加项目名称或标识符；
• 问题是否可重现(外部客户报告不具有典型性，对测试人员是需要的)；
• 目击者，观察者(可以从他们的角度提供的分析数据)；
• 附件——附加的分析数据，如测试数据或结果；
• 备注说明；
• 分析问题的详细数据，如分析工作量、建议、分析者、完成日期、分析文本、根本原因；
• 花费在设计、实现、测试更改或校正上的成本；
• 变更的类型：逻辑、接口、数据、计算或其他定义的变更类别；
• 受更改影响的代码行(LOC)；
• 受影响基线：功能、分配、产品；
• 完成日期。

在小型项目中，项目组成员即包括了变更管理的全部成员，可以考虑使用简单的工具，如建立word的模板来管理变更请求/问题报告，使用excel电子表格来追踪和更新变更管理的过程，使用简单的数据库来统计变更数据和生成变更的度量标准。对于中大型项目或项目群管理，从提升效率和降低管理成本角度，使用必要的变更管理工具是有必要的。

参考资料：NASA Software Safety Guidebook, NASA-GB-8719.13, NASA, 2004。

原文始发于微信公众号（薄说安全）：功能安全之软件变更管理要素分析