原文網址：http://www.windcat.idv.tw/archives/000523.html

 RUP（Rational Unified Process）

　　RUP（Rational Unified Process）是演變自Rational公司Ivar Jacobson、Grady Booch和James Rumbaugh於1998年發表的“The Unified Software Development Process”（Ivar Jacobson, 1998）一書中描述的Unified Process。RUP除了協助研發單位分配軟體開發工作和責任，以確保在可預期的時程和預算內開發出符合使用者需求的高品質軟體外，更可以根據使用組織的需求去調整或擴充。是故，RUP是一套嚴謹的軟體工程流程（Software Engineering Process），同時也是一套流程框架（Process Framework）。此外，由於這套流程產品是由Rational公司研發的，故RUP能與該公司旗下一系列軟體開發工具互相整合（Phillippe Kruchten, 2000；趙光正, 2002）。

　　直到2000年底，有超過一千家公司在使用RUP，其中包括許多不同領域以及大、小型的專案（Intel、Ericsson、Xerox、Volvo、Oracle…），顯示RUP兼具多樣性和廣泛的可用性（Usability）。超過50%的使用者把RUP用在電子商務上或預計作這樣的應用。組織使用RUP的方式有很大差異，有些企業的依正規方法，從RUP中演進自己的公司流程，再小心遵循它。其它的較不正規的方法則是把RUP視為範本（Template）或指導方針。

圖 2－7 RUP的家譜
資料來源：趙光正, 2002

　　回顧過去，RUP 每一個版本的演進除了繼承過去的優點外，往往會再合併許多領域的知識。1987年Ivar Jacobson在經歷多年電信製造商Ericsson AB之歷練後，於瑞典創造出Objectory Process。由於這項產品著重在使用案例觀念和物件導向設計，很快地就得到軟體工業界的認同，並且廣被世界各地的公司採用。而後在1992年發表了簡化版的Objectory Process（Ivar Jacobson et al., 1992）。

　　1995年Rational與Object AB兩間公司合併後，整合Rational Approach 與Objectory Process（3.8 版）形成Rational Objectory Process 第四版，此版本吸收了Objectory的反覆式開發（Iterative Development）和架構的固定格式，並結合Rational的流程繼承模型和主要的使用案例觀念。由於Rational公司的另一個部門在1996年完成UML0.8版，故第四版率先採用當時剛誕生的統一模型語言（Unified Modeling Language）。1997年，Rational又合併了Requisite與SQA兩間公司；因此，此版本也合併了Requisite需求管理（Requirement Management）構想和SQA詳細的測試程序（Test Procedure）。

　　RUP第五版除了將第四版的Rational Objectory Process與Pure－Atria合併外，更增加了資料工程（Data Engineering）、企業模型（Business Model）、專案管理、組態管理（Configuration Management）等領域的東西。而2000版則是由於Rational取得Object Time創辦人開發即時（Real－Time）物件導向方法的元素，並將該元素放到RUP中，使得即時物件導向方法之元素能夠跟一系列Rational開發工具緊密的整合。由於RUP演變至今融合許多現代最好的軟體開發實務經驗，因此能夠適合各種專案或組織使用。最特別的地方是它包含六項最好的軟體開發實務經驗：　　

　　1.用反覆式方法開發軟體
　　2.管理需求
　　3.以元件為基礎（Component－based）的架構
　　4.視覺式模型製作軟體（Visually Model Software）
　　5.持續驗證軟體品質
　　6.控制軟體的變動

　　完整的RUP包含兩個主要結構（維度），水平軸代表時間和流程啟始後的各個生命週期，隱含反覆式開發（Iterative Development）與專案管理工作流程（Project Management Workflow）。垂直軸代表核心工作流程（Core Workflow），即是將把活動依照本質加以分類的結果（如下圖所示）。

圖 2－8 RUP整體結構
資料來源：趙光正, 2002

