RUP實施之奪命七招

領測軟件測試網 ��Rational統一過程(Rational Unified Process，RUP)提供了一個極有價值的軟件開發業務框架，它正在成為一個廣受歡迎的當代軟件開發過程的事實標準——它整合了公認的最佳實踐，例如適應性的、迭代的和風險驅動的開發模式；它是由在大、小型系統開發中均具有豐富經驗的世界級領導者設計的；它在應用和擴展上都很靈活，而且被正式的出版物以及相應產品很好地記錄了下來。然而作為框架，必須根據每個項目團隊及其環境的需要進行調整。RUP本來是用一種輕型和敏捷的方式來開發項目的，而不是被當作一個“萬能尺碼”的開發過程。若干因素妨礙了RUP的成功實施，其導致的結果往往非常糟糕。

�牐牨疚挠寐詭б稽c俏皮的口吻，與大家分享一組常見的RUP應用陷阱。如果您的目標是讓RUP實施的結果一塌糊涂，那么我們向您推薦以下七招。

�牐�第一招：在RUP之上疊加瀑布思維

�牐犇�的開發過程是否有點像：(1)企圖定義和穩定絕大部分的需求，然后進行簽署；(2)基于需求，進行詳細設計；(3)基于設計，進行實現；(4)進行集成、系統測試和部署。這是一個線性的、串行的瀑布型生命周期的典型例子，而且是一個最優先的、最棒的，也是最常見的讓RUP實施完全失敗的策略。如果您的開發過程看上去與這很像，那么祝賀您，您成功地沒有采用RUP！

�牐犼P于瀑布型生命周期與迭代式開發最重要的一件事是，我們在20世紀60年代和70年代被誤導了：許多人當時接受到的教育是瀑布式做法是聰明老練的。然而，歷史研究表明，這一建議的出現并沒有得到任何統計意義上的證據的支持，而且更為重要的是，當前的軟件項目失敗研究結論性地表明，瀑布型是風險最高、極易失敗、低生產率以及高缺陷率的軟件構建方法。如果您要一個軟件項目失敗，您應該遵循瀑布型做法！而與之相反，現在有極具說服力的證據表明，迭代和演進式方法(如RUP)能帶來較低的失敗率、更低的風險和更高的生產率。值得稱道的是，美國國防部原本提倡瀑布過程和觀點，在發現那么多采用了該方法的失敗之后，不但放棄了對它的要求(如1988年的STD-2167A標準)，而且從1994年的報告開始，積極地鼓勵采用更加現代化的迭代式生命周期來取代瀑布型做法。

�牐爮陌l展的角度，瀑布型過程與20世紀60年代開發軟件的隨心所欲方式相比，它是一個相對合理的策略。這一做法借鑒了其他領域的工程和建造，但遺憾的是，未經對其應用于軟件開發的真正適應性進行認真和嚴肅的研究，它就被廣泛地傳播和采用了，于是幾代師生都不假思索地學習、不斷地照搬它。不幸的是，如今仍有許多軟件過程“專家”、咨詢顧問、項目經理和過程工程顧問(例如某些帶有瀑布型偏好的CMM實施顧問)似乎一點兒不知道已有的研究證據，仍然繼續根據自己的主觀意愿或信念而非統計意義上的證據來行事。

�牐犛行〇|西必須像建筑那樣被建造，然而人們發現軟件通常不屬于這一類。這有許多原因，最具有說服力的是一個錯誤的假定，即可以在項目的第一個階段中定義絕大部分的需求。Capers Jones等人的研究粉碎了這一神話。如圖1所示，在這項含有6700個項目的龐大研究中，蔓延的需求(在項目開始時沒有預見到的需求)是軟件開發業當中非常顯著的一個事實，在普通項目中它大概占到了25%，而在大型項目中則占到50%。




需求變化呈常態

�牐犉俨际絻r值觀和做法是：(1)完成絕大部分的需求，隱含著假定那些以前沒見過該產品的用戶們能很好地定義這些需求；(2)根據能夠精確地為一個定義很差的問題制定解決方案這一假設，進行詳細設計；(3)盡管設計還沒有被證實，而且往往不可能被證實，仍然進行系統的實現；(4)集成、測試和部署。

