SWE是Software engineering process group的缩写，也就是说它本质上是个功能组。SWE下辖6个过程。在过程评估模型中，过程实施指标包含两个，一个是BP，一个是WP。
BP（Basic Practice）面向活动，讲的是你需要做的事，即这个活动在开发过程中有没有做这几件必要的事？比如你说你去打扫厕所，那你需要擦马桶、擦水龙头、擦花洒、拖地面......总之是个事儿。这个在Automotive SPICE官方文档中对应的是绿区，讲的是How。
WP（Work Product）面向结果，即最终呈现给评审员的材料。你说你把厕所打扫干净了，那你自己记录的Checklist呢？照片呢？总之是可被审查的成果。这个在Automotive SPICE官方文档中属于蓝区的范畴，讲的是What。
我们今儿这篇文章只讨论BP，因为BP的活如果都干了，大多数的WP你手里也就有了。SWE中包含多少个BP呢？一共是4+(5+6+5+3+4+3)+3*6=48个BP。这个计算式子是怎么来的呢？
之前@东晓一家介绍过PDCA管理法（见先决知识点），定策略肯定属于Plan的范畴，建立双向可追溯性和确保一致性则属于Check，沟通与总结测试结果属于Act/Adjust的范畴。剩下的这些BP比如画架构、定接口、写测试用例肯定就算是Do的范畴了。
对于Check和Adjust，我们需要做三件事，即建立双向可追溯性、确保一致性、沟通和总结测试结果。我们发现SWE中的六个过程（Process），每个过程都有这三件事需要做。算下来一共是3*6=18个BP。
对于Plan，我们需要做策略，SWE中有4个策略需要制订，即软件单元验证策略、软件集成策略、软件集成测试策略和软件合格性测试策略。
剩下的26个BP就都是Do了。我们可以采用东晓一家的三字法。这里我有小部分用的不是东晓老师的说法，关于用词每个人都有自己的喜好吧。
现在我们知道了，以前不画架构，不写每个函数具体的流程图，不写开机序列的顺序图，一心想写好代码，直接发给黑盒测试组测试的流程是不正规的，是不符合功能安全的。那遵循软件开发的6个过程，48个基本实践，怎么这么繁琐？第一次执行时有没有重点可寻？是否满足二八原则呢？即能否只把20%的BP做好就能达到80%的效果呢？库乐玛公司（KUGLER MAAG CIE）提供了的Automotive SPICE的免费视频教程，我们看看能否快速地理解Automotive SPICE软件开发6大过程的核心要点。
后台回复：“ECU008获取ASPICE3.1中文版标准！
这个过程可帮助您的组织将系统需求中与软件相关的部分转化为一组软件需求。
为什么我们要用文档来记录软件需求？
通常来说，您已经有了系统需求或客户需求，那为什么还要投入时间和精力来记录其他软件需求呢？在一个项目中，你希望按时、在预算内、以客户要求的质量交付商定过的结果。如果不记录软件需求，可能会忽略掉功能或完全误解客户的期望。这会导致额外的工作、成本和延迟。您还可以忽略对软件的功能或非功能方面至关重要的软件方面。这可能导致错误的开始，甚至是额外的开发周期。
这一过程与SYS的上下游都有紧密的联系，上游即系统需求分析（SYS.2），系统架构设计（SYS.3），下游即软件架构设计（SWE.2）和软件合格性测试（SWE.6）。其他依赖性强的流程是项目管理（MAN.3）和配置管理（SUP.8），例如，因为发布管理和缺陷管理（SUP.9）和变更请求管理（SUP.10）。这里的联系是，测试中发现的缺陷必须得到解决，错误修复和更改请求必须在回归测试中得到解决。
以下是Automotive SPICE®软件需求分析中最重要的三个关键点。
1-1 你需要考虑的不仅仅是客户的要求
文本化记录软件需求的一个重要原因是，你需要考虑的不仅仅是客户的期望。软件必须符合标准、规范和其他增加需求数量的规定。出于文档目的，将系统需求或仅在软件开发的情况下、客户和其他利益相关者的需求映射到反映软件内部视图的软件需求中。软件需求反过来构成了软件合格性测试（SWE.6）和所有下游流程的基础，例如软件架构设计（SWE.2）。
1-2 确保你分析并理解需求的含义
顾名思义，这个过程的另一个面是需求分析。您应分析需求的可行性或风险。这两者紧密相连。如果您不确定某个需求的可行性，则存在固有的风险，因为可能需要时间才能找到解决方案，或者根本没有解决方案。显然，这与我们在项目管理（MAN.3）中必须执行的评估有着密切的联系，尤其是MAN.3 BP5。另一个需要分析的主题是可测试性(testability)。当然，测试人员的支持可以用来确保这一点。通常，测试人员还被要求评审(review)需求。此外，分析应涵盖技术影响。这包括评估需求之间的依赖关系。
我在关于系统需求分析（SYS.2）的视频中加入了一个例子。
最后，分析还应涵盖需求的业务方面。因此，应确定各种要求的实施如何影响成本和时间。现在，你可以说你不能在需求数据库中记录所有这些。请记住，Automotive SPICE®没有说明您应在何处文本记录这些信息。
例如，您可以在需求数据库中介绍分析的第一部分（可行性和风险）、相应和相关变更请求中的技术含义，以及项目管理工具中对成本和进度的影响。
1-3 建立可追溯性和一致性
该过程还要求您确保软件需求、系统需求和系统架构之间的可追溯性。
然而，Automotive SPICE®明确表示不需要冗余。您可以决定是希望跟踪系统需求、系统架构还是两者的组合。这取决于哪种方法以最佳方式支持您的开发，而不是哪种方法对您更容易。
可追溯性可通过DOORS等超链接、Rectify等特定的可追溯性工具、可追溯性矩阵或你们公司工具环境支持的其他可管理方式来建立。
可追溯性的目的是支持以下3项：
——一致性检查，即验证软件需求的完整性和准确性。
——变更请求或缺陷情况下的影响评估。
——报告的执行情况。
这个点的另一部分是确保一致性。
一致性意味着您可以根据系统需求和系统架构分别证明软件需求的完整性和正确性。
这只能通过评审（review）来确定。
如果您跳过此评审，您可能有不完整或错误的软件需求。最糟糕的是，您甚至可能没有注意到软件合格性测试（SWE.6）中的缺陷，因为该测试是根据您的软件需求执行的。如果这些都是错误的，你的测试可能不会显示任何错误的行为。所以，请不要跳过评审这个环节！
这个过程有助于组织搭建和记录软件产品的内部逻辑。
软件架构的目标是什么？期望是既然您已经有了软件需求（SWE.1），这些需求描述了软件应该做什么。软件架构设计的目的是定义如何实现软件需求中记录的功能。简而言之，需求描述了“什么what”，架构则描述了“如何how”。
许多组织和项目在理解如何记录体系结构以及需要哪些元素方面存在问题。
软件架构的三个关键点
——恰当的视图
——接口
——可追溯性
2-1 架构视图
通常，软件架构只包括软件的物理视图、框图等。在如今大多数复杂的项目中，这显然是不够的。当然，您希望对软件进行分层分解，以演示和解释如何在不同组件和子组件中实现功能性和非功能性需求。
其他的视图包括：
——动态视图，
——显示特定功能分解的特定功能视图，
——状态流程图，
——接口等等。
通常，系统越复杂，需要的视图就越多。
由于不同的视图必须保持一致，因此应该使用适当的UML或SysML工具。该工具需要支持一致性检查。
2-2 接口
评估中经常遇到的一个陷阱就是缺乏对接口的详细描述。
评审员希望看到的接口文档的内容包括：
——名称
——类型
——单位
——Resolution
——范围
——默认值
等等。
如果没有这些信息，就不可能在集成测试中对接口进行适当的测试。同样，在适当的UML或SysML工具中描述这些接口才能够支持不同视图之间的一致性。
作为对SYS.2中定义的补充，当前章节从进程间通信机制和总线通信机制的角度考虑了软件组件之间的特定软件接口。
2-3 可追溯性
这个过程还要求您确保软件架构和软件需求之间的可追溯性。
通常情况下，需求和架构之间存在工具造成的不连续，这会使证明可追溯性变得困难。
可追溯性的目的是：
——支持一致性检查，即检查软件需求覆盖范围的完整性和准确性。
——支持变更请求或有缺陷情况下的影响评估。
——支持利益相关者的期望报告，并确定需求是否已在架构中实现。
Automotive SPICE中的软件详细设计和单元构造过程（也称为SWE.3）帮助您的组织为软件组件（SWC）提供经过评估的详细设计，并指定和生产软件单元。
软件详细设计的目标是什么？许多组织和项目在理解如何记录详细设计方面存在问题。那么，在这个过程中你应该管理的三个方面是什么呢？
以下是Automotive SPICE®中软件详细设计的最重要方面。
3-1 细节的层次
通常，组织很难确定详细设计应该有多么具体。一个很好的办法是记住详细设计的目的是什么。它是实现代码和单元测试的基础。尤其是单元验证需要详细描述。在这方面，必须要考虑覆盖范围。
在安全方面，ISO26262中的关键软件可提供指导。在非安全软件中，通常至少需要C0-或声明（statement）覆盖，一些客户要求C1-或分支覆盖。覆盖率目标越高，详细设计所需的细节就越多。如果您有ASIL-B的分类模块，则需要C1覆盖。这意味着您的详细设计应该识别软件的不同分支。
3-2 接口
我在评估中经常遇到的一个陷阱是缺乏对外部和内部接口的详细描述。
接口文档的预期内容包括：
1.名字
2.类型
3.单位
4.resolutions
5.取值范围
6.默认值
如果没有这些信息，就不可能在单元测试中对接口进行适当的测试。
如果外部接口是在架构级别中描述的（SWE.2），并在软件集成测试（SWE.5）中进行测试，那这当然是可以的。
3-3 文档的时间安排
在实现代码之前描述详细设计。通常情况下，详细设计是在事后描述的，也就是在编写代码之后。
为什么这样做是一个问题？单元测试应该检查代码是否满足详细设计。如果在写代码之后再写详细设计，那么单元测试的关键点就丢失了。
现在，你可以说你可能不需要单元测试。关键是，您应该从软件架构而不是代码中派生出软件详细设计。如果这个链条断了，那么文档的内容和所有的测试就会突然变得毫无意义。因此，在开始编写代码之前，必须先编写软件详细设计。
循序渐进地迭代开发软件详细设计和代码并没有什么错。
Automotive SPICE®中软件单元级别的验证过程（简称SWE.4）有助于贵公司证明所实施的软件单元不仅有效，而且满足要求。这些是之前在SWE.3中规定的。
Automotive SPICE®中的软件单元验证过程可帮助贵公司验证软件单元是否以所需的质量实施了详细设计以及相关的功能性和非功能性需求。最终，这一过程为您作为供应商提供了保证。
单元验证，这是一系列后续测试中的第一组测试。
如果不进行单元验证，将产生两个负面后果：
——并不是所有的问题都能保证在之后被发现，因为后续的测试有不同的重点，比如集成测试和需求测试。
——然而，如果您在更高的测试级别上发现这样的问题，您将不得不重新运行夹在两个测试之间的大多数测试。
这是因为单元级别的错误行为可能会掩盖更高测试级别的问题。正如你所见，这个过程可以帮助你发现更多的问题，同时减少你的努力和成本。
以下活动是Automotive SPICE®软件单元验证中最重要的三项活动。
4-1 定义软件单元验证的策略
正如你可能从我们的一些视频中了解到的，策略是一种易于理解的教学描述。这对于更大的分布式项目尤其重要，这样所有人都会知道如何做。
该策略的主要目的是描述您打算如何证明软件单元符合详细设计。
需要三种类型的验证，您应该解释它们应该如何工作：
——静态和动态分析，
也就是说，使用分析工具检查代码。
——代码审查，
同事阅读并审阅同事提供的代码。
——单元测试，
使用书面测试规范证明符合详细设计。
此外，Automotive SPICE®需要回归测试策略。回归测试仅仅意味着，如果你改变了一个单元中的某些东西，你就可以确保所有没有改变的东西仍然运行良好。
一个实际的例子：如果使用持续集成（CI），通常会在夜间测试期间再次运行所有单元测试。所以，策略就是我刚才说的这些。
4-2 提供详细设计的双向可追溯性和一致性
这里需要三种类型的可追溯性，即用于：
——详细设计中的每个单元您都知道对应到哪个测试规范。如果每个测试规范都能对应到某个单元，那么可追溯性是双向的。
——每个单元你都知道代码审查和静态分析的结果。
——每个单元测试规范你都知道单元测试结果。
那么一致性意味着什么？例如，对于详细设计中的单元与相应测试规范之间的关系，一致性要求：
——该单元链接到了正确的测试（而不是另一个单元的测试）
——本测试适用于对这个单元进行完整的测试。
如果情况并非如此，则必须链接其他测试。
一致性还要求测试能够真实的正确的测试软件单元。换句话说：没有差错的测试。
4-3 总结和交流测试结果。
这通常被称为测试总结报告。这份总结报告应该发送给需要这些信息的人，比如开发团队、项目经理、质量工程师等等。
让我们仔细看看这份报告应该长成什么样子：顾名思义，它应该总结结果，隐藏不必要的细节。摘要报告应该传达的主要信息是什么？它应符合软件详细设计。
我将给你一个我在评估中经常看到的反例：报告包含饼图，显示了1520项本应执行的测试，但其中112项无法执行，89项测试失败。就这样。目前还没有关于112项测试无法进行的原因和风险的信息。也没有关于89次失败测试的问题会产生多大问题的信息。报告也没有显示是否与详细设计相符。事实上，详细设计一丁点也没有提到。他们必须将饼图与956个软件单元相关联，而不仅仅是与1520个测试相关联。我想你已经明白了这一点。当然，这会是评估中的减分项。
Automotive SPICE®中的软件集成和集成测试过程（也称为SWE.5）帮助您的组织确保软件体系结构的各个元素被集成，然后进行测试，以证明它们按照计划一起工作，并按照软件架构中的描述进行交互。
在我的课堂和评估中，我遇到了很多问题，比如“嘿，我们做了大量的需求测试，为集成测试付出的额外努力真的值得吗？”
那么，你的看法是什么？想过吗？
为了回答这个问题，我们必须首先阐明集成测试的含义。
集成测试的目的是检查代码是否符合软件架构设计。这包括根据SWE.2检查接口、动态行为和资源消耗。
那么，让我们把最初的问题修改为：“需求测试能证明符合软件架构吗”？答案是：当然不能，因为这些测试针对的是需求，而不是架构。到目前为止，一切顺利。但你们中的一些人可能会说：“好吧，明白了。但是，针对软件架构进行测试的附加值是什么？如果代码功能运行良好，这还不够好吗？”
让我们仔细看看：在需求测试中是否可以检测到代码与软件架构不一致的情况？是的，可以，但不能保证。你可以将需求测试的数量乘以一千、一万、十万，但这仍然不能保证。成本会激增，但软件仍然会有错误，这些错误本可以通过对架构进行测试来避免！现在，底线是：与详尽的需求测试相比，执行集成测试可以以更低的成本为您提供更健壮的软件。祝贺你现在理解了这一过程的价值，你是“高端俱乐部”中的一员了！
以下是Automotive SPICE®中软件集成和集成测试的最重要的三个方面。
5-1 定义软件集成和集成测试的策略
正如你可能从我们的一些视频中了解到的，策略是一种易于理解的教学描述。这对于更大的分布式项目尤其重要，这样所有人都会知道如何做。
该策略首先从一个开发人员的角度描述了软件团队的工作流程，他们可以在将软件交付到团队工作流之前，执行一些简单的集成测试。然后团队可以进行一些集成测试，作为夜间测试运行的一部分。当这些完成后，他们会在将工作交付到项目工作流之前执行一些最终的集成测试。然后可能会有一些额外的集成测试。此外，Automotive SPICE需要“回归测试策略”。回归测试仅仅意味着，如果你改变了软件中的某些东西，你就可以确保所有没有改变的东西都能正常工作。
一个实际例子是：如果使用持续集成，通常会在夜间测试期间再次运行所有集成测试。所以，策略就是我刚才说的这些。
5-2 为软件架构提供双向可追溯性和一致性
可追溯性意味着，对于每个相关的架构元素，例如接口，您可以对应到相应的测试。如果反过来你也能做到这一点（即每个接口测试都能对应到架构中的接口），反之亦然，那么可追溯性是双向的。
那么一致性意味着什么？在我们前面的示例中，一致性要求接口链接到正确的测试（而不是其他测试）。这个测试应该对接口进行完整的测试。如果情况并非如此，则必须链接其他测试。一致性还要求测试能够真正的正确的测试接口。换句话说，没有差错的测试。
5-3 总结并交流测试结果
这通常被称为测试总结报告。这份总结报告应该发送给需要这些信息的人，比如开发团队、项目经理、质量工程师等等。让我们仔细看看这份报告应该是什么样子。顾名思义，它应该总结结果，隐藏不必要的细节。摘要报告应该传达的主要信息是什么？你怎么认为？当然，它应当符合软件架构。
Automotive SPICE中的软件合格性测试过程（也称为SWE.6）有助于您的组织保证集成软件满足软件需求。
什么是软件合格性测试？我们期望您已经有了软件需求，所以我们的目标是对照这些需求进行检查，并确定它们是否完全满足并正确实现。
由于该过程是在软件交付前不久执行的，可以直接交付给客户，也可以作为系统的基础，因此与项目管理（MAN.3）、配置管理（SUP.8）、产品发布（SPL.2）等过程有着密切的关系，当然还有软件需求分析（SWE.1）。
如果软件合格性测试不能很好地被执行，错误可能无法被发现，客户满意度也会下降。测试环境取决于产品。例如SIL、PIL或HIL。
以下是Automotive SPICE®软件合格性测试三个的最重要方面。
6-1 你需要一个明确的测试策略
与所有测试和支持过程一样，软件合格性测试需要开发和定义测试策略。对于每个测试级别，您可能需要一个单独的测试策略，但是最好在所有测试级别上开发和协调测试策略。这可以确保涵盖所有需求，并避免冗余。
测试策略应涵盖以下主题：
——有问题的测试对象
——开发测试用例和测试数据的方法（例如，开发正/负测试、等价性划分）
——回归测试策略，在Automotive SPICE术语中，这意味着您定义了在错误修复或更改请求后要如何重新测试
——测试环境
——与项目计划和发布计划相关的测试覆盖率
——进入和退出标准以及测试中断标准
当然，这个过程与问题解决管理（SUP.9）有很强的联系，所以您可以使用测试策略或缺陷管理策略来文档化如何处理失败的测试。
6-2 选择正确的测试用例
这个期望听起来可能微不足道，但并不是这样…
该过程希望根据测试目标和覆盖率，为各种测试选择测试用例。其目的和期望是，对于不同的交付，根据上述测试策略对软件进行适当的测试。
这个想法是，你可以有不同期望的交付。策略的一个例子是，您可以完全覆盖重要交付所有已实现的软件需求。
对于较小的交付，仅测试自上次交付以来实施的需求增量。
当然，对于这种方法，必须选择正确的测试用例。选择测试用例的另一种可能情况是回归测试，它包括更改请求和/或错误修复。这里选择的测试用例涵盖了变更请求或bug，以及它们可能产生的影响。后者意味着对可能受变更请求或错误修复影响的需求的依赖性也会被测试。
6-3 建立可追溯性和一致性
这个过程还要求您确保软件测试用例和软件需求之间的可追溯性。
可追溯性可以通过超链接来建立，比如在DOORS中，通过特定的可追溯性工具（比如Rectify），通过可追溯性矩阵，或者通过工具环境支持的其他可管理方式。
可追溯性的目的是：
——支持一致性检查，即检查软件需求覆盖范围的完整性和准确性。
——支持变更请求或缺陷情况下的影响评估。
——支持报告利益相关者的期望，并确定哪些需求已经通过测试，通常称之为覆盖率报告。
这个要点的第二部分是一致性，在这种情况下，软件需求和软件测试用例之间是一致的。如果覆盖范围完整且正确，通常会检查一致性。这只能通过审查（Review）来执行。
如果您无法证明您的软件已完全正确覆盖，您可能会发布一个未经充分测试的软件，因此确保一致性符合您的最佳利益！因此，请确保正确执行此审查（Review）！
[1]Video tutorials and expert talks on Automotive SPICE, functional safety and cybersecurity
[2]kuglermaag.com/automoti
[3]kuglermaag.com/automoti
[4]SWE.3 - System Architectural Design - Kugler Maag Cie
[5]kuglermaag.com/automoti
[6]Get familar with the Automotive SPICE®-Process SWE.5
[7]kuglermaag.com/automoti
声明：本翻译稿仅用于学习交流，不得用于商业行为。如有侵权请联系本文作者进行删除。
后台回复：“ECU008获取ASPICE3.1中文版标准！
阅读原文，关注作者知乎！
推荐阅读
谈谈对两家AUTOSAR工具看法
奥迪首款800V车型技术总览
CAN设计与应用指南
汽车软件需求是如何变成用户功能？
电子电气架构设计需要考虑哪些方面？
汽车E/E架构的网络安全分析
电子电气架构设计需要考虑哪些方面？
