ASPICE 追溯性实践分享

01前言

接着之前的分享，遗留的追溯性ASPICE 认证实践及个人理解分享-CSDN博客文章浏览阅读961次，点赞22次，收藏17次。ASPICE是Automotive 和SPICE的组合，全英文为（Automotive Software ProcessImprovement and Determination）中文为汽车软件过程能力提升和能力评定。https://blog.csdn.net/weixin_43957681/article/details/137726102?spm=1001.2014.3001.5501我们在实践中应该如何实现各环节的追溯性呢？本篇文章将做简单的分享，如有不足之处，欢迎批评指正。

如上图所示，追溯性主要体现在：

需求拆分追溯（利益相关方需求拆解，系统需求拆解，软件需求拆解等），
需求和设计的追溯（系统需求和系统架构设计，软件需求和软件架构设计）
需求和测试用例的追溯（系统需求和系统测试，软件需求和软件功能测试）
测试用例和测试结果（Bug）的追溯
设计和测试规范的追溯
需求和变更的追溯

通过解决追溯性问题，ASPICE能够确保软件开发过程中各个阶段和活动之间的关联性和一致性，从而提高软件开发的质量和可靠性。追溯性也有助于提高开发过程的可管理性和可追踪性，减少因开发活动之间的不一致性而导致的风险和问题。

02追溯微观结果示例及介绍

“微观”追溯指的是针对具体的某个需求，下图举例的是SYS.2的一个需求（需求的内容是汽车BCM部件对应的一个简单需求示例，大家无需关注需求内容）。

当建立好完整的需求追溯以后，针对特定的某个需求，直观的效果应该能够达到，需求来源于哪里，需求被拆分成了多少个更详细的需求，需求的设计是怎样的，需求的实现进度如何，需求的测试用例有哪些，需求对应用例的测试结果如何（是否产生了bug）？

如下将对具体各个部分进行介绍：

需求的属性内容。如上图第一部分，里面描述了需求的基本内容，所属产品，描述，等属性。实践中，该环节主要以表格的方式呈现，不同的列定义了需求的不同属性，如优先级、实现团队、时间要求等等。
需求的拆解追溯。如上图第二部分，可以看到一个SYS-R1的需求被拆解成为了SR1.1,SR1.2,SR1.3三个软件需求。用Child 标识了。其实还应展示需求的上层需求，及需求的Parent，但实践中，有时系统需求可能会直接复用利益相关方的需求，需要根据实际情况调整。
需求的设计追溯。如上图第三部分，此处展示的的是该需求在具体的设计文档中，被如何设计的，点击链接即进入对应设计文档或其他有引用的文档内，以查看依赖关联关系。
需求的实现过程追溯。如上图第四部分，该需求共有2个执行的任务，分别是系统需求设计，编码实现，测试用例执行。并可以看到每一个任务当前都还是TODO的状态，即说明该需求当前还未实现。
需求的测试用例追溯。如上图第五部分，需求对应六个测试用例，其中3个用例当前未执行（no result）,2个执行通过，1个执行失败。
需求的测试结果追溯。如上图第6部分，需求测试产生了一个bug【BDP-1】，且该bug和第五部分执行失败的用例是有对应关系的。

如上就是特定需求下能清晰的展现该需求的各类依赖关系。