�牐犉俨夹徒吡�回避需求變化的現實，它假定需求和設計能夠正確地被指明和凍結，這與項目的現實嚴重不符。軟件開發在設計和實現之前無法固定需求有許多原因，但不管什么原因，高明的應對方法不是去“對抗變化”，竭力固定需求，而正相反，應像Kent Beck積極主張的那樣“擁抱變化”，并把這當作軟件過程的一個核心驅動力。

�牐犛谑�，在RUP當中，開發的行進表現為一系列的迭代，每個迭代都被時間盒限定在一個固定的工期(例如正好4周)當中，每次迭代結束時都將產生最終系統某個子集的一個穩定內部發布。在迭代式開發中，時間盒限定是一個關鍵的概念：它意在固定迭代的結束日期，而且通常不允許結束日期的推遲。如果無法滿足所有的目標，那么就要從迭代中去掉一些需求，而不是延長當前迭代的工期。

�牐犜谝粋�迭代中，有一種類似微型瀑布的情況。首先挑選一小部分需求，相對全面地對其進行分析；用幾天時間進行設計，然后迅速地對系統的這一部分開始實現、集成和進行實際的系統測試與壓力測試。每次迭代的結束將產生一個可運行的部分系統，它能產生反饋，并引發未來迭代中對需求和設計的調整。隨著時間的流逝，這些反饋-適應迭代周期揭示了一組合適的需求和一個健壯的、經過驗證的設計與實現。這里，一個串行的瀑布方法在周(而不是月或年)的尺度上得到了應用，而且存在一個有機的反饋和適應機制。在一個數周的時間尺度上，一個串行的生命周期是可行的，然而當迭代長度增加時，這種方式將不再有效。 �牐�

�牐牸词沟搅私裉�，在第一輪警報響起的十多年之后，仍有不少咨詢公司、管理者、教師和作家們把瀑布型生命周期或觀點當作一門優越的技術來提倡�？朔�有意識或無意識地在RUP和迭代式開發之上疊加瀑布價值觀，是一個項目團隊面臨的最大挑戰之一。真正掌握了RUP的一個最深刻的變化不在于諸如寫用例、對象建模等技能上，也不在于在學習RUP提供的許多工件和活動上(所有這些都是可選的)，而在于對瀑布思維的根本態度和期望的轉變。下面是RUP事實中四個典型的錯誤。 

�牐犲e誤一：在RUP的階段上疊加瀑布型階段 

�牐燫UP開發周期由四個階段組成(起始、細化、構建和移交)，導致RUP實施失敗的最常見策略就是把這四個階段與瀑布階段(需求、分析設計、實現和部署)直接等同起來。在此對RUP的四個階段作一簡短描述。 

�牐�1. 起始：制定系統的業務依據；探查一小部分(大概占10%)但很重要的需求，以便對項目范圍的大致規模和關鍵風險有比較準確的把握，并決定是否值得為細化階段撥付資金。 

�牐�2. 細化：迭代地構建核心架構，消除項目的主要技術風險。所謂的構建架構，是指真正地編程、集成和測試——決不是紙面上的練習或可拋棄的原型。為了達到這一目的，可能需要迭代地詳細探查絕大部分的需求(可能占到80%)，并同時并行地實現系統中有風險的核心部分。在這一階段中，通過反饋-適應周期不斷地評估部分實現，需求則可能發生顯著的變化。請注意與經典的瀑布式需求定義不同，RUP的絕大部分需求是在與開發核心架構的工作并發的過程中精化的，而且從實際的開發當中獲得了反饋。在此階段，還要決定是否為項目的最終完成撥付資金。 

�牐�3. 構建：迭代地構建在細化階段尚未完成的內容，進行迭代集成和質量保證，為部署作準備。在這一階段需求變化較少，因為大部分需求的不穩定性已經在前面階段得到了迭代式的澄清。 

�牐�4. 移交：完成Beta測試，解決遺留問題并部署系統。 �牐� 

�牐犲e誤二：迭代不是太長就是太短 

