|
論壇說明 |
歡迎您來到『史萊姆論壇』 ^___^ 您目前正以訪客的身份瀏覽本論壇,訪客所擁有的權限將受到限制,您可以瀏覽本論壇大部份的版區與文章,但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限,請註冊成為我們的一份子,註冊的程序十分簡單、快速,而且最重要的是--註冊是完全免費的! 請點擊這裡:『註冊成為我們的一份子!』 |
|
主題工具 | 顯示模式 |
2004-05-16, 04:54 PM | #1 (permalink) |
註冊會員
|
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. |
送花文章: 0,
|
|
|
相似的主題 | ||||
主題 | 主題作者 | 討論區 | 回覆 | 最後發表 |
RUP2 第3章 靜態結構:流程描述 | mic64 | 程式 & 網頁設計技術文件 | 0 | 2004-05-16 04:55 PM |