如果你已经精通瀑布模型和V型模型，那么是时候向ASPICE的更广阔世界迈出一步了。

ASPICE源自一系列ISO文档，这些文档涉及围绕软件开发建立标准。ASPICE代表Automotive SPICE，SPICE代表Software Process Improvement and Capability dEtermination。SPICE旨在为评估人员提供一个框架，以判断组织的软件开发和交付能力。然后，客户在搜索软件供应商时可以使用评估的分数。这类似于ISO9000、CMMI和其他等等在软件部门的尝试。德国汽车工业协会（VDA，“automotive industry Association”）为其行业量身定制了SPICE，从而产生了ASPICE。

随着使用ASPICE的德国汽车制造商对其供应商的重视，标准也随之蔓延。ASPICE成为许多汽车制造商和供应商判断您的组织使用定义最佳实践的开放标准开发系统和软件的能力的一种方法。如果您的系统和软件开发方式符合ASPICE，并且可以通过证据证明，您的客户可以放心，您知道自己在做什么，从而降低客户选择您作为供应商的风险。

我们现在知道APSICE是从哪里来的；所以让我们深入研究一下！我们将重点关注基于V模型的系统工程过程组（SYS）和软件工程过程组。

ASPICE开发模型从SYS.1需求激发过程开始，在该过程中接收、分析、讨论和理解客户的利益相关者需求。在SYS.2系统需求分析过程中，以客户的利益相关者需求为基础，创建、更新和审查系统需求。在SYS.2后，系统测试是在SYS.5系统鉴定测试过程中开发和链接的，提供有关系统需求的早期反馈。接下来，在SYS.3系统体系结构设计过程中，对系统的体系结构进行设计和记录。系统集成测试是在SYS.4期间并行开发的。该循环在软件中重复。SWE.1开发软件需求，SWE.6开发他们的测试。SWE.2设计软件体系结构，SWE.5进行软件集成测试。在“V”的底部，SWE.3软件详细设计和单元构建过程侧重于软件设计和实际编程的细节，同时为SWE.4软件单元验证过程创建单元测试。当审视整个开发过程时，会出现上一个和下一个过程（以及右边的测试）之间的联系模式。每个链接（上/下、左/右）都提供了为什么会这样或那样的可追溯性，并提供了审查和反馈的机会。

为每个ASPICE过程定义的是一组“基本实践”。遵循和实施基本实践，并提供证据，本质上是一个组织如何显示对ASPICE的遵守。例如，SYS.2系统需求分析过程的第一个基本实践是：

SYS.2.BP1：规定系统要求。使用利益相关者需求和对利益相关者要求的更改来确定系统所需的功能和能力。在系统需求规范中指定功能性和非功能性系统需求。

基本实践涵盖了确保系统及其软件以合理和可追溯的方式开发的基本活动。然而，ASPICE并没有规定如何符合其基本实践。通常使用工具来管理SYS和SWE流程，例如亚远景研发管理平台。