策略 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]
