进退两难
RUP 包含一个工件扩展库，其中有许多您不需要的东西。没有一个组织需要全部的内容。事实上，RUP 最新版本（7.0）的第一个关键原则是“使过程适应组织和项目”，所以您需要将 RUP 按您的组织及其项目的大小和需求进行剪裁。这样剪裁的结果是 RUP 的一部分，被称为开发案例（development case）。在开发案例中，您将描述在项目中使用的所有活动、角色、工件和模板。
每个所选择的支持工件（可交付的）都将需要资源来生产它。向开发案例中添加的每一项元素都应该根据期望的效益进行平衡，您需要考虑的方面包括：时间节省、质量获得，或为项目评估、计划和范围管理提供的基础。换句话说，开发案例太大将会不必要地浪费项目的钱。问题是：您如何继续让您的开发案例正常？您打算自己找出如何剪裁 RUP 的方法吗，或者您打算从外面雇佣一个 RUP 顾问或过程工程师吗？自己处理 RUP 的裁剪，让您的团队等着您的指导，在缺乏剪裁 RUP 的内行经验的情况下，这样做是很困难的。您将不得不花费一些时间来找出哪个工件要被略去、哪个要被添加，并且确定应该如何用它们来适合您的项目，或组织。事实上，您需要了解 RUP 的全部才能够以合理的方式对它进行剪裁，因此您将在将来的六个月中非常繁忙。
另一种方法，您可以雇佣一个 RUP 顾问，一个可以在什么工件是强制的，以及在特定的情况下只需要哪个工件的方面指导您的人。顾问可以帮助按照您的需求修改 RUP 模板，并最恰当地将它们用于创建有用的工件工具。但是外部的 RUP 顾问对您的业务的了解是有限的，更不要提您的组织或公司的文化。这意味着顾问将使用相当多（昂贵）的时间了解您的业务 —— 否则，结果将是剪裁出来的开发案例并不符合您公司的需求和特性。
我们已经扮演过外部的 RUP 顾问的角色，并且为各种各样的公司成功地定义了开发案例。作为顾问，我们相信剪裁 RUP 的外部专家经验的价值，并且我们已经开发了帮助加速剪裁过程，并且与此同时描述组织具体需求的技术。我们将介绍两个概念：职责矩阵和工件流。
职责矩阵
我们基于建立“什么”和“谁”利用面向目标的方法来剪裁 RUP。我们开始研究项目应该交付 什么 （哪些工件）。由工件开始的一个很大的优势是工件是有形的东西。通过观察哪些工件获得的基线状态（已经被正式地批准）可以很容易地检查项目进展。
工件必须总是有用的。这可能听起来微不足道，但是在许多情况下，我们发现了由那些不知道工件用途的人撰写的工件。我们经常提出的问题是，“如果没有工件被生成，将会出现什么问题？”这个问题的答案澄清了工件的目的。如果您不能找到此问题的具体答案，那么有很大可能性此工件是多余的。
在决定生成哪个工件之后，我们研究 谁 （哪个角色）负责创建每个工件。我们将工件、角色和职责一起放入我们的职责矩阵中。我们在最左边的列放工件，在最顶端的行放角色。在交叉部分我们放上表示各种职责的符号。这就形成了如图 1 所示的矩阵。
图 1：职责矩阵实例
工件的作者不仅涉及创建此工件的那个人。要完成矩阵，我们还要研究哪些角色支持创建过程，以及哪角色些负责正式地接收一个工件。通过访谈、讨论会和评论的方式能够支持角色给出输入。当然，我们能够识别出细粒度的职责，但这很少有用。注意，负责工件（将其写在纸上或汇集工件）的角色是实际的作者。由于这涉及特殊的技能，因此该职责不容易委托。例如，我们要注意的是不要将太多的工件分配给项目经理。他或她应该只撰写并负责管理工件。
职责矩阵将使简化我们得到适当的开发案例的过程。它提供了许多优点：
◆我们可以在所有涉众出席的一个（或多个）会议上填写职责矩阵。这使其成为每个人都同意的联合工作。
◆我们不需要对业务有很多的了解来支持职责矩阵的创建。
◆职责矩阵可以被用来作为开发案例的一部分，以非常简洁且易读的方式提供对所剪裁的 RUP 的主要构建模块的概述。
填写职责矩阵
职责矩阵可以通过不同的方法填写。我们将看一看其中的三种。
策略 1：从 100% RUP 开始
通常的起始点是一组标准的 RUP 工件和角色。RUP 顾问对组织中需要什么 RUP 工件和角色进行有根据的推测，并填写职责矩阵中的所有职责。该职责矩阵随后用作与涉众进行讨论的基础。
然而，该方法有两个不利方面：
与公司经验不相关。职责矩阵没有使用涉众熟悉的角色和工件。
从涉众的观点出发，RUP 引入了所有的新词汇。因此职责矩阵很难让人理解。这各问题可以通过给人们具体的 RUP 培训，按照开发案例来剪裁来解决。
策略 2：从中间开始
在此策略中，RUP 顾问提供一个合理的工件及角色集合，如果需要的话，包括一些具体公司的工件和角色，并将这些填写在职责矩阵中。但不填写交叉部分。RUP 顾问应该设法使所有公司特有的工件和角色不覆盖已经在 RUP 中确定的内容。在对工件和角色进行解释之后，可以将它们移动、重命名或替换，并且通过完成职责矩阵将职责进行划分。
公司特有的工件和角色的使用，以及涉众选择其职责的事实，使从其中识别新的开发案例更加容易。然而，该方法也有一个不利方面：
提供工件和角色的合理集合需要业务知识。这意味着 RUP 顾问不得不花时间学习业务知识。
策略 3：从零开始
我们喜欢“从零开始”的策略。RUP 顾问从调查会议开始，在这个过程中，公司中所有的涉众都会出席。在该会议中，将讨论公司中存在的工件和角色，并放入到职责矩阵中。还应该讨论为什么使用某个工件或角色的理由。通常，当参与者说明现有的工件和角色的意图时，在被识别出的角色和工件中的差别、重叠和不一致的地方将会出现活跃的讨论。在此情境下，RUP 顾问扮演者中介的角色，接受涉众提出的角色和工件，并试图找出相应的 RUP 角色和工件。涉众最终同意每个角色和工件是至关重要的。
此方法的优点是涉众（RUP 的外行）可以从熟悉的工件和角色开始，并且可以互相并对 RUP 顾问清楚地说明他们的意图。RUP 顾问（业务的外行）而后可以使用他或她的 RUP 知识，在可能的地方转化涉众对 RUP 的输入，并且识别出应该被保留的公司特有的角色和工件。
RUP 拥有许多详细的角色和工件。扩展或减少 RUP 工件的内容来满足公司的需要可能是有用的。将若干角色的职责联合为一个角色，或将许多现有的角色中的一个 RUP 角色的职责分开也是可能的。例如，RUP 有一个管理员角色，系统管理员。在许多公司中，该角色分为两个：一个负责硬件和操作系统，而另一个负责管理应用程序。
在创建职责矩阵的过程中，将新的职责矩阵中的工件和角色映射到公司的原始职责设置是有用的。这将帮助人们将在新的 RUP 方法中期望他们做什么，与他们当前的工作联系起来。
该方法的结果是尽可能多地确定了 RUP 角色和工件的职责矩阵。这意味着每个团队成员都可以利用大量的 RUP 文档来获得对新方法的更好了解。同时，有一些 RUP 知识的新的团队成员可以快速地找到他们在项目中的路标。然而，与此同时，职责矩阵根深蒂固的来源于公司的现有最佳实践。
一旦对要使用哪些角色和工件，以及如何称呼它们达成了一致，RUP 顾问就可以继续在职责矩阵中分配职责了。通常，我们在一个单独的会议中做这件事。每个工件应该至少有一个给予了“写”职责（W）的角色（实际的作者），而大多数工件同时要收到贡献/审阅的职责（C）。此外，一些工件必须正式地被接受（A）。参见图 1 的实例。
工件流
在与现场的所有涉众确定了职责矩阵之后，下一个步骤是添加更多详细信息。在此阶段，我们着重于在职责矩阵中已经定义的工件之间的关系。
一般而言，工件流在一个单独的会议中被设定，同时建立工件之间的关系。设想我们对以下的工件达成了一致：前景、用例模型、软件架构文档、用例规格说明、用例实现和组件。那么做出关于它们之间关系的提议是非常容易的。我们只专注于工件之间的关系，而不关心哪些角色使用它们，或负责创建它们。参见图 2 中的例子，其中使用了被提及的工件。
图 2：工件流实例
前景和用例模型之间的关系是直接的，单向关系。用例模型 源自于前景。这不意味着用例模型只能够包含来自于前景的元素。用例模型应该表示与前景相同的范围，只是更详细。任何前景范围以外的用例模型元素都应该引起一场关于调整前景或从用例模型中去掉超出范围的元素的讨论。
软件架构文档（SAD）也源自于前景，并且上面进行的观察在这里也是有效的。软件架构文档也收到来自于用例模型的输入，由于在 SAD 中，我们需要一个对认为哪个用例在架构上是很重要 —— 也就是，哪个来自于系统的核心 —— 的描述。而用例模型又是随后的用例规格说明 的来源。应该再次出现关于用例的详细说明，但如果用例详细说明中存在用例模型范围以外的功能，那么我们需要决定是否应该调整用例规格说明或用例模型。
在用例实现中，我们满足了功能和非功能的规范，也就是说，用例规格说明和 SAD。用例实现只包含来自于用例规格说明但不出自于 SAD 的元素。换句话说，如果 SAD 中的指示，连同实际的用例规格说明对开发人员来说足够构建用例的代码，那么用例实现 就是空的。在实践中，我们将用例实现文档作为参考。在那种情况下（我们与所有的涉众达成一致），我们构建代码，并且根据 SAD 测试和编制文档。
工件流有一个优点。项目中的主要流是以简洁的格式直接可见的。另外，出现在活动流中的主要流也是直接可见的。
结束语
职责矩阵和工件流给出了开发案例主要部分的简洁、但完整的概述。当使用本文中说明的策略进行定义时，一定要确保新的 RUP 方法是根植于公司这些年来所积累的最佳实践中的。
文章来源于领测软件测试网 https://www.ltesting.net/
