再谈双向追溯性

引子

双向追溯性(bi-traceability)是ASPICE模型在工程活动中的一个主要要求。很多项目在为了满足ASPICE要求时，常常的感觉是：“花了很多工作量来做双向追溯性，却没得到多少收益”。

本文分析和解读双向追溯性的目的及作用，期待项目能通过双向追溯性，获得更多的收益及价值。

（1）ASPICE模型中的双向追溯性要求 

如上图所示，ASPICE模型中包括四类双向追溯性要求：

• ① V模型左边的垂直追溯
• ② V模型左边的“各层次的需求或设计”与V模型右侧的“验证(测试)规范”间的水平追溯
• ③ V模型右边的“验证(测试)规范”与“验证(测试)结果”间的追溯
• ④“变更请求”与“变更请求影响的工作产品”之间的追溯

说明：本文如下内容主要包括上述的①/②，不包括上述的③及④。

（2）双向追溯性的本质目的

举例说明：

如上图所示，【系统需求分析活动】的输入是《相关方需求》，输出是《系统需求》。

通常的汽车ECU产品的《系统需求》和《相关方需求》规模都很大。

在这样的场景下，通过什么方式，来保证：

1）《系统需求》中覆盖了所有的《相关方需求》

2）《系统需求》中，没有非预期的内容（即：没有包括《相关方需求》中没有包括的内容）

最常见的解决复杂问题的方法，是将问题进行系统化的结构分解，分解到“可控”的颗粒度。例如：

如上图所示，《相关方需求》和《系统需求》分别进行了分解，之后建立了《相关方需求》和《系统需求》之间的双向追溯性关系：

(1) 正向追溯：《相关方需求》—>《系统需求》

• S-Req1 : Sys-Req1, Sys-Req2
• S-Req2 : Sys-Req3
• S-Req3 : Sys-Req2

(2) 反向追溯：《系统需求》—>《相关方需求》

• Sys-Req1 : S-Req1
• Sys-Req2 : S-Req1, S-Req3
• Sys-Req3 : S-Req2

基于如上的追溯性关系，工程师就可以方便的确认，双向追溯性的两端，其内容是否是正确的，例如：

通过如上的分析，可以了解到：

双向追溯性的本质目的是帮助确认某个工程活动的“输出工作产品”与“输入工作产品”之间的一致性。

（3）双向追溯性的颗粒度

在建立双向追溯性时，工作产品需要分解到“可控”的颗粒度，在这个颗粒度上，工程师可以比较容易地进行工作产品之间一致性的确认。

什么是可控的颗粒度呢？

VDA Guideline中对此有明确的建议，例如《系统需求》及《相关方需求》需要分解到“需求”颗粒度。

此部分内容可参考本公众号的如下文章：

• ​​VDA Guideline解读（1）：bi-traceability and consistency​​

当然了，VDA Guideline中的只是建议，在某种特定场景下，即使没有满足VDA Guideline要求，只要双向追溯性可以很好的支持工程师进行工作产品之间一致性的确认，也是可以接受的。

（4）双向追溯性的其它作用

基于双向追溯性，还可以支持项目做如下的事情

• 需求的实施状况（例如：有多少需求被测试通过了，有多少需求还未着手，有多少需求在开发中）
• 变更场合，有哪些受影响的工作产品
• 影响分析（当实施CR或缺陷修复时，影响到哪些需求/设计）

推荐阅读：

• ​​Automotive SPICE和Automotive SPICE评估的那些事​​
• ​​如何达到并维持Automotive SPICE能力度级别​​
• ​​引入Automotive SPICE，企业要知道的二三事​​
• ​​引入Automotive SPICE，企业要知道的二三事（续）​​
• 欢迎访问公众号菜单，2020及2021文章合集下载

文章转载自公众号：仨人谈起