Aspice（Automotive SPICE） 中文翻译为汽车软件过程改进及能力评定。是为保证软件质量的规范，要求供应商按照Automotive SPICE的要求进行产品的设计与开发。是汽车行业中常用于质量管理的工具。
Aspice 的过程组包含了供应商过程组，系统过程组，软件过程组，支持过程组，管理过程组，过程改进过程组，重用过程组。此篇文章着重介绍系统过程组，软件过程组这两个与开发人员强相关的部分。

01 “V”字模型的示意
先来看看过程组。因为所有工程（即：系统工程和软件工程）过程的组织似于”V“字，因此常在人们口中为V模型。左边的过程与右边的过程正好对应，但需要知道的是，过程“SWE.3软件详细设计与单元构建”与“SWE.4软件单元验证”是独立和分离的。
V模式很好的诠释了我们项目开发过程中几个重要的工作过程与工作内容。
图1 “V”字模型示意图

02 追溯性和一致性
ASPICE重要之一的就是需要具备双向追溯性和一致性。追溯性着重工作产品之间存在引用和链接，进一步支持覆盖率，影响分析，需求实施，状态跟踪等。相反，一致性关注内容和定义。

图2 双向可追溯性和一致性示意图双向追溯性更多被定义为在测试用例与测试结果之间，往往漏掉测试用例与软件需求之间的双向追溯性。
图2 可知我们需要具备双向追溯性的有：系统需求与软件需求；软件需求与软件单元测试；软件详细设计与软件单元测试等等，可见图蓝色部分。
需要注意的是，软件集成测试的依赖对象主要是软件架构设计； 软件集成测试主要是根据软件架构的接口设计以及接口之间的数据时序，数据流向，测试一个子系统内部各个接口之间的数据输入/传输/输出是否正确。详细内容介绍可见我这边文章：浅聊集成测试。

03 ASPICE各过程的详细内容介绍

• SYS1 系统需求（筛选审核）

1. 其中包含了硬件/软件/结构等所有的客户需求。

2. 主要输出：系统需求Feature清单/系统需求功能规范

• SYS2 系统需求分析

1. 此过程进行需求的分析，划分哪部分是属于软件任务，那部分是属于硬件任务或者是结构设计相关的任务。分析需求是否具备可实现性等，为后续的架构设计做铺垫。

2. 主要输出：系统需求Feature清单/系统需求功能规范

• SYS3 系统架构设计

1. 建立系统架构设计，识别哪些系统需求被分派到哪些系统元素中，并按已定义的标准评估系统架构设计。是软件架构设计的依赖对象，必须现有系统架构设计再有软件架构设计。定义了软件的详细设计，描述了软件单元，每个软件单元及其接口。

2. 主要输出：系统架构设计说明文档

• SYS4 系统集成和集成测试

1. 根据系统需求以及系统架构设计进行系统集成测试用例的编写，然后进行系统集成测试。属于白盒测试。

2. 主要输出：系统集成测试用例/系统测试计划/系统集成测试报告

• SWE1 软件需求分析

1. 根据筛选后的系统需求进行软件部分的需求分析。

2. 主要输出：软件需求Feature清单

• SWE2 软件架构设计

1. 目的是建立软件架构设计，是被每条软件按需求被分配到哪个软件元素中，并按照已定义的标准评估软件架构设计

2. 主要输出：软件架构设计说明文档

• SWE3 软件详细设计与单元构建

1. 目的是为软件单元提供一个已评估的详细设计以实现软件单元

2. 主要输出：软件详细设计说明文档

• SWE5 软件集成与集成测试

1. 制定了系统集成策略，制定包括回归测试在内的集成测试策略，形成测试计划；选择测试用例，形成集成测试规范中的测试用例；然后进行进行测试并形成系统集成测试结果

2. 主要输出：软件集成测试计划/软件集成测试用例/软件集成测试报告

• SWE6 软件合格性测试输出

1. 制定包括回归测试策略在内的软件合格性测试策略；开发软件合格性测试规范；然后选择测试用例；测试集成软件；总结和沟通结果：总结软件合格性测试结果

2. 主要输出：软件合格性测试报告

   
   

04 总结
一，ASPICE流程的利弊

ASPICE是为了规范我们代码开发流程，同时提高我们的代码质量，严格做到在开发前有明确的开发方案，明确的开发流程，任何代码的设计都有靠谱的依据来源，是我们代码质量的保证。
简单来讲，就是在保证代码质量的情况下，按时完成我们的项目目标。如果仅仅是为了完成项目目标，而对于我们完成的交付物不做最后的“估值”，那我认为我们完成的这个任务没有任何的意义，因为它不被人们满意的接受。而完成这最后的“估值”就需要我们输出的那些文档作为支撑，我们通过这个文档以及测试结果来进行验收，来判断设计，开发是否符合客户的需求，是否满足于最初的项目目标。
作为项目管理者来讲，我们更喜欢这个文档按照标准输出，他更像我们与开发者之前沟通的桥梁，通过这些文档，我们能知道开发者更加详细的设计方案与想法。在沟通中会少了很多前期的沟通成本。
可能针对开发人员来说，遵顼这个流程的最大挑战就是文档的输出，严格按照标准的ASPICE来进行项目开发，我们需要从上至下按照V模型进行。即：先完成系统需求，系统架构设计，再完成软件需求，软件架构，软件详细设计，最后才是代码开发和测试，而现实中的很多项目因为时间关系代码开发和文档编写都是并行，这是不符合ASPICE的要求的，并没有很好的发挥ASPICE的优点来把控我们的代码质量。
而如果严格按照这个流程来执行，在开发端的时间将会延长至少一倍，对我们的人力成本也是一个很大的挑战。ASPICE要求的设计文档都需要相关的开发人员进行输出，用程序员的话来讲：写这些文档的时间比码代码的时间更长，写一个功能的开发文档，我可以完成至少3个同等功能的开发。
二，ASPICE流程规范，是否需要裁剪？

虽然ASPICE在我们项目开发过程中具有很好的指导作用，但是否我们需要完全“死板”遵循。前面已经提到，我们的ASPICE流程虽然好，但是需要的时间长，人工成本高，针对任务重且周期短的项目是不友好的。因此，这个问题我的答案是：根据项目实际情况进行裁剪。
在项目开发中，我们常常会参与或者组织项目阶段总结会。之前小鹿组织的一个项目总结会中，很多工程师常常对项目的任务的优先级有很大的疑惑：是先完成文档设计工作还是先完成代码交付工作？这种疑惑常发生在生命周期短的项目，工程师常常同时被催促输出文档以及代码。标准的回答是：按照开发流程，是先完成文档设计，再做代码开发，但是由于我们的时间紧张，因此他们同步进行。在会上，我们达成的统一目标就是：充分使用，合理安排，在满足客户的需求下，对文档的要求进行适当的裁剪，在此条件之前，按时按质的完成项目目标。
裁剪仅仅是为了将有限的时间安排在重要的事项中。针对生命周期长的项目，可严格遵循；针对生命周期短且任务重的项目，可做适当的裁剪 ，裁剪掉相对不重要的过程以及流程，或者做并行处理。当然根据实际情况实际评估。
小鹿说：ASPICE是我们保证代码质量，优化代码开发流程的工具，它可以指导我们做项目开发，但我们可以根据开发任务做裁剪。实际情况实际分析哦！
以上仅表示个人看法。欢迎大家指点。