未通过 ovf 规范一致性或虚拟硬件合规性检查。_汽车软件过程能力模型ASPICE解读3软件质量保证核心一致性...

上文给大家在末尾留了一个问题，为什么我会给出那几条对软件供应商质量审核的实践性条款？如果，对软件质量管理比较熟悉的同学，可能一看就明白了，这次内容给大家做一个说明。

01

软件质量保证核心-追溯与一致性

我们知道，质量管理就是符合要求，而要求是会经过一系列的过程步骤来进行传递的。所以，为了保证质量，最核心的是保证各种要求传递的符合性和经过系统工程分解后的一致性。因为，系统工程分解的质量，可能与设计能力相关，但传递的一致性，这个就属于质量管理范畴需要解决的问题了。

回顾之前给大家看的这个图，V模型

以V模型为导向的ASPICE工程过程，从客户需求/系统需求/系统架构/软件需求/软件架构/软件设计/软件架构到所有测试之间都存在着双向追溯关系。

但这个关系，如果按照瀑布模式展开，左边的工作都做完才能展开右边的测试项。但我知道，问题越早发现，解决代价越小。因此，等到左边再完成，错过，需求、架构设计、还有详细设计发现问题的，这也是在软件行业，大家基本都开始推行，敏捷增量迭代开发的原因。所有这些 需求，设计，包括对应的测试，都在一一个短周期内完成，来更好的保障质量。

敏捷不仅仅适用于互联网，在传统软件设计中也是可以适用的。所以，汽车软件生命周期过程，虽然是V模型，但绝对不等于是采用瀑布模型，这个大家一定要充分理解。我看有写老师，直接把体系的V模型，转为瀑布模型的输入输出，这个是值得商榷的。

02

相关体系标准的解读

ASPICE对于一致性和可追溯性的要求提出了非常具体的要求，下面内容主要来自SPICE PAM V3.1：

MAN.3项目管理 

MAN.3.BP9：确保一致性。确保项目的估算、活动、日程、计划、接口、承诺在各相关成员中保持一致。

解读:ASPICE要求项目管理要管控好项目估算、项目活动、项目日程、项目计划、内外部接口、相关承诺等方面，并且分析任何一项变更引起的关联其他变更，以取得相关成员的承诺和一致性理解。估算结果以及依托估算形成的项目计划，作为项目监控的重要输入，保持定量监控和定性监控与计划的一致性。

 SUP.8配置管理

SUP.8.BP8：确认配置项信息。确认配置项信息和相应的基线完整性，确保基线一致性。典型的方法是通过执行基线和配置管理审计。

解读:作为配置管理的一条基本实践，需确保配置项和基线的完整性一致性，并且在执行评审时，重点确认配置信息是否完整，与基线是否一致。做配置审计，物理审计的重点关注完整性/版本/模板等信息，功能审计完整性应深入结合工程过程组的要求进行审计。指定符合公司产品类型和研发管理现状的审计检查单。

SUP. 10变更申请管理

SUP.10.BP8：建立双向追踪。变更申请和变更引起的工作成果变动之间建立双向追踪。解读：比如，一项变更申请是由一个问题引发，变更申请和对应的问题报告应建立双向追踪。对变更点做影响分析，通过技术评审等方式从技术/成本等多个角度进行分析判断。

工程过程组对双向追溯和一致性要求

SYS.2系统需求分析/ SYS.3系统架构设计/ SYS.4系统集成和集成测试/ SYS.5系统合规性测试/SWE.1软件需求分析/ SWE.2软件架构设计/ SWE.3软件详细设计和单元实现/ SWE.4软件单元验证/ SWE.5软件集成和集成测试/ SWE.6软件合规性测试SYS.2.BP6：干系人需求和系统需求间建立双向追踪性。SYS.2.BP7：干系人需求和系统需求间确保一致性。SYS.3.BP6：系统需求和系统架构设计之间建立双向追踪，双向追踪涵盖系统需求分配到系统架构设计各模块。SYS.3.BP7：系统需求和架构设计间确保一致性。典型的系统需求包括系统架构需求，参照BP5。SYS.4.BP7：系统架构设计各要素和集成测试规范的测试用例间建立双向追踪，集成测试规范的测试用例和测试结果之间建立双向追踪。SYS.4.BP8：系统架构设计的各要素和集成测试规范中的测试用例间确保一致性。SYS.5.BP5：系统需求和系统合规性测试的测试用例之间确保一致性和双向追踪性。测试用例和测试结果之间确保一致性和双向追踪性。

SYS.5.BP6：系统需求和合规性测试规范中的测试用例间保持一致。

WE.1.BP6：系统需求和软件需求间建立双向追踪性，系统架构和软件需求间建立双向追踪性。SWE.1.BP7：系统需求和软件需求间确保一致性，系统架构和软件需求间确保一致性，在只有软件开发的情况下，系统需求和系统架构指给定的操作环境。这种情况下，需确保干系人需求和软件需求的一致性和双向追踪性。

SWE.2.BP7：软件需求和软件架构设计各模块间建立双向追踪。

SWE.2.BP8：在软件需求和软件架构设计之间确保一致性，软件需求包含软件架构需求。SWE.3.BP5：软件需求和软件单元之间，软件架构设计和软件详细设计之间，软件详细设计和软件各单元之间，建立一致性和双向追踪性。 

SWE.3.BP6 ：确保软件需求和软件各单元间的一致性，确保与软件架构的一致性，确保详细设计和软件单元间的一致性。

SWE.4.BP5：软件单元和静态测试结果之间，软件详细设计和单元测试规范之间，，单元测试规范和单元测试结果之间建立双向追踪性。

SWE.4.BP6：软件详细设计和单元测试规范之间保持一致性。

SWE.5.BP7:软件架构设计和集成测试规范中的测试用例间建立双向追踪，集成测试规范中的测试用例和测试结果间建立双向追踪。

SWE.5.BP8：软件架构的各模块和集成测试规范中的测试用例间保持一致性。

SWE.6.BP5：软件需求和合规性测试规范中的测试用例间建立双向追踪，合规性测试规范的测试用例和测试结果间建立双向追踪。

SWE.6.BP6：软件需求和合规性测试规范中的测试用例间确保一致性。

解读：系统工程过程组和软件工程过程组，均分别有两个实践是对一致性和双向追踪的要求，现将互相之间的依赖关系整理如下：(1)双向追踪包括覆盖率，一致性和影响分析。(2)一致性通过双向追踪来实施，通过评审记录来证明。(3)在只有软件开发的情况下，系统需求和系统架构指给定的操作环境，这种情况下，需确保干系人需求和软件需求的一致性和双向追踪性。(4)软件单元测试用例来源于软件详细设计，单元测试的人员是，研发人员而不是测试。(5)集成测试用例来源于架构设计。(6)合规性测试用例来源于客户需求。

03

具体的案例分析

我们来看一个具体 需求追踪的例子：

整个模板其实并不复杂，不再多做解释了。

如果需要，具体需求追踪矩阵课编辑模板的，可以扫码联系，免费赠送。

-End-

如果觉得文章还行，别忘记点 在看！

由于一群已满，对质量研发管理感兴趣同学，可以扫我的码，入二群

注明：文中大量引用标准相关文档内容及网络部分资源，版权归原作者，如有侵权请联系立即删除。