�牐犎绻�把計劃的平均迭代長度定為6～12個月，在絕大多數情況下是很不適宜的。RUP有一條慣例：“在理想情況下，一個迭代的工期應該是2～6周�！钡�代式開發與RUP方法的精華在于通過小規模的工作步驟逐步獲得一個可能不完善的實現，接著快速集成，進行QA和測試，快速獲得反饋，然后基于該反饋調整需求、設計和實現。短小的步驟、反饋和調整是關鍵的思想。過長的迭代則達不到這種效果，因而是使RUP實施失敗的一個良好策略。 

�牐犲e誤三：在設計前磨亮需求 

�牐牭�代式方法允許有指導方向的試驗和創造，而瀑布方法迫使我們從一開始就必須做到聰明絕頂，這種在沒有反饋的情況下，把絕大部分需求定義并穩定下來的想法與軟件開發的現實不符。 

�牐牸僭O用瀑布方法建議我們購買軟件的方式來購買衣服，那么，我們必須要在看不見能得到什么的情況下來確切地描述我們需要什么，甚至還不能先試穿一下，看看穿上這件衣服效果如何。我們必須要在真正收到這件衣服的幾個月甚至幾年之前，精確地指明每一個測度。一旦我們改變了主意，或者長胖了、變瘦了，那只有老天來幫忙了。不錯，這恰恰就是瀑布方法的解決之道——在設計或實現之前確定絕大部分的需求。如果我們連買衣服都不想用這種辦法，那么，憑什么讓我們相信它對軟件開發也是有效的呢？�牐� 

�牐犲e誤四：項目剛開始就期望獲得可信的估算和詳細的計劃 

�牐犚晃皇�油業高層主管對您說：“我聽說FooBarKhan那里有石油，我太想要了！請您趕緊用一周的時間寫一份報告，告訴我那里有多少石油，在那里建油田需要花多少錢、多少時間、多少資源�！痹谑�油業中，這樣的場景是很滑稽的，為什么同樣的做法反而被軟件工業接受了呢？理智的石油人士知道：沒有預先在試驗性鉆探上大量投入是不可能獲得答案的。只有通過調查發現了儲量和地質情況的真相，作出估算或初步的計劃才有可能�？墒�，在同樣的不確定性和高復雜度的情況下，我們卻奢望沒有投入實際的“試驗性鉆探”調查就能對軟件項目進行估算和計劃，這不是很可笑嗎？ 

�牐爟H僅因為我們能夠作出計劃顯示出我們正取得進展，并不意味著我們真的能夠做到。在沒有獲得任何關于未完成工作量的真實信息的情況下，在日程表上填上精確的日期是容易的。如果我們依賴完美的計劃來交付一個項目，那么失敗將是注定的。迭代方法允許我們邊干邊學，隨著迭代的進行，我們獲得了有關真實需求的更多信息，對真正的風險有了更好的了解，對我們應對項目的各項挑戰的能力也有了更為清晰的認識。 �牐�

�牐犛袝r固定價格交付要求的存在被當成瀑布方法的一個理由，因為在沒有真實信息的條件下作出決策也是合理的。迭代方法對初始的估算可能并沒有什么改善，不過您能很快知道您做得怎么樣，然后您可以更加容易地選擇必要的時機啟動協商，設定干系人的期望和管理項目范圍。正如RUP所倡導的，一個處理固定價格投標與合同的理智方法是一種兩階段的策略。在第一階段中，針對初始短暫(比如4周)的固定時間和固定價格簽訂合同，以便開展實際的調查和試探性編程，以產生更加成熟的范圍、風險和需求規約。這一經改進的規約隨后可被用作第二階段(完整的開發)投標的基礎。第一階段調查的投入并沒有浪費，其結果將節省第二階段的工作量，并有助于產生第二份(最終的)更加符合實際的合同。

�牐�第二招：把RUP當作一個重型的、先斷性的過程來用

