史萊姆論壇

返回   史萊姆論壇 > 教學文件資料庫 > 程式 & 網頁設計技術文件
忘記密碼?
註冊帳號 論壇說明 標記討論區已讀

歡迎您來到『史萊姆論壇』 ^___^

您目前正以訪客的身份瀏覽本論壇,訪客所擁有的權限將受到限制,您可以瀏覽本論壇大部份的版區與文章,但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限,請註冊成為我們的一份子,註冊的程序十分簡單、快速,而且最重要的是--註冊是完全免費的!

請點擊這裡:『註冊成為我們的一份子!』

Google 提供的廣告


 
 
主題工具 顯示模式
舊 2004-05-16, 04:54 PM   #1 (permalink)
註冊會員
 
mic64 的頭像
榮譽勳章
UID - 582
在線等級: 級別:16 | 在線時長:330小時 | 升級還需:27小時級別:16 | 在線時長:330小時 | 升級還需:27小時級別:16 | 在線時長:330小時 | 升級還需:27小時級別:16 | 在線時長:330小時 | 升級還需:27小時級別:16 | 在線時長:330小時 | 升級還需:27小時級別:16 | 在線時長:330小時 | 升級還需:27小時
註冊日期: 2002-12-06
VIP期限: 2007-04
住址: MIB總部
文章: 412
精華: 0
現金: 499 金幣
資產: 499 金幣
預設 RUP2 第2章 Rational 統一流程

第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.
mic64 目前離線  
送花文章: 0, 收花文章: 16 篇, 收花: 56 次
 


主題工具
顯示模式

發表規則
不可以發文
不可以回覆主題
不可以上傳附加檔案
不可以編輯您的文章

論壇啟用 BB 語法
論壇啟用 表情符號
論壇啟用 [IMG] 語法
論壇禁用 HTML 語法
Trackbacks are 禁用
Pingbacks are 禁用
Refbacks are 禁用

相似的主題
主題 主題作者 討論區 回覆 最後發表
RUP2 第3章 靜態結構:流程描述 mic64 程式 & 網頁設計技術文件 0 2004-05-16 04:55 PM


所有時間均為台北時間。現在的時間是 10:34 AM


Powered by vBulletin® 版本 3.6.8
版權所有 ©2000 - 2014, Jelsoft Enterprises Ltd.


SEO by vBSEO 3.6.1