隨需而變的RUP

MILY: 宋體; mso-bidi-font-size: 12.0pt; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">隨需而變的RUP

溫 昱

在數學史上，悖論是一直困擾著數學家的難題。

1902年，英國著名哲學家、數學家羅素曾經提出一個著名的理發師悖論：在薩維爾村，唯一的一位理發師掛出一塊招牌：“我只給村里所有那些不給自己理發的人理發�！庇腥藛査�：“你給不給自己理發？”理發師頓時無言以對。因為，他如果給自己理，那他就屬于“給自己理發的人”，根據他自己所說，他就不應該給自己理發；他如果不給自己理發，也根據他所說，他就應該給自己理發。所以，他理也不是，不理也不是。

如果你還沒有揭開Rational統一過程（Rational Unified Process，RUP）的神秘面紗，你可能也會遇到“RUP悖論”！

看看Per Kroll怎么說，“實際上，RUP并不困難也不復雜。編寫本書的目的就是要告訴讀者RUP實際上是很簡單的[1]�！痹倏纯碐ary Pollice說些什么，“為每一個項目定制你的過程。不要假定一個開發過程的每一個方面都自動地適合你當前的情況[2]�！庇谑�，“悖論”似乎出現了——既然RUP很簡單，那么為什么必須定制？

現實情況就是這么尷尬，不少人還在坐等RUP會突然變得簡單！醒醒吧，看看方法論學家Peter Coad給我們的提醒——如果發生了問題，請上升一個層次，找出該做的事情[3]。

聽Peter Coad大師的教誨沒錯！

本文上升一個層次，站在“軟件過程層”，介紹過程開發理論；然后列舉三個案例，從而示范如何運用這些理論，幫助我們在日常工作中切實有效地進行RUP實施。本文雖然不是專門探討Agile和其他軟件過程的，但筆者認為，過程開發理論對理解所有軟件過程都是大有裨益的。

1、 過程開發理論

在這一部分，我們將介紹3個軟件過程開發的相關理論。首先，是“軟件過程也是軟件”的觀點，它讓我們感悟到，軟件過程是也開發出來的。接下來，在過程開發的基礎上，探討過程開發的再工程理論。而過程開發再工程理論的基礎，是要首先對軟件過程有深刻理解，所以，我們最后探討軟件工程元模型的相關理論。

1.1、軟件過程也是軟件

不知道如何定義“大師”，但大師說話總是很有啟發性。當看到面向對象的“單一職責原則”被表述成“一個類應該僅有一個引起它變化的原因”時，我就想這太Cool了——多么具有可操作性的表述呀——謝天謝地沒有表述成“一個類應當只有一個職責”。

“軟件過程也是軟件”就是很有啟發性的大師級表達。一個類比，有四兩撥千斤之妙！

《軟件過程也是軟件》是軟件工程大師Osterweil的一篇論文[4]，論文中指出：軟件過程也是軟件。軟件有一個開發的過程，軟件過程也有一個開發的過程；軟件開發產出軟件產品，軟件過程開發產出過程產品；軟件開發可以是一個演進過程，軟件過程開發也可以是一個演進過程。

軟件過程也是經過了需求捕獲、分析、設計、實現和測試等活動才開發出來的。軟件過程開發中，需求是指采用該軟件過程的目的是什么（高層需求），要用來指導哪些活動（需求）；分析和設計是指，各活動產出什么產品，活動之間如何銜接，以及如何并行執行；再看看實現，通常我們將軟件過程文檔化，相當于軟件開發的coding；還有測試，軟件過程開發的測試，最常見的是相關人員通過頭腦來進行“運行”和評審。

進一步講，軟件過程不僅有開發過程，而且有完整的軟件過程生存周期。因為軟件過程在開發出來之后，也有交付使用、維護升級直至廢棄的過程。交付使用就是將軟件過程實施，用于指導軟件項目的開發。然而，如果在使用軟件過程時發現有錯誤之處（bug，需糾錯性維護）或欠缺之處（新需求，需升級性維護），就需要對原軟件過程進行修改或增強。直到有一天，當其經過修改和增強也不能滿足指導開發的需要時，就意味著要將其廢棄——于是軟件過程生存周期結束。

1.2、軟件過程的再工程

軟件工程技術歷經三十年的發展，目前已進入成熟期。隨著學科的深入發展，軟件開發技術中，分化出了軟件再工程技術。同樣，軟件過程開發中，也分化出了軟件過程的再工程技術。

再工程（reengineering）是一個工程過程，它通過逆向工程、重構和正向工程的組合，將現有系統重新實現為一種新的形式。下圖（來自參考文獻[4]）顯示了正向工程、逆向工程、再工程等概念的關系。

當實施軟件的再工程時，軟件理解是再工程的基礎和前提。而對于軟件過程來說，需要對軟件過程進行再工程時，也必須全面到位的理解該軟件過程，這也是開展軟件過程再工程的首要條件。下一節，我們就來討論軟件過程的元模型。

