[mic64]

第2章 Rational 統一流程
在本章，我們提供Rational 統一流程（Rational Unified Process，RUP）的
概觀，簡介流程的結構，描述這個流程產品並列出它的主要特性（Feature）。
什麼是Rational 統一流程（Rational Unified Process，RUP）？
RUP 本身是一種軟體工程流程（Software Engineering Process）。它提供研發
單位一個嚴謹的方法，分配軟體開發工作和責任；目的是確保在可預期的時程和
預算內，開發出符合使用者需求的高品質軟體。
RUP 是一套流程產品，由Rational 所研發和維護，並且與該公司旗下一系列
軟體開發工具相整合。RUP 產品可由Rational 發行的光碟或網際網路取得。本書
是RUP 產品的一部份，不過這只是RUP 知識庫裡的一小部份。本章稍後會描述
RUP 的實體結構。
RUP 同時也是一套流程框架（Process Framework），可根據使用組織的需求
去調整或擴充。第3 章會進一步說明這個流程框架是怎麼形成的，並且介紹流程
的模型－構成流程的主要元素。
RUP 溶入許多現代最好的軟體開發實務經驗，呈現的方式適合各種專案或
組織使用。最特別的地方是它包含第1 章提到的六項最好的軟體開發實務經驗：
1. 用反覆式方法開發軟體
2. 管理需求
3. 以元件為基礎（Component－based）的架構
4. 視覺式模型製作軟體（Visually Model Software）
5. 持續驗證軟體品質
6. 控制軟體的變動
RUP 是一項產品
許多組織逐漸意識到一個定義完整、有充分說明的軟體開發流程對軟體專案
的成功是很重要的。過去幾年來，他們累積所研發的知識並跟開發人員一起分享
成果。這些整理過的實務經驗通常都是由一些方法論、市面上的教科書、訓練課
程和專案累積的技能而來。不幸的是這些實務經驗最後都裝訂精美，被放在開發
人員的書架上堆積灰塵 –很少被更新、很快就不適用，而且幾乎沒有人去遵循它。
就像Lee Osterweil8發表的文章說的：“軟體流程也是軟體”（Software
8 Lee Osterweil, “Software Processes Are Software Too,” Proceedings of the Ninth International
Conference on Software Engineering, pp.2-13, Mar. 30-Apr. 2 , 1987, Monterey, CA.

Processes Are Software Too）。跟那些積滿灰塵的指引不同，RUP 和其它軟體工具
產品一樣經過設計、開發、出貨和維護。事實上，RUP 有軟體產品的特徵：
.. Rational 定期更新產品
.. 使用Web 技術直接線上瀏覽，對開發人員而言，資訊隨手可得
.. 可以調整它並設定它的組態，以符合研發單位的特殊需求
.. RUP 和Rational 一系列軟體工具相整合，開發人員可以從軟體工具直接
瀏覽流程所提供的指引。
把流程視為軟體產品有下面的好處：
.. 流程不會過時不適用；使用者可以定期取得有最新技術的更新版。
.. 所有的專案成員都可以在內部網路取得最新版的流程
.. 採用Java Applet、流程瀏覽器並內建搜尋引擎，允許開發人員同步取得
流程指引或政策，同時還包括他們應該使用的最新文件範本（Template）
.. 超鏈結提供流程導覽功能，可直接跳到軟體開發工具、外部參考文件或
指引
.. 可輕易依照公司或專案的不同，局部修改流程或把流程加以特殊化等等
.. 每個專案或部門都可以管理自己的流程版本或改變流程。
總之，這個網路版的Rational 統一流程產品提供許多紙上談兵流程所沒有
的優點。
流程產品的組織方式
這項產品包含下面幾個項目：
1.一套網路版的Rational 統一流程，可透過光碟或網際網路取得。你可以把
這份網路版當成Rational 統一流程的虛擬電子教練（e－coach），它提供
一個完整的超鏈結網站，以HTML 格式描述流程。
2.一本入門書，也就是你現在正在讀的這本書。
虛擬電子教練（e－coach）可以用任何現在的瀏覽器看，例如Netscape 的
Navigator 或Microsoft 的Internet Explorer。如此我們可以很容易取得所有資訊，
因為：
.. 大量使用超鏈結
.. 圖形導覽方式（大部分的圖形元素都有超鏈結指到它們所描述的流程元
素）
.. 階層式樹狀瀏覽器
.. 完整的索引
.. 內建搜尋引擎

