ASPICE是一个框架wHICH起源于软件开发，后来被汽车工业所采用。这个名字是一个缩写词
在汽车工业引入SPICE模型时，很明显，描述软件开发的过程框架不足以开发汽车产品，因此添加了几个检查系统工程活动的基本实践，并产生了ASPICE通过几个过程领域，A-SPICE描述了预期将在汽车产品开发公司上实施什么样的基础和通用实践。
许多人认为A-SPICE只关心与产品开发相关的过程，但在现实中它也关心开发产品的所有支持功能，例如适当的资源管理、具有适当技能的人员来执行工作、供应商管理、质量和监控、持续的过程改进等等。
汽车行业的大多数工程师都知道A-SPICE这个名字，但是，他们并不熟悉框架中描述的过程领域，因为他们并不能直接看到它。这实际上是很好的，只要一个良好的A香料符合程序在公司到位。任何A-香料培训通常都会提到，A-SPICE需要根据公司的具体需求进行适当的定制，而不应该是流程领域和基于A-SPICE的基础实践与实际公司流程之间的1比1映射。
如果一个流程被很好地定义，并根据特定公司的具体需求进行了适当的定制，那么通过遵循这个过程，该公司的人员就能够开发出一个好的产品，而无需额外的额外努力，并且符合A-香料标准。
当评审员来到一个组织对一个项目进行A-香料评估时(称为3级评估)。评审员寻找证据，以证明公司所定义的正式程序正在被遵循，并且这种过程符合A-SPICE框架。
在评估期间，对每个过程领域进行审查，以确定其成熟度。然后，这种成熟度反映在过程属性上给定的能力级别上。一旦评估了所有的过程属性，我们就可以得到整体的能力水平。
A-SPICE有5个能力级别来确定过程的成熟度：
级别0-不完整：这是没有应用进程的起点。
第1级--执行：流程在那里，并为其目的服务。这是人们所知道的，即使没有完全标准化。
第2级- 管理：该过程是遵循的，它是众所周知的所有团队成员。它有很好的控制和维护。
第3级-建立：该过程在组织中得到遵循和标准化。基于标准的实践在组织中的使用是众所周知的。
第4级-可预测：该过程在其范围内是可预测的。变异率很低
第5级-创新：过程不断改进，以达到组织目标。
直白的理解：
Level 0:企业不知道怎么做，做不出来或做出来的产品不完整。
Level 1:企业能做出该产品，但尚未总结出该产品的一些开发经验、设计规范、管理规范。由于缺少这些设计规范、管理规范的指导，每次开发完成的产品可能过程差异较大。（代表企业已经能够完成产品研发相关的工作。但缺乏管理。虽然偶尔能够成功，但项目中存在大量不确定的因素，对项目缺乏掌控能力，无法确保一定能够按时交付高质量的产品。）
Level 2:企业可以通过项目管理方式来管理整个项目的开发。包含制定项目计划、项目开发监控、调整与管理、项目交付管理等。但该管理活动只适用某个项目，在其他项目上，这些管理方法和过程可能不适用。（代表企业不仅能够完成产品研发相关工作，还能有提前制定严谨和周全的项目计划，并能有效根据计划实施项目的监控、调整和管理，确保项目有序进行。）
Level 3:公司已经积累相关开发与管理经验，知道如何管理各类项目的开发过程。各个过程域的担当只需要按公司过程规范来裁剪，并执行相关过程即可完成项目的开发，确保项目的开发品质。（代表不仅各项目能够管理得很好，而且能够有效的从历史项目中积累经验和教训，形成公司的知识资产和标准工作流程，用于对今后项目的参考和指导以及公司管理的持续改善。）
Level 4:企业关于开发的过程与管理已经稳定，开始收集对应各过程对应的数据。通过对过程和结果数据的分析、统计与回归计算，来预测过程的结果。并可根据预测的结果，对项目开发过程进行实时调整。（引入统计学知识和技术，对项目相关各项数据进行统计和分析，并将之运用于未来的项目管理之中，达到对项目结果的预测，并根据预测结果对项目进行实时的调整，确保达成项目目标。）
Level 5:企业可以根据本身的商业目标需求，来反向调整过程相关因素，持续改善过程。（代表企业能够基于商业目标的需要，主动的对过程进行调整，对变革管理有很强的管理能力，能够基于对过程的量化分析设定明确有效的过程改进目标，并能对过程改进结果进行有效的量化监控和分析。）
Aspice 的过程组包含了供应商过程组，系统过程组，软件过程组，支持过程组，管理过程组，过程改进过程组，重用过程组。下面着重介绍系统过程组，软件过程组这两个与开发人员强相关的部分。
01 “V”字模型的示意
先来看看过程组。因为所有工程（即：系统工程和软件工程）过程的组织似于”V“字，因此常在人们口中为V模型。左边的过程与右边的过程正好对应，但需要知道的是，过程“SWE.3软件详细设计与单元构建”与“SWE.4软件单元验证”是独立和分离的。
V模式很好的诠释了我们项目开发过程中几个重要的工作过程与工作内容。
02 追溯性和一致性
ASPICE重要之一的就是需要具备双向追溯性和一致性。追溯性着重工作产品之间存在引用和链接，进一步支持覆盖率，影响分析，需求实施，状态跟踪等。相反，一致性关注内容和定义。
双向追溯性更多被定义为在测试用例与测试结果之间，往往漏掉测试用例与软件需求之间的双向追溯性。
上图可知我们需要具备双向追溯性的有：系统需求与软件需求；软件需求与软件单元测试；软件详细设计与软件单元测试等等，可见图蓝色部分。
双向可追溯性和一致性是ASPICE特别在意的点。但这种可追溯性和一致性在项目的实操过程中，审查员一般只能以抽查的方式检测。特别是一致性，工具是很难检查出来。
因此ASPICE要求，需求文档需要被验证，且需要有具体标准定义。设计文档需要被评估，且评估准则可包括质量特性如模块化、可靠性、安全性（security）和可用性等。
需要注意的是，软件集成测试的依赖对象主要是软件架构设计； 软件集成测试主要是根据软件架构的接口设计以及接口之间的数据时序，数据流向，测试一个子系统内部各个接口之间的数据输入/传输/输出是否正确。详细内容介绍可见我这边文章：浅聊集成测试。
03 ASPICE各过程的详细内容介绍
SYS1 系统需求（筛选审核）
其中包含了硬件/软件/结构等所有的客户需求。
主要输出：系统需求Feature清单/系统需求功能规范
SYS2 系统需求分析
此过程进行需求的分析，划分哪部分是属于软件任务，那部分是属于硬件任务或者是结构设计相关的任务。分析需求是否具备可实现性等，为后续的架构设计做铺垫。
主要输出：系统需求Feature清单/系统需求功能规范
SYS3 系统架构设计
建立系统架构设计，识别哪些系统需求被分派到哪些系统元素中，并按已定义的标准评估系统架构设计。是软件架构设计的依赖对象，必须现有系统架构设计再有软件架构设计。定义了软件的详细设计，描述了软件单元，每个软件单元及其接口。
主要输出：系统架构设计说明文档
SYS4 系统集成和集成测试
根据系统需求以及系统架构设计进行系统集成测试用例的编写，然后进行系统集成测试。属于白盒测试。
主要输出：系统集成测试用例/系统测试计划/系统集成测试报告
SWE1 软件需求分析
根据筛选后的系统需求进行软件部分的需求分析。
主要输出：软件需求Feature清单
SWE2 软件架构设计
目的是建立软件架构设计，是被每条软件按需求被分配到哪个软件元素中，并按照已定义的标准评估软件架构设计
主要输出：软件架构设计说明文档
SWE3 软件详细设计与单元构建
目的是为软件单元提供一个已评估的详细设计以实现软件单元
主要输出：软件详细设计说明文档
SWE5 软件集成与集成测试
制定了系统集成策略，制定包括回归测试在内的集成测试策略，形成测试计划；选择测试用例，形成集成测试规范中的测试用例；然后进行进行测试并形成系统集成测试结果
主要输出：软件集成测试计划/软件集成测试用例/软件集成测试报告
SWE6 软件合格性测试输出
制定包括回归测试策略在内的软件合格性测试策略；开发软件合格性测试规范；然后选择测试用例；测试集成软件；总结和沟通结果：总结软件合格性测试结果
主要输出：软件合格性测试报告
04 总结
一，ASPICE流程的利弊
ASPICE是为了规范我们代码开发流程，同时提高我们的代码质量，严格做到在开发前有明确的开发方案，明确的开发流程，任何代码的设计都有靠谱的依据来源，是我们代码质量的保证。
简单来讲，就是在保证代码质量的情况下，按时完成我们的项目目标。如果仅仅是为了完成项目目标，而对于我们完成的交付物不做最后的“估值”，那我认为我们完成的这个任务没有任何的意义，因为它不被人们满意的接受。而完成这最后的“估值”就需要我们输出的那些文档作为支撑，我们通过这个文档以及测试结果来进行验收，来判断设计，开发是否符合客户的需求，是否满足于最初的项目目标。
作为项目管理者来讲，我们更喜欢这个文档按照标准输出，他更像我们与开发者之前沟通的桥梁，通过这些文档，我们能知道开发者更加详细的设计方案与想法。在沟通中会少了很多前期的沟通成本。
可能针对开发人员来说，遵顼这个流程的最大挑战就是文档的输出，严格按照标准的ASPICE来进行项目开发，我们需要从上至下按照V模型进行。即：先完成系统需求，系统架构设计，再完成软件需求，软件架构，软件详细设计，最后才是代码开发和测试，而现实中的很多项目因为时间关系代码开发和文档编写都是并行，这是不符合ASPICE的要求的，并没有很好的发挥ASPICE的优点来把控我们的代码质量。
而如果严格按照这个流程来执行，在开发端的时间将会延长至少一倍，对我们的人力成本也是一个很大的挑战。ASPICE要求的设计文档都需要相关的开发人员进行输出，用程序员的话来讲：写这些文档的时间比码代码的时间更长，写一个功能的开发文档，我可以完成至少3个同等功能的开发。
二，ASPICE流程规范，是否需要裁剪？
虽然ASPICE在我们项目开发过程中具有很好的指导作用，但是否我们需要完全“死板”遵循。前面已经提到，我们的ASPICE流程虽然好，但是需要的时间长，人工成本高，针对任务重且周期短的项目是不友好的。因此，这个问题我的答案是：根据项目实际情况进行裁剪。
在项目开发中，我们常常会参与或者组织项目阶段总结会。之前小鹿组织的一个项目总结会中，很多工程师常常对项目的任务的优先级有很大的疑惑：是先完成文档设计工作还是先完成代码交付工作？这种疑惑常发生在生命周期短的项目，工程师常常同时被催促输出文档以及代码。标准的回答是：按照开发流程，是先完成文档设计，再做代码开发，但是由于我们的时间紧张，因此他们同步进行。在会上，我们达成的统一目标就是：充分使用，合理安排，在满足客户的需求下，对文档的要求进行适当的裁剪，在此条件之前，按时按质的完成项目目标。
裁剪仅仅是为了将有限的时间安排在重要的事项中。针对生命周期长的项目，可严格遵循；针对生命周期短且任务重的项目，可做适当的裁剪 ，裁剪掉相对不重要的过程以及流程，或者做并行处理。当然根据实际情况实际评估。
扫一扫
638
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
