绝不能“不进行追溯”：对实现可追溯性的实践性建议（转与 Rational Edge）

 
developerWorks中国
本系列的更多信息:
Rational Edge

本文内容包括：
理论：基本法则
实际的追溯性
总结
注释
参考资料
致谢
参考资料
关于作者
对本文的评价

相关链接：
Rational 技术文档库
Rational Edge 电子月刊中文版


developerWorks 中国  >  Rational  >
Rational Edge: 绝不能“不进行追溯”：对实现可追溯性的实践性建议

文档选项

将此页作为电子邮件发送

拓展 Tomcat 应用

下载 IBM 开源 J2EE 应用服务器 WAS CE 新版本 V1.1
级别： 初级
Thomas Behrens, CTO, Alpheus Solutions
2007 年 4 月 16 日
本文来自于Rational Edge：建立软件需求与已实现的特性之间的追溯关系是迭代、增量软件开发中最常被忽视的实践。本文中作者将介绍追溯性，并且介绍将追溯技术集成到您的开发环境中的具体技术。
在软件开发项目中出现的非常频繁的是，需求不符合涉众的意愿，重要的功能丢失了，不必要的特性出现在最终产品中 ——所有这些都“不具备可追溯性”。换句话说，与具体特性有关的工作和对该特性的实际需求之间不存在明显的联系。但是，可追溯性的概念生来就与要交付的产品的质量相联系。不幸的是，可追溯性常常被作为不必要的孤儿对待。
实际上，在我的顾问经历中，需求工程中没有一个方面是 1) 作为对工程工作至关重要的部分被经常引用的，并且 2) 在实践中常常被忽略的 1。 我将说明我认为这种忽视的根源是什么。然后我将提出大量最佳实践来应对这些原因。虽然可追溯性还应用于 Rational 统一过程 (Rational Unified Process，RUP）的其他规程 —— 并且与可追溯性存在许多关联，例如，问题、假设和风险 —— 但是本文将主要关注需求规程。
本讨论假设读者基本了解需求工程，并且理想化的使用用例。
让我们从一些需求追溯关系背后的理论开始。
什么是可追溯性？
根据 IEEE Standard Computer Dictionary 2 ，追溯被称为“开发过程中两个或多个产品之间可以建立的关联的程度，特别是与其他产品有前驱后继或主次关系的产品”。
Rational 统一过程（Rational Unified Process，RUP）将可追溯性的概念更一般地定义为“追溯项目要素到其他相关项目要素的能力，特别是那些与需求相关的要素。”
如您所见，“可追溯性”是非常一般化的概念，容易理解。尽管如此，问题是大多数人会立即绘制出拥有定义明确的层次的简单层次结构，例如主次关系。但当现实更复杂时，无知（或现代化的选择：工具依赖）就取代了常识、规程和对一些基本法则的遵守。因此，可追溯性信息根本没有建立，或只是敷衍的建立，而且您失去了提高质量并且快速响应变更的机会。您如何能阻止这种事的发生呢？为了回答这个问题，我们首先需要了解我们为什么想要追溯。拥有追溯关系的好处是什么？
追溯有两个重要的目标：
通过证明产品具有涉众所要求的所有功能，并且通过证明产品没有表现出涉众没有要求的任何功能，确保产品的质量（“构建恰当的产品”）。质量的另一方面是确保所要求的功能能恰当运行（“正确构建产品”）。在开发过程中，“确认” 3 维度追溯不同的抽象或细化级别。“验证”追溯将需求、分析及实现的工作产品追溯到各自的测试。这两个维度，“确认”和“验证”追溯，如图 1 所示，引用了核心的 RUP 规程。 支持变更的影响分析，确认出受影响的需求、设计，及实现工件，以及相关的测试。

图 1：追溯关系维度
除了这两个目标之外，还有一些切实的好处，主要是关于进展报告和项目状态的评定： 4
已实现需求的百分比？ 成功实现的（也就是，经过测试的）需求的整体百分比？ 如果变更了具体实现，那么需要重新运行的用户试验测试的数量是多少？
但当我们了解了好处之后，我们如何着手实现可追溯性呢？以下部分根据上面提到的“确认”追溯概念介绍需求的追溯关系。
追溯需求的必备条件是需求类型的清晰定义。需求类型是根据最普通的“涉众请求”、“特性”、“用例”和“补充需求”，在不同的详细或抽象级别上的需求分类。（要了解介绍性的内容，参见附注 2）。不论您什么时候编制一个需求，它都必须属于一个具体的需求类型。
除了需求类型以外，层次 —— 或更一般的说法，需求类型之间的一组有效的关系 —— 必须要定义。该关系确定了需求类型追溯到哪个需求类型，或从其他哪个需求类型追溯而来 5 。需要注意一些复杂性：
一个需求类型可以追溯到超过一个的其他需求类型。举例来说：特性表示系统功能视图。用例表示来自最终用户视角的目标。用例主要覆盖功能需求，且因此使用补充需求来获取以用例格式没有记录好的需求。因此特性可以追溯到用例或补充需求（参见图 2）。 需求类型的实例可以追溯到另一个需求类型的多个实例（而反过来基于追溯来的关系）。举例来说：具体特性能追溯到许多用例，但用例可以由许多特性追溯而来，导致许多如图 2 中所示的关系。 7
在需求层次的根部，我们拥有可以归到个别涉众身上的涉众请求，他的请求是根据项目范围进行评估的。
需求类型及其关系一起被称为追溯策略。追溯策略必须预先确定，并且应该编进需求管理计划（标准的 RUP 工作产品）。为了让需求是可追溯的，它必须是可引用的 —— 也就是，在不同的工作产品之上，必须将它在整个生命周期中明确确定。

图 2：追溯关系
可以明确的且隐式的追溯到需求。明确的追溯要求您手动地建立两个需求类型之间的关系。隐式的追溯是由可追溯项（也就是，您的需求类型）之间的本来关系产生的 —— 举例来说，实际的层次需求，或通过自动地向您的工作产品应用转换。 8 。
在大多数情况下，追溯关系被显式地处理。
建立显示的追溯关系有许多不同的方法。两个需求之间的逻辑追溯关系 —— 由它们的标识符表示 —— 可以通过各种不同的方法来物理地实现。最普遍的是：
在需求工作产品中，在需求定义的地方（例如，在对照索引中）。 在需求工作产品中，一个专用的部分中（例如，在对照索引的表中）。 需求工作产品的外部（例如，通过电子表格、定制数据库或专用的需求管理工具）。
选择 1 常被称为“鲁莽的追溯”，因为需求和追溯关系定义在相同的地方。选择 2 和 3 被称为“客气的追溯”，因为追溯关系与需求分别维护。
让我们来快速地评价一下这几个不同的选择：选择 1 应该彻底报废。这样的文档不但会很快就难于维护，而且读者会被文字中的追溯信息搞乱，这使得文档很难阅读。此外，追溯不是对于需求所获取的唯一的元信息。其他信息，例如优先级、状态，或风险也需要维护。选择 2 表现为一种折中的方法，并且如果策略确保 trace-from 追溯关系只建立于文档中，或上溯到稳定的文档中，它也有效。这使得选择 3 成为最令人期待的追溯方法。电子表格会使您的工作很费劲，但专用的需求管理工具，例如 IBM Rational RequisitePro，是为管理这种类型的信息特别设计的。
如您所见，在大多数情况下，建立追溯性需要人工操作。因此，成本效益分析一般就成为实现适当追溯策略的推动力。
首先您需要有需求。需求可以通过各种途径出现，但编写需求的人 9 负责撰写需求，创建标识符并建立追溯性。
已知建立并维护追溯关系的基本法则很简单，那么似乎很难理解的是，为什么大量项目一直放弃追溯。这种现象经常被这样解释“工作太多”以及“利益不明显”。这可以由以下根本原因来解释：
没有为项目定义可使用的，一致同意的追溯策略。 没有把追溯性看成需求工程的主要部分。 努力付出了，但从没认识到好处
以下介绍了一些最佳实践，它们将应对一个或多个上述三个根本原因，见括号中提示。
建立恰当的追溯层次。不要过度地雄心勃勃。我曾见过一些项目，已知它们的时间限度，和它们使用基于用例的方法的成熟度，它们试图追溯到不恰当的详细层次。在您第一个项目中，不要尝试向下追溯到个别用例步骤层次。您必须对追溯策略有深入的思考，并对实际的工作进行合理的判断。[1]
平均分配您的工作。包括将追溯性建立为需求编制的一部分。不让将其作为分离的任务。该任务经常延迟，即使只延迟了需求的一个子集，追溯关系就会变成碎片，并且因此没有用了。[2, 3]
对追溯性应用质量保证。当您执行检查或审查时，也要包括追溯性。追溯也会出错。首先，确保追溯性可用，其次，在使用之前确认，因此增加您使用它的信心。[2, 3]
调整并重新访问您的追溯策略。过去能够成功采用的追溯策略不一定永远有效。组织运作的项目变更了。项目的类型不同了。不同的项目需要不同的需求类型和/或为追溯定义的不同关系。从内部的开发项目到与外部厂商的集成项目可能引入了新的产品。从纯粹的传统（说明性的）需求方法到基于用例的方法引入了新的需求类型。您的追溯策略需要响应这些变更 10 。[1]
培养您的团队。追溯是团队工作。负责贯彻此规程的团队必须得到关于项目追溯方法的恰当培训。他们需要了解并理解的是，将需求追溯到其起源与撰写高质量的需求定义是同等重要的。[1, 2]
团队外的人员作为补充。如果您能够确定一个项目团队以外的人员来执行项目的追溯性需求，让该雇员为下一个变更请求做影响分析。这样也许会以更适当的方式传递消息。[2, 3]
如果怀疑做得少，不如做的恰当。有一个可以遵守的追溯策略比一个不完全策略的要强。后者需要一定的付出工作，但很可能不能带来好处。前者依赖于追溯策略中确定的详细层次，而且，如果要求提高了，可以 —— 按附加的成本，并且通过专用的，计划良好的过程 —— 进行扩展。[1]
想透彻，但不要让其成为负担。建立追溯信息时要勤奋且深思，但不要让追溯讨论占用您的团队会议（或者“单独为其开会”）。Pareto Law 也应用于追溯的维护。但如果有疑问，不管争论的结果怎样，建立追溯连接。这在复杂的影响分析中是有利的，可以确保您找到所有相关的详细阐述的需求。[1]
利用您的需求结构来支持追溯性。追溯性不应该驱动您编制需求的方法。但常常，结构好的需求文档会更容易地支持追溯性。举例来说：
特性“客户所有未付款的发票总量不能超过其信用额度”可能会被许多用例所引用，例如“(Customer) Place Order”，或者作为用例步骤的“(Account Manager) Adjust Credit Limit”。另外，该特性可能作为约束编制进领域概念“Customer”的描述中。这不但令文档更加可维护，而且您也可以提高追溯性。取代追溯多个用例步骤，您可以追溯到一个领域概念“Customer”，这就完全足够的，或者利用好的粒度层，您可以追溯到属性“所有未付款的发票的总量” 11 。[1, 3]
利用工具支持。工具不是银弹。它们没有消除必须确定追溯策略的负担，且它们不能确认您的追溯是正确且完全与否。但需求管理工具，例如 IBM Rational RequisitePro，允许您：
以隐式的方式在确定需求的集合上简单地建立并维护追溯 在一定程度上执行确定的追溯策略 支持经过需求层次的变更传播，根据已建立的追溯性，识别可能会受到该变更影响的需求 可视化并报告您的追溯（参见图 3）。
因此，这些 RequisitePro 的功能，减少了全部的手动工作，并且增加了追溯的可靠性。[1]
如您所见，您可以采用许多对策使追溯更容易建立，这将提高投资收益比，并因此首先使追溯成为可能。

图 3：IBM Rational RequisitePro 中的追溯关系矩阵允许您可视化并报告追溯关系。
迭代且增量的项目交付（预计并考虑到项目过程中相当多的变更），大大增加了在传统软件开发方法之上的追溯需求。因此，在项目过程中，任何可能更高的、预先的成本都更容易回收（参见工具条）。正确追溯需求的能力是对于在商业环境中管理遵从性的必要条件。追溯性是能力成熟度模型（Capability Maturity Model）中的基本概念。
要想在追溯中取得成功，需要预先选定恰当的追溯策略，清楚地编制并传达它，并且通过审查确保追溯策略被实现，并且有效的执行。这将使您在产品质量和受控变更方面获益。

项目接近尾声了。项目经理收到了一个变更请求，随后出资人打电话来要求快速评估该变更请求的影响。快速确认相关的涉众请求：“The frequency of the clearing cycle”。项目经理告诉了负责系统此部分的系统分析师。系统分析师收到了所有相关的需求文档，并且开始利用搜索引擎搜索与该需求相关的关键词：“‘Clearing Cycle‘、 Frequency”。项目经理看起来有点不安，并问：“为什么你不使用（在项目中一度存在的）追溯矩阵？”系统分析师快速回答：“没有人更新这些表格，因此，我不相信它们！”
此故事的教训在于：追溯不能“半途而废”。如果您不相信您的追溯信息，那么您最初就最好别干此工作。