�牐犞匦突蜉p型、先斷性或適應性的過程常常被人提及，而一個“重型過程”的稱謂通常具有貶義，它具有以下性質：剛性和控制；許多活動和RUP工件是在一種官僚主義的氛圍當中創建的；大量的文檔；細致入微的長時間的詳細計劃；在基本工作之上存在大量的過程開銷；以過程為本，而不是以人為本；以一種機械的方式把人視為可插拔的部件；先斷性而非適應性。一個先斷性的過程企圖在一段相對長的時間段里(比如幾乎在項目的整個周期中)計劃和預測活動與資源(人員)的分配，其價值觀隱含著對瀑布型的偏好。

�牐犗喾�，一個輕型或敏捷的過程意味著“精簡與平實”，它具有如下特點：除去了所有不必要的官僚主義的過程開銷，盡量減少創建低價值或無意義的文檔；專注于工作環境中人的本性之現實，讓軟件開發成為一種樂趣；它是適應性的。

�牐牉榱舜俪蒖UP實施的失敗，請采取以下重型、先斷性的做法：

�牐�* 對整個迭代項目進行詳細的計劃。從一開始就定義所有迭代的編號和日期，規定每個迭代中將要發生的事情。

�牐�* 創建絕大部分甚至所有的RUP工件。

�牐�* 增加大量項目和過程的正規程式，甚至建立幾個項目委員會。

�牐�* 在項目中追求一種機械的時鐘驅動感，把人當作整個項目機器中的專用齒輪。

�牐牥裄UP設計成一個重型或先斷性的過程并非其創始人的本意，造成這一假象主要是由于人們誤添了錯誤的過程觀點或對RUP本身有誤解，而RUP產品提供的龐大的詳細過程文檔又加劇了錯誤的印象，極容易導致RUP被錯誤地實施。RUP作者們的本意是鼓勵人們以一種輕型的、敏捷的、適應性的過程實質來運用它。比方說：

�牐牎� 應該創建RUP活動和工件的一個最小集，即只包含那些真正有附加值的東西；隨著項目的進展，如果任何的過程開銷活動沒有附加值，那么就果斷地拋棄它。

�牐牎� 對所有的迭代，都不預設詳細的計劃。有一個高層的計劃(叫作階段計劃)估計項目的完工日期和其他主要的里程碑，然而它并不詳細指定通向這些里程碑的路徑。一個細化的計劃(叫作迭代計劃)只是提前對一個迭代(比如下一個兩周的迭代)進行較細致的計劃。從一個迭代到另一個迭代的詳細計劃是適應性地完成的。

�牐�第三招：忽視對象技術技能

�牐燫UP的直接目標在于開發面向對象系統。多年來，我們觀察到許多對象技術項目失敗或遇到嚴重的挫折，一個普遍的問題是缺乏真正地能以對象方式思考，熟練掌握對象設計、對象模式和面向對象編程的人員。擁有技藝精湛的OT開發人員是一個絕對優先的關鍵成功因素，而采用RUP或其他過程則相對次要。正如Grady Booch所言，“人遠比過程重要”。

�牐犚虼�，如果要讓RUP實施真正失敗，就可忽視聘用或培養那些擁有出色對象技能的人員。真正有實效的OT培養并非指先有一個星期的Java技術課程，然后是一個星期的面向對象分析設計課程，而是需要向軟件工程師提供半年內大至八周的、有老師精心指導的培訓，之后還需要一年左右的專家輔導鞏固期。 �牐�

�牐爩ο蠹夹g開發技能絕非小菜一碟，成功的對象設計與編程需要受過良好訓練的開發人員。確保項目失敗的絕好辦法可以是：不必大量投入來聘用或培養熟練的對象技術人才，或者讓技能生疏的工程師勉強過關以減少這方面的投入。我們還要強調加強對象設計與設計模式技能和培養的必要性，不能僅僅關注對象編程。

�牐�第四招：貶低適應性、迭代式開發

�牐犜赗UP的核心理念和最佳實踐(管理需求、迭代式開發、控制變更、校驗質量、基于架構和構件的設計)中，迭代式開發的地位是最突出的。對于正從瀑布式價值觀和實踐上開始轉變的組織而言，迭代式開發就像一場革命。事實上，在對待開發軟件思考的許多層面上，如果向RUP轉變的一個組織沒有經歷一場深刻甚至痛苦的變革，那么通常說明他們沒有“把握”迭代式開發并真正地采用它。 �牐�

