ASPICE VDA Guideline解读(18)：SUP.10 变更请求管理

Posted 2023-03-20

参考技术A SUP.10 变更请求管理"过程的目的是确保变更请求被管理、跟踪和实施。

在什么场景下需要应用SUP.10来进行变更管理呢？

举个例子来说明变更请求的各种情况，如下图所示：

客户发布了"客户需求规约"基线

产品需求工程师基于"客户需求规约"基线，开发并发布了"产品需求规约"基线

开发工程师基于"产品需求规约"基线，开发并发布了"产品设计和实现"基线

场景1：当已建立基线的"客户需求规约"发生变更时，需要应用SUP.10：

场景2：测试工程师在实施测试活动时，发现了缺陷（注：按"SUP.9 问题解决管理"处理缺陷），开发工程师在解决缺陷的过程中，发现有必要变更已建立基线的产品需求规约。此时需要触发"SUP.10 变更请求管理"过程来请求变更“产品需求规约”。

场景3：当由于例如"设计重构“的原因，对已建立基线的"产品设计"进行变更。

变更请求管理策略：

a需覆盖变更请求影响的各个学科(如：软件、电路）、各个领域（如：应用层软件、底层软件）

b需覆盖变更请求影响的各相关方，如客户、供应商、内部相关方等

c需定义变更请求在各学科、各领域、各相关方之间的传递和管理

d需定义变更请求的"状态模型"

e需定义活动的目标，如响应时间

f需定义变更请求批准在组织结构层级上的指导，如变更请求的影响到达XX成本时，需要项目经理批准，而当变更请求的影响到达XX成本时，需要部门总监批准

e可以根据项目所处的不同阶段（如：A样件、B样件），定义变更请求处理的不同要求

f需定义确保"变更请求"与"变更请求影响的工作产品及基线"之间的双向追溯性的机制

[SUP.10.RL.1] If the strategy does not include all aspects above, the indicator BP1 must not be rated F.

老杨解读：如果策略中没有包括上述的各点，则BP1的打分不能是F。

[SUP.10.RL.2] If the strategy does not address interfaces between multisite organizations/projects, subprojects, and/or groups in case of correspondingly complex projects, the indicator BP1 must not be rated higher than P.

老杨解读：如果在项目结构相对复杂的场景下，策略中没有处理处于不同地点的组织/项目、子项目和/或组之间的接口，则BP1的打分不能高于P。

[SUP.10.RC.1] If the strategy does not include goals according to e) above, the indicator BP1 should be downrated.

老杨解读：如果策略中没有包括活动的目标（上述的e），则应降低BP1的打分。

[SUP.10.RC.2] If change request handling is actually different over project life cycle phases but not consistent with the defined strategy, the indicator BP1 should be downrated.

老杨解读：如果在项目的不同阶段，变更请求的处理是不同的，但与已定义的策略不一致，则应减低BP1的打分。

[SUP.10.RC.3] If the use of a strategy is obvious by the implementation in a tool but not explicitly documented this should not be used to downrate the indicator BP1 to N or P.

老杨解读：如果是使用工具来处理变更请求，但没有明确的文档化的策略，不能基于此来降低BP1的打分至N或P。

(2) 变更请求的批准

<ASPICE模型要求>

SUP.10.BP5: 变更实施前获得批准 / Approve change requests before implementation

基于分析结果和资源可用性，对变更请求进行优先级排序，并根据策略批准

Change requests are prioritized based on analysis results and availability of resources before implementation and approved according to the strategy.

通常由CCB(Change Control Board)来批准变更请求，CCB是由变更请求影响的所有相关方的代表组成，并具有批准的授权。

[SUP.10.RL.3] If not all relevant disciplines or stakeholders are represented in the actual CCB the indicator BP5 must not be rated F.

老杨解读：如果CCB中没有包括所有相关的学科或相关方，则BP5的打分不能为F。

[SUP.10.RC.4] If it is apparent that decisions are not taken or not taken in time by the CCB without justification, the indicator BP5 should be downrated.

老杨解读：如果CCB没有及时对变更请求做决定，并缺少正当理由，则应减低BP5的打分。

(3) 影响分析和变更确认

<ASPICE模型要求>

SUP.10.BP4: 分析和评估变更请求 / Analyze and assess change requests

根据策略，分析变更请求，包括它们对受影响的工作产品和其它变更请求的依赖。评估变更请求的影响，并建立确认实施的标准。

SUP.10.BP6: 评审变更请求的实现 / Review the implementation of change requests

变更请求在关闭前进行评审，以确保满足已定义的确认标准，并已应用所有相关过程。

[SUP.10.RL.4] If the analysis does not adequately address potential side effects due to specific risks and complexity of the potential changes the indicator BP4 must not be rated F.

老杨解读：如果不能对由于特定风险和潜在变化的复杂性而产生的潜在副作用进行分析，则BP4的打分不能为F。

[SUP.10.RC.5] If the technical content of the change request or in case of alterntives the decision for one alternative is not properly documented the indicator BP4 should be downrated.

老杨解读：如果没有正确记录变更请求的技术内容或备选方案的决策，则应降低BP4的打分。

[SUP.10.RL.5] If the review of implemented changes fails to detect that relevant processes are not applied; the indicator BP6 shall be downrated.

老杨解读：如果对已实施的变更的评审未能检测到相关过程未被应用，则应降低BP6的打分。

[SUP.10.RC.6] If the confirmation of a successful implementation of change requests is not based on documented criteria the indicator BP6 should be downrated.

老杨解读：如果对成功执行变更请求的确认不以文档化的准则为依据，则应降低BP6的打分。

