由來：
rup（rational unified process）統一過程模型
是由rational公司（現被ibm公司收購）開發的一種軟體工程過程框架
是乙個物件導向的基於web的程式開發方**
特點：
rup既是一種軟體生命週期模型
又是一種支援物件導向軟體開發的工具
它將軟體開發過程要素和軟體工件要素整合在統一的框架中
rup中的軟體生命週期在時間上被分解為四個順序的階段：
初始階段（inception）
細化階段（elaboration）
構造階段（construction）
交付階段（transition）
每個階段結束於乙個主要的里程碑(major milestones)
並在階段結尾執行一次評估以確定這個階段的目標是否已經滿足
如果評估結果令人滿意的話，可以允許專案進入下乙個階段。
初始階段
目標是為系統建立商業案例（business case）並確定專案的邊界。
商業案例包括專案的驗收規範、風險評估、所需資源估計、階段計畫等。
要確定專案邊界，需識別所有與系統互動的外部實體，並在較高層次上定義外部實體與系統互動的特性
主要包括識別外部角色（actor）、識別所有用例並詳細描述一些重要的用例。
階段結束里程碑：生命週期目標（lifecycle objective）里程碑，包括一些重要的文件
如：專案構想（vision）、原始用例模型、原始業務風險評估、乙個或者多個原型、原始商業案例等。
需要對這些文件進行評審，以確定正確理解用例需求、專案風險評估合理、階段計畫可行等。
細化階段
目標是分析問題領域，建立健全的體系結構基礎，編制專案計畫，完成專案中高風險需求部分的開發。
里程碑：生命週期體系結構（lifecycle architecture）里程碑。
包括風險分析文件、軟體體系結構基線、專案計畫、可執行的進化原型、初始版本的使用者手冊等。
通過評審確定軟體體系結構已經穩定、高風險的業務需求和技術機制已經解決、修訂的專案計畫可行等。
構造階段
將所有剩餘的技術構件和穩定業務需求功能開發出來，並集成為產品，所有功能被詳細測試。
從某種意義上說，構造階段只是乙個製造過程，其重點放在管理資源及控制開發過程以優化成本、進度和質量。
里程碑：初始執行能力（initial operational capability）里程碑。
包括可以執行的軟體產品、使用者手冊等，它決定了產品是否可以在測試環境中進行部署。
此刻，要確定軟體、環境、使用者是否可以開始系統的執行。
移交階段
移交階段的重點是確保軟體對終端使用者是可用的。交付階段可以跨越幾次迭代，包括為發布做準備的產品測試，基於使用者反饋的少量調整。
里程碑：產品發布(product release)里程碑。
此時，要確定最終目標是否實現，是否應該開始產品下乙個版本的另乙個開發周期。
在一些情況下這個里程碑可能與下乙個週期的初始階段的相重合。
rup的9個核心工作流
6個核心過程工作流
商業建模（business modeling）
需求（requirements）
分析和設計（analysis & design）
實現（implementation）
測試（test）
部署（deployment）
3個核心支援工作流：
配置和變更管理（configuration & change management）
專案管理（project management）
環境（environment）
開發思想：
迭代增量
rup是融合了噴泉模型和增量模型的一種綜合生命週期模型
噴泉模型（fountain model） 並行開發+重疊反覆
增量模型（incremental model） 設計核心功能+逐步累加
每一次迭代就是為了完成一定階段性小目標而從事的一系列開發活動
rup通過迭代增量建模思想提高了風險控制能力
這體現在：
迭代計畫安排是風險驅動的，高風險因素集中在前兩個階段解決，特別是體系結構級的風險在細化階段就得到了解決，及早降低了系統風險
每一次迭代都包括需求、設計、實施、部署和測試活動，因此，每乙個中間產品都得到了整合測試，而且這個整合測試是在乙個統一的軟體體系結構指導下完成的
每乙個階段結束時還有嚴格的質量評審，保證里程碑文件的質量
由於中間版本的產品是逐步產生的，而且核心功能和效能需求已經包含在前面的版本中，所以，可以根據市場競爭的情況適時推出中間版本，降低市場風險。
rup的最佳實踐：
短時間分割槽式的迭代：2～6周，不鼓勵時間推遲；
適應性開發：小步驟、快速反饋和調整；
在早期迭代中解決高技術風險和高業務價值的問題；
不斷地讓使用者參與迭代結果的評估，並及時獲取反饋資訊，以逐步闡明問題並引導專案進展；
在早期迭代中建立內聚的核心架構；
不斷地驗證質量；盡早、經常和實際地測試；
使用用例驅動軟體建模：用例是獲取需求、制定計畫、進行設計、測試、編寫最終使用者文件的驅動力量；
視覺化軟體建模：使用uml（unified modeling language，統一建模語言）進行軟體建模；
仔細地管理需求：不要草率地對待需求，而要有機地進行需求的提出、記錄、等級劃分、追蹤。拙劣的需求管理是專案陷入麻煩的乙個常見原因；
實行變更請求和配置管理。
rup是乙個通用的過程模板，包含了很多開發指南、工件、開發過程所涉及到的角色說明等
因此，具體開發機構在應用rup開發專案時要做裁剪。
rup裁剪可以分為以下幾步：
⑴ 確定本專案需要的工作流。
⑵ 確定每個工作流需要的工件。
⑶ 確定4個階段之間的演進計畫。
以風險控制為原則，決定每個階段實施的工作流，每個工作流的執行程度，生成的工件及其完成程度等。
⑷ 確定每個階段內的迭代計畫。
規劃rup的4個階段中每次迭代開發的內容。
⑸ 規劃工作流內部結構。
用活**（activity diagram）規劃工作流中涉及的角色、角色負責的活動及產出的工件。
軟體的生命週期 及 RUP
軟體的產生之道報廢的生命週期 需求 問題的定義，可行性的分析，需求分析 設計 概要設計，詳細設計，整合測試 維護與測試 綜合測試，維護 詳解 1 問題的定義以及規劃，和軟體開發計畫 此階段是軟體開發方與需求方共同討論，主要確定軟體的開發目標以及可行性 2 需求分析 在確定軟體開發可行的情況下，對軟體...
軟體生命週期模型
軟體生存期模型是跨越整個生存期的系統開發 運作和維護的全過程的結構框架。軟體開發模型能夠清晰直觀的定義軟體開發的過程，明確定義要完成的各項活動和任務，用來作為軟體專案的基礎。典型的開發模型有 瀑布模型 快速原型模型 增量模型 螺旋模型等 瀑布模型 瀑布模型的優點 瀑布模型以文件驅動，遵守嚴格的線性流...
RUP軟體開發生命週期
rup rational unified process 統一軟體開發過程，統一軟體過程是乙個物件導向且基於網路的程式開發方 1.起始階段 為專案建立乙個業務案例 1 意圖 建立業務模型用例 明確專案的範圍 2 結果 專案的實際需求 初始的業務案例。包括 成功準則，風險評估，所需資源評估，顯示主要里...