{iThome 書評—6} Rational 統一流程入門

統一流程入門 第二版
— The Rational Unified Process An Introduction 2nd 統一流程入門 第二版 — The Rational Unified Process An Introduction 2nd
———————————–
作者/Phillippe Kruchten/著
譯者/趙光正/譯
出版社/維科圖書有限公司 出版
ISBN/957-8675-79-8

內容簡介
這本書非常簡潔,裡面快速介紹Rational統一流程(Rational Unified Process ,RUP)的一些概念、結構、內容和動機。RUP是一個具備網際網路功能的軟體工程流程,它強化團隊的生產力並提供成員最好的軟體實務經驗。RUP非常特別,開發團隊可以透過它了解統一模型語言(Unified Modeling Language , UML)、軟體自動化和業界最佳實務經驗的所有優點。

Rational統一流程統一整個軟體開發團隊的工作,並且讓每位成員達到最高生產力,因為它為大家帶來了成千上萬個專業與頂尖業界領導者的經驗。想在可預期時程內、用合理預算、輕易完成為品質軟體嗎?快拿本書當作你的指導手冊吧!本書作者與你分享他最深層的流程相關知識,並且把焦點放在RUP的關鍵點,讓你很快就能專精RUP這個已被證實過、確實可行的軟體開發解決方案。

本書第二版主要根據最新版的Rational統一流程更新以符合最新內容。事實上,完整的RUP2000裡’還包括:
1.更多的e-開發指引
2.一份學習地圖,教你如何把流程應用到各式各樣的專案和技術上
3.擴充過的測試分析,現在它會橫跨整個產品生命週期
4.改良過的應用程式介面設計範園一特別針對如何開發有效的網際網路應用程式
5.針對及時與互動系統,提供更詳盡的說明
6.深入淺出介紹如何用樣式和框架來設計系統

Philippe Kruchten是Rational統一流程產品的首席架構設計師。他有超過25年的大型、軟體密集式系統開發經驗,這些系統的領域包括通訊、安全防禦、太空、交通和軟體開發工具。他並擁有Ecole Centralc de Lyon(法國)的機械工程學位和French Institute of Telecommunications的電腦科學博士學位。

前言

RUP (Rational Unified Process) 是由 IBM Rational 所研發並推廣的軟體開發流程。它是一套流程框架 (Process Framework),可根據開發團隊的需求去調整或擴充,自訂的流程描述不外乎包括了四項元素:誰(Who)做了什麼(What),如何做(How)和什麼時候(When)做;它也是一套產品,由 Rational 所研發和維護,並整合在該公司的 Rational Suite Enterprise 套裝軟體內。安裝好該光碟產品,便可以把這份產品當成 RUP 的虛擬電子教練 (e-coach),它提供一個完整的超鏈結網頁,以 HTML 格式來描述流程,並附有各種格式的樣版(Template),如 HTML、RTF、PDF…等,及一個簡單的 Case Study:Rational Project Web Example;而 RUP本身更是一種軟體工程流程(Software Engineering Process),它提供研發單位一個嚴謹的方法,分配軟體開發工作和責任,目的是確保在可預期的時程和預算內,開發出符合使用者需求的高品質軟體。

本書不到 300 頁的內容,是將RUP 作一個整體介紹,算是一個縮影。作者是由 RUP 的首席架構師 Kruchten 所著,事實上,第一章是由軟體三巨頭之一的 Grady Booch 所撰寫的論文,是本書最有價值的地方;而第二至第六章則涵蓋了 RUP 的流程框架介紹,包括了靜態結構的流程描述與動態的流程行為說明。最能代表 RUP 的是一張看起來像是鯨魚的二維流程結構圖,水平軸代表時間和流程開始後的各個生命週期,也就是分為初始、詳述、建構、轉移等四個開發階段;以及垂直軸代表的是核心工作流程,也就是把活動按照本質加以分類的結果。諸如企業塑模、需求、分析與設計、實作等活動,也稱之為規程 (discipline)。七至十七章則是第二部分的工作流程介紹,是由 RUP 流程開發團隊的工程師們所撰寫的,諸如專案管理的工作流程、需求的工作流程等,包括了工作流程的目的、定義主要的概念、工作人員與工作成果、活動與輔助工具等。這一部份的內容看看參考就好,因為工作流程不外乎是談及什麼人在某個時間點做了什麼事 (產出),以及如何串接等,每一個專案的開發都會是不一樣的,沒有必要也不可能採取統一制式的工作流程。

