策略 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 方法是根植于公司这些年来所积累的最佳实践中的。
[1] [2]
