aspice软件开发流程（工作笔记：模型，标准，方法论）

本文目录

• 工作笔记：模型，标准，方法论
• aspice是什么意思啊
• ASPICE VDA Guideline解读（18）：SUP.10 变更请求管理

工作笔记：模型，标准，方法论

在实际工作中，我们经常会遇到这样的问题：与设计开发相关的模型、标准、方法有那么多，选择哪一个呢？或者在汽车嵌入式软件开发时，我们希望应用Automotive SPICE，也希望使用Agile（Agile的好处很诱人：轻量化、快速响应、拥抱变化等），那么如何解决Automotive SPICE和Agile的冲突呢？
过程模型或能力度模型（如：CMMI, Automotive SPICE）：是明确定义“需要做什么(What)”以及“做的目的(Why)”。
标准：满足某种条件情况下必须要满足的要求，比如当车载E/E系统是与功能安全相关时，则适用于ISO26262标准，其中就有比如“单元测试覆盖度”的要求。
方法论：是在特定场景下应用的特定方法，比如在开发车载嵌入式软件时，其应用层软件可以采用基于模型开发（MBD）的方法。
如上图所示：

过程模型或能力度模型定义的是“What”和“Why”，比如：需要射中靶心

方法论是采取的具体方式，是“How”，比如：

1）在旅游的时候（左图），我们可以用那样一种弓箭来射中靶心；

2）在正式比赛时（右图），我们需要用专业弓箭来射中靶心
我们能把处于“What”层面的过程模型或能力度模型与处于“How”层面的方法论进行比较吗？
1）模型：人需要穿衣服(what)，以保暖(Why)
2/3）在冬季沈阳（场景），穿一件羽绒服（方法）

4）通过”Why”来衡量解决方案（How）的有效性：在冬季的沈阳，穿羽绒服可以达到保暖的目的吗？
举个Automotive SPICE中的具体例子：
1）ASPICE MAN.3 BP10：评审和报告项目进展（What：评审和报告；Why：监控项目进展）

2/3）需求稳定明确时（场景），采用传统开发方法，进行周监控和里程碑监控（方法）

4）通过”Why”来衡量解决方案（How）的有效性：在需求稳定明确的场合，采用传统开发方法用周监控和里程碑监控的方式，可否达到监控项目进展的目的呢？
继续上一个例子：
1）ASPICE MAN.3 BP10：评审和报告项目进展（What：评审和报告；Why：监控项目进展）

2/3）需求不稳定不明确时（场景），采用Scrum方式：每日站例会、Sprint评审会议和Sprint回顾会议方式（方法）

4）通过”Why”来衡量解决方案（How）的有效性：在需求不稳定不明确的场合，采用Scrum的每日站例会、Sprint评审会议和Sprint回顾会议方式，可否达到监控项目进展的目的呢？
经常有人问我如下的类似问题：
比如1：为了满足ASPICE要求，在使用Scrum方法时，是否需要开周会，形成周会议记录？

ASPICE有要求要开周会吗？
比如2：为了满足ASPICE要求，在基于模型开发时，在Matlab/Simulink中的模型设计内容需要拷贝到Word中，形成一份Word版本的详细设计吗？

ASPICE有要求Word版本的详细设计吗？
提出这样的问题，是将模型在某场景下应用的方法论，当成了模型的要求。

aspice是什么意思啊

aspice的意思是：汽车行业软件过程改进与能力评定的过程评估模型。

ASPICE是Automotive SPICE的简称，即汽车行业软件过程改进与能力评定的过程评估模型。

ASPICE包括32个过程，三个生命周期过程，主要是生命周期过程，组织生命周期过程，支持生命周期过程，进一步可以细分为需求获取组、供应管理组系统组、软件组、支持组、管理组、过程改进组等。

过程评估模型：使用过程评估模型来确定过程能力的概念，在APICE是基于如下图的二维框架。第一个维度是由过程参考模型定义的过程来提供，即满足参考模型要求以及参考模型指定成果要求；第二个维度是由过程属性的能力等级所构成。

过程参考模型：指的是按照一定的过程类别分组，针对每个过程，描述其目的，获得其结果清单等。

aspice的能力成熟度的划分：

ASPICE根据企业管理的情况，将企业的软件研发能力划分为6个级别，0级为最低级，5级为最高级。

0级：代表一种混乱的状态。

1级：代表企业已经能够完成产品研发相关的工作，但缺乏管理，虽然偶尔能够成功，但项目中存在大量不确定的因素，对项目缺乏掌控能力，无法确保一定能够按时交付高质量的产品。

2级：代表企业不仅能够完成产品研发相关工作还能有提前制定严谨和周全的工作计划，并能有效根据计划实施项目监控和管理，各项目能够有序进行。

3级：代表不仅各项目能够管理得很好，而且能够有效的从历史项目中积累经验和教训，形成公司的知识资产和标准工作流程，用于对今后项目的参考和指导以及公司管理的持续改善。

4级：引入统计学知识和技术，对项目相关各项数据进行统计和分析，并将之运用于未来的项目管理之中，达到对项目结果的预测，并根据预测结果对项目进行实时的调整，确保达成项目目标。

5级：代表企业能够基于商业目标的需要，主动的对过程进行调整，对变革管理有很强的管理能力，能够基于对过程的量化分析设定明确有效的过程改进目标，并能对过程改进结果进行有效的量化监控和分析。

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

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需定义确保"变更请求"与"变更请求影响的工作产品及基线"之间的双向追溯性的机制
If the strategy does not include all aspects above, the indicator BP1 must not be rated F.
老杨解读：如果策略中没有包括上述的各点，则BP1的打分不能是F。
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。
If the strategy does not include goals according to e) above, the indicator BP1 should be downrated.
老杨解读：如果策略中没有包括活动的目标（上述的e），则应降低BP1的打分。
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的打分。
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是由变更请求影响的所有相关方的代表组成，并具有批准的授权。
If not all relevant disciplines or stakeholders are represented in the actual CCB the indicator BP5 must not be rated F.

老杨解读：如果CCB中没有包括所有相关的学科或相关方，则BP5的打分不能为F。
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

变更请求在关闭前进行评审，以确保满足已定义的确认标准，并已应用所有相关过程。
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。
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的打分。
If the review of implemented changes fails to detect that relevant processes are not applied; the indicator BP6 shall be downrated.

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

跟踪变更请求至关闭，并给变更发起者提供反馈。
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的打分。
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。
If closed CRs do not reflect a final state, the indicator BP7 should be downrated.

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

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