(4) 变更请求的状态模型和工作流

<ASPICE模型要求>

SUP.10.BP3:记录变更请求的状态 / Record the status of change requests

状态模型的状态被分配给每个变更请求以便于跟踪

SUP.10.BP7: 跟踪变更请求至关闭 / Track change requests to closure

跟踪变更请求至关闭，并给变更发起者提供反馈。

[SUP.10.RL.6] If the strategy does not include the definition of a status model, workflow, criteria for status changes, stakeholders and their authorization, the indicator BP1 shall be downrated.

老杨解读：如果策略中没有包括状态模型的定义、工作流、状态迁移条件、相关方及其授权，则应降低BP1的打分。

[SUP.10.RL.7] If the status model and workflow does not fit to the actual way of working or is not applied correspondingly, the indicator BP3 must not be rated higher than P.

老杨解读：如果状态模型及工作流没有被恰当的应用或与实际不符，则BP3的打分不能高于P。

[SUP.10.RC.7] If closed CRs do not reflect a final state, the indicator BP7 should be downrated.

老杨解读：如果已关闭的变更请求不能反映出最终状态，则应降低BP7的打分。

示例场景：状态模型中定义了“已解决(Solved)”和“已关闭(Closed)”两个状态。但实际项目中无法进入“已关闭(Closed)”状态

ASPICE详细介绍-1.什么是ASPICE？

什么是ASPICE？

ASPICE全称是“Automotive Software Process Improvement and Capacity dEtermination”，即汽车软件过程改进及能力评定，简称A-SPICE或ASPICE。

属于过程模型，由过程和能力度两个维度构成，用于评价汽车行业软件设计开发团队的能力水平，改善车载软件质量

过程模型

CMMI介绍

ASPICE标准是建立在能力成熟度模型（Capability Maturity Model：CMM）的基础上，设计初是用于审核投标厂商资格的理论模型，后来被应用于软件流程改善和软件研发团队能力评价。

CMM:1986年卡耐基-梅隆大学(CMU)下属的软件工程研究所(SEI)

SEI正式发布CMM后，陆续又开发出了系统工程、软件采购、人力资源管理、整合产品和过程开发方面等多个能力成熟度模型。其中开发模型（Development Model）可用于指导产品开发，简称为CMMI-DEV，共有22个过程域，细分为过程管理、项目管理、工程和支持四大类。
1994年，SEI整合了不同专业领域的CMM，推出了能力成熟度模型集成（Capability Maturity Model Integrated：CMMI），不仅仅局限于软件开发成熟度。

采用IDEAL模型来进行过程改进：通过不断的分析差距、建立计划、实施行动、总结经验，来取得提升。

A-SPICE介绍

1994年，由国际标准化组织（International Organization for Standardization：ISO）、国际电工委员会（International Electrotechnical Commission：IEC）和信息技术委员会JTC1联合制定并发布了国际标准ISO15504，又称SPICE( Software Process Improvement and Capability dEtermination)，这个标准专为软件公司设计，旨在改进软件开发过程及评估公司应用的流程的有效性。
基于SPICE ，各产业/领域亦发展出各自的标准：
1）汽车产业：Automotive SPICE
2）医疗设备产业：Medi SPICE
3）航空产业：SPICE 4 Space (S4S)
4）测试：Test SPICE
5）企业：Enterprise SPICE

2005年汽车行业的SPICE：Automotive SPICE从ISO15504体系中独立出来，由欧洲德国汽车工业联合会(Verband Der Automobilindustrie：VDA)的品质管理中心(Quality management center：QMC)运营发展，发布了ASPICE第一个版本：ASPICE v2.0。该标准是“面向汽车行业的流程评估模型”，目的是为了改善汽车电子控制单元（ECU）软件的质量。

在2010年，ASPICE改版成v2.5；在v2.5版中，有两份文件：PRM（Process Reference Model）和PAM（Process Assessment Model）。

过程参考模型可以看作过程评估模型的一个维度
过程评估模型是一个二维框架，X轴是过程参考模型里的一堆过程（Process），Y轴是度量框架里的过程属性（PA）

在2015年，ASPICE再次进行了改版，在原有文件的结构做了如下修订：
1）PRM和PAM两者进行了合二为一

2）文内的BP增加了细节的说明
3）consistency和traceability从一个基础实践(BP)拆成两个基础实践(BP)
4）将工程流程(ENG)拆分为系统工程流程(SYS)和软件工程流程(SWE)
5）对原有的ENG.5和ENG.6 拆分成SWE.2, SWE.3, SWE.4

在2017年时VDA QMC又发布了ASPICE V3.1版本。V3.1是在V3.0的基础上做了一些勘误和微小的改动(大多数集中在文字部分的变更)并将“HIS SCOPE（HIS是AudiAG，由BMW, DaimlerChrysler，Porsche和Volkswagen成立的制定软件开发规则的组织，2016年解散）”正式改名为了“VDA SCOPE”。

ASPICE官网：https://www.automotivespice.com/download/
可以下载最新的英、日、韩、中版本ASPICE文档！

---

总结

早期，车厂需求文件中提到软件流程认证可以选用CMMI或ASPICE，CMMI评估师也可以直接获得ASPICE审核员资格。但是随着车用软件的发展与ASPICE标准的改版，ASPICE与CMMI现在已经彻底分开。
ASPICE的评估严格来说并不是“认证”，其实ASPICE的评估结果应该是评估报告，而不是证书。它只是表明项目评估范围内的过程具备的能力度等级。目前行业内流行的ASPICE证书只是作为评估通过的一个附加证明，是为了便于企业商务市场宣传应用而生的一个产物而已。