MUNIK解读ISO26262:功能安全之变更管理

点击上面蓝字

关注MUNIK公众号

 

 

 

导读

 

在项目管理中,变更管理和配置管理息息相关。变更管理在企业运行中同样很重要,如果一项重要的变更没有进行管理,那么在实施过程中,导致只有一部分知晓,造成信息不一致的情况,一方面不利于项目管理进度,除此外也会影响公司的品牌形象。

01

认识变更管理

MUNIK

图1:需求分类 摘自IT帮《BangBA公开课》讲义

 

变更管理的目的

变更管理的目的是在整个功能安全生命周期中,分析和控制功能安全相关工作成果、相关项和要素的变更,同时在整个安全生命周期内维护工作成果、相关项和要素的相关功能和特性。

变更管理的误解

很多人对于变更管理存在这样的误解:是不是变更越少更利于项目的管理?在完整的项目生命周期内,变更管理并不是为了拒绝变更,而是通过变更管理来控制变更,使得变更带给项目的影响变得有序可控,因此在项目启动时,建立变更管理制度和相关流程规范,以便指导和规范执行变更的相关人员进行项目变更行为。

 

02

变更管理流程

MUNIK

 

图2:常规项目变更管理流程

 

上图为常规项目变更管理流程,当我们在进行功能安全开发时,应注意考虑功能安全特有的一些方面:

 

变更需求

启动变更时,首先应为变更请求分配一个唯一的ID。 其次,所有变更请求都需要提供相关信息,例如日期、原因、准确和具体的描述,以及更改所基于的配置(包括版本)。

变更需求识别

可由项目经理命名的变更管理员应首先确定变更是否与功能安全相关。如果不相关,请给出原因,然后记录并关闭更改;如果相关,应进一步对更改进行分类。常见的分类主要包括错误解决、调整、消除、增强和预防。

通过对变更需求进行识别,得出其与功能安全无关的结论,并提供相应的依据转移至质量体系,便可关闭该条变更需求。 

变更需求分析

对每一个变更需求,应按照标准要求进行影响分析。应考虑以下因素:

(1)识别受影响的工作产品、相关项和要素以及要更改的工作产品、相关项和要素;

(2)在分布式开发的情况下,相关各方的识别和责任;

(3)变更对功能安全的潜在影响;

(4)实现和验证更改的时间表;

(5)对工作成果的每次变更,应重新启动安全生命周期的适用阶段。后续阶段的开展应符合ISO 26262标准。

 

变更需求评估

评估主要包括变更类型、对象、责任、对功能安全的潜在影响及相关进度表分析的准确性和合理性。评估小组应给出评估结论,例如接受、拒绝或推迟更改。

评估团队应至少包括项目经理、项目安全经理、质量保证和相关开发人员。

如果变更请求被接受,评估团队需要确定谁将对变更负责,包括执行者和验证者,以及变更的最新日期。此决定应考虑执行变更请求所涉及的接口。

变更实施

变更执行人应根据变更分析和评估的结果实施变更,然后展示工作成果。

变更验证

变更验证者应验证变更的实施是否达到了变更分析和评估的预期目的,然后将最终验证结果记录在变更管理计划中。如果变更影响了安全相关功能或特性,则应在发布相关项前,对功能安全评估和适用的认可评审进行更新。

记录与关闭

项目经理负责监控变更状态。《变更管理表》中记录变更状态,由变更当前状态的干系人负责维护。变更结束前,应当记录变更的相关明细、变更的工作产品清单和变更对象信息,并给出变更的实施时间。实施变更和验证结束后,安全经理负责变更的评审,然后通知配置管理员更新变更影响的工作产物基线。

 

03

总结

MUNIK

 

 

变更管理是功能安全项目管理中非常重要的一个方面,它能够有效识别对功能安全有影响的变更,控制对项目的影响,从而保证项目顺利完成。因此在功能安全开发过程中,变更管理需要建立规范的流程和方法,同时也需要团队的协作和努力。

回到本文的源头文章“ISO26262标准解读”,请点击链接:ISO26262 Functional Safety of Automotive汽车功能安全服务