我们经常会看到这样的场景：领导询问开发进度，这就涉及到从需求（开发范围）到任务的跟踪；某测试人员抱怨需求人员修改了需求没有告诉他，这就涉及到从测试用例到需求的跟踪以及需求变更时的影响分析；由于缺乏可跟踪性，还会无法通过审计，例如CMMI、ISO26262、FDA等等。所以，对可跟踪性的需求一方面是来自于内部的管理压力，另一方面也来自于外部的监管。随着中国融入全球经济的加速，外部监管、对于标准的遵从也变得愈发重要和迫在眉睫，这一点在医疗设备、汽车、航空航天等行业表现得尤其明显，因为你想要进入国际市场，就得遵循国际标准。

道理很浅显，大家都很明白，可是之所以研发管理的可跟踪性依然做得不怎么样，这就涉及到流程建设和工具基础设施问题了。所谓思维要到位，技术手段也得配套跟上。

所以，本文要从三个维度来聊一聊可跟踪性：缺乏可跟踪性的案例；可跟踪性治理；实现可跟踪性后带来的收益。 

1 缺乏可跟踪性的案例

想像一下这个场景：您的一个与安全有关的项目已经到了尾声，所有的项目工件之间已经建立了可跟踪性。当审计人员到来时（这个审计可以是内部的质量保证人员、客户或外部监管机构），您需要演示给他们看哪些软件需求来自哪些系统需求。现在，每个软件需求被链接到了一个或多个系统需求，并且任意的系统需求也被链接到了一个或多个软件或硬件需求。看上去，对于通过审计来说，一切都很完美，对吧？ 

尽管花了很多精力来建立链接，然而，从审计的眼光看来：虽然许多软件需求不知怎么就和系统需求建立了关联，然而，整体的可跟踪性策略却并不清晰。接下来，如果在进一步的审计采样中确定系统需求的某些方面没有在软件（或硬件）中得到实现，审计就开始变得有压力了。 

通过这个案例，我们看到虽然有良好的建立可跟踪性的意愿，但由于缺乏方法，也会导致失败。最终得到的效果，也许就像下图这样的一团糟：

2 实现可跟踪性的治理

有了这次失败的经历后，您也许会重新思考：为了达到良好的可跟踪性所花的时间和金钱到底值不值得？毫无疑问，您的大脑中会产生一个疑问：如果效果这么差，那么我使用工具和在上面投入如此多的时间的理由是什么呢？您也许会考虑在接下来的项目中，大幅减少在这方面的时间和精力投入。 

这一决定正确吗？逃避问题无助于问题的真正解决。您应该进行根因分析，找出真正的问题所在。从根本上说，工具是非常有价值的，并且，如果以正确的方式来建立可跟踪性，还会带来显著的附加价值。 

产生这一问题的主要原因常常是由于试图“链接所有事物”到“所有事物”的盲目做法所带来，而不是建立项目特定的可跟踪性策略。从前，在没有便利的工具支持创建可跟踪性时，这一问题几乎不存在，因为创建这样的可跟踪性已经远远超出了可接受的范围。基于这一事实，项目经理和团队就被迫围绕如下问题深入思考：

• 危害和风险分析的结果分别在哪些需求中实现？

• 用来实现（真的实现了吗？）考虑中的系统功能（等于系统需求）的软件需求是什么？

• 哪些软件需求并不是来自于系统需求，而是由于架构设计决策的结果，因此应该认为是“派生”需求（没有与其他功能需求的链接）？

• 哪些源代码不是来自于功能需求，而是（例如）来自于到硬件的接口？

• 哪些源代码之所以出现，是由于采用了防御性编程原则，而不是基于功能需求？

• 哪些测试用例分别验证了哪些需求？

• 哪些需求分别在哪些架构部分中实现？ 

这一问题列表还可以再多，但它们对于您想在项目中实现真正有用的可跟踪性，是一个很好的思考点。 

感谢Polarion这一现代和创新的工具对可跟踪性的良好支持，才使得在今天能更轻松地在软件开发过程中的工件之间建立有意义的关联（这才是可跟踪性的本质！）。她可以极大降低创建可跟踪性的复杂度和出错率。 

如果您已经了解了本文所描述的问题，并且设计出了相应的可跟踪性策略，那么就要恭喜您，您已经上路了，通过审计当然也就毫无压力了！ 

限于篇幅，这里并没有全面展开如何在Polarion中实现可跟踪性治理，先上几张图吧，具体的实现下回接着讲：

图注：从原始需求到源代码的钻取分析

图注：从需求到测试用例、缺陷的三维跟踪 

3 实现可跟踪性后带来的收益

这里仅列举一些：

• 强有力的手段，确保客户请求得到了真正的实现

• 轻松而快速的从系统需求导航到源代码/硬件实现

• 当发生变更时，有效支持变更分析，避免变更遗漏支持并简化产品实现的完整性检查

• 支持并简化产品验证的完整性检查

• 用来跟踪实现与验证进度的良好手段 

可跟踪性是实现良好研发管理的基石，Polarion通过全方位丰富手段实现可跟踪性。本文试图从理论层面略作梳理，下文将从平台的支持层面帮助您了解到当今最前沿的ALM工业实践是如何做到这一点的。

（未完待续）