【IT168 技术文章】
作者提出了一项将 Rational 统一过程进行剪裁的技术，以适应软件项目具体需求，即使外聘的 RUP 专家不熟悉本公司及其文化。
设想您是一个 IT 部门的经理，该部门的软件开发职员在满足市场需求的过程中需要更多灵活性。过程的级别应该通过开发的范围和分布、项目的技术复杂度，及文档的需求进行平衡。您采用的方法应该着重于在早期减少风险，包括技术风险。通过引入迭代开发，您将争取增加最终用户的满意度。要满足这些需求，您和您的开发团队已经决定在您未来的项目中使用 Rational Unified Process?，或称 RUP?。您已经做出了一个重要的决定，但现在您有更多的决定要做，尤其对不熟悉 RUP 的项目经理来说是个挑战。
进退两难
RUP 包含一个工件扩展库，其中有许多您不需要的东西。没有一个组织需要全部的内容。事实上，RUP 最新版本（7.0）的第一个关键原则是“使过程适应组织和项目”，所以您需要将 RUP 按您的组织及其项目的大小和需求进行剪裁。这样剪裁的结果是 RUP 的一部分，被称为开发案例（development case）。在开发案例中，您将描述在项目中使用的所有活动、角色、工件和模板。
每个所选择的支持工件（可交付的）都将需要资源来生产它。向开发案例中添加的每一项元素都应该根据期望的效益进行平衡，您需要考虑的方面包括：时间节省、质量获得，或为项目评估、计划和范围管理提供的基础。换句话说，开发案例太大将会不必要地浪费项目的钱。问题是：您如何继续让您的开发案例正常？您打算自己找出如何剪裁 RUP 的方法吗，或者您打算从外面雇佣一个 RUP 顾问或过程工程师吗？自己处理 RUP 的裁剪，让您的团队等着您的指导，在缺乏剪裁 RUP 的内行经验的情况下，这样做是很困难的。您将不得不花费一些时间来找出哪个工件要被略去、哪个要被添加，并且确定应该如何用它们来适合您的项目，或组织。事实上，您需要了解 RUP 的全部才能够以合理的方式对它进行剪裁，因此您将在将来的六个月中非常繁忙。
另一种方法，您可以雇佣一个 RUP 顾问，一个可以在什么工件是强制的，以及在特定的情况下只需要哪个工件的方面指导您的人。顾问可以帮助按照您的需求修改 RUP 模板，并最恰当地将它们用于创建有用的工件工具。但是外部的 RUP 顾问对您的业务的了解是有限的，更不要提您的组织或公司的文化。这意味着顾问将使用相当多（昂贵）的时间了解您的业务 —— 否则，结果将是剪裁出来的开发案例并不符合您公司的需求和特性。
我们已经扮演过外部的 RUP 顾问的角色，并且为各种各样的公司成功地定义了开发案例。作为顾问，我们相信剪裁 RUP 的外部专家经验的价值，并且我们已经开发了帮助加速剪裁过程，并且与此同时描述组织具体需求的技术。我们将介绍两个概念：职责矩阵和工件流。
职责矩阵
我们基于建立“什么”和“谁”利用面向目标的方法来剪裁 RUP。我们开始研究项目应该交付 什么 （哪些工件）。由工件开始的一个很大的优势是工件是有形的东西。通过观察哪些工件获得的基线状态（已经被正式地批准）可以很容易地检查项目进展。
工件必须总是有用的。这可能听起来微不足道，但是在许多情况下，我们发现了由那些不知道工件用途的人撰写的工件。我们经常提出的问题是，“如果没有工件被生成，将会出现什么问题？”这个问题的答案澄清了工件的目的。如果您不能找到此问题的具体答案，那么有很大可能性此工件是多余的。
在决定生成哪个工件之后，我们研究 谁 （哪个角色）负责创建每个工件。我们将工件、角色和职责一起放入我们的职责矩阵中。我们在最左边的列放工件，在最顶端的行放角色。在交叉部分我们放上表示各种职责的符号。这就形成了如图 1 所示的矩阵。
图 1：职责矩阵实例
工件的作者不仅涉及创建此工件的那个人。要完成矩阵，我们还要研究哪些角色支持创建过程，以及哪角色些负责正式地接收一个工件。通过访谈、讨论会和评论的方式能够支持角色给出输入。当然，我们能够识别出细粒度的职责，但这很少有用。注意，负责工件（将其写在纸上或汇集工件）的角色是实际的作者。由于这涉及特殊的技能，因此该职责不容易委托。例如，我们要注意的是不要将太多的工件分配给项目经理。他或她应该只撰写并负责管理工件。