�牐犲e誤一：信奉剛性和先斷性觀點

�牐犨@種觀點的含義即企圖凍結需求和設計，而非擁抱變化；試圖計劃未來所有的迭代，而不是適應性地調整。瀑布模型對如何處理變化存在著尤為明顯的偏見。在某種程度上，整個瀑布方法可以被視為大體上是反對變化的——一旦需求被“批準”(凍結)，即便后來發現某個需求是錯誤的，仍然需要特別費力地改變它。

�牐犲e誤二：顛倒迭代式開發的做法

�牐犿椖拷浝硭坪跸矚g瀑布型生命周期那種表面上“明顯”的穩定性和確定性，問題在于它們具有欺騙性——只有通過測試，才能評估對事物真偽的預先假定；只有通過實現，才能知道一個任務到底需要多少工作量。在項目當中，我們其實都在玩一個游戲——我們作出假設，猜想事物會是什么樣子，解決方案將如何。然而事實上，我們的工作是基于不完善的信息。

�牐犅斆鞯捻椖拷浝硗ㄟ^設置許多檢查點來驗證先前的假定：布置了收集信息的任務，想方設法地抓住各種機會，利用新獲取的信息來調整計劃。迭代方法允許人們收集信息，通過迭代來改進計劃，甚至改變方向。瀑布方法最大的錯誤可能在于，計劃的制定脫離了現實，而且即使當收集到新的信息時，這種計劃也不能被更新，改變計劃被認為是預測未來行為的一種失敗。然而調整計劃并非預測的失敗，相反是一次改進的機會。

�牐犲e誤三：沒有讓干系人了解迭代式開發的意義

�牐牽蛻粽J為轉交了項目的需求，他們就可以袖手旁觀，直到完整的產品被交付。管理者也已經習慣性地認為，他們可以期待在項目的第一天就能制定完美的計劃，然后按部就班地執行，而且幾乎不需要什么調查、試驗編程或概念驗證，就可以獲得可靠的估算。如果一個項目失敗了，他們會認為，不是因為計劃錯誤，而是因為計劃沒有得到執行，或者是由不稱職的計劃或估算人員造成的，而這種思維恰恰是讓管理者招致惡名的一個原因。

�牐牉榱俗尩�代開發發揮作用，客戶必須參與其中。迭代式開發的精髓是根據反饋進行及時調整，而不是預先揣測。如果客戶不感興趣，不積極參與以確保構建了他們要求和需要的系統，那么他們必將自食其果。軟件開發最難的部分在于構建“對”的東西，讓功能和易用性真實有效。開發人員很少是領域專家，他們需要獲得幫助來理解解決問題需要些什么，以及如何來構建“對”的系統，而瀑布方法剝奪了開發團隊與客戶之間有意義的交流�？蛻魬�該在定義需要開發些什么的任務當中扮演積極的角色。最佳的做法是在開發人員與用戶/客戶的協作之下，從理解需要解決的問題開始，并以一種演進的方式來探查問題(包括機遇和挑戰)。迭代方法提供了對于這類開發來說非常關鍵的適應性反饋。

�牐犲e誤四：過度建模并創建了很多低價值的工件

�牐燫UP是一個能夠解決許多不同問題的框架。然而，您不太可能在項目中使用RUP全部的內容。迭代式開發的觀點是為了獲得實際的反饋，當只獲得一部分需求或設計時，就盡快開始編程，而不是停滯于對需求和設計的百般揣測。因此，一種有效的讓RUP和迭代失敗的方法是創建所有的RUP文檔，并試圖用最大的精度來細化它們，在編程之前至少畫上N頁的UML圖。 �牐�

�牐燫UP就像一個藥箱或一家藥店，我們大部分人可能不會走進一家藥店，每一種藥都買上一些然后全部服下，我們知道要謹遵醫囑，只服用我們需要的藥。有人抱怨說RUP太龐大了，這就好比說藥店里的藥太多了。真正的問題在于：人們需要更好地了解如何知道自己需要些什么。把風險緩解作為判斷依據是確定RUP究竟應該用多少的一個好辦法：理解您面臨的問題，然后挑選能夠幫助解決這些問題的技術(藥)。

