ASPICE-SYS&SWE

过程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]

过程ID

SYS.2

过程名称

系统需求分析

过程目的

系统需求分析过程的目的是:将已定义的利益相关方需求转换成一组系统需求，以指导系统设计。

过程成果

成功实施这个过程的结果如下;

1)建立了一组定义的系统需求;

2)对系统需求进行分类，并分析了其正确性和可验证性;

3)分析了系统需求对运行环境的影响;

4)定义了系统需求实施的优先级;

5)根据需要更新系统需求;

6)建立了利益相关方需求和系统需求之间的一致性和双向可追溯性;

7)从成本、进度和技术影响来评估系统需求;

8)约定了系统需求，并与所有受影响方沟通。

基本实践

SYS.2.BP1:定义系统需求。

使用利益相关方需求及其变更，以识别系统所需的功能和能力。在系统需求规范中定义功能性和非功能性系统需求。[成果 1,5,7]

注 1:影响功能和能力的应用参数是系统需求的一部分。

注 2:关于利益相关方需求的变更，适用SUP.10

SYS.2.BP2:结构化系统需求。

在系统需求规范中结构化系统需求，例如:

1. 按项目相关集群进行分组
2. 按项目中逻辑顺序排序，
3. 基于项目相关准则进行分类
4. 根据利益相关方需要进行优先级排序。

[成果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. 详细说明每个必需系统元素的设计，需要考虑到以下内容：内存和容量的需求、硬件接口需求、用户接口需求、外部系统接口需求、性能需求、指令结构、安全及数据保护特性、系统参数设定、人工操作、可重用组件等
5. 系统元素与需求之间的映射关系
6. 描述系统组件运行模式（启动、停止、睡眠模式、诊断模式等）
7. 描述在不同运行模式下各个系统组件之间依赖关系；
8. 描述系统和系统组件的动态行为。

输出工作产品

1.     沟通记录；

2.     审查记录；

3.     跟踪记录

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:系统集成测试用例可关注:

1. 系统项之间的正确信号流
2. 系统项之间信号流的时效性和时序依赖性
3. 使用接口正确解释所有系统项的信号
4. 系统项之间的动态交互

注 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]

过程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]

过程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]

输出

工作产品

1. 沟通记录    -> [成果8]
2. 评审记录    -> [成果6]
3. 追溯记录    -> [成果1,6]
4. 变更控制记录-> [成果5,7]
5. 分析报告    -> [成果2,3,4,7]
6. 接口需求规范-> [成果1,3]
7. 软件需求规范-> [成果1]
8. 验证准则    -> [成果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]

输出

工作产品

1. 软件架构设计->[成果1，2，3，4，5]
2. 沟通记录    ->[成果6]
3. 评审记录    ->[成果5]
4. 追溯记录    ->[成果5]
5. 接口需求规范->[成果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]

输出

工作产品

1. 软件详细设计->[成果1,2,3]
2. 软件单元    ->[成果6]
3. 沟通记录    ->[成果5]
4. 评审记录    ->[成果4]
5. 追溯记录    ->[成果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：在总结中提供来自测试用例执行的所有必要信息，以便其他方得以判断结果。

输出

工作产品

1. 测试规范->[成果2]
2. 测试计划->[成果1]
3. 沟通记录->[成果5]
4. 评审记录->[成果3,4]
5. 追溯记录->[成果4]
6. 验证结果->[成果3,5]
7. 测试结果->[成果3,5]
8. 分析报告->[成果3]

过程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：在总结中提供来自测试用例执行的所有必要信息，以便其他方可以判断结果。

输出

工作产品

1. 软件项  ->[成果4]
2. 集成软件->[成果4]
3. 测试规范->[成果3,5]
4. 测试计划->[成果1,2]
5. 沟通记录->[成果8]
6. 评审记录->[成果7]
7. 追溯记录->[成果7]
8. 测试结果->[成果6,8]
9. 编译清单->[成果4,7]

过程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：在总结中提供来自测试用例执行的所有必要信息，以便其他方判断结果。

输出

工作产品

1. 测试规范->[成果2，3]
2. 测试计划->[成果1]
3. 沟通记录->[成果6]
4. 评审记录->[成果5]
5. 追溯记录->[成果5]
6. 测试结果->[成果4,6]