統一軟體開發過程
| 軟體開發 |
|---|
| 核心行動 |
| 範式與模式 |
| 方法論與框架 |
| 支援行為 |
| 實踐 |
| 工具 |
| 標準與知識體系 |
統一軟體開發過程（英語：Rational Unified Process，縮寫為RUP）是一種軟體工程方法，為迭代式軟體開發流程。最早由Rational Software公司開發，因此冠上公司名稱。Rational Software公司後來被IBM併購，成為IBM之下的一個部門，因此又稱IBM-Rational Unified Process。[1]
RUP描述了如何有效地利用商業的可靠的方法開發和部署軟體，是一種重量級過程（也被稱作厚方法學），因此特別適用於大型軟體團隊開發大型專案。
在軟體工程領域，與RUP齊名的軟體方法還有：
產品生命周期中的指導方針和模板
[編輯]RUP為專案成員定義了在一個產品生命周期中如下指導方針和模板。
迭代式開發
[編輯]給定的時間內，開發一個大型的複雜的軟體系統，定義問題並構建解決方案是不可能一蹴而就的。在專案的開發過程中，由於體系結構方面的約束，客戶的需要或對原始問題更精確的理解，需求會經常地變更。迭代式開發允許通過後續的細化產生對專案更好的理解，並在每個迭代的階段，把專案的最高風險的事項作為最高優先級的任務集中精力解決。理想的，每一次迭代都以一個可執行的發布為結束，這樣可以減少一個專案風險，更多地允許客戶的互動並幫助開發人員集中精力。
管理需求
[編輯]對於任何大型專案來說，一個文件框架是必不可少的；因此RUP描述了如何描述功能性，約束，設計決定和業務需求。
用例和場景是過程規定的製品的例子，在貫穿系統整個開發和部署的過程中，用例和場景在捕捉功能需求和提供一致的線索上是非常有效的。
使用基於構件的體系架構
[編輯]基於構件的體系架構（CBA）創造了容易擴充的系統，並提升了軟體的重用性和可讀性。一個構件經常與物件導向程式設計中的一個對象有關。
RUP提供了構建這種系統的一個系統化的方法，關注於在把所有資源投入到一個專案之前，開發出一個早期的可執行的體系架構。
軟體的視覺化建模
[編輯]將你的程式設計從代碼上抽象出來，並用圖形化構件塊展現出來是得到解決方案的全面意象的一種有效方法。這對於專案的技術人員來說，一方面，能夠更容易地勾畫出如何最好的實現一個給定邏輯集合的輪廓，另一方面，能夠更容易地構造在業務過程和實現業務過程的實際代碼之間的中間物。
統一建模語言（UML）是表示專案的產業標準方法，因此經常被RUP使用。
驗證軟體品質
[編輯]品質評估是所有軟體專案中最經常的失敗所在，因為通常這樣專案的僅僅在專案總結中進行品質評估和甚至由另外的團隊來進行品質評估。 RUP在規劃品質控制和評估方面有所幫助，並把品質控制和評估包括在每個專案成員都參與的整個過程中。
控制軟體的變更
[編輯]在所有的軟體專案中，變更是不可避免的，RUP定義了控制和監控變更的方法。一個表面上很小的變更可能以完全不可預計的方式對應用程式產生影響，這一點對一個成功專案至關重要。RUP同時定義了安全的操作環境，保證一個程式設計師對另一個系統的修改將不會對他系統地修改。這一點與基於構件的體系架構有很大的關係。
迄今為止，這些指導方針是通用的，可以在一個專案的生命周期中遵守。為了把握一個專案的時間尺度，RUP把一個專案分為四個不同的階段：
- 構思階段 ：包括使用者溝通和計劃活動兩個方面，強調定義和細化用例，並將其作為主要模型。
- 細化階段 ：包括使用者溝通和建模活動，重點是建立分析和設計模型，強調類的定義和體系結構的表示。
- 構建階段 ：將設計轉化為實現，並進行整合和測試。
- 移交階段 ：將產品發布給使用者進行測試評價，並收集使用者的意見，之後再次進行迭代修改產品使之完善。
參見
[編輯]參考文獻
[編輯]外部連結
[編輯]