�牐�第五招：回避那些真正懂得迭代式開發的顧問

�牐犛幸恍┧�謂的專家顧問并沒有真正領會迭代式開發以及RUP對瀑布型價值觀和先斷性做法的根本拋棄。他們所傳達的RUP信息是錯誤的，而且通常夾帶著瀑布思維。

�牐牉槟�的第一個RUP迭代項目組建這樣一個團隊：他們從來沒有從事過基于短時間盒的適應性迭代式開發，尤其是那些項目領導者。找到那些執著于瀑布型觀點和做法的人。堅決不要與知道如何進行迭代式開發的顧問簽約。如果一位經驗豐富的顧問不幸參加了這個項目，保證他只能扮演一個配角，對他的建議進行多番辯論、嚴厲質疑，最終讓項目領導拒絕他的想法，而且還要不斷奚落他。一定要找這樣的人——他們曲解RUP，不露聲色地疊加先斷性的瀑布觀點，例如，認為細化階段就是為了詳繪模型，然后在構造階段進行實現，或者在項目一開始就計劃和分配所有迭代的工作。��

�牐�第六招：大張旗鼓地實施RUP

�牐犎绻�可能的話，在某一天向整個組織介紹RUP，然后要求所有的項目第二天就照辦而不告訴任何人實施的細節。如果這條辦不到，那么就對組織進行強制教育，而且只培訓那些開發人員,而不包括經理或IT執行主管。如果所有人都必須參加RUP學習，那么盡量在RUP實施前6個月這么做，否則人們就會全然忘了它，然后只好再找一位RUP“導師”提供短期的1天培訓來強化瀑布理念。如果必須在培訓后馬上實施RUP，那么至少應該在全組織內的所有項目上進行實施，同時讓所有人立刻切換過來。

�牐犌�萬不要這樣做：在一位有經驗的教練指導下，通過一個小型的示范項目，嘗試采用一批少量的、簡單的RUP做法，從實踐中學習，逐漸地增加實施內容，在取得第一個項目的基礎上再啟動第二個。如果某人提出相反意見，就立刻解雇他。請出那些懷疑RUP/迭代、支持瀑布型的人，讓他們來負責管理RUP實施項目。

�牐�第七招：誤解清單

�牐牉榱舜_保取得RUP實施中的徹底誤解和失敗，我們向您提供以下檢查清單(評分表)。得分越高，RUP的實施也就越失�。�

�牐�* 您認為起始階段 = 需求；細化階段 = 設計；構造階段 = 實現。

�牐�* 您認為細化階段的目的是為了完整細致地定義模型，并在構造階段將它翻譯成代碼。

�牐�* 您認為在細化階段只需創建原型(事實上，應該在細化階段針對高風險的架構元素編程實現具有產品級質量的核心子系統)。

�牐�* 您試圖在開始設計或實現之前定義絕大部分的需求，或者在開始實現之前完成絕大部分的設計。

�牐�* 您認為一個合適的迭代長度只能以月為單位來計算，而不是周。

�牐�* 您認為編程之前的UML繪圖和設計活動階段是為了完整地、精確地定義極其詳盡的設計與模型，認為編程只是簡單、機械地把模型翻譯成代碼。

�牐�* 您企圖從頭至尾詳細地計劃一個項目，然后把工作分配到每一個迭代；竭盡全力地企圖預測所有的迭代以及在每一個迭代中發生的情況。

�牐�* 一個組織在進入細化階段之前，就要求獲得可信的計劃和估算。

�牐�* 一個組織認為實施RUP就意味著從事盡可能多的活動或創建大量的文檔，把RUP當作一個有許多步驟需要遵循的規范過程來運用。

�牐犖覀兿嘈抛裾詹⑦\用了以上的奪命七招，您的RUP和迭代開發項目實施必將一塌糊涂。

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

TAG: rup 實施 之 奪命 七招