关于 ASPICE 的理解

目录

1.总体预览 

2.关键概念解释

2.1 过程评估模型

2.2 过程参考模型

2.3 过程属性

2.4 基本实践

2.5 工作产品

2.6 通用实践

2.7 通用资源

2.8 过程实施指标

2.9 过程能力指标

3.各个等级说明

3.1 级别等级定义

3.2 评估指标与过程能力

3.3 评定指标

4.双向追溯关系

5.关于系统开发

6.关于软件开发

7.ASPICE认证的典型问题

 

---

1.总体预览 

包含三个生命周期过程，主要生命周期过程，组织生命周期过程，支持生命周期过程，进一步可以细分为，需求获取组-供应管理组-系统组-软件组-支持组（QA组）-管理组-过程改进组等。

2.关键概念解释

2.1 过程评估模型

PAM  Process Assessment Model

使用过程评估模型来确定过程能力的概念，在APICE是基于如下图的二维框架。

第一个维度是由过程参考模型定义的过程来提供，即满足参考模型要求以及参考模型指定成果要求

第二个维度是由过程属性的能力等级所构成。

2.2 过程参考模型

PRM  Process Reference Model

指的是按照一定的过程类别分组，针对每个过程，描述其目的，获得其结果清单等，如上述的图即为ASPICE过程参考模型。

2.3 过程属性

PA Process Attribute

是通用实践 + 通用资源（GP + GR）组合形成的针对一个过程的特征描述。

如：下表为过程实施过程属性

2.4 基本实践

BP   Base Practice

指某个特定过程中指定活动的指标。

举例单元开发这个过程来说，开发详细设计-定义软件接口-描述动态行为等，这些活动为该过程的基本实践。

2.5 工作产品

WP  Work Product

工作产品指的是每个过程，输出的工作产物。

依然拿软件单元设计来说，软件详细设计-软件单元等为其输出的工作产品

2.6 通用实践

GP  Generic Practice

通用实践指出每个过程属性的特征，是通用类型，即它们适用于任何过程。是面向活动的指标。

还是以过程实施过程属性为例，针对通用实践它是一种归类性质的，一方面它要求实现了基本实践的目的，另一方面它要求产出对应的工作产品，因此它是针对所有过程通用性要求。

2.7 通用资源

GR  Generic Resource

通用资源与整体的过程属性相关联。是面向基础设施的指标。

还是针对过程实施过程属性为例，通用资源指的是使用资源来实现基本实践，这里的资源包含人力-工具等在基本实践过程中用到的资源。

2.8 过程实施指标

包含 基本实践 + 工作产品

2.9 过程能力指标

包含 通用实践 + 通用资源

3.各个等级说明

3.1 级别等级定义

级别	过程属性	评定
等级 1 级	PA 1.1:过程实施	主要
等级 2 级	PA 1.1: 过程实施 PA 2.1: 实施管理 PA 2.2:工作产品管理	完全 主要 主要
等级 3 级	PA 1.1: 过程实施 PA 2.1: 实施管理 PA 2.2: 工作产品管理 PA 3.1: 过程定义 PA 3.2: 过程部署	完全 完全 完全 主要 主要
等级 4 级	PA 1.1:过程实施 PA 2.1: 实施管理 PA 2.2:工作产品管理 PA 3.1: 过程定义 PA 3.2: 过程部署 PA 4.1: 定量分析 PA 4.2:定量控制	完全 完全 完全 完全 完全 主要 主要
等级 5 级	PA 1.1: 过程实施 PA 2.1: 实施管理 PA 2.2:工作产品管理 PA 3.1: 过程定义 PA 3.2: 过程部署 PA 4.1: 定量分析 PA 4.2:定量控制 PA 5.1: 过程创新 PA 5.2: 过程创新实施	完全 完全 完全 完全 完全 完全 完全 主要 主要

3.2 评估指标与过程能力

如下图所示（具体PA内容，大家可查手册）

Level1要求 BP + WP + PA1.1 满足要求；

Level2要求在Level1的基础上 ，满足PA2.1+PA2.2要求；

Level3要求在Level2的基础上，满足PA3.1+PA3.2要求；

Level4要求在Level3的基础上，满足PA4.1+PA4.2要求；

