關鍵字：RUP 剪裁
RUP即Rational Unified Process，是Rational公司開發的軟件過程產品。The Unified Software Development Process也指的是RUP，不過去掉了前面的公司名。本文分別采用“統一軟件過程”和“RUP”作為其全稱和簡稱。 就筆者所了解，當前國內業界普遍關心的一個問題是：RUP的剪裁原理是什么，有沒有工程化的RUP剪裁過程。本文將討論上面兩個問題。本文有不少觀點來自個人心得，有不妥之處，敬請斧正。
第一部分 RUP的剪裁原理
首先介紹“軟件過程也是軟件”這一著名原理，然后指明RUP的剪裁原理是：軟件過程開發的再工程。
一、 軟件過程也是軟件
軟件工程大師Osterweil在其論文《Software Processes are Software Too》中高屋建瓴地指出：軟件過程也是軟件。軟件有一個開發的過程，軟件過程也有一個開發的過程；軟件開發產出軟件產品，軟件過程開發產出過程產品；軟件開發可以是一個演進過程，軟件過程開發也可以是一個演進過程。
1. 軟件過程也有一個開發的過程
軟件過程也是經過了需求捕獲、分析、設計、實現和測試等活動才開發出來的。下面僅簡單論述。軟件過程開發中，需求是指采用該軟件過程的目的是什么（高層需求），要用來指導哪些活動（需求）；分析和設計是指，活動之間如何銜接甚至并行執行，各活動產出什么產品；實現是指，將軟件過程文檔化，相當于軟件開發的coding；軟件過程開發也有測試，不過是在腦子里run的，而上級領導用腦子run兩遍批示通過就是驗收測試。
進一步講，軟件過程不僅有開發過程，而且有完整的軟件過程生存周期。因為軟件過程在開發出來之后，也有交付使用、維護升級直至廢棄的過程。交付使用就是將軟件過程實施，用于指導軟件項目的開發。要是在使用軟件過程時發現有錯誤之處（bug，需糾錯性維護）或欠缺之處（新需求，需升級性維護），可以對原軟件過程進行修改或增強。當其經過修改升級也不能滿足指導開發的需要時，就將其廢棄，軟件過程生存周期結束。 順便插一句，當前異�；鸨�CMM說是“軟件過程框架和標準”，當如何理解。從“軟件過程也是軟件”的角度考慮，CMM的本質其實是軟件過程開發的需求和測試方案：CMM的每個“關鍵實踐”都是軟件過程開發的一條需求；至于“關鍵過程域”和“關鍵實踐類”，從需求的層次角度（請參考Wiegers著陸麗娜譯《軟件需求》一書），可分別理解為“業務需求”和“用戶需求”；CMM提問單的每個問題就是測試方案的一個一個的測試案例，測試方案是依照需求來制定的，CMM把需求和測試方案二合一了�！癈MM是軟件過程的進化框架”也不難從“軟件過程也是軟件”的角度找到犀利的理解，那就是：CMM對所有軟件過程開發的需求，依據重要性和相互依賴關系，劃分了優先級，然后依據需求的優先級將需求分成五組，即初始級、可重復級、已定義級、定量管理級和優化級。
2. 軟件過程開發產出過程產品
軟件開發產出的軟件產品是程序和文檔的集合，那么，過程開發產出的過程產品是什么樣呢？過程成品從存在形式上，是一些文檔。通過評審的過程產品，就是標準化制度化的文檔，這些文檔來指導和制約軟件開發過程。
過程產品都必須具備四要素：功能要素（即活動），行為要素（即活動間通過依賴等關聯構成活動模型，其實四大經典開發模型的圖基本都是活動模型），組織要素（即人和活動間的關聯），信息要素（即產品）。
再看RUP，該過程產品也是一些文檔，總共有上千頁，被組織成可以在線查詢的知識庫。我們看其核心概念：角色、活動、工作流和工件，并沒用離開四要素的范疇：角色即人（的職責），工件即產品，工作流是涉及角色、活動和工件的模型。
3. 軟件過程開發也可以是一個演進過程
為了進一步證明軟件過程開發和軟件開發的相似性，我們選擇很流行的“演進”概念來考察二者。演進開發在RUP中叫增量開發，就是后一步的開發在前一步開發的半成品的基礎上進行。軟件開發采用演進開發的，一般稱為“噴泉模型”。而軟件過程開發也可以采用演進開發，特別是開發針對大項目的軟件過程時，由于軟件過程足夠復雜，演進開發是必要的。
二、 RUP的剪裁原理
首先說明再工程的概念，然后說明RUP剪裁就是一項再工程。
1. 再工程的概念
再工程（reengineering）是對現有軟件系統的重新開發過程，包括逆向工程、新需求的考慮和正向工程三個步驟。
2. RUP剪裁是軟件過程開發的再工程
既然“軟件過程也是軟件”，那么再工程概念對軟件過程開發也適用。RUP剪裁的故事就可以這樣講：Rational公司開發出了RUP；我們想將RUP剪裁后用于某軟件項目，于是我們就對RUP進行逆向工程得到《RUP開發需求》和《RUP設計方案》等文檔；然后，再考慮我們這個軟件項目得到《某軟件項目軟件過程需求》；最后，比較兩個需求，借鑒《RUP設計方案》，進行軟件過程開發的正向工程得到《某軟件項目軟件開發過程》。
是的，“RUP剪裁是軟件過程開發的再工程”的觀點確實很有啟發，為我們制定工程化的RUP剪裁過程打下了堅實的理論基礎。
第二部分 對RUP進行逆向工程
依據“RUP剪裁是軟件過程開發的再工程”的觀點，RUP剪裁分為對RUP進行逆向工程、考慮軟件過程新需求和過程開發正向工程三個步驟。但是，對RUP進行逆向工程只需進行一次，以后的RUP剪裁過程都可以重用了。所以，筆者將“對RUP進行逆向工程”從“工程化的RUP剪裁過程”單獨提出討論。
另外，本文也不打算詳細闡述逆向工程的工程化過程，那將是非常龐大和非常理論化的。本文采取的方法是，列出逆向工程過程的產出產品的子集，而且每個產品的內容也僅涉及核心子集。
其實，如果不從理論化的角度講，對RUP進行逆向工程其實就是個理解RUP的過程（不理解RUP就沒用辦法進行剪裁），因此，下面的闡述也是筆者對RUP的一點理解，拋磚引玉，敬請斧正。
一、 需求
Rational的大師們在開發RUP時先要進行需求捕獲，他們捕獲到的需求肯定少不了下面的內容：
◆RUP將是一個有足夠通用性的過程產品，將RUP適當剪裁后應能適合絕大多數項目。（功能需求）
◆采用RUP作為開發過程，開發風險必須最小化。（非功能需求）
二、 分析
接下來進行分析，想必會是這樣：
◆開發過程由多種“活動”組成。
◆每種“活動”生產出不同的“產品”，也可能多種“活動”生產出一種“產品”。
◆活動有業務建模、需求、分析和設計、實現、測試、實施、配置和變更管理、項目管理和環境。（RUP的九個核心工作流）
◆產品有：用例模型、分析模型、設計模型、源程序和測試報告等。
◆活動可以包含子活動，子活動之間可以并行進行，干脆把活動改稱工作流，把子活動改稱活動。
◆“產品”可以是成品或供演進的半成品，干脆把成品和半成品合稱為“工件”。
三、 設計
接下來進行設計，想必會是這樣：
◆為了滿足通用性需求：借鑒面向對象的泛化思想（即參數化或模板），RUP只提供框架而和具體項目無關。
◆為了滿足風險最小化需求：引入階段概念和迭代開發模型，以便給開發者足夠多的機會，在付出太多代價之前放棄或調整開發。
四、 實現
RUP的實現我們都看到了，就是那個可以在線查詢的知識庫，內容很豐富。
第三部分 工程化的RUP剪裁過程
在對RUP進行了逆向工程，并且比較好地理解了RUP之后，還需要進行的兩個步驟是RUP剪裁過程的核心部分，本段給出一種工程化的解決方案。首先，討論軟件過程開發的需求工程；然后，討論軟件過程開發的正向工程，即五步法；最后，對五步法給出幾點說明，著重說明五步法是如何降低RUP剪裁的復雜性的。下面要闡述的工程化的RUP剪裁過程，不是放之四海而皆準的，但確實有一定的通用性。
一、 軟件過程開發的需求工程
這里，軟件過程開發的需求工程，完全可以借鑒軟件開發中的需求工程，包括需求捕獲、需求分析、編寫需求文檔和需求評審。
1. 需求捕獲
首先明確項目環境，然后向項目所有涉及人員收集信息。項目環境包括軟件類型、軟件規模、軟件重要程度、開發人員素質、合作單位素質等，這些因素都會影響到將來軟件過程的制定。項目涉及的人員包括用戶、開發人員、合同確定者和投標者等，從他們那里收集對軟件過程的要求。
2. 需求分析
研究采集到的要求，形成有條理的需求表述。
3. 編寫需求文檔
將有條理的需求表述文檔化。
4. 需求評審
組織由上級領導、開發人員及其他人員參加的評審。若評審未獲通過，根據具體情況從上面三步的其中一步開始回溯，直至評審通過。
二、 軟件過程開發的正向工程
采用“五步法”。一方面，五步法保留了RUP的優秀概念，如階段、迭代、工作流、工件和角色等。另一方面，五步法采用了一些旨在降低RUP剪裁復雜性的策略，在后面“五步法的幾點說明”中有講述。
1. 確定本項目的軟件過程需要哪些工作流
根據項目規模的大小不同，RUP的九大工作流并不總是需要的；另外嵌入式軟件項目一般不需要業務建模工作流。雖然工作流中可以包含并行執行的活動，但本階段并不關心這些，而是僅把工作流看成黑盒，也就是說工作流退化成了活動。
2. 確定每個工作流產出哪些工件
因為很多開發單位還是評審傳統形式的文檔，因此，可以規定工作流產出某傳統文檔。
3. 確定階段間演進
RUP將開發過程分為四個階段（初始階段、細化階段、構造階段和移交階段）是控制風險的很好的方法，確定階段間演進就是要以風險控制為原則，決定每個階段要執行哪幾個工作流，每個工作流執行到什么程度，產出的工件有哪些，每個工件完成到什么程度。
4. 確定階段內的迭代計劃
迭代是RUP非常強調的一個概念，可以進一步降低開發風險，在RUP的四大階段（在后三個階段進行迭代更常見）中，決定是否采用迭代開發，每次迭代開發的內容有哪些。
5. 規劃工作流內部結構
工作流不是活動的簡單堆積，工作流涉及到角色、活動和工件，并且工作流的復雜程度和項目規模及角色多少等有很大關系。因此，我們應首先決定本軟件過程要設立哪些角色；如果第二步中引入了傳統文檔，還要將傳統文檔映射到RUP工件；最后，規劃工作流內部的結構，通常用活動圖的形式給出。
若想通過對RUP剪裁得到比較復雜的軟件過程，無疑這一步是剪裁的難點。
三、 五步法的幾點說明
1. 確定軟件過程的時機
在實際中，確定軟件過程的時機不是一成不變的。比如，如果新項目和該項目組以前開發過的某個項目很相似，就可以在軟件開發開始之前確定將采用的軟件過程；如果是不熟悉的項目，就可能在初始階段完成后才能確定或修改要采用的軟件過程；如果項目有很多未知因素，迭代計劃推遲到階段開始前比較好，工作流規劃也同樣推遲。
2. 五步法為何前瘦后胖
五步法中的五步，讓人感覺前三步很“瘦”，而后兩步比較“胖”，這是為什么呢？其實，將迭代計劃和角色設立都往后推遲，是為了使軟件過程開發簡單化。軟件過程開發主要有兩種流派：以活動為中心和以角色為中心。而RUP的工作流這個核心概念是角色和活動并重的，通過適當推遲規劃工作流，可以使RUP剪裁簡單化。五步法正是這樣一種RUP剪裁過程：它以活動為中心的，它的第一步就是確定活動；并且它把角色的設立推遲到了最后，既降低了RUP剪裁的復雜性，又保留了工作流的優點。
3. 傳統文檔和RUP工件的對應關系
傳統文檔和RUP工件之間，有時存在一定的對應關系，而且往往是一對多的關系。因此五步法的第二步可以用傳統文檔，不僅是符合習慣的，也減少了軟件過程開發先期階段的細節，降低了RUP定制的復雜性。到了第五步，再將傳統文檔分解成RUP工件，以利用RUP的工作流方面的指南。傳統的《軟件定義文檔》可以分解為RUP的scope、vision和features；傳統的《軟件需求規格說明書》的非功能需求部分要包括RUP的business rules；等等。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/