.. 完整的網站地圖
圖2-1 是一張虛擬電子教練（e－coach）的網頁快照，你可以從這張圖找到
許多方便的特性（Feature）。
圖 2-1 網路版的Rational 統一流程
我們不但可以在這個虛擬電子教練（e－coach）中找到完整的流程描述，還
可以找到：
.. 工具顧問，當你用其它由Rational 所提供的軟體開發工具時（例如視覺
式模型製作工具Rational Rose 或組態管理工具ClearCase），還會提供額
外的指引
.. 流程主要工作成果的範本（Template），例如：
. Microsoft Word 和Adobe FrameMaker 的範本，供一般文件與報告使用
. Rational SoDA 範本，可自動合成多個文件來源
. RequisitePro 範本，負責協助管理需求
. Microsoft Project 範本，協助規劃以Rational 統一流程為基礎的週期
性專案
. HTML 範本，可用來擴充線上流程
.. 一個小型專案工作成果例子

從Rational 統一流程2000 版開始，這個虛擬電子教練（e－coach）就包含
多個不同版本的Rational 統一流程。裡面包括一個標準Rational 統一流程，它
可以作為一般軟體的起點，也包含一些事先規劃、有額外指引的新版本，提供給
特定種類軟體開發用。Rational 統一流程電子商務版就是其中一個新版本。本書
從共同觀點描述Rational 統一流程，而不是要詳細介紹某一個單一版本。
誰在使用Rational 統一流程
到1999 年底為止，超過一千家公司在使用Rational 統一流程，其中包括不
同領域以及大型或小型的專案。這顯示Rational 統一流程的多樣性和廣泛的可
用性（Usability）。下面是從不同行業挑出來的範例廠商，它們遍及世界各地：
.. 電信事業：Ericsson、Alcatel、MCI
.. 交通、太空和國防：Lockheed－Martin、British Aerospace
.. 製造業：Xerox、Volvo、Intel
.. 金融業：Visa、Merrill Lynch、Schwab
.. 系統整合業：Ernst & Young、Oracle、Deloitte & Touche
超過50%的使用者把Rational 統一流程用在電子商務上或打算在不久的將
來作這樣的應用。這是工業界正在改變的一個預兆：因為上市時間的壓力和對品
質的要求不斷提高，各家公司都專注學習他人的經驗，並且準備採用已被證實
過、有用的、最好的實務經驗。
這些組織採用Rational 統一流程的方式有很大差異：有的依正規方法，從
Rational 統一流程中演進自己的公司流程，再小心遵循它。其它的則採用比較不
正規的方法，把Rational 統一流程視為忠告、範本（Template）或指引的寶庫，
就像有個軟體工程虛擬電子教練（e-Coach）在陪伴他們一樣。
流程結構：從兩個維度看
圖2－2 顯示整個Rational 統一流程的整體結構。這個流程有兩個主要結
構。如果你喜歡的話，可以把它們稱為兩個維度：
.. 水平軸代表時間和流程開始後的各個生命週期
.. 垂直軸代表核心工作流程（Core Workflow），也就是把活動按照本質加
以分類的結果
第一個維度表示流程開始後的動態觀點，以週期、階段、反覆、里程碑來表
示。我們將在第4 章動態架構：反覆式開發方式（Iterative Development）和第7
章專案管理工作流程（Project Management Workflow）再深入說明。

第二個維度表示流程的靜態觀點，以流程元件（Process Component）、活動、
工作流程、工作成果和工作人員等詞表示。我們在第3 章的靜態結構：流程描述
中說明。
圖 2-2 流程結構－兩個維度
Rational 統一流程中最好的實務經驗
本節把Grady Booch 在第1 章所提到的六個最好的核心實務經驗再作一次複
習，並把它們對應到Rational 統一流程的主要元件。當然，Rational 統一流程還
包括許多其它最好的軟體開發實務經驗。
反覆式開發方式（Iterative Development）
由Rational 統一流程所推薦的反覆式開發方式（Iterative Development）方
法比一般的線性或瀑布式（Waterfall）開發方法更好，原因如下：
.. 它讓你把變動需求（Change Request）列入考慮。事實上，需求是經常
在變動的。變動需求與需求中”令人討厭的傢伙”經常是麻煩的來源，
這會導致交貨延遲、錯過預定計畫時程、無法滿足客戶或讓開發人員心
灰意冷等結果。
.. 在Rational 統一流程中，整合不是發生在最後階段的一個”大爆炸”，
而是以循序漸進的方式整合各個元素。這個反覆式方法幾乎不斷在做整
合。過去漫長的不確定性和痛苦時間－幾乎花40%的功夫在專案最後時