Level5要求在Level4的基础上，满足PA5.1+PA5.2要求；

因此可以看出，ASPICE评审过程中，在满足基本过程要求的基础上，更注重过程的能力。

3.3 评定指标

N	没有达成	0～ ≤ 15%达成
P-	部分达成	> 15% ～ ≤ 32.5% 达成
P+	部分达成	> 32.5% ～ ≤ 50% 达成
L-	主要达成	> 50% ～ ≤ 67.5% 达成
L+	主要达成	> 67.5% ～ ≤ 85% 达成
F	完全达成	> 85% ～ ≤ 100% 达成

4.双向追溯关系

这里特地说明一下，软件单元需要和静态检查结果，详细设计以及软件需求建立追溯关系；

软件需求和系统需求建立追溯关系。

5.关于系统开发

有点懒，就直接摘录了，此处与本人开发过程相关，摘录参考《© VDA Quality Management Center》

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:建立利益相关方需求基线。将利益相关方的需求正式化，并建 立基线以便项目使用和依照利益相关方需要进行监控。供应商应确定利益 相关方未说明的但对指定和预期用途有必要的需求，并将其包括在基线 中。[成果 2,3 ] 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:结构化系统需求。在系统需求规范中结构化系统需求，例如：  按项目相关集群进行分组，  按项目中逻辑顺序排序，  基于项目相关准则进行分类，  根据利益相关方需要进行优先级排序。 [成果 2, 4] 注 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]

输出工作产品

13-04 沟通记录 → [成果 8] 13-19 评审记录 → [成果 6] 13-21 变更控制记录 → [成果 1] 13-22 追溯记录 → [成果 6] 15-01 分析报告 → [成果 2, 3, 4, 7] 17-08 接口需求规范 → [成果 1, 3] 17-12 系统需求规范 → [成果 1, 5] 17-50 验证准则 → [成果 2]

SYS.3 系统架构设计

过程 ID	SYS.3
过程名称	系统架构设计
过程目的	系统架构设计过程的目的是: 建立系统架构设计，识别将哪些系统需求分配 给哪些系统要素，并依照已定义的准则评估系统架构设计。
过程成果	成功实施这个过程的结果如下： 1) 定义了识别系统要素的系统架构设计； 2) 将系统需求分配给系统的要素； 3) 定义了每个系统要素的接口； 4) 定义了系统要素的动态行为； 5) 建立了系统需求和系统架构设计之间的一致性和双向可追溯性； 6) 约定了系统架构设计，并与所有受影响方沟通。

基本实践

SYS.3.BP1: 开发系统架构设计。开发并文档化系统架构设计，该设计基于 系统功能性需求和非功能性需求定义系统要素。 [成果 1] 注 1：系统架构设计的开发通常包括在适当的各层级上分解成要素。 SYS.3.BP2: 分配系统需求。将系统需求分配给系统架构设计的要素。[成果 2] SYS.3.BP3: 定义系统要素的接口。识别、开发并文档化每个系统要素的接 口。 [成果 3] SYS.3.BP4: 描述动态行为。评估并文档化系统要素之间相互作用的动态行 为。[成果 4] 注 2: 动态行为取决于运行模式（例如:启动、关机、正常模式、标定和诊断 等）。 SYS.3.BP5: 评估备选的系统架构。定义架构设计的评估准则。根据已定义 的准则，评估备选的系统架构。记录被选定的系统架构的选择理由。 [成果 1] 注 3：评估准则可以包括质量特性（模块性、可维护性、可扩展性、可扩缩性、 可靠性、安全（security）可实现性、易用性）和开发-购买-重用分析的结果。 SYS.3.BP6: 建立双向可追溯性。建立系统需求和系统架构设计的要素之间 的双向可追溯性。 [成果 5] 注 4：双向可追溯性覆盖系统需求向系统架构设计的要素的分配。 注 5：双向可追溯性有助于覆盖率、 一致性和影响分析。 SYS.3.BP7: 确保一致性。 确保系统需求和系统架构设计间的一致性。[成 果 1, 2, 5, 6] 注 6：一致性由双向可追溯性支持，并可通过评审记录来证明。 注 7: 系统需求通常包括系统架构需求。参见 BP5。 SYS.3.BP8: 沟通约定的系统架构设计。与所有相关方沟通已约定的系统架 构设计及对系统架构设计的更新。[成果 6]

