Rational統一建模過程的十大要素

為了有效的應用 Rational 統一過程 （RUP）,首先要理解它的關鍵目標,并且弄清楚每一個目標為什么重要,他們是怎么樣結合在一起，共同幫助你的開發團隊滿足涉眾需求，生產出優質產品的。

首要的是抓住要點
有天晚上，我的鄰居 Randy 過來求助。他正在為周末野營和徒步旅行作準備，但是不知道帶些什么東西才好。他知道，我經常領導和參加野外旅行，而且我能夠很快的決定在有限的包裹里塞些什么東西，他還記得我曾經給他提過，我有一張我擁有的所有設備和衣服的清單�！澳敲�，我可以借那張清單嗎？”他問道。

“當然，但是恐怕幫助不大�！蔽医忉尩�。你看，在我的外出設備清單中有好幾百項，涉及很多種類型的外出，從背包攀登到滑雪,旅行時間從幾天的短途旅行到很多天的遠征探險。我知道，如果沒有相應的指南，Randy 將會陷入冗長的清單之中，以致弄不清，就他相對簡單的外出而言，什么才是他真正需要的。

始于要素，逐步遞增
因此，我提出看一下 Randy 在他的鼓鼓囊囊的包里面都已經裝了那些東西。我們可以看以看，他是否可以少帶些什么以減輕負擔，或者是還有什么該帶的卻沒有帶。過了一會兒，我已經能肯定，他真正缺少的不是別的，而是對野外旅行的理解，也就是說，抓不住野外旅行的要點。

我拿出一張空白的紙，列出以下十個項目：（1）

• 地圖（Map）
• 指南針（Compass）
• 太陽鏡和防曬油（Sunglasses 和 sunscreen）
• 額外的食物和水（Extra food 和 water）
• 額外的衣服（Extra clothing）
• 頭上戴的小燈（Headlamp）
• 急救箱（First-aid kit）
• 打火機（Fire-starter）
• 火柴（Matches）
• 刀子（Knife）

“你看，Randy 。這就是你真正需要的。如果你從這十大要素出發，那么，無論遇到什么旅行，再來考慮還需要增加哪些內容就變得容易多了�！倍嗄昵�，我第一次登山時，靠的就是這張清單，現在我仍然使用它，無論我準備的旅行時那種類型、要去多長時間。每一項的膨脹或者壓縮取決于旅行本身。始于簡短的清單，然后需要時再擴展，這是一種方式;始于冗長的清單，然后再來決定不采用什么，這是另一種方式。但是兩種方式相比，前者顯然要容易得多。

把這一課應用到 RUP 中
當我幫助項目組就 RUP 的很多元素進行排序時，常常聽到這樣的問題：“我怎樣對所有這些內容進行排序？而且決定在我的項目里究竟需要哪些要素？”“RUP 包括這么多的信息。它一定是針對大項目的――我真的能在我的小項目使用它嗎？”

我斷定，這些人真正需要的是“ RUP 的十大要素”，就像我給我的朋友 Randy 的簡單的清單一樣。這個 RUP 的清單，可以作為任何項目的符合情理的起點，無論小項目、中型項目還是大型項目。這個列表會聚焦在被我稱之為“精華或要素”的東西上，可能是 RUP 的，也可能是任何有效軟件過程的。

迭代式開發循環模型

在所有成員領悟到提交合格產品所需要的關鍵過程元素之前，項目往往陷入某個特定主題的細節的沼澤中。然后，當項目拖后時，大家就會怪罪以前被過分強調的某些活動，或者是怪罪大家不理解其用處的某些活動，“嘿，我早就告訴你需求管理（或者是用例、收集項目度量數據、使用配置管理、使用缺陷跟蹤工具、召開項目狀態會議里面的一個或幾個）會放慢我們的進度！你不信！”

有一個“精華或要素”列表讓團隊成員采用一種更系統、更全面的方式來思考和執行整個軟件開發過程。一旦一個過程框架或“構架”到位了，團隊成員就能更有效的面對和處理單個的問題域（大部分時間我得承認，需求管理應該在列表的頂部）。同樣，一開始就標識顯然的問題以及相關的風險，并且確定處理他們的優先級，也是很重要的，這樣，團隊才能在早期就根據需要采取相應的解決或緩解對策。