期－現在變成了六到九個小時的整合工作，而且需要整合的元素也變少
了。
.. 採用反覆式方法讓你及早降低風險，因為一般來說，整合是唯一可以發
現並處理風險的時候。當你開始進行早期反覆時，可以經歷所有流程元
件（Process Component），從各種角度去演練專案，包括工具、現成
（Off-the-shelf）軟體和人員技能等等。事先察覺到的風險已經不再是
風險，而且未知的風險也將顯露出來。
.. 它提供一個能改變戰術的產品管理方法，例如為了提早跟現有產品競
爭，你可以先發表少掉某些功能的產品與對手競爭或借用其它廠商所提
供的技術。
.. 它讓軟體變得更容易就可以再使用（Reuse），因為在設計或實作時，可
以很容易就找出其中相同的部分，而不用在還沒有任何設計或實作時就
得找出共通性。
.. 它可以產生更穩固的架構，因為你可以在多次反覆中不斷修正錯誤。產
品從初始階段（Inception）進入詳述階段（Elaboration）時，我們可以
在早期反覆發現瑕疵，而不必等到最後大量的測試才發現。也能在問題
還能被解決的時候，先發現效能瓶頸，而不必在交貨時才搞得手忙腳亂。
.. 開發人員可以持續學習，他們的能力和技能可以在整個生命週期完全發
揮。例如測試人員（Tester）可以早點測試；技術寫作人員（Techinical
Writer）可以早點撰寫文件等等。如果不是用反覆式開發方式（Iterative
Development）方法，這些人必須等一段時間才能開始他們的工作，結
果是不斷擬定計畫卻沒有實質進度。試問如果有一位測試人員面對三尺
高的產品設計文件，他該如何測試呢？訓練的需求和額外人員也可及早
在審查評估時確定。
.. 開發流程本身也可以在執行過程加以改良。反覆的最後評估不只從產品
時程看專案，同時也分析需要改變的組織和流程中的人員，讓下次反
覆可以做得更好。
專案經理（Project Manager）時常抗拒這種反覆式方法，因為它看起來像是
永無止境、無法控制的脫序行為。事實上，在Rational 統一流程中，這種反覆
式方法是可以被控制的；每次反覆都是以編號、週期和目標妥善計畫。參與者
（Actor）的工作和責任也都定義得很明白，而且進度也有很客觀的測量方法。
有些修正會在反覆中一再出現，不過這些都是可以控制的。
第4 章會詳述反覆式方法，而在第7 章會描述如何管理反覆式流程（Iterative
Process）並規劃它。

需求管理（Requirement Management）
需求管理（Requirement Management）是一套有系統的方法，它用來引導、
組織、溝通和管理易變的軟體系統和應用程式的需求。
有效的需求管理（Requirement Management）具有下面的優點：
.. 把複雜專案控制的更好
對打算完成的系統行為和需求惱人的部分缺乏了解，通常是無法控制專
案的因素。
.. 改善軟體品質和客戶滿意度
系統品質的基本測量方式，是看系統是否做到原本打算做的事。這只有
在關係人9對那些該做、那些該測試有共識時才能評估出來。
.. 減少專案成本和延遲
修正需求錯誤要花的成本是很昂貴的。因此，及早降低開發週期的錯誤
可以降低專案成本和延遲。
.. 改善團隊的溝通方式
需求管理（Requirement Management）讓使用者可以在流程初期參與，
並且確保應用程式滿足他們的需求。管理完善的需求建立關係人對專案
需求和約定的共識，關係人包括：使用者、消費者、管理階層、設計師
（Designer）和測試人員（Tester）。
第9 章需求工作流程（Requirement Workflow）會再詳述這項Rational 統一
流程的重要特性（Feature）。第13 章組態管理與變動管理工作流程（Configuration
and Change Management Workflow）會討論並追蹤跟變動有關的觀點。
元件的架構和使用元件
使用案例負責驅動Rational 統一流程完成整個生命週期，但是設計活動把
焦點放在架構概念－系統架構或軟體密集式（Software-intensive）系統的軟體架
構（Software Architecture）。流程的早期反覆把焦點放在產生並驗證軟體架構，
也就是在開發週期初期，先用一個可執行的原型（Prototype）呈現，在後期的反
覆中，這個原型會逐漸演進成最後系統。
Rational 統一流程提供一套有規律、系統化的方法去設計、開發並驗證架
構。它提供範本（Template），以多重觀點去描述架構。它還提供保存架構風格
（Architectural Style）、設計規則和限制的方法。設計流程元件（Design Porcess
9 所謂的關係人就是跟專案成果-也就是相關利益-有關係的任何人或組織代表。關係人可能
是一般使用者、買主、承包商、開發者、專案經理或任何關切專案的人和那些必須由此專案滿足
需求的人。

