在安全软件的管理活动中，软件变更是软件质量管理的一个环节，也是功能安全认证的重要审核项。特别是当安全软件已经在现场进行部署后，对其的变更控制应更为谨慎。从提出一个软件变更请求，需要经过提出变更、问题分析、影响分析、批准变更、更改实施、变更验证，最后到变更发布，涉及到项目中不同的角色：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。
原文始发于微信公众号（薄说安全）：功能安全之软件变更管理要素分析
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论