RUP 的十大要素
那么，在 RUP 的十大要素中應該包括哪些內容呢？下面是我的意見：

• 1. 開發前景
  
• 2. 達成計劃
  
• 3. 標識和減小風險
  
• 4. 分配和跟蹤任務
  
• 5. 檢查商業理由
  
• 6. 設計組件構架
  
• 7. 對產品進行增量式的構建和測試
  
• 8. 驗證和評價結果
  
• 9. 管理和控制變化
  
• 10. 提供用戶支持

讓我們逐一的審視這些要素，看一看它們什么地方適合 RUP，找出它們能夠成為十大要素的理由。

1. 開發一個前景
有一個清晰的前景是開發一個滿足涉眾真正需求的產品的關鍵。

前景抓住了 RUP 需求流程的要點：分析問題，理解涉眾需求，定義系統，當需求變化時管理需求。

前景給更詳細的技術需求提供了一個高層的、有時候是合同式的基礎。正像這個術語隱含的那樣，它是軟件項目的一個清晰的、通常是高層的視圖，能被過程中任何決策者或者實施者借用。它捕獲了非常高層的需求和設計約束，讓前景的讀者能理解將要開發的系統。它還提供了項目審批流程的輸入，因此就與商業理由密切相關。最后，由于前景構成了“項目是什么？”和“為什么要進行這個項目？”，所以可以把前景作為驗證將來決策的方式之一。

對前景的陳述應該能回答以下問題，需要的話這些問題還可以分成更小、更詳細的問題：

• 關鍵術語是什么？（詞匯表）
• 我們嘗試解決的問題是什么？（問題陳述）
• 涉眾是誰？用戶是誰？他們各自的需求是什么？
• 產品的特性是什么？
• 功能性需求是什么？（用例）
• 非功能性需求是什么？
• 設計約束是什么？

2. 達成計劃
“產品的質量只會和產品的計劃一樣好�！� （2）

在 RUP 中，軟件開發計劃（SDP）綜合了管理項目所需的各種信息，也許會包括一些在先啟階段開發的單獨的內容。SDP 必須在整個項目中被維護和更新。

SDP 定義了項目時間表（包括項目計劃和迭代計劃）和資源需求（資源和工具），可以根據項目進度表來跟蹤項目進展。同時也指導了其他過程內容的計劃：項目組織、需求管理計劃、配置管理計劃、問題解決計劃、QA 計劃、測試計劃、評估計劃以及產品驗收計劃。

軟件開發計劃的格式遠遠沒有計劃活動本身以及驅動這些活動的思想重要。正如 Dwight D.Eisenhower 所說：“ plan 什么也不是，planning 才是一切�！�

“達成計劃”—和列表中第 3、4、5、8 條一起—抓住了 RUP 中項目管理流程的要點。項目管理流程包括以下活動：構思項目、評估項目規模和風險、監測與控制項目、計劃和評估每個迭代和階段。

3. 標識和減小風險
RUP 的要點之一是在項目早期就標識并處理最大的風險。項目組標識的每一個風險都應該有一個相應的緩解或解決計劃。風險列表應該既作為項目活動的計劃工具，又作為確定迭代的基礎。

4. 分配和跟蹤任務
有一點在任何項目中都是重要的，即連續的分析來源于正在進行的活動和進化的產品的客觀數據。在 RUP 中，定期的項目狀態評估提供了講述、交流和解決管理問題、技術問題以及項目風險的機制。團隊一旦發現了這些障礙物（籬笆），他們就把所有這些問題都指定一個負責人，并指定解決日期。進度應該定期跟蹤，如有必要，更新應該被發布。

這些項目“快照”突出了需要引起管理注意的問題。隨著時間的變化/雖然周期可能會變化，定期的評估使經理能捕獲項目的歷史，并且消除任何限制進度的障礙或瓶頸。

5. 檢查商業理由
商業理由從商業的角度提供了必要的信息，以決定一個項目是否值得投資。商業理由還可以幫助開發一個實現項目前景所需的經濟計劃。它提供了進行項目的理由，并建立經濟約束。當項目繼續時，分析人員用商業理由來正確的估算投資回報率（ROI，即 return on investment）。

