1.RUP簡介
RUP（Rational UnifiedProcess，統一軟件開發過程，統一軟件過程)是一個面向對象且基於網絡的程序開發方法論。
2.RUP的核心概念
角色：描述某個人或者一個小組的行爲與職責。RUP預先定義了很多角色。
活動：是一個有明確目的的獨立工作單元。
工件：是活動生成、創建或修改的一段信息。
3.RUP 所能處理的問題
- 有缺陷的/無法預見結果的/高度依賴於個別"英雄"程序員的/不可重複的開發過程
- 開發的軟件難以適應用戶的要求
- 在應對需求的變更方面無能爲力
- 需要單調乏味和昂貴的測試流程
- 項目開發中出現的嚴重缺陷發現的太遲
- 開發的軟件難以維護和擴充
4.RUP開發的六大經驗
- 1.迭代式開發
1. 迭代式開發在軟件開發的早期階段就想完全、準確的捕獲用戶的需求幾乎是不可能的。實際上，我們經常遇到的問題是需求在整個軟件開發工程中經常會改變。迭代式開發允許在每次迭代過程中需求可能有變化，通過不斷細化來加深對問題的理解。迭代式開發不僅可以降低項目的風險，而且每個迭代過程都可以執行版本結束，可以鼓舞開發人員。
2.迭代式開發的特徵
- 在進行大規模的投資之前就解決了關鍵的風險問題
- 使得早期的用戶反饋在初始迭代中就能出現
- 連續進行測試和集成
- 各個目標里程碑提供了短期的焦點
- 對里程碑的測量是通過對實現的評定來進行的
- 可以對局部的實現進行部署
3.風險分析
- 2.管理需求
確定系統的需求是一個連續的過程，開發人員在開發系統之前不可能完全詳細的說明一個系統的真正需求。RUP描述瞭如何提取、組織系統的功能和約束條件並將其文檔化，用例和腳本的使用已被證明是捕獲功能性需求的有效方法。
需求管理技巧
1：分析問題
進行問題分析是爲了理解業務問題，確定涉衆的最初需要，並提出高層解決方案。這些推理和分析行爲找出“隱藏在問題背後的問題”。
在問題分析過程中，將對實際問題的說明取得一致，並確定有關的涉衆。初始解決方案的界限和約束從技術和業務兩個方面來定義。在適當的時候，項目的商業理由還分析期望從系統獲得的投資回報。
2：理解涉衆需要
需求有許多來源。它們可能來自於對項目結果感興趣的任何人。客戶、合作伙伴、最終用戶以及領域專家都是某些需求的來源。而管理人員、項目團隊成員、業務策略和管理機構是另外一些需求源。
獲取需求的手段包括訪談、集體討論、概念原型設計、問卷調查和競爭性分析等。需求獲取的結果可能是一份圖文並茂的請求或需要列表，並按相互之間的優先級列出。
3：定義系統
定義系統指的是解釋涉衆需求，並整理爲對要構建系統的意義明確的說明。在系統定義初期，需要決定需求的構成、文檔格式、語言規範、需求等級、請求優先級和預計工作量、技術和管理風險以及系統規模等。系統定義活動還可包括與最關鍵的涉衆請求直接聯繫的初期原型和設計模型。
4：管理系統規模
項目規模由分配給它的需求集定義。管理項目規模，使之適合可用資源（時間、人力和資金），是成功管理項目的關鍵。管理規模是一個持續不斷的活動，需要迭代式和遞增式開發，這就將項目細分爲更易於管理的若干個小部分。
使用需求屬性（如優先級、工作量和風險）作爲協商應包含需求的基礎，對管理規模而言是相當有用的技巧。側重於屬性，而不是需求自身，將減少通常對敏感問題的爭論。
這也有助於培養小組負責人的談判技巧，還有助於在項目中爲組織培養推介人，對於客戶而言也是如此。產品/項目推介人應能夠代表組織拒絕那些超出可用資源的規模變更，也應有相應能力擴展資源以適應擴大的規模。
5：改進系統定義
對高層系統定義達成一致並充分理解了系統初始規模後，投入資源改進系統定義不僅有可能，而且也是經濟的。改進系統定義包括兩個重要的考慮事項：制定更詳細的高層系統說明和驗證系統是否符合涉衆需要，是否按說明運行。
說明通常是項目團隊的重要參考材料。在制定說明時一定要考慮受衆。人們常會犯一個錯誤，那就是用複雜定義表示構建起來很複雜的東西，尤其是在受衆無法或不願意耗費精力去思考某些重要的需要取得一致認識時候。這就難以向項目團隊內外的人員解釋系統目的。相反，你可能會發現需要爲不同的受衆編制不同類型的說明。
6：管理變更的需求
不管您多麼認真地定義需求，需求終將改變。實際上，一些變更是非常值得的！這意味着您的團隊需要與涉衆保持密切聯繫。能否適應變更需求是評測團隊的涉衆敏感度和運作靈活性的一個尺度 - 敏感度和靈活性都是對項目成功有貢獻的團隊特徵。變更不是敵人，而沒有管理的變更纔是真正的敵人。
需求變更表明多少需要耗費一些時間來實施某個特定的功能，而且對一個需求的變更對其他需求可能有影響。管理需求變更包括這樣一些活動：設立基線、追蹤每個需求的歷史、確定哪些依賴關係值得追蹤、在相關項之間建立可追蹤關係以及維護版本控制等。
- 3.體系結構
組件使重用成爲可能，系統可以由組件組成。基於獨立的、可替換的、模塊化組件的體系結構有助於降低管理複雜性，提高重用率。RUP描述瞭如何設計一個有彈性的、能適應變化的、易於理解的、有助於重用的軟件體系結構。
採用構件架構的優勢
- 對體系結構進行自下而上的設計/實現和測試
- 用一種系統化的做法來定義好的體系結構
- 採用定義明確的接口來使得變更有彈性
- 採用現成的和通過逆向工程得到的構件
- 由高級別的用例來驅動
- 易於直觀上的理解
上述就是纔有構件結構的優勢
- 4.可視化建模
RUP往往和UML聯繫在一起，對軟件系統建立可視化模型幫助人們提供管理軟件複雜性的能力。RUP告訴我們如何可視化的對軟件系統建模，獲取有關體系結構於組件的結構和行爲信息。
- 5、驗證軟件質量
在RUP中軟件質量評估不再是事後進行或單獨小組進行的分離活動，而是內建於過程中的所有活動，這樣可以及早發現軟件中的缺陷。
- 6、控制軟件變更
迭代式開發中如果沒有嚴格的控制和協調，整個軟件開發過程很快就陷入混亂之中，RUP描述瞭如何控制、跟蹤、監控、修改以確保成功的迭代開發。RUP通過軟件開發過程中的製品，隔離來自其他工作空間的變更，以此爲每個開發人員建立安全的工作空間。
- 5.RUP的開發過程
RUP中的軟件生命週期在時間上被分解爲四個順序的階段，分別是：初始階段（Inception）、細化階段（Elaboration）、構造階段（Construction）和交付階段（Transition）。每個階段結束於一個主要的里程碑（MajorMilestones）；每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。
- 1． 初始階段
初始階段的目標是爲系統建立商業案例並確定項目的邊界。爲了達到該目的必須識別所有與系統交互的外部實體，在較高層次上定義交互的特性。本階段具有非常重要的意義，在這個階 段中所關注的是整個項目進行中的業務和需求方面的主要風險。對於建立在原有系統基礎上的開發項目來講，初始階段可能很短。初始階段結束時是第一個重要的里程碑：生命週期目標（Lifecycle Objective）里程碑。生命週期目標里程碑評價項目基本的生存能力。
初始階段
意圖
建立業務模型用例
明確項目範圍
結果
項目的實際需求
---初始用例模型和領域模型
初始的業務案例,包括
---成功準則
---風險評估
---所需資源評估
---顯示主要里程碑進度表的階段計劃
在初始階段的最後,檢查項目的生命週期目標,決定是否繼續進行全範圍的開發
- 2． 細化階段
細化階段的目標是分析問題領域，建立健全的體系結構基礎，編制項目計劃，淘汰項目中最高風險的元素。爲了達到該目的，必須在理解整個系統的基礎上，對體系結構作出決策，包括其範圍、主要功能和諸如性能等非功能需求。同時爲項目建立支持環境，包括創建開發案例，創建模板、準則並準備工具。細化階段結束時第二個重要的里程碑：生命週期結構（Lifecycle Architecture）里程碑。生命週期結構里程碑爲系統的結構建立了管理基準並使項目小組能夠在構建階段中進行衡量。此刻，要檢驗詳細的系統目標和範圍、結構的選擇以及主要風險的解決方案。
細化階段
意圖
分析問題域
建立一個健全的合理的體系結構基礎
結果
用例圖和領域模型
一個可執行的體系結構和文檔
一個修訂的用例圖和風險評估
一個針對整個項目的開發計劃
在這個階段的最後已經細化的系統目標和範圍,體系結構的選擇以及主要風險的解決辦法,並決定是否需要進行構造
- 3． 構造階段
在構建階段，所有剩餘的構件和應用程序功能被開發並集成爲產品，所有的功能被詳細測試。從某種意義上說，構建階段是一個製造過程，其重點放在管理資源及控制運作以優化成本、進度和質量。構建階段結束時是第三個重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑決定了產品是否可以在測試環境中進行部署。此刻，要確定軟件、環境、用戶是否可以開始系統的運作。此時的產品版本也常被稱爲“beta”版。
構造階段
意圖
迭代增量的開發一個完整的軟件系統,該產品是準備提交給用戶使用的
產品
- 完整的用例圖和設計模式
- 用戶手冊
- 可執行代碼
- 開發文檔
- 每次迭代的評測標準
- 改進的開發計劃
4． 交付階段
交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括爲發佈做準備的產品測試，基於用戶反饋的少量的調整。在生命週期的這一點上，用戶反饋應主要集中在產品調整，設置、安裝和可用性問題，所有主要的結構問題應該已經在項目生命週期的早期階段解決了。在交付階段的終點是第四個里程碑：產品發佈（Product Release）里程碑。此時，要確定目標是否實現，是否應該開始另一個開發週期。在一些情況下這個里程碑可能與下一個週期的初始階段的結束重合。
交付階段
意圖
爲用戶安裝部署軟件
產品
- 可執行的程序
- 改進的系統模型
- 每次迭代的評測標準
- 改進的用戶文檔
- 改進的開發文檔
- 6.RUP軟件開發與生命週期
- 7 RUP帶來觀念的變化
1. 更強的計劃性: 迭代開發意味着要有更強的預見性和計劃性,階段的劃分,階段內的迭代都需要仔細的規劃,這要求香米管理者承擔更大的責任,而所換來的則是開發任務的具體化和可預見性
2. 坦然面對迭代過程中一部分中間製品的推倒重來: 不要恐懼這樣的現實,由於迭代過程的細化和相應工具的支持,其影響是可以控制的
3. 把軟件放在首位:過分強調規格說明的作用是不恰當的,因爲用戶所購買的是軟件而不是規格說明,在開發過程中,需求和規格說明都是允許變化的
4. 儘早進行困難的工作:強調與實現的關係密切,而將困難工作放在開發後進行是十分有害的,會使開發後期突然遇到"集成地獄"而使開發過程失去控制
5. 確定迭代的數量,持續時間的內容: RUP 給出了一定的指南,但主要靠項目管理者根據實際情況確定,因而責任更加重大
即需要好的項目管理者,也需要好的體系結構設計師,一個成功的軟件項目同時需要者兩種人,而且項目管理者本人就應當懂得體系結構設計