文章主要内容：
Automotive SPICE 过程参考模型
SYS.1 需求挖掘
| 过程ID | SYS.1 |
| 过程名称 | 需求挖掘 |
| 过程目的 | 需求挖掘过程的目的是:在产品和/或服务的整个生命周期内收集、处理和跟踪不断变化的利益相关方的需要和需求，从而建立一个需求基线，作为定义所需工作产品的基础。 |
| 过程成果 | 成功实施这个过程的结果如下: 1)建立了与利益相关方的持续沟通; 2)定义和基线化了约定的利益相关方需求; 3)建立了变更机制，以便基于利益相关方需要的变化，评估利益相关方需求的变更并将其纳入需求基线; 4)建立了持续监控利益相关方需要的机制; 5)建立了机制，以确保客户可以容易地判定其要求的状态和处置结果 6)识别了因技术或利益相关方需要的变化而引发的变更，评估相关的风险并管理其带来的影响 |
| 基本实践 | SYS.1.BP1:获得利益相关方需求和要求。 通过直接征求客户意见并通过评审客户业务提案(相关部分)，目标运行和硬件环境以及其它影响客户需求的文档来获取并定义利益相关方的需求和要求。[成果1，4] 注 1:需求挖掘可能需要客户和供应商的参与。 注 2:约定的利益相关方需求和对变更的评估可基于可行性研究和/或成本和时间分析。 注 3:必须收集并记录保持每个客户需求可追溯性所需的信息。 SYS.1.BP2:理解利益相关方的期望。 确保供应商和客户对每个需求有同样的理解。[成果 2] 注 4:与客户一起评审需求和要求有助于更好的理解客户需要和期望。参见过程 SUP.4 联合评审。 SYS.1.BP3:达成需求共识。 获得所有相关方关于需求的明确协议，以便于开展工作。[成果2] SYS.1.BP4:建立利益相关方需求基线。 将利益相关方的需求正式化，并建立基线以便项目使用和依照利益相关方需要进行监控。供应商应确定利益相关方未说明的但对指定和预期用途有必要的需求，并将其包括在基线中。[成果23] SYS.1.BP5:管理利益相关方的需求变更。 依照利益相关方需求基线来管理所有利益相关方需求的变更，以确保识别技术和利益相关方需要的变化而带来的改进，以及确保受变化影响的人能够评估影响和风险，并启动适当的变更控制和缓解措施。[成果3.6] 注 5:需求变化可有不同的来源，例如技术和利益相关方需求的变化、法律约束。 注 6:在定义约定的利益相关方需求时所获的和所需的信息可能需要信息管理系统来进行管理，存储和引用. SYS.1.BP6:建立客户_供应商查询沟通机制。 给客户提供可以了解其需求变更状态和外置结果的方法，供应商能够以客户指定的语言和形式沟通包括数据在内的必要信息。[成果 5] |
| 输出工作产品 | 08-19风险管理计划→[成果6] 08-20风险缓解计划→[成果6] 13-04沟通记录 →[成果1，4] 13-19评审记录 →[成果4，5] 13-21变更控制记录→[成果3，4] 15-01需求分析报告 →[成果2，3，6] 17-03利益相关方需求→[成果1，2] |
SYS.2 系统需求分析
| 过程ID | SYS.2 |
| 过程名称 | 系统需求分析 |
| 过程目的 | 系统需求分析过程的目的是:将已定义的利益相关方需求转换成一组系统需求，以指导系统设计。 |
| 过程成果 | 成功实施这个过程的结果如下; 1)建立了一组定义的系统需求; 2)对系统需求进行分类，并分析了其正确性和可验证性; 3)分析了系统需求对运行环境的影响; 4)定义了系统需求实施的优先级; 5)根据需要更新系统需求; 6)建立了利益相关方需求和系统需求之间的一致性和双向可追溯性; 7)从成本、进度和技术影响来评估系统需求; 8)约定了系统需求，并与所有受影响方沟通。 |
| 基本实践 | SYS.2.BP1:定义系统需求。 使用利益相关方需求及其变更，以识别系统所需的功能和能力。在系统需求规范中定义功能性和非功能性系统需求。[成果 1,5,7] 注 1:影响功能和能力的应用参数是系统需求的一部分。 注 2:关于利益相关方需求的变更，适用SUP.10 SYS.2.BP2:结构化系统需求。 在系统需求规范中结构化系统需求，例如:
[成果24] 注 3:优先级排序通常包括将功能性内容分配给已发布的计划。参见 SPL.2.BP1。 SYS.2.BP3:分析系统需求。 分析已定义的系统需求(包括它们的相互依赖关系)，以确保正确性、技术可行性和可验证性，并且支持风险识别。分析对成本、进度和技术的影响。[成果 1,2,7] 注4:对成本和进度的影响分析有助于项目估算的调整。参见MAN.3.BP5 SYS.2.BP4:分析对运行环境的影响。 识别定义的系统和运行环境中其他要素之间的接口。分析系统需求对这些接口和运行环境的影响。 [成果 3,7] SYS.2.BP5:制订验证准则。 对每一个系统需求制订验证准则，定义定性的和定量的措施用于需求验证。 [成果 2,7] 注 5:验证准则证明了需求可以在约定的约束范围内得到验证，并且通常被用作系统测试用例开发或其它证明符合系统需求的验证措施的输入。 注 6:测试不能覆盖的验证由 SUP.2 覆盖。 SYS.2.BP6:建立双向可追溯性。 建立利益相关方需求和系统需求之间的双向可追溯性。[成果 6] 注 7:双向可追溯性有助于覆盖率， 一致性和影响分析。 SYS.2.BP7:确保一致性。 确保利益相关方需求和系统需求之间的一致性。[成果 6] 注 8:一致性由双向可迫溯性支持，并可通过评审记录来证明。 SYS.2.BP8:沟通约定的系统需求。 与所有相关方沟通约定的系统需求及对系统需求的更新。[成果8] |
| 输出工作产品 | 04-06 系统架构设计→[成果 1,2,3,45] 13-04沟通记录→[成果6] 13-19评审记录→[成果5] 13-22追溯记录→[成果5] 17-08 接口需求规范→[成果3] |
| 过程ID | SYS.3 |
| 过程名称 | 系统架构设计 |
| 过程目的 | 建立系统架构，确定哪些需求分配给哪些系统元素，并根据定义的标准评估所设计的系统架构。 |
| 过程成果 |
|
| 输出工作产品 | 1. 沟通记录； 2. 审查记录； 3. 跟踪记录 4. 系统架构设计 |
Note：系统架构设计
a. 已经定义了系统架构设计，并已经标识了系统元素；
b. 系统需求已经被分配给了系统元素；
c. 系统元素的每个接口已经定义；
d. 已经定义了系统的动态行为目标；
e. 在系统需求和系统架构设计之间已经建立了一致性和双向可追溯性；
f. 系统架构设计已经传达给受影响的各方并且达成了一致。
SYS.4 系统集成与集成测试
| 过程ID | SYS.4 |
| 过程名称 | 系统集成与集成测试 |
| 过程目的 | 系统集成与集成测试过程的目的是:集成系统项以产生与系统架构设计相一致的集成系统，并确保系统项得到测试，以提供集成的系统项符合系统架构设计(包括系统项之间的接口)的证据。 |
| 过程成果 | 成功实施这个过程的结果如下; 1) 制订了与项目计划、发布计划和系统架构设计相一致的系统集成策略，以集成系统项; 2) 制订了包括回归测试策略在内的系统集成测试策略，以测试系统项之间的交互; 3) 根据系统集成测试策略，制订了系统集成测试规范，以适于提供集成的系统项符合系统架构设计(包括系统项之间的接口)的证据; 4) 根据集成策略将系统项集成为完整的集成系统; 5) 根据系统集成测试策略和发布计划，选择了系统集成测试规范中的测试用例; 6) 使用选定的测试用例测试了系统项之间的交互，并记录了系统集成测试结果; 7) 建立了系统架构设计的要素和系统集成测试规范中的测试用例之间的一致性和双向可追溯性，并建立了测试用例和测试结果之间的双向可追溯性; 8) 总结了系统集成测试结果，并与所有受影响方沟通。 |
| 基本实践 | SYS.4.BP1:制订系统集成策略。 制订与项目计划和发布计划相一致的系统项集成策略。基于系统架构设计识别系统项，并定义其集成顺序。[成果 1] SYS.4.BP2:制订包括回归测试策略在内的系统集成测试策略. 遵循集成策略，制订集成系统项的测试策略。该策略包括当系统项变更时对集成的系统项实施再测试的回归测试策略。[成果 2] SYS.4.BP3:开发系统集成测试规范. 根据系统集成测试策略，开发系统集成测试规范(包括系统项的各集成步骤的测试用例)。测试规范应话于提供集成的系统项符合系统架构设计的证据。[成果 3] 注 1:系统要素之间的接口描述是系统集成测试用例的输入。 注 2:符合系统架构设计是指，定义的集成测试适于证明系统项之间的接口满足系统架构设计的规范。 注 3:系统集成测试用例可关注:
注 4:可使用仿真环境(例如:硬件在环仿真，车载网络仿真，数字原型)支持系统集成测试。 SYS.4.BP4:集成系统项。 根据系统集成策略，将系统项集成为集成系统，[成果4] 注 5:系统集成可逐步集成系统项(例如:作为原型硬件的硬件要素，外设(传感器和执行器)，机械和集成软件)，以产生与系统架构设计相一致的系统。 SYS.4.BP5:选择测试用例. 从系统集成测试规范中选择测试用例，测试用例的选择应根据系统集成测试策略和发布计划具备足够的要盖率。[成果 5] SYS.4.BP6:执行系统集成测试. 使用选定的测试用例执行系统集成测试。记录华成测试结果和日志。[成果6] 注 6:不符合项的处理，见SUP.9 SYS.4.BP7:建立双向可追溯性. 建立系统架构设计要素与系统集成测试规范中的测试用例之间的双向可追溯性，建立系统集成测试规范中的测试用例与系统集成测试结果之间的双向可追溯性。[成果7] 注 7:双向可追溯性有助于覆盖率、一致性和影响分析。 SYS.4.BP8:确保一致性. 确保系统架构设计要素与系统集成测试规范中的测试用例之间的一致性。[成果 7] 注 8:一致性由双向可追溯性支持，并可通过评审记录来证明。 SYS.4.BP9:总结和沟通结果。 总结系统集成测试结果，并与所有受影响方沟通。[成果 8] 注 9:在总结中提供来自测试用例执行的所有必要信息，以便其他方判断结果。 |
| 输出工作产品 | 08-50 测试规范→[成果3，5] 08-52 测试计划→[成果 1，2] 11-06 系统→[成果4] 13-04 沟通记录→[成果 8] 13-19评审记录→[成果7] 13-22 追溯记录→[成果 7] 13-50测试结果→[成果6，8] |
SYS.5 系统合格性测试
| 过程ID | SYS.5 |
| 过程名称 | 系统合格测试 |
| 过程目的 | 系统合格性测试过程的目的是:确保集成系统得到测试，以提供符合系统需求的证据，并确保系统可用于交付。 |
| 过程成果 | 成功实施这个过程的结果如下; 1)制订了与项目计划和发布计划相一致的系统合格性测试策略(包括回归测试策略)，用以测试已集成的系统。 2) 根据系统合格性测试策略，制订了已集成系统的系统合格性测试规范以适于提供符合系统需求的证据。 3) 根据系统合格性测试策略和发布计划，选择了系统合格性测试规范中的测试用例。 4)使用选择的测试用例测试了已集成的系统，并记录了系统合格性测试的结果。 5)建立了系统需求与系统合格性测试规范中测试用例之间的一致性和双向可追溯性，并建立了测试用例与测试结果之间的一致性和双向可追溯性。 6)总结了系统合格性测试结果，并与所有受影响方沟通 |
| 基本实践 | SYS.5.BP1:制订包括回归测试策略在内的系统合格性测试策略。 制订与项目计划和发布计划相一致的系统合格性测试策略。该策略包括当系统项变更时，对已集成系统实施再测试的回归测试策略。[成果1] SYS.5.BP2: 开发系统合格性测试规范。 根据系统合格性测试策略，开发系统合格性测试规范(包括基于验证准则的测试用例)。该规范应适于提供集成系统符合系统需求的证据。[成果2] SYS.5.BP3:选择测试用例。 从系统合格性测试规范中选择测试用例。对于系统合格性测试策略和发布计划而言，所选择的测试用例应具备足够的覆盖率。[成果3] SYS.5.BP4: 测试已集成的系统。 使用已选择的测试用例测试已集成的系统。记录系统合格性测试的结果和日志。[成果4] 注 1:不符合项的处理，见 SUP.9。 SYS.5.BP5:建立双向可追溯性。 建立系统需求与系统合格性测试规范中的测试用例之间的双向可追溯性。建立系统合格性测试规范中的测试用例与系统合格性测试结果之间的双向可追溯性。[成果5] 注 2:双向可追溯性有助于覆盖率、一致性和影响分析。 SYS.5.BP6:确保一致性。 确保系统需求和系统合格性测试规范中的测试用例之间的一致性。 [成果5] 注 3:一致性由双向可追溯性支持，并可通过评审记录来证明。 SYS.5.BP7:总结和沟通结果。 总结系统合格性测试结果，并与所有受影响方沟通。[成果6] 注 4:在总结中提供来自测试用例执行的所有必要信息，以便其他方判断结果。 |
| 输出工作产品 | 08-50测试规范→[成果2,3] 08-52测试计划→[成果1] 13-04沟通记录→[成果6] 13-19评审记录→[成果5] 13-22追溯记录→[成果5] 13-50测试结果→[成果4,6] |
SWE.1软件需求分析
| 过程ID | SWE.1 |
| 过程名称 | 软件需求分析 |
| 过程目的 | 软件需求分析过程的目的是：将系统需求中与软件相关的部分转化为一组软件需求。 |
| 过程成果 | 成功实施这个过程的结果如下: 1)定义了系统中分配给软件要素的软件需求及其接口; 2)将软件需求进行分类，并分析了其正确性和可验证性; 3)分析了软件需求对运行环境的影响; 4)定义了软件需求实现的优先级; 5)根据需要更新了软件需求: 6)在系统需求与软件需求之间、在系统架构设计与软件需求之间建立了一致性和双向可追溯性; 7)从成本、进度和技术影响来评估软件需求; 8)约定了软件需求，并与所有受影响方沟通。 |
| 基本实践 | SWE.1.BP1:定义软件需求。 使用系统需求和系统架构及其变更来识别软件所需的功能和能力。在软件需求规范中定义功能性和非功能性软件需求。[成果1,5,7] 注1：影响功能和能力的应用参数是系统需求的一部分。 注2： 如果只有软件开发，系统需求和系统架构是指给定的运行环境（参见注5）。在这种情况下，应将利益相关方需求作为识别软件所需功能和能力以及识别影响软件功能和能力的应用参数的基础。 SWE.1.BP2:结构化软件需求。 在软件需求规范中结构化软件需求，例如:
[成果2, 4] 注3： 优先级排序通常包括将软件内容分配给已计划的发布。参见SPL.2.BP1。 SWE.1.BP3:分析软件需求。 分析已定义的软件需求，包括其相互依赖关系，以确保正确性、技术可行性和可验证性，并支持风险识别，分析对成本、进度和技术的影响。[成果2, 7] SWE.1.BP4:分析对运行环境的影响。 分析软件需求对系统要素接口及运行环境的影响。[成果3, 7] 注5： 运行环境是指软件运行所在的系统(例如：硬件、操作系统等) 。 SWE.1.BP5:制订验证准则。 对每个软件需求制订验证准则，定义定性的和定量的措施以用于需求验证。 [成果2, 7] 注6： 验证准则证明了需求可以在约定的约束范围内得到验证，并且通常被用作软件测试用例开发或其他证明符合软件需求的验证措施的输入。 注7：测试不能覆盖的验证由SUP.2覆盖。 SWE.1.BP6:建立双向可追溯性。 建立系统需求与软件需求之间的双向可追溯性，建立系统架构设计与软件需求之间的双向追溯性。[成果 6] 注8： 应通过建立同时满足项目和组织要求的方法来避免冗余。 注9：双向可追溯性有助于覆盖率、一致性和影响分析。 SWE.1.BP7:确保一致性。 确保系统需求与软件需求之间的一致性，确保系统架构与软件需求之间的一致性。[成果 6] 注10：一致性由双向可追溯性支持，并可通过评审记录来证明。 注11：如果只有软件开发，必须确保利益相关方需求与软件需求之间的一致性和双向可追溯性。 SWE.1.BP8:沟通约定的软件需求。 与所有相关方沟通约定的软件需求及对软件需求的更新。[成果 8] |
| 输出 工作产品 |
|
Note：
分析报告Analysis Record：分析的内容、分析人、所采用的分析准则（选择的准则或采用的优先级计划、决策准则、质量准则）、记录结果（决定或选择的内容、选择的原因、做出的假定、潜在风险）、正确性分析的方面（完整性、可理解性、可测试性、可验证性、可行性、有效性、一致性、内容的充分性）
软件需求说明书（Software Requirement Specification）：识别适用的标准、识别软件架构考虑及约束条件、识别必需的软件元素、识别软件元素之间的关联关系、考虑给出以下信息（必需的软件性能特性、必需的软件接口、必需的安全特性、数据库设计需求、必需的错误处理及属性恢复机制、必需的资源消耗特性）
SWE.2软件架构设计
| 过程ID | SWE.2 |
| 过程名称 | 软件架构设计 |
| 过程目的 | 软件架构设计过程的目的是：建立软件架构设计，识别将哪些软件需求分配给软件的哪些要素，并依照定义的准则来评估软件架构设计。 |
| 过程成果 | 成功实施这个过程的结果如下: 1)定义了识别软件要素的软件架构设计; 2)将软件需求分配给软件的要素; 3)定义了每个软件要素的接口; 4)定义了软件要素的动态行为和资源消耗目标; 5)建立了软件需求与软件架构设计之间的一致性和双向可追溯性; 6)约定了软件架构设计，并与所有受影响方沟通。 |
| 基本实践 | SWE.2.BP1: 开发软件架构设计。 开发并文档化软件架构设计，该设计基于软件功能性需求和非功能性需求定义软件要素。[成果1] 注1： 将软件分解为适当的各层级上的要素，直至软件架构设计的最低层级要素，即详细设计种描述的软件组件。 SWE.2.BP2:分配软件需求。 将软件需求分配到软件架构设计的要素。 [成果2] SWE.2.BP3:定义软件要素的接口。 识别、开发并记录软件要素的接口。[成果3] SWE.2.BP4:描述动态行为。 评估并记录软件要素的时序和动态交互，以满足系统所需的动态行为。[成果4] 注2：动态行为取决于运行模式（例如：启动、关机、正常模式、标定、诊断等）、进程及进程间相互通信、任务、线程、时间片、中断等。 注3： 在评估动态行为时，宜考虑目标平台和目标对象的潜在负载。 SWE.2.BP5:定义资源消耗目标。 在适当的层级上确定并文档化软件架构设计的所有相关要素的资源消耗目标。[成果4] 注4：资源消耗通常取决于资源，如：内存(ROM、RAM、外部/内部EEPROM或数据闪存)、CPU负载等。 SWE.2.BP6:评估备选的软件架构。 定义架构的评估准则。根据定义的准则评估备选的软件架构，记录被选定的软件架构的选择理由。[成果1，2，3，4，5] 注5：评估准则可包括质量特性（模块性、可维护性、可扩展性、可扩缩性、可靠性、安全security可实现性和易用性）以及开发-购买-重用分析的结果。 SWE.2.BP7:建立双向可追溯性。 建立软件需求与软件架构设计要素之间的双向可追溯性。 [成果5] 注6：双向可追溯性覆盖软件需求向软件架构设计的要素的分配。 注7：双向可追溯性有助于覆盖率、一致性和影响分析。 SWE.2.BP8:确保一致性。 确保软件需求与软件架构设计之间的一致性。[成果1，2，5，6] 注8：一致性由双向可追溯性支持，并可通过评审记录来证明。 SWE.2.BP9:沟通约定的软件架构设计。 与所有相关方沟通已约定的软件架构设计及对软件架构设计的更新。[成果6] |
| 输出 工作产品 |
|
Note
软件架构设计包括内容有：
a. 软件架构整体描述；
b. 包含任务结构的运行系统描述；
c. 确定任务与进程之间的通信；
d. 识别必需的软件元素；
e. 识别自主开发及供应方提供的代码；
f. 识别软件元素之间的关联及依赖关系；
g. 确定数据存储及灾备方案；
h. 描述不同模型系列或配置如何衍生出产品变体；
i. 描述软件的动态行为（启动、关闭、软件升级、错误处理、恢复）；
j. 确定数据存储位置及数据损坏的预防办法；
k. 描述哪些数据是在什么情况下是持续存在的；
l. 还要充分考虑以下内容（软件必需的性能特性、软件必需的接口、软件必需的安全特性、数据库设计需求）
SWE.3软件详细设计和单元构建
| 过程ID | SWE.3 |
| 过程名称 | 软件详细设计和单元构建 |
| 过程目的 | 软件详细设计和单元构建过程的目的是：为软件组件提供经过评估的详细设计，并定义和生成软件单元。 |
| 过程成果 | 成功实施这个过程的结果如下: 1)开发了描述软件单元的详细设计； 2)定义了各软件单元的接口; 3)定义了软件单元的动态行为; 4) 建立了软件需求与软件单元之间的一致性和双向可追溯性； 建立了软件架构设计与软件详细设计之间的一致性和双向可追溯性； 建立了软件详细设计与软件单元之间一致性和双向可追溯性; 5)约定了软件详细设计及该设计与软件架构设计的关系，并和所有受影响方沟通; 6)生成了软件详细设计所定义的软件单元。 |
| 过程成果 | SWE.3.BP1: 开发软件详细设计。 开发软件架构设计中定义的各软件组件的详细设计，该设计基于软件功能性需求和非功能性需求定义软件单元。[成果1] SWE.3.BP2:定义软件单元的接口。 识别、定义和文档化各软件单元的接口。[成果2] SWE.3.BP3:描述动态行为。 评估并文档化相关软件单元之间的动态行为和交互。[成果3] 注1：并非所有的软件单元都有动态行为可描述。 SWE.3.BP4:评估软件详细设计。 从互操作性、交互、关键性、技术复杂性、风险和可测试性方面对软件详细设计进行评估。[成果1，2，3，4] 注2：评估结果能作为软件单元验证的输入。 SWE.3.BP5:建立双向可追溯性。 建立软件需求与软件单元之间的双向可追溯性。 建立软件架构设计与软件详细设计之间的双向可追溯性。 建立软件详细设计与软件单元之间的双向可追溯性。[成果4] 注3：对以上方法进行组合，覆盖项目和组织需要，避免冗余。 注4：双向可追溯性有助于覆盖率、一致性和影响分析。 SWE.3.BP6:确保一致性。 确保软件需求与软件单元之间的一致性。 确保软件架构设计、软件详细设计及软件单元之间的一致性。[成果4] 注5：一致性由双向可追溯性支持，并可通过评审记录来证明。 SWE.3.BP7:沟通约定的软件详细设计。 与所有相关方沟通已约定的软件详细设计及对软件详细设计的更新。[成果5] SWE.3.BP8:开发软件单元。 根据软件详细设计，开发并文档化各软件单元的可执行形式。[成果6] |
| 输出 工作产品 |
|
SWE.4软件单元验证
| 过程ID | SWE.4 |
| 过程名称 | 软件单元验证 |
| 过程目的 | 软件单元验证过程的目的是:验证软件单元，以提供软件单元符合软件详细设计和非功能性软件需求的证据。 |
| 过程成果 | 成功实施这个过程的结果如下: 1)制订了包括回归策略在内的软件单元验证策略，以验证软件单元; 2)根据软件单元验证策略，制订了软件单元验证准则，以适于提供软件单元符合软件详细设计及非功能性软件需求的证据; 3)根据软件单元验证策略及软件单元验证准则，验证了软件单元并记录了结果; 4)建立了软件单元、验证准则及验证结果之间的双向可追溯性和一致性; 5)总结了单元验证结果，并与所有受影响方沟通。 |
| 基本实践 | SWE.4.BP1: 制订包括回归策略在内的软件单元验证策略。 制订软件单元验证策略(包括软件单元变更时实施再验证的回归策略)。验证策略应定义如何提供软件单元符合软件详细设计和非功能性需求的证据。[成果1] 注1：可能的单元验证的方法包括静态/动态分析、代码评审、单元测试等。 SWE.4.BP2:制订单元验证准则。 根据验证策略，制订单元验证准则，以适于提供软件单元及其在组件内的交互符合软件详细设计及非功能性需求的证据。对单元测试而言，该准则应定义在单元测试规范中。[成果2] 注2：可能的单元验证准则包括单元测试用例、单元测试数据、静态验证、覆盖率目标及编码规范（如MISRA规则）。 注3：单元测试规范的实施形式可为：例如自动测试台上的脚本。 SWE.4.BP3:执行软件单元的静态验证。 使用已定义的验证准则来验证软件单元的正确性。记录静态验证的结果。[成果3] 注4：静态验证可包括静态分析、代码评审、依照编码规范和指南的检查、及其它方法。 注5： 不符合项的处理，见SUP.9. SWE.4.BP4:测试软件单元。 根据软件单元验证策略，使用单元测试规范测试软件单元。记录测试结果和日志。[成果3] 注6： 不符合项的处理，见SUP.9. SWE.4.BP5:建立双向可追溯性。 建立软件单元与静态验证结果之间的双向可追溯性。 建立软件详细设计与单元测试规范之间的双向可追溯性。 建立单元测试规范与单元测试结果之间的双向可追溯性。 [成果4] 注7：双向可追溯性有助于覆盖率、一致性和影响分析。 SWE.4.BP6:确保一致性。 确保软件详细设计与单元测试规范之间的一致性。[成果4] 注8：一致性由双向可追溯性支持，并可通过评审记录来证明。 SWE.4.BP7:总结并沟通结果。 总结单元测试结果和静态验证结果，并与所有受影响方沟通。[成果5] 注9：在总结中提供来自测试用例执行的所有必要信息，以便其他方得以判断结果。 |
| 输出 工作产品 |
|
Note
测试规范说明书 Test Specification：包括测试设计规格书、测试用例规格书、测试过程规格书、识别回归测试的测试用例；对于系统集成测试，要识别必需的系统要素，例如硬件要素、接线要素、参数设定和数据库等；识别系统元素集成必要的序列或排序
测试计划Test Plan：分级的测试计划、测试策略（黑盒/白盒测试、系统边界测试、回归测试策略等）；如有必要，编制综合测试计划
验证结果及测试报告Verification Result and Test Report：验证checklist、通过的项、失败的项、待验证的项、发现的问题issue、风险分析、解决方案、结论、签名确认。测试报告按照要求，形成测试日志分级、形成异常报告、形成测试报告分级。
SWE.5软件集成和集成测试
| 过程ID | SWE.5 |
| 过程名称 | 软件集成和集成测试 |
| 过程目的 | 软件集成和集成测试过程的目的是:将软件单元集成到更大的软件项，直至与软件架构设计相一致的完整的集成软件，并确保集成的软件项得到测试，以提供集成的软件项符合软件架构设计(包括软件单元之间和软件项之间的接口)的证据。 |
| 过程成果 | 成功实施这个过程的结果如下: 1)制订了与项目计划、发布计划和软件架构设计相一致的软件集成策略，以集成软件项; 2)制订了包括软件回归测试策略在内的软件集成测试策略，以测试软件单元之间和软件项之间的交互; 3)根据软件集成测试策略，开发了软件集成测试规范，以适于提供集成的软件项符合软件架构设计(包括软件单元之间和软件项之间的接口)的证据； 4)根据集成策略集成了软件单元和软件项直至完整的集成软件； 5)根据软件集成测试策略和发布计划，选择了软件集成测试规范中的测试用例； 6)使用选定的测试用例测试了集成的软件项，并记录了测试结果； 7)建立了软件架构设计要素与软件集成测试规范中的测试用例之间的一致性和双向可追溯性，并建立了测试用例与测试结果之间的一致性和双向可追溯性； 8)总结了软件集成测试结果，并与所有受影响方沟通。 |
| 基本实践 | SWE.5.BP1:制订软件集成策略。 制订与项目计划和发布计划相一致的软件项集成策略。基于软件架构设计识别软件项，并定义其集成顺序。[成果1] SWE.5.BP2:制订包含回归测试策略在内的软件集成测试策略。 遵循集成策略，制订集成的软件项的测试策略。该策略包括当软件项发生变更时，对集成的软件项实施再测试的回归测试策略。[成果2] SWE.5.BP3:开发软件集成测试规范。 根据软件集成测试策略，为各集成的软件项开发测试规范(包括各集成的软件项的测试用例)。测试规范应适于提供集成的软件项符合软件架构设计的证据。[成果3] 注1：符合架构设计是指，定义的集成测试适于证明软件单元之间的接口以及软件项之间的接口满足软件架构设计的规范。 注2：软件集成测试用例可关注：
SWE.5.BP4:集成软件单元和软件项。 根据软件集成策略，将软件单元集成到软件项，进而将软件项集成到集成软件。[成果4] SWE.5.BP5:选择测试用例。 从软件集成测试规范中选择测试用例。根据软件合格性测试策略和发布计划，选定的测试用例应具备足够的覆盖率。[成果5] SWE.5.BP6:执行软件集成测试。 使用选定的测试用例执行软件集成测试，并记录集成测试结果和日志。 [成果6] 注4：不符合项的处理，见SUP.9 注5：可用硬件的调试接口或仿真环境（例如，软件在环仿真）支持软件集成测试。 SWE.5.BP7:建立双向可追溯性。 建立软件架构设计要素与软件集成测试规范中的测试用例之间的双向可追溯性。 建立软件集成测试规范中的测试用例与软件集成测试结果之间的双向可追溯性。[成果7] 注7：一致性由双向可追溯性支持，并可通过评审记录来证明。 SWE.5.BP8:确保一致性。 确保软件架构设计要素与软件集成测试规范中的测试用例之间的一致性。[成果7] 注8：在总结中提供来自测试用例执行的所有必要信息，以便其他地方可以判断结果。 SWE.5.BP9:总结和沟通测试结果。 总结软件集成测试结果，并与所有受影响方沟通。[成果8] 注8：在总结中提供来自测试用例执行的所有必要信息，以便其他方可以判断结果。 |
| 输出 工作产品 |
|
Note
软件项，两大块，一个是集成的软件，一个是文档。集成的软件可分为：源代码、软件元素、可执行代码、配置文件；文档包括：描述和识别源代码、描述和识别软件元素、描述和识别配置文件、描述和识别可执行代码、描述软件生命周期状态、描述归档和发布标准、描述软件单元编译、描述软件组件的构建
集成的软件：多个软件组件的集合。这里的软件一般是针对某一特定ECU配置的一组可执行文件以及有关的文档和数据。
构建列表Build list: 识别软件应用系统的聚合、识别所需的系统元素（参数设定、宏程序库、基本数据、作业控制语言等）、识别软件编译时必需的顺序序列、识别输入输出资源库。
SWE.6软件合格性测试
| 过程ID | SWE.6 |
| 过程名称 | 软件合格性测试 |
| 过程目的 | 软件合格性测试的目的是: 确保集成软件得到测试，以提供符合软件需求的证据。 |
| 过程成果 | 成功实施这个过程的结果如下: 1)制订了与项目计划和发布计划相一致的包括回归测试策略在内的软件合格性测试策略，以测试集成软件; 2)根据软件合格性测试策略，开发了集成软件的软件合格性测试规范，以适于提供符合软件需求的证据; 3)根据软件合格性测试策略和发布计划，选择了软件合格性测试规范中的测试用例 4)使用选定的测试用例测试了集成软件，并记录了软件合格性测试结果； 5)建立了软件需求与软件合格性测试规范中的测试用例之间的一致性和双向可追溯性， 建立了测试用例与测试结果之间的一致性和双向的可追溯性； 6)总结了软件合格性测试结果，并与所有受影响方沟通。 |
| 基本实践 | SWE.6.BP1: 制订包括回归测试策略在内的软件合格性测试策略。 制订与项目计划和发布计划相一致的软件合格性测试策略。该策略包括当软件项发生变更时，对集成软件实施再测试的回归测试策略。[成果1] SWE.6.BP2: 开发软件合格性测试规范。 根据软件合格性测试策略，基于验证准则，开发包含测试用例在内的软件合格性测试规范。测试规范应适于提供集成软件符合软件需求的证据。[成果2] SWE.6.BP3:选择测试用例。 从测试规范中选择测试用例。根据软件合格性测试策略和发布计划，选定的测试用例应具备足够的覆盖率。[成果3] SWE.6.BP4:测试集成软件。 使用选定的测试用例测试集成软件。记录测试结果和日志。[成果4] 注1：不符合项的处理，见SUP.9。 SWE.6.BP5:建立双向可追溯性。 建立软件需求与软件合格性测试规范中的测试用例之间的双向可追溯性。 建立软件合格性测试规范中的测试用例与软件合格性测试结果之间的双向可追溯性。[成果5] 注2：双向可追溯性有助于覆盖率、一致性和影响分析。 SWE.6.BP6:确保一致性。 确保软件需求与软件合格性测试规范中的测试用例的一致性。 [成果5] 注3：一致性由双向可追溯性支持，并可通过评审记录来证明。 SWE.6.BP7:总结和沟通结果。 总结软件合格性测试结果，并与所有受影响方沟通。[成果6] 注4：在总结中提供来自测试用例执行的所有必要信息，以便其他方判断结果。 |
| 输出 工作产品 |
|