Component）裡面包含特定的活動以找出架構的限制與重要元素和教人如何作架
構選擇的指引。管理流程教你如何在早期反覆規畫架構設計並把主要技術風險的
解決方案列入考慮。
軟體元件（ Software Component）被定義成一段有價值的軟體、模組
（Modle）、套件（Package）或完成確定功能的子系統。元件有明確的邊界，而
且可以被整合到一個定義良好的架構中。它是設計抽象概念的具體實現。以元件
為基礎（Component－based）的開發方式具有下面的優點：
.. 定義一個模組化（Modular）的架構時，你將找出、分離、設計、開發
和測試一個完整的元件。這些元件可以單獨測試，並且逐步整合成完整
系統。
.. 其次，有些元件可以被再使用（Reuse），尤其是那些對相同問題提供相
同解法的元件。這些可被再使用的元件通常比工具組或類別（Class）
函式庫大。它們形成組織內再使用的基礎，提高軟體的整體生產力和品
質。
.. 近年來已經有一些成功支援軟體元件（Software Component）觀念的商
業基礎建設出現－例如CORBA、網際網路、ActiveX 和Java Beans 等
等－已經引發不同領域的現成（Off-the-shelf）元件業，讓開發人員可
以購買並整合元件，而不用自行開發。
第一個優點發揮原有的模組化（Modular）和封裝（Encapsulation）觀念，
讓潛在的物件導向技術觀念更進一步。最後兩點把軟體開發工作從設計軟體（一
次一行程式碼）變成組合軟體（組合元件完成）。
Rational 統一流程在許多方面都支援以元件為基礎（Component－based）的
開發方式：
.. 反覆式方法允許開發人員慢慢找出元件，並且決定那些要自行開發、那
些要再使用（Reuse）和那些要用買的。
.. 把焦點放在軟體架構（Software Architecture）讓你明白表達整個結構。
此架構列舉所有的元件和它們之間的整合方法，還有基本的互動機制和
樣式（Pattern）。
.. 一些概念（例如套件Package、子系統Subsystem 和階層Layer 等等）
常被用在分析與設計中，以組織元件並明確說明介面。
.. 測試時先測單一元件，然後逐漸擴展到更大的整合元件。
第5 章詳述架構概念和它在Rational 統一流程所扮演的角色。
模型和UML
Rational 統一流程有很大一部份跟開發與維護所開發出來的系統模型有