输出工作产品

04-06 系统架构设计 → [成果 1, 2, 3, 4, 5] 13-04 沟通记录 → [成果 6] 13-19 评审记录 → [成果 5] 13-22 追溯记录 → [成果 5] 17-08 接口需求规范 → [成果 3]

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]

6.关于软件开发

有点懒，就直接摘录了，此处与本人开发过程相关，摘录参考《© VDA Quality Management Center》

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] 注 4：对成本和进度的影响分析有助于项目估算的调整。参见 MAN.3.BP5。 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：如果只有软件开发，系统需求和系统架构是指软件的运行环境（参见注 2）。在这种情况下，必须确保利益相关方需求与软件需求之间的一致性和双向 可追溯性。 SWE.1.BP8:沟通约定的软件需求。与所有相关方沟通约定的软件需求及对 软件需求的更新。[成果 8]

输出工作产品

13-04 沟通记录 → [成果 8] 13-19 评审记录 → [成果6] 13-21 变更控制记录 → [成果5, 7] 13-22 追溯记录 → [成果1, 6] 15-01 分析报告 → [成果 2, 3, 4, 7] 17-08 接口需求规范 → [成果1, 3] 17-11 软件需求规范 → [成果1] 17-50 验证准则 → [成果 2]

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]

输出工作产品

04-04 软件架构设计 → [成果 1, 2, 3, 4, 5] 13-04 沟通记录 → [成果6] 13-19 评审记录 → [成果5] 13-22 追溯记录 → [成果5] 17-08 接口需求规范 → [成果 3]

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]

输出工作产品

04-05 软件详细设计 → [成果 1, 2, 3] 11-05 软件单元 → [成果 6] 13-04 沟通记录 → [成果 5] 13-19 评审记录 → [成果 4] 13-22 追溯记录 → [成果 4]

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

输出工作产品

08-50 测试规范 → [成果 2] 08-52 测试计划 → [成果 1] 13-04 沟通记录 → [成果 5] 13-19 评审记录 → [成果 3, 4] 13-22 追溯记录 → [成果 4] 13-25 验证结果 → [成果 3, 5] 13-50 测试结果 → [成果 3, 5] 15-01 分析报告 → [成果 3]

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] 注 6： 双向可追溯性有助于覆盖率、一致性和影响分析。 SWE.5.BP8: 确保一致性。确保软件架构设计要素与软件集成测试规范中 的测试用例之间的一致性。[成果 7] 注 7： 一致性由双向可追溯性支持，并可通过评审记录来证明。 SWE.5.BP9: 总结和沟通测试结果。总结软件集成测试结果，并与所有受 影响方沟通。[成果 8] 注 8：在总结中提供来自测试用例执行的所有必要信息，以便其他方可以判断结 果。

输出工作产品

01-03 软件项 → [成果 4] 01-50 集成软件 → [成果 4] 08-50 测试规范 → [成果 3, 5] 08-52 测试计划 → [成果 1, 2] 13-04 沟通记录 → [成果 8] 13-19 评审记录 → [成果 7] 13-22 追溯记录 → [成果 7] 13-50 测试结果 → [成果 6, 8] 17-02 编译清单 → [成果 4, 7]

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

输出工作产品

08-50 测试规范 → [成果 2, 3] 08-52 测试计划 → [成果 1] 13-04 沟通记录 → [成果 6] 13-19 评审记录 → [成果 5] 13-22 追溯记录 → [成果 5] 13-50 测试结果 → [成果 4, 6]

7.ASPICE认证的典型问题

a.为了管理各个工作产品，以及支持ASPICE过程，一般都需要有相关的工具作为支持，典型如ALM工具；

b.ASPICE提供了各个WP的要求，但是并没有提供模板，一般认证机构会提供相应的模板；

c.针对每个过程，评估师如何打分？这个依赖对应的评估师，一般评估师会提前提要求；

d.ASPICE过程与功能安全过程基本类似，一般经过ASPICE认证后，能满足功能安全要求。