軟體設計必讀經典(6)RUP活用，也可以是敏捷開發

RUP（Rational Unified Process）是由IBM Rational所研發並推廣的軟體開發流程。它是一套流程框架（Process Framework），可根據開發團隊的需求加以調整或擴充，自訂的流程描述包括4項元素：「誰」（Who）做了「什麼」（What），「如何」做（How），和「何時」（When）做。

《The Rational Unified Process》作者為RUP首席架構師Philippe Kruchten，本書主要整體介紹了RUP。

最佳軟體開發實務經驗

第一章由軟體三巨頭之一的Grady Booch所撰寫的論文，也是全書最有價值的部分。

Grady Booch在第一章揭露軟體的價值何在，以及軟體開發時經常發生的問題，諸如無法處理需求的變動、模組間無法配合、軟體很難維護與擴充、太慢發現專案的嚴重瑕疵（Defect）等。並提及各專案的失敗原因雖然不同，但共同主因會是：不精確的溝通方式、脆弱的架構、很難處理的複雜性、不一致的需求、設計和實作、測試不足、沒有克服風險等。

從根本問題找尋解決方案，在實務應用上證實可行，並廣為業界成功組織所採用的軟體開發方式，這些條件成為RUP的關鍵性精髓，也可說是軟體開發最佳的實務經驗（Best Practices），包括：以反覆式（Interative）方式開發軟體、管理需求、以元件為基礎（Component-based）的架構、以視覺化方式製作軟體模型（Visually Model Software）、持續驗證軟體品質、控制軟體的改變。

另外，反覆式開發聽起來很有道理，實際執行卻有相當難度，因為人們一般很難忍受不確定性，尤其是專案經理，因為反覆式開發看起來像是永無止境、無法控制的脫序行為。

事實上，在RUP的規範中，反覆式可以被控制，每次反覆都是以編號、周期和目標妥善計畫，只是其中又會衍生出專案管理的其它議題，仍舊使得專案管理人員喜歡循序的瀑布（Waterfall）開發方法，因為瀑布式開發每一個階段的產出都有很明確的定義。

問題是，我在前兩期介紹XP時，曾指出，軟體的根本問題在於風險。瀑布式開發的缺點是太晚揭露風險，這在現今多變的需求開發中早已證實不可行。如果反覆式開發才能解決軟體開發的根本問題，那麼，無論遇到哪些阻礙，還是應該堅持反覆式開發。畢竟，「Do the Right thing」後，才能「Do the thing Right」！

現在許多中大型組織，只因為RUP很容易產出「好看」的文件，而把RUP視為制式化開發模式，當作應付各級主管的工具，並沒有用心體認RUP精髓，無法成功擷取實務經驗，造成許多開發人才原地空轉，浪費不必要的資源，殊為可惜。

以架構為中心及使用案例驅動的開發流程

本書第五、六章，揭露出「4+1」的架構觀點，以及利用「使用案例驅動（Use Case Driven）」的開發流程。

「4+1」共有5個觀點，包括邏輯觀點、實作觀點、程序觀點、配置觀點，還有一個擺在中間的使用案例觀點，利用它來驗證其他4個觀點，也可以就是利用需求功能來驗證各個階段的開發產出。每一個觀點都有相關角色的開發人員職掌，例如需求分析師會專注在使用案例觀點，結構分析／設計師會專注在邏輯觀點，而程式設計師則著重在實作觀點。

RUP強調「Use Case Driven」，卻不是「Use Case First」。兩者的差異在於，前者是利用功能需求驗證架構的一致性、結構的彈性，以及實作的完整性等；後者則單純以需求作為涵蓋整個系統的建構，卻忽略了其它觀點，使得系統不具彈性、延展與可重用性等。國內短線的專案開發生態經常是如此，導致軟體人員只重視需求的功能面與實作的技術面，卻忽略軟體的主結構，使得系統不具應變的特性。

一般軟體人員對RUP的印象是僵化、官僚、受控制的重型（Heavyweight）開發流程。事實上，在熟讀本書之後，我更確定RUP的本質精髓與敏捷式開發流程是一樣的，它們都強調反覆式開發、需求導向以及對測試的重視，只是作法不同而已。

統一流程入門第二版（The Rational Unified Process:　An Introduction，Second Edition）

Phillippe Kruchten/著

趙光正/譯

維科圖書出版

售價：400元

《作者簡介》

王克明

台北工專五專部電子科畢業。現於HSDc軟體設計顧問團隊擔任架構師／顧問／講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。

熱門新聞