關。模型幫我們了解、釐清問題並提供相關解決方案。模型是簡化的實況，幫我
們有效控制龐大、複雜而難以整個理解的系統。我們在本書介紹幾種常用模型：
使用案例模型（Use-case Model）（第6 章）、企業模型（Business Model）（第8
章）、設計模型（Design Model）與分析模型（Analysis Model）（第10 章）和測
試模型（Test Model）（第12 章）。
UML 是一種圖形的模型語言，可以把軟體密集式（Software-intensive）系統
的工作成果加以視覺化、詳述、建構並製作文件（Documenting）。UML 讓你用
標準方式寫下系統藍圖，它同時適用於概念項目（例如企業流程Business Process
和系統功能）和具體項目（例如以特定程式語言撰寫的類別Class、資料庫綱目
Schema 和可再用的軟體元件等等）10。
UML 是一種能表達不同模型的一般性語言，可是它無法告訴你如何開發軟
體。它只提供詞彙，並沒有告訴你如何寫書。這就是為什麼美商瑞理軟體公司開
發Rational 統一流程協助我們用UML 完成工作。Rational 統一流程是一個指
引，它引導大家如何有效製作UML 模型。告訴你需要什麼模型、為何需要模型
和如何製作模型。Rational 統一流程2000 目前採用UML 1.4 版。
流程與產品的品質
人們時常會問，為什麼Rational 統一流程沒有工作人員負責品質工作。答
案是品質不是是少數人的工作。相反地，品質是開發組織所有成員的責任。開發
軟體時，我們在兩個地方很注重品質：產品品質和流程品質。
.. 產品品質
即正在生產的主要產品（軟體或系統）和構成產品的產品元素的品質（例
如元件、子系統和架構等等）。
.. 流程品質
在製造產品期間，實作出可接受流程（包括品質的測量Measurement 與
準則Criteria）的程度和它被支持的程度。此外，流程品質跟支援主要產
品的工作成果（例如反覆計畫Iterative Plan、測試計畫Test Plan、使用
案例實現Use-case Realization 和設計模型Design Model 等等）也息息相
關。
然而Rational 統一流程把焦點放在驗證並客觀評估產品是否符合預期品質
水準。這是第12 章測試工作流程（Test Workflow）、其它流程與產品衡量標準
（Metric）的主要目的。
組態管理（Configuration Management）和變動管理（Change
10 Grady Booch et al., UML User Guide. Reading, MA： Addison Wesley Longman, 1998.

Management）
在反覆式開發方式（Iterative Development）中時常會修改很多工作產品。為
了可以彈性規劃並執行開發工作以及允許改變需求，反覆式開發方式把焦點放在
追蹤變動並確保工作成果間保持同步等重要議題。為了符合開發組織的需要，變
動管理（Change Management）用系統化的方式管理需求、設計和實作的變動。
它也包含追蹤瑕疵與誤解、專案約定等重要活動，以及跟這些活動相關的特定工
作成果與發行版本（Release）。
第13 章組態和變動管理工作流程（Configuration and Change Management
Workflow）詳述管理這些軟體的重要觀點和它們之間的相互關係。
Rational 統一流程的其它關鍵特性（Feature）
除了六種最好的實務經驗外，Rational 統一流程的其它三個重要特性
（Feature）也蠻值得一提：
.. 由使用案例所驅動的開發工作和它所扮演的角色
.. 把Rational 統一流程當作流程框架（Process Framework），採用的組織
可以裁減或擴充它
.. 需要用軟體開發工具支援流程
以使用案例驅動的開發方式（Use-case-driven Development）
看著傳統物件導向的系統模型，說出系統如何做到需要的功能，不是一件簡
單的事。我們相信困難點在於系統執行特定工作時，缺乏一個可靠亦可見的思緒
貫穿整個系統。Rational 統一流程用使用案例定義系統表現的行為，提供一個這
樣的思緒。
在物件導向中，使用案例不是必要的，但是它提供系統需求和其它工作成果
（例如設計和測試等等）間的重要連結。其它物件導向方法也提供類似使用案例
的表達方式，只不過是用不同名稱，例如情節（Scenario）或思緒。
Rational 統一流程是一種以使用案例驅動（Use-case-driven）的方法，也就
是說系統定義的使用案例是其它開發流程的基礎。在流程的一些工作流程（特別
是需求、設計、測試和管理）中，使用案例扮演一個重要角色。使用案例對企業
模型（Business Model）也很重要。
如果你對使用案例的觀念不是很熟悉。第6 章以使用案例驅動的流程
（Use-case-driven Process）會詳細介紹它，並且告訴你如何使用它。

