RUP（RATIONAL Unified Practices）
以前在博客的總結中呢簡要的介紹了一下RUP，今天在這裏詳細的敘述一下。在介紹RUP以前呢先簡單說一下軟件軟件危機的特徵和開發所面臨的的問題。程序員
- 軟件危機特徵：
1.開發週期超過規定日期架構
2.開發成本嚴重超標框架
3.軟件質量難於保證工具
- 軟件開發面臨的問題：
1.不能知足需求和定位需求性能
2.模塊難於集成測試
3.到最後才發現錯誤編碼
4.對於終端用於質量差spa
5.負載時性能差設計
6.沒有協調團隊的能力對象
7.不斷修改，發佈問題
RUP（統一過程）
是面向對象的軟件開發過程，一個過程是指想要達到一個目標而採起的一組有序的步驟。
RUP適應於UML的生命週期方法，RUP提出了一整套以UML爲基礎的開發準則，用以指導軟件開發人員以UML爲基礎進行軟件開發。
- RUP所處理的問題
1.有缺陷的、沒法預見結果的、高度依賴與個別「英雄」程序員的、不可重複的開發過程
2.軟件不適應用戶需求
3.不能很好的變動需求
4.須要單調乏味和昂貴的測試流程
5.項目中嚴重缺陷發現的太遲
一. RUP措施：
迭代式開發
管理需求
使用構件架構
可視化建模
檢驗質量
控制變動
- 瀑布模型的缺點：
延遲關鍵風險解決
延遲和集中系統的集成和測試
排除了早期部署
常常致使較大的無計劃的反覆
- 迭代開發詳述：
1.每一個版本都在固定時間被開發
2.迭代成果是一個可執行產品的一個版本，是最終產品的子集
3.經過屢次迭代連續增長和精化系統，在每一個迭代過程逐步增長信息、細化
4.每次迭代選擇目前對風險影響最大的使用實例進行，來分解和下降風險。
- 迭代式開發的優勢：
下降風險
獲得早期用戶反饋
持續的測試和集成
適應變動
提升複用性
- 風險分析
需求管理
下面這幅圖就是一款軟件所經歷的各個階段，從客戶需求的描述到程序編碼以及商業顧問的詮釋。
我以爲很形象因此就保留下來了。
- 包括
1.提取、組織烯烴的功能約束，並將它們寫成文檔；
2.估計需求的變化並評估它們會產生的影響；
3.跟蹤需求的實現
採用構件架構優點：
1.對體系結構能夠自上而下設計、實現和測試
2.用系統化作法來定義好的體系結構
3.用定義明確的接口使變動有彈性
4.採用現成的和逆向工程獲得的構件
5.由高級別的用例來驅動
6.易於直觀上的理解
RUP的基本特徵
1.迭代式增量開發
2.用例驅動
採用用例驅動軟件的整個開發過程，保證需求的可跟蹤性，確保系統全部功能均被實現。
3.以軟件體系結構爲中心
開發早起識別與軟件體系結構緊密相關用例，造成體系結構框架後續細化最終實現整個系統。
RUP軟件開發生命週期
- 週期開發過程四個階段：
起始階段：爲項目監理一個業務案例
細化階段：創建工程計劃和合理的體系結構
構件階段：建造系統
提交階段：把系統提供給最終用戶
RUP帶來的觀念變化：
1.有更強的預見性，每次迭代都要仔細規劃。
2.坦然面對迭代過程當中推倒再重來，迭代過程當中的細化和響應工具的支持影響是能夠控制的。
3.軟件首位
4.儘早進行困難工做
5.肯定迭代數量增強開發過程監控