1.3、深入認識軟件過程：軟件過程元模型

模型從某一角度出發，捕捉事物最重要的方面，而忽略或簡化其他方面。軟件過程作為一個研究領域，也可以用模型來刻畫它的領域知識。比如，下圖的模型刻畫了RUP中測試工作流相關的角色，以及角色負責的工作。

不同的軟件過程（如RUP和XP），過程模型會有很大不同。為了考察軟件過程的共性，我們來研究軟件過程的元模型。下圖（來自參考文獻[5]）顯示了軟件過程元模型。

軟件過程元模型顯示了任何軟件過程都必不可少的角色（role）、活動（activity）、工作產品（work product）的概念。角色是對個人或作為開發團隊的一組人職責的規定；具體人和角色的關系，好比人和帽子的關系�；顒泳褪墙巧珗绦械墓ぷ鲉卧�。而工件是工作的成品或半成品。

角色的職責，具體體現在他執行活動和負責工件上。工件是由活動生產出來的——工件是活動的輸出；比如制定《編碼規范》。然而，活動本身也可能以工件為輸入——活動可能要求使用工件；比如編碼活動要參考《編碼規范》。當然，工件既是活動的輸入又是它的輸出——活動修改工件；比如修改《編碼規范》。

2、 RUP實施

在上一部分，我們討論了軟件過程開發的相關理論。理論是用來指導實踐的，RUP作為一種著名的軟件過程，其實施照樣離不開理論的指導。不破除對RUP的恐慌（“軟件過程也是軟件”理論解決該問題），不全面認識RUP（軟件過程元模型理論解決該問題），不理解RUP實施的工程實質（軟件過程的再工程理論解決該問題），就不可能充分發揮RUP的作用。

當然，本文介紹的三個理論著眼于大局的感悟，若要真正深刻地認識RUP，還有不懈地學習和實踐才行。但是，倘若沒有軟件過程開發及再工程的理論指導，RUP實施將難免失于“莽撞”，有瞎子摸象、囫圇吞棗之嫌。這恐怕也是不少人使用RUP以及其他軟件工程方法收獲不大的根本原因所在。

接下來，我們以上述理論為指導，談一些RUP實施中的具體問題。首先，從整個RUP實施的角度，討論其宏觀過程，并重點分析過程開發理論的指導作用。然后，是一個RUP定制的例子——軟件項目外包管理，通過發現外包開發和自行開發的共同之處，從而在RUP的基礎上定制外包管理過程。最后，以著名的EUP為例說明如何對RUP進行擴充，以啟發讀者，在掌握軟件過程開發理論之后，其實可以進一步讓RUP適應實際實踐的需要。

2.1、RUP實施指南

在開發組織中引入RUP及其支持工具，原因是因為它們可以提高項目質量，從而得到實際的商業利益。但是，RUP的引入對開發組織來說，意味著改變（或部分改變）以前的工作方法，其中必然會有一定風險。讓我們根據相關理論分析解決之道。

回憶一下Osterweil的教誨：軟件過程也是軟件！想必擅長軟件開發的你，已有了思路了——讓我們有理有據地進行需求采集、分析、設計，之后“開發出”適合團隊實際情況的RUP實施方案。有了實施方案，評審通過之后，就成為指導團隊協作的管理依據，這是RUP實施已完全明朗。

下面結合參考文獻[1]給出的相關指南，對上述過程進行工程化的描述。在項目開始時引入RUP，共需如下5個步驟：

1．    評價（assess）。評價開發團隊以前在軟件過程方面遇到的問題，明確過程實施的目標。

2．    計劃（plan）。計劃RUP的具體實施過程，包括相關培訓。

3．    配置和定制（configure and customize）。剪裁和定制RUP，使它符合項目的實際情況。

4．    執行（execute）。進行培訓，并啟動項目，在項目中運用你定制的RUP。

5．    評估（evaluate）。評估RUP的實施情況，為以后改進做準備。

由上面的步驟可以看出，RUP的實施不是一個單純的過程開發與執行，而是過程的再工程與執行。RUP包含了眾多的軟件開發最佳實踐，以及詳盡的工作指南，在RUP的基礎上進行再工程是明智的。由此還可以看出，我們介紹的軟件過程再工程理論，對指導具體RUP實施工作，是非常有意義的。

需要說明的是，最好在項目開始時（而不是項目進行到一半時）就實施RUP，這樣可以避免項目過程中工作方法的改變引起的復雜問題。

2.2、RUP剪裁案例：外包管理

可以說，外包和經濟全球化如影隨形。

全球IT外包市場在2004年強勁地增長到了516億美元，這是個讓國內軟件企業不得不動心的數字。但與印度等外包強國相比，國內軟件企業在許多方面存在差距，其中管理就是一個回避不了的問題。

