当用户对工件运行分析时,他们可设置分析所探查的遍历(方向)。缺省情况下,有四个可用方向:上游、下游、两者(上游和下游)以及全面可跟踪性。此主题讨论全面可跟踪性遍历以及其与上游和下游的不同之处。以下图像显示 “影响分析图”屏幕中遍历选项卡上的遍历选项:

使用全面可跟踪性会产生比较大的影响分析图,因为全面可跟踪性遍历目标工件的每一个节点。 请小心使用此选项。如果您不确定全面可跟踪性是否为正确选项,请首先使用”两者”遍历选项。如果浏览目标工件的上游和下游工件,但并不浏览每一个节点,那么影响分析图包含的工件数量更少,执行的速度也更快。
以下场景讨论全面可跟踪性遍历可能比“两者”遍历更有帮助的情况。
场景 1:分配新开发者 John 来处理某个组件。John 从组件的设计开始,并浏览相关工件。因为 John 是项目的新开发者,所有他不了解可能的依赖关系和交互,即使他从最佳位置开始。John 使用“全面可跟踪性”遍历来查看向上从其中一个设计元素指向需求和包含模块的链接,而向下从模块中的其他需求指向设计的相关部分。John 还遵循以下链接:向下从设计元素指向测试用例,从测试用例指向自己拥有的测试计划,而相反从测试计划指向其他设计元素和需求。
场景 2:Susan 是一个产品经理,正在考虑进行更改以一般化她的其中一个产品中的组件功能。她使用“全面可跟踪性”遍历来了解该组件的配置和产品系列。她遵循向下从配置到类似配置的关系,但用于了解潜在更改位置的不相关组件可能使组件适用于包含在其他产品系列中。此包含增加组件复用并降低成本。
以下场景讨论两者遍历可能比“全面可跟踪性”遍历更有帮助的情况。
场景 1:开发者 John 必须对某些代码进行设计更改才能修复可伸缩性缺陷。在 John 更改设计之前,他希望复审上游和下游工件。
上游工件是与设计相关的需求和工作项。工作项可能描述可伸缩性问题的详细信息。John 已经分配给工作项,因此他不会通过可跟踪性链接了解太多,除了复查该链接是否存在之外。但是,查看上游需求很重要,因为他必须确保新设计满足需求,包括任何刚刚链接的业绩需求。
下游工件是测试用例。John 必须确保测试用例已更新为使用新设计。他可能还需要为新业绩和可伸缩性需求及其设计创建测试用例。
每个附加深度级别都会大大增加所描述的节点数。有时增加节点数正好是您所希望的操作,而有时并非如此。当您增加深度时应谨慎使用。
以下图显示了每一个与焦点工件相关的遍历(上游、下游、两者以及全面可跟踪性)是如何移动。