設定流程組態
Rational 統一流程很平常也很容易理解，因此有許多小型到中型軟體開發組
織，尤其是對流程文化觀念沒有很好基礎的組織，會照本宣科去用它。它也是一
種流程框架（Process Framework），採用的組織可以修改、調整或擴充它，以符
合特定需要、特性（Feature）、限制或組織歷史、文化與領域。
不要盲目跟隨流程，以免做些沒有用的工作或產生沒價值的工作成果。應該
盡可能減少流程，只要能完成賦予工作、快速產出可預期的高品質軟體就可以
了。採用的組織根據其特定規則去補充流程就可得到最好的實務經驗。
流程元素包括工作成果、活動、工作人員、工作流程、指引和工作成果範本
（Artifact Template）等等，它們都是可以被修改、客製化、增加或忽略的。第3
章結構：流程描述會介紹這些基本流程元素，同時也會描述框架（Framework）
的流程模型。第17 章Rational 統一流程的組態設定與實作會解釋採用的組織如
何實作流程並簡述設定組態的步驟。
工具支援
為了更有效率，必須有足夠的工具支援流程。有許多工具可以支援Rational
統一流程，它們可以把許多活動的步驟加以自動化。這些工具可以用來產生並維
護許多軟體工程流程（Software Engineering Process）的工作成果－尤其是模型，
例如視覺式模型製作（Visual Modeling）工作、寫程式、測試等等。這些工具支
援變動管理（Changing Management）與組態管理（Configuration Management）
的瑣碎紀錄工作，每次反覆都需要做這些工作。
第3 章介紹工具指導員觀念，它提供工具相關指引。第7 章到第15 章的工
作流程裡面會介紹一些支援工具。
Rational 統一流程簡史
過去幾年來，Rational 統一流程已經很成熟了，它反映出許多人和公司的
經驗，今天它已成為Rational 的富庶資產。我們很快地來看一看Rational 統一流
程2000 豐富的血統，如圖2－3 所示。
回顧過去，Rational 統一流程（第5 版）繼承自（第4 版）。Rational 統一
流程合併了許多領域的東西，例如資料工程（Data Engineering）、企業模型
（Business Model）、專案管理、組態管理（Configuration Management）等等，而
Rational Objectory Process 則是合併了Pure－Atria 的結果。在2000 年Rational
取得Object Time 創辦人開發即時（Real－Time）物件導向方法的元素，把它放
到Rational 統一流程中。同時它也跟一系列Rational 開發工具間有緊密的整合。

Rational Objectory Process 第4 版是1995 年Rational 與Object AB 合併後，
整合Rational Approach 與Objectory Process（3.8 版）的結果。由Objectory 看來，
流程繼承自流程模型（在第3 章說明）和主要的使用案例觀念。由Rational 背景
看來，它得到目前反覆式開發方式（Iterative Development）和架構的固定格式。
這個版本也合併了Requisite 公司的需求管理（Requirement Management）構想，
和SQA 公司詳細的測試程序（Test Procedure），這些公司後來也都跟Rational 合
併了。最後，這個版本的流程率先採用當時剛誕生的統一模型語言（UML 0.8 版）。
Objectory Process 是在1987 年由Ivar Jacobson 在瑞典創造出來的，這是他
在瑞典電信製造商Ericsson AB 多年的經驗成果。這個流程後來變成他公司
Objectory AB 的產品。由於這項產品著重在使用案例觀念和物件導向設計，很快
地就得到軟體工業界的認同，並且廣被世界各地的公司採用。在1992 年發表了
簡化版的Objectory Process11。
圖 2-3 Rational 統一流程的家譜
Rational 統一流程屬於一般化的流程中特定而詳細的實例，在Ivar
Jacobson 、Grady Booch 和James Rumbaugh 發表的The Unified Software
11 Ivar Jacobson et al., Object-Oriented Software Engineering ： A Use-Case-Driven Approach.
Reading, MA： Addison-Wesley, 1992.

Development Process12中則描述一般化的流程。
摘要
.. Rational 統一流程是一個軟體開發流程，裡面包含整個生命週期。
.. 流程的產品概念讓我們保有最新的知識財產，這個產品是以虛擬電子教
練（e－coach）方式放在開發人員工作站中。
.. Rational 統一流程裡面有許多新技術和新方法的指引：物件技術、以元
件為基礎（Component－based）的開發、模型與UML、架構和反覆式
開發方式（Iterative Development）等等。
.. Rational 統一流程不是死板板的，它是活的而且可以不斷更新和演化。
.. Rational 統一流程有一個穩固的流程架構基礎，並且允許開發組織設定
它的組態和調整它以符合需要。
.. Rational 統一流程支援六個最好的軟體開發實務經驗：
1. 以反覆式方法開發軟體
2. 管理需求
3. 以元件為基礎（Component－based）的架構
4. 視覺式模型製作軟體（Visually Model Software）
5. 持續驗證軟體品質
6. 控制軟體的變動
.. 許多Rational 開發工具都有支援Rational 統一流程。
12 Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development
Process. Reading： MA： Addison Wesley Longman, 1998.