常用軟件過程——RUP

RUP是用例驅動，以架構爲中心，迭代式開發過程。

一、用例驅動

用例（Use Case）是一種通過用戶的使用場景獲得需求的技術。區別於傳統的功能分解獲取需求的辦法，用例方法強調用戶是如何使用系統的，即描述用戶與系統之間的交互，而不涉及系統內部的行爲。用例的一般表示法是UML用例圖。

用例方法的主要特點有：

需求表述的抽象性。用例方法以UML用例圖的形式表示，對於用例、參與者之間的關係一目瞭然，能更在一個高的抽象級別上理解系統。
需求表述的完整性。某些用戶可能並不瞭解他會使用到系統的某個功能，但UML用例圖將有助於發現這些問題。
用例驅動指的是在軟件開發過程中，採用用例方法捕獲及分析業務需求，並確保由它們來驅動軟件的設計、實現和測試，使最終系統更能滿足最終用戶的需要。

二、以架構爲中心

軟件架構（體系結構）是構成軟件各部分的組件、組件之間的交互及組件組合的約束。軟件架構也關係到功能性、可用性、系統彈性、性能、可重用性、可理解性等方面。

在RUP開發的細化階段，建立一個健壯架構的基礎。在構造階段和交付階段，再進一步完善架構。在整個開發過程中，架構進一步完善。RUP強調以架構爲中心，有利用打造一個可持續開發、可持續維護的軟件；且最大限度規避了項目的技術風險。

三、迭代式開發

RUP是一個基於迭代式生命週期模型定義的軟件過程。RUP分爲4個階段，即初始階段、細化階段、構造階段、交付階段。每個階段可以有多次迭代。在每次迭代中，包含商業建模、需求、分析及設計、測試、部署等依次進行的活動（核心過程工作流），以及配置和變更管理、項目管理、環境（核心支持工作流）。

由於是迭代式開發，在後一階段就有機會更正前一階段的錯誤和疏漏。但是，這樣會不會產生惰性，導致把更多問題遺留到後續的迭代中呢？RUP明確定義了各階段的目標，必須在達到目標後，才能進入下一階段：

初始階段，目標是確定項目邊界。
細化階段，目標是分析業務領域以確定架構，並編制明細項目計劃。
在構建階段，目標是構造可運行的代碼，並集成測試。
交付階段的重點是確保軟件對最終用戶是可用的。
RUP的缺點：

RUP的優點很多。用例驅動對需求管理非常有利，能夠確保需求在與用戶交互時、系統實現時均不被遺漏；以架構爲中心有利於打造一個強健的系統，而不會因系統規模增大而倒塌；迭代式開發有效消解了風險。那麼，RUP還有什麼不完美的嗎？

對於我們這些行業應用軟件開發者來說，RUP過於複雜。

用例驅動。用例分析作爲一項軟件技術，遠遠比功能分解複雜。大部分需求人員不具備編寫用例的能力，用戶多數看不懂用例。因此，在交互過程中，傳統以功能列表描述爲主的《需求規格說明書》應用更加廣泛。

以架構爲中心。對於業務邏輯非常複雜的系統，打造一個強健的架構是必須的。但對於一些業務邏輯相對簡單，而用戶交互邏輯複雜的系統，過於強調架構似乎沒有必要。例如，對於一個有着很多模塊的網站，各個模塊相對獨立，訪問各自的表，維護一套用例圖、類圖、時序圖就成爲累贅。

迭代式開發。迭代式開發作爲消解風險是非常必要的。RUP迭代中的6個核心工作流和3個核心支持工作流過於繁雜，必須爲每個工作流指定其執行者。雖然RUP指出這些工作流在每次迭代中並不都是必須的，但對於一個嚴謹的軟件過程來說，給予項目經理過多的裁剪權，也意味着爲項目引入新的風險。