面對這種形勢，本文的RUP剪裁案例，就舉外包管理！

那么，一個企業如何通過對RUP的定制，使它適合軟件外包管理的要求呢？總體而言，軟件的外包管理包括承包方的選擇和外包開發的管理兩大部分，由于篇幅所限，本文僅討論外包開發管理。

軟件項目外包開發有其顯著特點，那就是承包方自己承擔軟件開發和人員管理方面的工作，但軟件產品和與雙方都相關的軟件過程，則由委托方和承包方共同管理。因此，外包項目的管理可以分為3個階段：項目啟動，項目開發，項目驗收。以上3個階段和RUP的4個階段有著良好的對應關系，如下圖所示：

在RUP剪裁方面，用于管理自身開發和用于管理承包方開發，有很大的不同。比如，一方面，開發工作由承包方來做，所以在外包開發階段，大多數核心工程工作流為空；但另一方面，承包方的開發過程不透明又非常危險，難以監控開發進度，所以多設立檢查點非常有必要。

另外需要注意的是，外包的軟件項目，往往是委托方自己的更大項目的子項目。這時，委托方還應著重考察雙方軟件過程的“兼容性”，不要在最后才進行集成，應當在早期的里程碑就持續不斷的進行集成，并進行相關的測試和反饋。

總之，正如軟件過程元模型理論告訴我們的，所有的軟件過程都有共性。我們應當重視軟件外包開發存在的新問題，但并不能因為“不熟悉”或“害怕新事物”，而演繹出“白馬非馬”的故事來。

2.3、他山之石：EUP簡介

對RUP的剪裁與實施，普遍存在一個誤解，那就是RUP剪裁只能簡化RUP，而不能擴充。

EUP網站[8]聲稱，根據Ronin International公司的經驗，RUP并不總是足夠。筆者也有過這樣的經歷：一次講授RUP課程的時候，有位聽眾問，哪個工作流負責軟件過程改進，我說，沒有，需要擴充RUP。

EUP（Enterprise Unified Process）是著名的RUP擴充方案，如下圖（來自參考文獻[8]）所示。在階段方面，增加了初始前階段（Pre-Inception phase）、產品化階段（Production Phase）和廢棄階段（Retirement Phase）。在工作流方面，增加了8個：1個核心支持工作流，7個核心企業工作流。

以軟件過程改進工作流為例，下圖（來自參考文獻[8]）顯示了其工作流程。

EUP也象RUP一樣提供詳盡的工作指南，例如下圖（來自參考文獻[8]）是“創建過程”活動的工作流明細。

可見，RUP不僅可以定制，還可以擴充。掌握了軟件過程開發理論，軟件過程“隨需應變”不再是遙不可及的天方夜譚。

3、軟件過程也應“隨需應變”

本文立足于軟件過程開發理論的討論，揭開了RUP的神秘面紗；然后選取了幾個RUP實施中的問題，結合理論進行討論和解決。

由于是“上升一個層次”進行思考，我們還得到很多啟發。

軟件過程和軟件一樣，是我們“開發”出來的。軟件項目各不相同、開發團隊情況各異、商業環境瞬息萬變，這些都是決定軟件過程開發或再工程的需求。面對如此復雜的軟件過程需求，不禁讓人想起了軟件開發領域“隨需應變”的口號來。而Roger S. Pressman在其經典著作《軟件工程：實踐者的研究方法》[9]中指出：“大約每隔5至10年，軟件界就會重定義‘問題’，將其焦點從產品轉移到過程�！闭沾丝磥�，沒幾年，軟件過程也要進入“隨需應變”時代了。

既然RUP很簡單，那么為什么必須定制？答案就是，軟件過程也應“隨需應變”！

參考文獻：

[1] Per Kroll等著，徐正生等譯. Rational統一過程：實踐者指南. 中國電力出版社，2004

[2] Gary Pollice等著，宋銳等譯. 小型團隊軟件開發：以RUP為中心的方法. 中國電力出版社，2004

[3] Stephen R. Palmer等著，熊煥宇等譯. 特征驅動開發方法原理與實踐. 機械工業出版社，2003

[4]http://portal.acm.org/citation.cfm?id=253440&coll=portal&dl=ACM&CFID=5918601&CFTOKEN=42777842

[5] http://media.ccidnet.com/media/ccu/339/02301.htm

[6] http://www.omg.org/technology/documents/formal/spem.htm

[7] http://www.shecn.com/xprogrammer/issue/12/pub_scott.htm

[8] http://www.enterpriseunifiedprocess.info

[9] Roger S.Pressman著，黃柏素譯. 軟件工程:實踐者的研究方法. 機械工業出版社，1999

作者簡介：

溫昱，架構設計師，資深咨詢顧問，松耦合空間（http://lcspace.nease.net）創辦人。擅長面向對象、架構和框架設計，對設計模式、UML和軟件工程有深入研究。可以通過wenyu@china.com和作者聯系。