　　RUP的完整結構是採用1996年Barry W. Boehm提出的軟體專案之必要程序（Barry W. Boehm , 1996）做為水平軸的四個階段，分別是Inception、Elaboration、Construction與Transition。各階段皆有其目標與里程碑（Milestone）。如下所述：
●初始階段 （Inception Phase）
　　目標：定義產品的範圍、降低風險的影響力、準備企業運作的初始作業，並以企業組織之管理指出專案進行之方向。即是建立整個專案之目標。相關之作業有，
　　　◆盡可能的用use cases描述整體需求。
　　　◆描繪出專案的整體架構。
　　　◆清楚定義專案的目標。
　　　◆初步的專案規劃。
　　里程碑：
　　　◆釐清顧客確實之需求，並確認滿足這些需求所須執行之活動。
　　　◆初步的循環排程。
　　　◆初步的架構。

●詳述階段（Elaboration Phase）
　　目標：此階段建立基礎架構、擷取產品之需求、再次降低風險，並且規劃出整個產品製作之架構。詳述階段的最後還必須進行成本預估、排程與規劃建構階段的一些細節。相關之作業有，
　　　◆針對產品的雛型架構進行設計。
　　　◆用use cases描述最終產品的各種功能。
　　　◆規劃循環式作業的各項細節
　　里程碑：
　　　◆透過use case描述的產品功能，再次確認顧客之需求。
　　　◆雛型架構之設計將決定整個產品後續之開發。
　　　◆釐清一些主要之風險。
　　　◆確認專案計畫是可行的，且能夠完成專案之目標。

●建構階段（Construction Phase ）
　　目標：此階段之任務就是將產品實作出來，確保產品的各項功能都能運作，且顧客收到產品時能夠符合需求。相關之作業有，
　　　◆產品之建置完成。
　　　◆各元件與最終產品之測試。
　　　◆產品是可以用的。
　　里程碑：
　　　◆產品有其功能性。
　　　◆產品能夠移交給顧客。

●轉換階段（Transition Phase）
　　目標：確保顧客能夠正常的使用產品，因此需要些教育訓練、支援與維護等作業，使顧客能夠滿意。
　　里程碑：
　　　◆有符合初始階段描述的目標。
　　　◆顧客滿意。

　　RUP的垂直軸共有九個核心工作流程（Core Workflow），依照不同範圍或原則將所有工作人員與活動加以區分，共形成六個核心工程工作流程和三個核心支援工作流程。核心工程工作流程如下：

　　■企業模型工作流程（Business Modeling Workflow）
　　■需求工作流程（Requirements Workflow）
　　■分析與設計工作流程（Analysis and Design Workflow）
　　■實作工作流程（Implementation Workflow）
　　■測試工作流程（Test Workflow）
　　■配置工作流程（Deployment Workflow）

核心支援工作流程如下：

　　■專案管理工作流程（Project Management Workflow）
　　■組態管理與變動管理工作流程（Configuration and Change Management Workflow）
　　■環境工作流程（Environment Workflow）

　　雖然六個核心工程工作流程是用傳統瀑布式（Waterfall）的方式來命名，但是RUP的實際運仍然是採用反覆式流程（Iterative Process）的方式，整個生命週期這些工作流程會不斷重複。一個專案完整的工作流程是由這九個核心工作流程（Core Workflow）交錯組成，而且在反覆中，這些工作流程會一再重複，只是每次強調的重點皆不同。

參考文獻
[1]　Phillippe Kruchten, 2000, “The Rational Unified Process An Introduction Second Edition”.
[2]　趙光正, 2002, “Rational 統一流程入門第二版”, 維科圖書有限公司.
[3]　Ivar Jacobson , Grady Booch, and James Rumbaugh, 1998, “The Unified Software Development Process”, Addison Wesley Longman.
[4]　Ivar Jacobson et al. , 1992, “Object-Oriented Software Engineering：A Use-Case- Driven Approach”, Addison-Wesley.
[5]　Barry W. Boehm , 1996, "Anchoring the Software Process", IEEE Software, July.