最佳的軟體開發實務經驗

Grady Booch 在第一章的論文中,揭露出軟體的價值何在,以及所衍生出在軟體開發時經常發生問題的症狀,諸如無法處理需求的變動、模組間無法配合、軟體很難維護與擴充、太慢發現專案的嚴重瑕疵 (Defect) …等。同時也提及了專案雖然有不同的失敗原因,但最主要的原因包括了:不精確的溝通方式、脆弱的架構 (Architecture)、很難處理的複雜性、不一致的需求、設計和實作、測試不足、沒有客服風險等。

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

當然,這些實務經驗可非一蹴可幾,是需要經過軟體組織持續不斷的學習與摸索,並建立紮實的本質素養方可的。舉個例,光是以元件為基礎的架構這一部份,要能瞭解什麼是元件,要如何適切地切割元件的大小,要如何定義出元件的介面,也可以說就是 Design for Interface,把善變的部分封裝在元件內部,這些可不是容易的事;再則以反覆式的開發方法,聽起來有道理,但做起來卻相當難執行,因為人們一般很難忍受不確定性,尤以專案經理時常抗拒這種開發方式,因為它看起來像是永無止境、無法控制的脫序行為。事實上,反覆式在 RUP 的規範中,是可以被控制的,每次反覆都是以編號、週期和目標妥善計畫。只是因為這一些會衍生出專案管理的其它議題,才使得專案管理人員喜歡循序的瀑布(Waterfall) 開發方法,每一個開發階段都定義了很明確的產出。問題是,我在前兩期介紹 XP 時,也曾提及了,軟體的根本問題在於風險。而瀑布式太晚把風險揭露出來,這在現今多變的需求開發中是早已證實不可行的。若反覆式是證實才能解決軟體開發的根本問題,那麼,無論過程遇到一些阻礙,還是應該堅持來達成。 ”Do the Right thing”後,才能“Do the thing Right”!

本書特別在第四章中,介紹了 RUP 的動態結構即為反覆式的開發方式。這也說明了一件事,那些把 RUP 當作僵化官僚的開發模式的軟體組織,實在沒有去用心體認 RUP 的關鍵精髓,擷取其成功的實務經驗,而只是把它拿來當作應付階層式組織各級主管的工具而已,因為很容易產出美美的文件,用它來交差應付。我在許多比較大型的組織中,的確看到很多這樣的現象,這麼多的軟體開發人才,卻一直在那裡空轉著,浪費太多不必要的資源,殊為可惜。

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

本書第五、六章,揭露出“4+1”的架構觀點,及以使用案例驅動 (Use case driven)的開發流程。架構可不容易被解釋與認知,RUP 是嘗試利用觀點 (View)來解釋架構,以讓軟體開發人員瞭解這些觀點的主要產出 (artifacts),以及如何調和這些產出,並仍能維持有一致性的全貌與見解。

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

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

我為什麼要介紹 RUP? 我不是輕量型 (lightweight)的敏捷式 (Agile)開發流程的擁護者嗎? RUP 給一般軟體人員的印象是僵化、官僚、受控制的重型 (heavyweight)開發流程,事實上,我在熟讀本書之後,更確定了,RUP 的本質精髓與其它所謂敏捷式的開發流程根本就是一樣的,它們均強調反覆式的開發、需求導向、以及對測試的重視,只是作法 (how-to)不一樣而已。而 RUP 被視為是高度儀式化的重型開發製程,這也是被那些崇尚軟體工程的專案管理人員給濫用了,卻忽略了軟體也包括了心理學、哲學與藝術的成分存在,而不是只有工程學而已 [Kruchten 2002]。另外,要注意的是,UML 可以是國際標準,但是流程卻沒有所謂的標準,它充其量只是範本 (Template)、一種框架而已。這麼說好了,團隊開發成員之間可以講相同的語言(UML),以利相互的溝通;但每個團隊要如何達成目標,則各有其方法與程序(Process)來達成任務。程序是“How-to”,每個團隊的“How-to” 是不會完全一樣的。

文章導覽

   

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。