商業理由應該給項目創建一個簡短但是引人注目的理由，而不是深入研究問題的細節，以使所有項目成員容易理解和記住它。在關鍵里程碑處，經理應該回顧商業理由，計算實際的花費、預計的回報，決定項目是否繼續進行。

6. 設計組件構架
在 RUP 中，軟件系統的構架是指一個系統關鍵部件的組織或結構，部件之間通過接口交互，而部件是由一些更小的部件和接口組成的。即主要的部分是什么？他們又是怎樣結合在一起的？

RUP 提供了一種設計、開發、驗證構架的很系統的方法。在分析和設計流程中包括以下步驟：定義候選構架、精化構架、分析行為（用例分析）、設計組件。

要陳述和討論軟件構架，你必須先創建一個構架表示方式，以便描述構架的重要方面。在 RUP 中，構架表示由軟件構架文檔捕獲，它給構架提供了多個視圖。每個視圖都描述了某一組涉眾所關心的正在進行的系統的某個方面。涉眾有最終用戶、設計人員、經理、系統工程師、系統管理員，等等。這個文檔使系統構架師和其他項目組成員能就與構架相關的重大決策進行有效的交流。

7. 對產品進行增量式的構建和測試
在 RUP 中實現和測試流程的要點是在整個項目生命周期中增量的編碼、構建、測試系統組件，在先啟之后每個迭代結束時生成可執行版本。在精化階段后期，已經有了一個可用于評估的構架原型；如有必要，它可以包括一個用戶界面原型。然后，在構建階段的每次迭代中，組件不斷的被集成到可執行、經過測試的版本中，不斷地向最終產品進化。動態及時的配置管理和復審活動也是這個基本過程元素的關鍵。

8. 驗證和評價結果
顧名思義，RUP 的迭代評估捕獲了迭代的結果。評估決定了迭代滿足評價標準的程度，還包括學到的教訓和實施的過程改進。

根據項目的規模和風險以及迭代的特點，評估可以是對演示及其結果的一條簡單的紀錄，也可能是一個完整的、正式的測試復審記錄。

這兒的關鍵是既關注過程問題又關注產品問題。越早發現問題，就越沒有問題。

9. 管理和控制變化
RUP 的配置和變更管理流程的要點是當變化發生時管理和控制項目的規模，并且貫穿整個生命周期。其目的是考慮所有的涉眾需求，盡可能的滿足，同時仍能及時的交付合格的產品。

用戶拿到產品的第一個原型后（往往在這之前就會要求變更），他們會要求變更。重要的是，變更的提出和管理過程始終保持一致。

在 RUP 中，變更請求通常用于記錄和跟蹤缺陷和增強功能的要求，或者對產品提出的任何其他類型的變更請求。變更請求提供了相應的手段來評估一個變更的潛在影響，同時記錄就這些變更所作出的決策。他們也幫助確保所有的項目組成員都能理解變更的潛在影響。

10. 提供用戶支持
在RUP中，部署流程的要點是包裝和交付產品，同時交付有助于最終用戶學習、使用和維護產品的任何必要的材料。

項目組至少要給用戶提供一個用戶指南（也許是通過聯機幫助的方式提供），可能還有一個安裝指南和版本發布說明。

根據產品的復雜度，用戶也許還需要相應的培訓材料。最后，通過一個材料清單（BOM 表，即 Bill of Materials）清楚地記錄應該和產品一起交付哪些材料。

關于需求
有人看了我的要素清單后，可能會非常不同意我的選擇。例如，他會問，需求在哪兒呢？他們不重要嗎？我會告訴他我為什么沒有把它們包括進來。有時，我會問一個項目組（特別是內部項目的項目組）：“你們的需求是什么？”，而得到的回答卻是：“我們的確沒有什么需求�！�

剛開始我對此非常驚訝（我有軍方的宇航開發背景）。他們怎么會沒有需求呢？當我進一步詢問時，我發現，對他們來說，需求意味著一套外部提出的強制性的陳述，要求他們必須怎么樣，否則項目驗收就不能通過。但是他們的確沒有得到這樣的陳述。尤其是當項目組陷入了邊研究邊開發的境地時，產品需求從頭到尾都在演化。

因此，我接著問他們另外一個問題：“好的，那么你們的產品的前景是什么呢？”。這時他們的眼睛亮了起來。然后，我們非常順利的就第一個要素（“開發一個前景”）中列出的問題進行了溝通，需求也自然而然的流動著

