符合CMMI标准的组织如何有效地采用ASPICE

　　作者：Vaibhav Anand，Shilpa Banerjee

　　基于丰富的汽车经验的精心设计的流程造就了可靠、符合客户要求并符合所需标准的产品。作为流程标准，CMMI 和 ASPICE 都确保您的组织能够建立一个流程模型，从而能够开发高质量的汽车软件。

　　然而，ASPICE是一个专门为汽车软件开发而设计的过程，因此增强了CMMI的优势。此外，ASPICE还与大多数汽车组织现在采用的ISO 26262标准共享一些工件。

　　尽管ASPICE已经存在了相当长的一段时间，但只有在汽车软件的主导地位大幅增加之后，它才获得了整个行业的认可。主要从事汽车嵌入式解决方案的组织也开始了解其重要性和相关性。许多早期符合CMMI 2.0或3.0标准的组织开始过渡到ASPICE。虽然这两个CMMI都提供了有关如何开发可靠软件的通用指南，但ASPICE深入研究得更深入一些。此外，CMMI合规性展示了整个组织的成熟度和能力，但ASPICE是特定于项目的。为建立一个项目的 ASPICE 合规性而执行的活动不能重用于另一个项目。下一节将更详细地讨论CMMI和ASPICE之间的差异。

　　ASPICE与CMMI有何不同？

　　如前所述，ASPICE对于符合CMMI标准的汽车组织来说是一个自然的过程。为了启动这一进展，利益相关者必须意识到两者之间的差异，以便他们做出明智的决定。

　　ASPICE 3.1CMMI 2.0

　　ASPICE更关注与V模型开发相关的实践。软件开发、系统工程、项目管理、质量保证和配置管理属于 ASPICE 的职权范围。

　　CMMI更详细地阐述了项目管理（PMC，PP）和组织层面的实践。但是，工程过程的详细说明较少。

　　重点介绍软件、硬件、机械部件如何互联（插件）、各模块之间的接口设计等。无法针对 CMMI 2.0 映射系统工程实践

　　在过程领域方面，一长串工件/工作产品，如质量保证计划、软件需求分析中的验证标准、系统需求分析等，在ASPICE中是强制性的。对于CMMI 2.0，与ASPICE相比，系统需求分析，系统架构设计工作产品，系统集成测试等不是强制性的。

　　对于任何符合ASPICE的项目，专用的QA资源都是强制性的，差距评估也是如此。这两个方面对于 CMMI 2.0 来说都不是强制性的

　　尽管CMMI和ASPICE之间存在这些差异，但仍有一些重叠必须利用，以使向APSICE的过渡更顺畅，更快。

　　从 CMMI 2.0 和 ASPICE 3.1 迁移的业务案例

　　CMMI 2.0 Level 3 或 Level 5 成熟组织在 ASPICE 3.1 方面仍可能存在差距。因此，应该有一个商业案例来为符合CMMI的组织采用ASPICE。要问的问题是，它是否会使组织受益，质量管理体系是否真的需要，我们是否有来自客户或项目类型的此类需求？在当今的汽车生态系统中，无论是欧洲、亚洲还是美国市场，ASPICE 已成为标准的业务需求，并可能成为交易的破坏者。

　　指定在ASPICE中要实现的目标能力水平非常重要，因为行动计划，差距分析，纠正和改进措施取决于它。ASPICE L3 就是要拥有完善的 QMS（质量管理体系），可以支持在项目中部署符合 ASPICE 标准的制度化程序、指南和模板。组织可以以能力级别 2 为目标，作为第一步，然后以 CL3 为目标。此外，如果团队有信心，直接瞄准 CL3 也没有坏处。通俗地说，ASPICE 3.1中的CL2是项目管理，验证，配置管理和质量保证的组合。在CL3，必须遵守质量管理体系的定义、程序、指南和模板。此外，必须评估整个质量管理体系的资产、工件和能力，以便它可以对所有适用的项目发号施令——需要做什么，怎么做。

　　执行差距分析 - CMMI 到 ASPICE

　　一旦确定了这种需求，建议在组织级别进行深入的差距分析，即过程定义，过程改进和指南，以在项目中实施过程，然后在项目级别，如何在项目范围内使用和实施组织定义的实践。

　　差距分析基本上评估可用的设计质量管理体系、资源、政策、手册、指南、模板、实施的实践和工作产品。纠正过程和改进措施由关键利益相关者（首席评估员、共同评估员、组织的高级管理层、质量主管、质量团队）根据优先事项、责任和活动顺序决定，这些活动应有效和高效地缩小差距。

　　ASPICE最初是由欧盟资助的一个项目，是作为CMMI的对应物创建的（多年来不断发展，采用多个ISO标准）。因此，人们可以观察到两个框架的术语、概念和实践之间的某种直接和间接映射。类似的概念，如CMMI 2.0中每个“实践领域”中的“意图”，可以映射到ASPICE 3.1中为每个流程标识的“过程目的”。CMMI 2.0中的“示例或示例活动和工作产品”对应于ASPICE中的“输出工作产品和工作产品特征”。在这两个框架中都可以找到非常相似的做法，即两个框架都从软件需求中寻找上游可追溯性。这两个框架都要求评估设计和相关决策，以确定纠正过程。此纠正课程基于阻碍实现目标或指标的根本原因。

　　为了在CMMI 2.0（甚至1.3）中通过各种适用流程实现ASPICE 3.1能力水平，几乎所有流程都需要改进，人力资源也需要培训。培训必须涵盖ASPICE的结构，概念和原则。此外，需要修复、审查和批准已确定的差距。必须确保ASPICE评估或差距修复的结果对组织的CMMI评级没有影响。在弥补差距时，应牢记两个框架方面，并应建立中间立场，以避免冗余和不必要的努力和资源。

　　从CMMI迁移到ASPICE的可能方法

　　一个渴望采用ASPICE的CMMI合规组织，通常首先通过CMMI驱动的流程展示ASPICE合规实践。它必须统一流程和实践，两全其美应纳入组织的质量管理体系。任何过程改进都必须从CMMI和ASPICE的眼睛中可视化。当然，组织将面临许多特定的挑战，必须通过专门的方法和程序来缓解这些挑战。

　　完成广泛的映射和隔离后，组织可以在从CMMI过渡到ASPICE时达成基本的经验规则。例如，QA在ASPICE合规项目中的参与程度大大高于CMMI项目。对于符合ASPICE的项目，实现可追溯性和一致性的粒度所需的精力和时间更高。此外，ASPICE项目团队和质量团队所需的培训和指导量在本质上是相当广泛的。这些指针无疑有助于更好地规划和执行项目，这直接帮助我们更快地实现所有相关流程的预期能力水平。

　　审核编辑：郭婷