RUP的剪裁原理和剪裁過程 (轉)

RUP的剪裁原理和剪裁過程 (轉)[@more@]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兩遍批示透過就是驗收測試。

　　進一步講，軟體過程不僅有開發過程，而且有完整的軟體過程生存週期。因為軟體過程在開發出來之後，也有交付使用、維護升級直至廢棄的過程。交付使用就是將軟體過程實施，用於指導軟體專案的開發。要是在使用軟體過程時發現有錯誤之處（，需糾錯性維護）或欠缺之處（新需求，需升級性維護），可以對原軟體過程進行修改或增強。當其經過修改升級也不能滿足指導開發的需要時，就將其廢棄，軟體過程生存週期結束。 順便插一句，當前異常火爆的CMM說是“軟體過程和標準”，當如何理解。從“軟體過程也是軟體”的角度考慮，CMM的本質其實是軟體過程開發的需求和測試方案：CMM的每個“關鍵實踐”都是軟體過程開發的一條需求；至於“關鍵過程域”和“關鍵實踐類”，從需求的層次角度（請參考Wiegers著陸麗娜譯《軟體需求》一書），可分別理解為“業務需求”和“需求”；CMM提問單的每個問題就是測試方案的一個一個的測試案例，測試方案是依照需求來制定的，CMM把需求和測試方案二合一了。“CMM是軟體過程的進化框架”也不難從“軟體過程也是軟體”的角度找到犀利的理解，那就是：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的pe、vision和features；傳統的《軟體需求規格說明書》的非功能需求部分要包括RUP的business rules；等等。