也許只有對于按照有明確需求的合同工作的項目組，在要素列表中加入“滿足需求”才是有用的。請記住，我的清單僅僅意味著進行進一步討論的一個起點。

總結：十大要素的應用
那么，發現了 RUP 的十大要素之后，怎樣才能讓它給我的職業生涯帶來根本的變化呢？這兒有一些建議，能幫助我們對付各種規模的項目。

對于非常小的項目
首先，如果誰來問我，在一個非常小的、沒有經驗的項目組（才學了 RUP ）中，如何使用RUP和Rational開發工具來構造一個簡單的產品，我會與他分享十大要素列表，以使項目組不被 RUP 的細節和 Rational Suites 的功能壓垮。

實際上，即使沒有任何自動化工具也可以實施十大要素。管理一個小項目，一個項目筆記本，就已經是一個非常好的起點，可以把它分成十個部分，每一部分專用于十大要素中的一個要素。（我還發現及時貼對于小項目變更請求的管理和跟蹤以及確定變更的優先級非常有用。）

對于增長的項目
當然，當一個項目的規模和復雜度增長時，以上這些應用十大要素的簡單方法很快就變得不可操作，而對自動化工具的需求就變得比較明顯了。然而，我還是愿意鼓勵項目的領導者剛開始時應用十大要素和RUP的“最佳實踐”，需要時再逐步增加支持工具，而不是一下子就嘗試使用全套 Rational Suites 。

對于成熟的項目團隊
對成熟的項目團隊而言，可能已經在采用某種軟件過程和使用 CASE 工具，十大要素可以提供一種快速評估方法，用來評估關鍵過程元素的平衡性，標識他們并確定改進的優先級。

對于所有的項目
當然，各個項目都不太一樣，有些項目似乎并不真正需要所有的要素。在這些情況下，重要的是考慮：如果你的團隊忽視某個要素后會發生什么問題。舉例如下：

• 沒有前景？你會迷失方向，走很多彎路，把力氣浪費在毫無結果的努力上。
• 沒有計劃？你將無法跟蹤進度。
• 沒有風險列表？你的項目會陷入“專注于錯誤的問題上”的危險里面，可能一下子被一個沒有檢測的地雷擊倒，并為此付出五個月的代價。
• 沒有問題列表？沒有定期的問題分析和解決，小問題會演變成大問題。
• 沒有商業理由？你在冒浪費時間和金錢的風險。項目最終要么超支，要么被取消。
• 沒有構架？在出現交流、同步和數據存取問題時，你可能無法處理。你也可能在伸縮性和性能上有問題。
• 沒有產品（原型）？你將不能有效的測試，并且會失去客戶的信任。
• 沒有評估？你將沒有辦法掌握實際情況與項目目標、預算和最后期限之間的距離。
• 沒有變更請求？你將無法估計變更的潛在影響，無法就互相沖突的需求確定優先級，無法在實施變更時通知整個項目組。
• 沒有用戶支持？用戶將不能最有效的使用產品，技術支持人員也會淹沒在大量支持請求中。

現在你知道了，不懂得十大要素是一件非常冒險的事情。我鼓勵你把它們作為項目組的一個起點。決定哪些是你們想要的，哪些是不要的，哪些是要修改的。然后，再決定還有哪些其他因素是你們項目（無論項目大�。┏晒ΓūＷC項目組及時的、不超預算的交付產品，并且真正滿足涉眾的真正需求）的關鍵因素。

其他要素
其他組織也出版了類似的軟件工程要素列表。IEEE 軟件雜志 1997 年 3/4 月號上有一篇 Steve McConnell 寫的文章，“軟件的十大要素”。軟件項目經理網絡也有一個“16 個關鍵軟件實踐”的列表，在 www.spmn.com 上可以找到。SEI-CMM 的 KPAs（Key Process Areas,關鍵過程域）也可以作為一種要素列表（見 www.sei.cum.edu）。

參考資料

• （1）參見“The Freedom of the Hills”,第6版，Mountaineers of Seattle出版，1997年。
  
  
• （2）參見“They Write the Right Stuff”,Charles Fishman,Fast Company,第6期，第95頁，1996年12月。
  

文章來源于領測軟件測試網 http://www.kjueaiud.com/