進退兩難
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 方法是根植于公司這些年來所積累的最佳實踐中的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
