RUP 概述
Rational Unified Process 是當今使用中的實際標準的軟件工程過程。1RUP 的目標是確保能夠按時并在預算之內生成能夠可預見地滿足最終用戶需求的高質量軟件。RUP 為在開發組織內分配任務和職責提供規程式的方法，并已經應用到許多項目中，這些項目有各種大小和復雜度，開發團隊有大有小，且開發時間有延續幾周的，也有延續幾年的。
圖 1 以二維的形式說明 RUP 的整個體系架構。水平軸代表時間并顯示了過程生命周期的各個方面。生命周期階段的管理視圖在頂部，迭代的軟件工程和項目管理視圖在底部。垂直軸代表按照邏輯分組的規程，表示過程的靜態方面 —— 如何用過程部件、規程、活動、工作流，工件和任務來描述 RUP。
圖 1. 規程、階段和迭代的 RUP 概念
在基于 RUP 項目的任何時間點，都會有按照多種規程發生的活動。區別不同生命周期階段的東西不是缺少某些規程，而是不同規程在整個工作流中所做出貢獻的相對量�；顒拥幕旌蠒S著項目的重點和優先權的變更而隨時變化。例如，在早期的迭代中，您將更多時間花費在需求上，而在晚期的迭代中，您將更多的時間花費在實現上。
RUP 階段和迭代
從管理觀點出發，RUP 軟件生命周期包括四個順序的階段，每個階段都以一個主要的里程碑結束。進行評估以確定是否達到階段的目標。令人滿意的評估結果可以使項目向下一個階段進行。簡要地說，RUP 生命周期的階段是：
- 初始：初始階段的目標是在所有涉眾之間達成關于項目的生命周期目標的協議。具有代表性的是，在項目進行之前必須確定重要的業務和需求風險。對于那些少量增強現有系統的項目來說，初始階段是簡短的，但仍舊著重于確保項目即值得做又可能實現。生命周期目標里程碑是初始階段的主要出口標準。它估計了項目的基本生存能力。
- 細化：細化階段的目標是為系統體系架構設定基礎，用來為構建階段的大多數設計和實現工作提供穩定的基礎。細化階段會描繪出一個將必要的業務需求結合了技術體系架構的可執行的系統，并論證所選技術方法的生存能力。該體系架構進化了對最重要的需求（哪些需求對系統的體系架構有很大的影響）的考慮和對風險的評估。生命周期體系架構里程碑為系統的體系架構建立了一個受控的基線，并令項目團隊在構構建段進行測量。
- 構建：構建階段的目標是澄清剩余的需求并完成基于基本體系架構的系統的開發。構建階段在某種意義上說是一個制造過程，在此階段要強調對資源的管理和對操作的控制，用來優化成本、進度和質量。在這個意義上說，管理團隊經歷著一個從初始和細化階段的知識產權的開發到構建和產品化階段的可部署產品的開發的變遷。初始的操作能力里程碑確定是否可以將產品部署到用戶能夠接受的環境中。
- 產品化：產品化階段的重點是確保軟件對最終用戶是可用的。產品化階段可以跨越若干次迭代，該階段包括為發布而進行的產品測試，以及根據用戶反饋做出較小調整。在生命周期的這個階段，用戶的反饋應主要用于對產品進行微調、配置、安裝和解決可用性問題，在項目生命周期的更早期就應該解決所有的主要結構問題。產品版本里程碑是一個您需要在此決定項目是否達到目標，及您是否應該開始另一個開發循環的位置。從軟件工程和項目管理的觀點出發，隨著迭代的進行，事情會逐日的發生。階段由若干迭代組成 —— 依照基本計劃和評價標準的不同序列的活動會致使工件的發布（內部或外部的）。生命周期的每個階段都由一系列迭代組成，迭代的特性根據您所在的生命周期的位置不同而不同。
RUP 和 MDA
目前，RUP 沒有提供對如何將軟件開發的 MDA 式樣整合到整個過程中的具體指導。這不奇怪，RUP 反映當前行業的最佳實踐，且只有在領域內很好地確定之后才能編制方法。MDA 是一個新興的方法，應用到 RUP 項目中重要的 MDA 最佳實踐僅到現在才變得可以得到。
然而從我們的經驗中可以得來許多重要的方式，我們可以以這些方式用 MDA 項目的最佳實踐來增強 RUP。特別是，RUP 的靈魂，即以體系架構為中心的迭代的開發過程，與 MDA 概念保持高度一致，并為在 MDA 方面取得成功提供極好的基礎。
然而，存在著一些領域對 MDA 提供額外的適當指導。在此，我們考慮許多重要的關于將 RUP 應用到 MDA 項目中的重要方面。
- MDA 項目所影響的主要階段是細化階段。觀察細化階段的活動并簡要地描述 MDA 改進是很重要的。
- 架構師是細化階段的主要角色，需要對其進行額外的考慮。隨著“架構師”的專業化，許多 MDA 項目都需要 MDA 架構師角色。從本質上說，該角色規定了具體的 MDA 活動和工件，創建轉換等。因此，出自該角色的主要 MDA 工件是映射文檔、轉換和 UML profile 文件。
- MDA 如與模型驅動自動化一樣與模型驅動體系架構有關。這提供了某種關于如何觀察 MDA 和 RUP 的指導。有代表性的是，MDA 自動操作 RUP 中的活動。MDA 利用針對支持將許多主要 RUP 活動自動化的額外工作來擴充 RUP 活動，而不是改變它們。
- MDA 的應用涉及許多 RUP 任務，但它們不需要額外的活動。相反地，每個任務中的標準活動將要求加入關于那些活動如何利用所選的具體工具和 MDA 技術來實現自動化的細節。在 RUP 中，我們稱這些額外的細節為 RUP Tool 指導。例如，一個進行關于對象的數據映射的團隊可能會利用建模工具進行一組 MDA 轉換。但在高級別上，他們關于“定義設計類”的工作流會基本上保持不變。
- 更深入的是，對 RUP 的主要變更包含對開發過程的視圖的更微秒的改變。MDA 促使架構師和開發人員在比非 MDA 項目中期望的更高的抽象級別上工作。這在構建階段是最明顯的，在此階段，MDA 的代碼自動化方面較大地改變了實現工作的重點。開發人員能夠在對 MDA 轉換進行輸入時繼續進行更抽象的分析并設計模型。他們發現他們更少地處理實際的實現模型和源代碼，而更多地進行針對解決方案的適當的著重于業務的工作流的設計。會有更少的開發人員實現模型到代碼的轉換。
- MDA 轉換常常形成于預先建立的解決方案框架（也稱為“參考體系架構”或“應用程序框架”）周圍。MDA 轉換用具體領域的業務邏輯擴充這些框架。這種將 MDA 和解決方案框架結合的方法具有很大的意義，因為完整的 MDA 方法是作為自動化一組可重復技術和資產的中心。然而，它更進一步地使開發過程更著重于重用、管理資產和增加了的解決方案的交付。
使用 MDA 定制解決方案框架
當今的企業軟件系統很少是（如果有的話）在集成開發環境（IDE）中從零開始，一行行地被開發出來的。相反，它們是通過用具體領域的業務邏輯來擴展現有解決方案框架，通過連接（并利用）來自不同源頭的信息，并通過設計豐富環境的用戶顯示和迭代服務創建而成的。因此，隨后的開發方法不是典型的“瀑布”方案，在瀑布方案中，收集需求之后進行分析和設計，并進行系統的實現。相反，此種開發方法是連續地擴展并細化現有的部分解決方案，通過一組迭代向解決方案中添加值來達到所期望的目標。
文章來源于領測軟件測試網 http://www.k11sc111.com/
