{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” 是不會完全一樣的。

{iThome 書評—4} 極致軟體製程中譯本

極致軟體製程
— Extreme programming explained : embrace change 極致軟體製程 — Extreme programming explained : embrace change
———————————–
作者/Kent Beck/著
譯者/李潛瑞/譯
出版社/培生 出版
ISBN/9867910311

內容簡介
本書分成三大部分:

第一部份:問題
從『基本的問題』到『回歸基本面』的章節,構築出XP試圖要解決的問題,並點出評估對策的標準。這部分會告訴你整個XP的概念。

第二部份:對策
從『快速走一遍』到『測試的策略』的章節,把第一部份抽象的概念,轉變成具體方法論的實踐。這部分說的就不是大體的狀況了,而是會把每一種實際做法,跟第一部份所說的問題和原則銜接起來。

第三部份:實踐
從『XP的導入』到『XP的應用』的章節,圍繞在如何實踐XP的各式主題上—像是實踐出適合自己的XP、它對『非常專案』中各種成員角色分工的期待、以及對商業人士的意涵。

這本書談的是XP背後的一些想法—它的緣起、哲學、故事、和迷思。
本書意欲幫助你在獲得充分訊息的狀況下,做出是否導入XP的決定。

如果你 讀過本書後,正確地做出用與不用XP的決定,我都已經達到我的目標。
本書的第二個目標,是要幫助那些正在使用XP的人,能夠對它有更深入的了解。

前言

製程是否與軟體設計有關? 我以為設計本來就不能昧於現實,要能在現實與理想之間,找出調和的解決方案—這會與現實的開發環境有關;再加上設計必然會面對團隊開發時,眾多“人”觀點之間的謀和溝通等議題—這也會與製程有關。所以我也會在「軟體設計必讀經典」系列中,介紹關於製程、方法論等一些好書。其中,本次書評的主角—極致軟體製程,最會是我想推薦給讀者們的經典指標。看到這本書,就如同在舊書攤找到絕世的武功秘籍一般,講究的是心法的傳授,整本書沒有一行程式碼、只有少數幾張圖而已,全都是口述的文字,但閱讀起來完全不沈悶,非常的白話,如同閒話家常般的告訴你軟體的一些道理。

XP, eXtreme Programming (X 要大寫,凸顯了 Magic Letter),中文翻譯為“極致”軟體製程,我覺得 eXtreme 一字也可翻為“極端”,極致代表的是將軟體製程發揮到最善;極端表達的則是有些顛覆傳統開發的方法,但很有效。(例如,搭檔編程,兩個人一起寫一支程式,開發效能反而提升)

教祖康貝特 (諧音),從本書發表以後,儼然成為與 UP (Unified Process)相對立的一種教派:一為輕量級 (XP)、另一為重量級 (UP)的開發製程。(當然,事實上那是僅從方法論的角度來比較看待之,這些製程的根本精髓仍是一致的) 其後闡述 XP 的書籍如雨後春筍,眾多有經驗的軟體開發者們,提出了從 XP的根本價值與原則,來找出解決實務問題的最佳對策與方法等,有三十本以上之多,而目前中譯本也出版了有五、六本左右,但賣得好像不好,本書在某書局又是只賣 NT$ 99。

從問題的根本找出解決方案

第一章開宗明義就提到:軟體的根本問題在於風險! 諸如無法準時交付、錯蟲太多、需求變更、不合適與不必要的功能、人員流動率 …等。因為看到這些問題,XP 先找出影響軟體製程的四個變數因子,然後提出了四種價值觀,再以此訂出開發的基本原則,然後回歸到簡單的基本面,制訂因應的對策,找出實務的解決方法,然後實踐它!

四個變數因子:成本、規模、時程、品質。 你會發現有趣的一件事,其中的三個因子,成本、規模與時程,幾乎都是被控制在客戶手裡,而開發承包單位大概只能控制品質這個因子而已。而品質這個因子正是與前三個因子為反比,所以,成本越低、規模越大、時程越短,那麼,品質必然會差。這種就是根本性的問題,這些變數因子如果沒有作有效控制,那麼導入如 CMMI 等,也是枉然的 (搞不好還更糟糕,增加了太多高度儀式化的工作)。 Kent Beck 在本書中提到了,他發現到可以先專注在規模變數的控制,也就是把規模收斂,專注在客戶真正想要的,早一點釋放出版本 (Release early),如此也比較容易消弭客戶與開發單位見解上的歧異。

四種價值觀:溝通、簡單、回饋、勇氣。 我覺得這就是群體生活最符合人性的恆常價值了。 團隊開發,不說出話來,如何溝通呢? 如果沒有回饋,如何知道你的問題呢? 沒有勇氣表達出你的觀點與決心,如何持續實踐下去呢? 經常性的溝通、回饋、有勇氣表達,團隊自然會造成一種良性的正回饋環路,而更容易有一致性的共識,而往往,簡單的呈現就會出來了。

當你認知到軟體開發的根本問題與所影響的變數,並有了團隊整體的開發價值觀後,就會比較容易找出開發的根本原則了。諸如,快速的回饋、把簡單視為正常、漸進式的改變、擁抱改變、作有品質的事。

把握住基本原則後,再來才是找出解決實務的方法。本書提出了十二種實務 (當然,具體實踐的作法,是在其它書籍中深入說明的),相當具有學習參考的價值,不過,可不要全盤照抄,國情、人文等因素,有些不一定行得通 (例如,要求客戶駐在承包公司),況且,方法是“How-to”,我們應該是從原則來自行找出方法來的,這才是符合 XP 的精神!

簡單的道理卻難以執行

我覺得 Kent Beck 是生活的大師,他把許多生活的哲理帶入了軟體領域來,書中也提到,他媽媽教導他開車時,不是讓車子一直保持在「正確」的方向,而是時時保持專注,這裡修正一點、那裡修正一點。嘿,這正是漸進修正的最根本道理啊。所以書中的副標題為何叫做“擁抱改變”? 因為,軟體開發中的每一件事物都會改變,而問題不在於改變本身,而是在於無法應付改變。

是的,我非常認同 XP 的智慧,不過我也不是 XP 的狂熱份子,我會動態找 How-to,所以例如,“測試先行 (XP 十二項實務之一)”,是我會主張在客戶單位堅持要導入的,而且是以使用案例(加上測試案例)作為功能測試的單位—而這就不是 XP 的方法了。 XP 是建議以 “Story board (或稱為使用者陳述)” 來作為需求的功能點,不過,我覺得使用案例實在很好用,沒必要完全拋掉 UML。 (XP 這點比較奇怪一點,幾乎不見 UML 的影子,甚至連圖形的設計表達都很少)

XP 的道理相當單純,但「執行面」可是很難執行。這在本書第二十四章有特別說明之。Kent Beck 提及,導入的難處,主要還是情感上的問題—特別是恐懼感作祟。我很認同! 所以,我從來不與客戶說我要協助你們導入某某方法論,通常就是以誘導的方式,不知不覺的融入,然後把它當成是一種習慣,團隊成員久而久之就會以為理所當然如此。

對了,為什麼簡單的道理反而不容易執行? 因為,人類往往有兩種天生的傾向:一、對於我們所碰觸的任何事物,通常會弄得過度複雜,基於這個原因,二、我們往往不能看到事物最明顯的一面。

{程序員邀稿} 以架構為中心的主要設計產出(2)

全文均刊登於北京「程序員(Programmer)」雜誌(台灣天瓏書局可購得), 2007 7月刊, p67~p69。 感謝朱海豔(helenna)小姐用心將文稿轉為簡體專業術語,以及將 Model 重新美編,並轉為簡體。

結構面的設計產出

關於軟體結構

所謂的系統結構(System Structure)分析與設計(Analysis and Design),係指如何正確、有效地分解設計範圍內系統的元素(Element,一般泛指物件(Object)),指派每一個物件所應有的屬性(attributes)與行為(behavior, 責任的分派),抽象表達靜態類別之間的關係,動態組合物件在執行期間(run-time)的訊息(Message)傳遞,以履行系統的功能需求(ex. 來自於 Use Case 的功能分析)...。做好結構分析、捕捉有效的領域概念,以成為系統的主結構,才能建構出堅若磐石的軟體系統,來應付現實複雜系統的善變,甚而讓系統呈現有機的次序成長、生生不息。

如何找出問題領域(Problem)的概念具化成為企業物件(Business Object)、指派每一個物件應盡的責任,並以此來建構系統中的軟體規格模型,已是高階系統分析與設計人員最大的挑戰與應具備的本質學能。更為難的是,如何將企業物件配合現實面的平台,例如如何活用 J2EE Spring and Hibernate 系統框架。因為,現實上,物件的狀態(state)就是被永續(persistent)儲存在資料庫系統內,而在需要用到(企業邏輯的運算)的時候才被活化(activate)起來;同時因為物件共用的議題而需要 AP 應用伺服器的系統支援,包括交易(transaction)控管、安全性(security)、效能(performance)、分散(distribution)等議題的設計考量。兩個層次(高階概念性的分析設計;細部平台面的設計),互補且缺一不可。

系統的內,也就在於分析所組成的內部結構元素,套現在 IT 的術語來說,也就是所謂的物件導向分析與設計(Object-Oriented analysis and design)。相對於系統的外,是著重在功能性的需求分析(也就是前一期內容所介紹如利用使用案例建構的需求模型)。兩者是互補—找出內部穩定的結構元素(物件,Object),來應變外部的功能需求。

而系統的結構分析,正是現今軟體人員們最大的罩門所在。在速成短線的專案開發生態,軟體人員只會看到現在所看到的—找出一個一個的功能,快速地利用所提供的平台技術(如 .NET, J2EE),疊床架屋的方式,Quick and Dirty 快速的給開發出來。不要以為利用 .NET 或 Java 等 OOP 語言,就是所謂的物件導向開發模式,這是兩回事,如果沒有用心地萃取具本質性(Essential)的物件(再一次強調,源自於問題領域的概念術語),而只是看到一個功能就成為一個 Class,那麼,這樣的系統完全會受限於需求性的變動而導致震盪不穩,是不會具軟體系統的彈性(flexibility)、穩定性(stability)與延展性(extensibility)!

什麼是軟體的結構?

軟體系統的整體呈現是來自於問題領域(Problem Domain),也就是把該領域中經常溝通的術語(terminology) 對映至軟體系統的物件,稱之為領域物件(Domain Object)或企業物件(Business Object)。 例如,”人事資源(Human Resource) 管理” 系統的開發,其核心的問題領域當然是以 “人事” ,經常溝通的術語會有 “員工(Employee)”、”部門(Department)”、”請假”、”請假細項(AskLeave Lineitem)”、”考績” …等,而這些術語自然地就會被捕捉(capture)至軟體系統內,而成為構成軟體系統主結構(main-structure)的成分元素了。

將組成軟體系統結構的元素組織在一起,並利用視覺化的方式來呈現,稱之為 “領域模型(domain model)”。領域模型代表真實世界中的概念性類別,呈現的是領域中的概念性類別或真實世界中的物件。在 UML 的模型中,最重要也是最必要的一張結構圖也就是類別圖(Class Diagram)。

參考下圖 1,通常使用 UML 表示法呈現的領域模型,凸顯的是概念(concept),再來則是以及概念之間的關連(association)與屬性(attributes)。例如 “Order”, “OrderLineItem”, “Customer” 都是屬於在該領域中的概念; Customer 與 Order 之間則存在著 1 對 1..多 的關連(一個客戶會有 1到 1..多筆訂購交易); Product(產品) 具有 description, price 的屬性。在概念性的分析時,細節(包括操作,屬性,資料型態等)在目前並不重要,最重要的是能突顯出概念的呈現,也就是找出類別(Class)。

圖 1、範例—訂購系統的類別圖(Class Diagram)
(點擊圖片鏈接看原圖)圖 1、範例—訂購系統的類別圖(Class Diagram)

那個時候最能表現出結構設計的應變能力? 筆者常說,當 SA(System Analyst) 遇到 有點像又不太像 這類的需求時,也就是結構設計發揮的時機了。 舉個例,訂購 若會視訂購的類型,可能是書籍、雜誌、百貨商品等,而有不同的訂購流程與處理邏輯,此時,懂得虛與實互補設計之道的 SA,會很自然地把訂購分為一般化與特殊化(generalization-specialization)—把已知的部分放在一般化;而未來要具體實現的部分放在特殊化。事實上,這也才只是利用到多型(polymorphism)的基本技巧而已,就已經足以解決為何程序員經常會為了訂購類型寫了一堆的 switch, if…then…else 這種的條件敘述,而造成程式碼混雜,難以維護了。

如何找出軟體的穩定結構元素,是系統分析人員最大的挑戰。SA 並不需要具備領域知識(Domain Knowledge),但卻要懂得如何與領域專家(Domain Expert)溝通合作,萃取其知識,並抽象(abstract)成為軟體的主結構。這相當不容易,那並非是純技術面,真正的軟體設計行家,絕對是具高度的抽象的能力,要能懂得從多個構面觀察,時常在反思與找問題(不是找答案)。筆者正是被這在 虛 與 實 均要能互補、一輩子也學不完的軟體設計領域,給深深地著迷,才從原來是系統管理與 Oracle 資料管理師,而至中年才轉到軟體一職來,並已把此視為是終身之職,是要窮究一輩子、甚至帶至下一輩子繼續來修行的。

回歸正題,關於結構設計的好書相當稀少,筆者這裡特別推薦 Peter Coad 軟體大師,從早期 1990年的 “Object-Oriented Analysis”,“Object-Oriented Design”,至 1998 年的 “Object Models”、1999年 ” Java Modeling In Color with UML” 等著作。尤其是 “Object Models” 一書所揭露出以交易為核心的 交易樣式(Transaction Pattern),更是軟體結構分析人員必讀的聖經。在筆者經常訪問與輔導各領域的公司時,經常在當場就直接展現與證明不用懂領域知識,也能馬上抓出該領域的核心結構,所使用的利器即是 交易樣式(Transaction Pattern)

閱讀全文 »

{程序員邀稿} 以架構為中心的主要設計產出(1)

全文均刊登於北京「程序員(Programmer)」雜誌(台灣天瓏書局可購得), 2007 6月刊, p74~p77。 感謝朱海豔(helenna)小姐用心將文稿轉為簡體專業術語,以及將 Model 重新美編,並轉為簡體。

前言

筆者在輔導專案的初期,第一個時間點就要能抓出系統開發的架構全貌,請注意一下,系統不全然是指軟體資訊系統,也有可能是將企業當成是系統,並對其作需求分析、結構設計,此稱之為企業塑模(Business Modeling)。這是牽涉到系統開發的範圍與層級,無論是企業或軟體系統,如何讓開發團隊所有成員與利益關係人(stakeholder),都能對待開發的系統有一致性的整體觀,這會是架構師首重的工作與責任。

保持整體觀可不是只透過一種設計產出就能讓所有人瞭解,道理很簡單,開發人員經常會有各自所關注的觀點,例如,需求分析人員關心的是系統能提供什麼功能與服務給使用者,他重視的是系統外部的功能需求;結構設計人員關注的是如何找出穩定的結構元素(經常是源自於問題領域的概念(concepts)),來支撐與應變外部需求的變動,他重視的就是系統內部的結構組成元素;實做人員當然就是重視能不能快速寫出程式(program),同時還能有高效率與彈性,他重視的就是系統平台面(ex. .NET or J2EE)的實做與相關設計議題;甚至,連客戶單位的高層管理人員,也有他重視的觀點,如資訊系統是如何協助與協助企業流程(Business Process)的自動化 …。

所謂架構呈現的整體,並不是靜態不變的,而是持續性的動態調和,架構師就是要能懂得如何調和 需求功能面、結構面與平台實作面 等多重觀點,凝聚各種不同的角色,還能有一致性的全貌見解。這可不是容易的事,軟體架構不只跟結構與行為有關,同時也跟背景環境有關,包括:使用方式、功能性(Functionality)、效能、彈性、再利用性(Reuse)、可理解性(Comprehensibility)、經濟效應與技術的限制與取捨 … 等。

本篇內文,筆者是希望利用一些 UML 視覺化的設計產出(artifacts),來說明這些產出是如何來協助架構師觀照與協調整體。這些設計產出,彼此之間有某種程度的關連性,並且要能保持一致性;架構師也容易瞭解架構的全貌是從哪一種角度來看待的觀點,然後知道如何在表象複雜的系統中,聚焦(focus)在系統廣度與深度的某一點,而不致偏離所探討的主題。 聚焦可是架構師必具備的能力,知道焦點的所在,決定是否再細分下去探究內部的細節;還是因為成員之間常因細節爭擾不紛時,就知道應該再把討論的焦點層次再往上,才比較能取得共識。

以架構為中心的觀點與產出

在前一期的專欄中,筆者提及了三個觀點來呈現架構(關於該三個觀點的解釋,請參照上期內容),參考如下圖 1。

圖 1、表達軟體架構的三種觀點
(點擊圖片鏈接看原圖)圖 1、表達軟體架構的三種觀點

以下列出筆者個人經常在使用的設計圖,用來呈現與解釋各種架構的觀點。請注意,筆者並不是會全部用到所有的設計圖,會視專案的規模與性質來決定該有哪些架構設計,有時甚至也會有額外、不一定非得是標準 UML 的設計圖。重點還是在於:你要知道該設計產出是在那一個觀點、表達的是那一個範圍與層次。筆者太常看到,團隊成員們之間,爭論的話題,根本就是不同觀點、不同層次,卻又不自知,難怪會經常導致溝通障礙的問題了。

閱讀全文 »

聊一下「版本控管」與 「Issue Tracking 」的專案開發機制

我在輔導各單位不同性質的軟體開發團隊,對於專案開發的工具導入,只要求至少要能提供兩種機制給團隊成員們使用。一為版本控管(Version Control);另一為 Issue Tracking

各個單位可以自行選擇,無論是選擇 VSS(Visual Source Safe)/VSTS(Visual Studio Team System), CVS, Subversion, ClearCase 等版本控管工具,以及使用 TFS(Team Foundation Server), ClearQuest, 甚至是只用 Excel 當作 Issue Tracking 工具,這些我都沒有意見,團隊成員們覺得好用、還有,真的有實際在用即可。

不過,我是蠻堅持要至少導入這兩種機制,理由為何? 我覺得道理就是很簡單、很自然。 版本控管機制如同 10 餘年前 Novell FileServer 一樣,所有的文件、設計產出(artifacts)、程式碼都是集中放在一個儲存區 (repository)內,團隊成員就是去同一個地方把開發的文件取出來(check-out),改完後再放回去(check-in),而不同於 FileServer,版本控管就是多了因為共用的議題而衍生出衝突的情形發生時,所提供的解決方式與功能。所以,三年多前,我到某大學教授資訊系的講師與教授等,其中一位帶學生作專案開發的女老師就問道了,每個參與開發的同學都負責某一部份的文件與程式碼,並放置在他們各自的硬碟中,但是要整合時卻是問題多多,該如何解決這問題? 這個就是,不是問題的問題。很自然地,放起一起就對了,交給版本控管工具來協助管理即可,但是,另外一個問題是,女老師認為安裝與設計這些工具是難事,呵,這好像不是理由,往對的方向走後,再來思考 How-to 的解決議題就是了。 Issue Tracking 為何也要導入? 只要是超過兩人以上的開發,必然會有溝通(其實,一個人也會有溝通的問題,與內心自己的溝通),也必然會有問題的紀錄與回應。我最是鼓勵團隊成員第一是勇於問問題,是的,要能勇敢的問問題,這本身就不是一件容易的事。其次就是不要只把問題放在心中,要能 Write Down 下來! 對於某些問題的本身,就是一個可以讓成員之間討論溝通的主題,然後就是把這些溝通的經過給紀錄保存起來,這才是真正有效的知識分享(knowledge sharing)。

簡單的說,版本控管是設計產中的一種共享;Issue Tracking 則是大量溝通的機制。

哪個時候導入? 我是不會專案一開始就馬上導入的,當然,專案經理可以先準備好,我也沒意見。理論上,應該是專案啟動時就要馬上導入的,但是,團隊成員,在那個時間點其實要謀和太多的議題了,包括技能、技術、產出之間的橋接、默契 … 等太多的事情了。我是不主張一開始就是花時間在工具的學習使用,反而是,慢慢地,等到團隊成員們越來越有默契、越來越覺得好像少了什麼東西似的,那個時候,就是可以找工具來導入的好時機了,而且往往是水到渠成,使用這些工具,不會變成壓力,而真正是一種助力了。

用哪些工具,有沒有差別,是否最好是能有一套統籌的 “ALM, Application life-cycle management” 專案管理機制比較好? 我是不會想那麼多、那麼嚴肅的。工具好用順暢即可,還有,更更重要的是,真的有在用才行! 嘿,是真的有在用,而不是變為一種形式上的紀錄而已喔,實在是好多單位,還真的是淪落為形式而已,哪可不是更形增加軟體開發人員的負擔與反感嗎? 我可不知道這些專案管理層級的主管們是在想什麼。

我輔導過的單位,有使用過 Microsoft TFS, Rational ClearQuest 等比較重量型的 Issue Tracking 工具,當然也有是採用 OpenSource 的工具。有些公司的專案經理,就會請我協助選擇個比較不錯,便宜(最好是免費)的工具,這些我當然欣然接受,沒有問題的。

哪一個 Issue Tracking 的工具功能最佳呢? 就我輔導過許多單位的經驗來看,嗯, 就某大型零售業資訊單位所使用的 Excel 最棒! 因為,他們是我所看過最勇於發問問題,也勤加記錄問題的解決步驟與方案。我們在每一次的輔導,一開始一定是針對 Issue 來討論的,而且,他們也會對 Issue 作分類,還標上顏色識別種類與重要程度。

真的有寫上 Issue,真的有對 Issue 來討論,這才是根本。所以,何嘗 Notepad 不也是一種 Issue Tracking 的工具呢?

{程序員邀稿} 從軟體架構師(Architect)的觀點來看軟體開發流程

前言

筆者多年來輔導過諸多不同類型與不同領域的軟體開發專案,本身的職務是擔任軟體架構師(Architect)與顧問輔導。架構師不是只負責技術面的問題,更要兼顧到專案開發的過程中, 」人」 的互動所衍生而來的諸多問題,包括想法的歧異、見解的落差、不同的觀點與角度,甚至情緒問題等等,這些都需要與專案經理協同合作,一同來解決問題。

軟體的開發,最終目標雖然是 「完成高品質」 的軟體系統,但在進行階段過程中,所衍生出的兩大議題—專案管理(Project Management)與開發流程(Development Process),卻是首要需克服的階段目標。而該兩大議題,均是係以 「人」 為核心的考量,專案管理講究的是 「領導統御」、」人和」;開發流程重視的是 「調和 (凝聚團隊成員的觀點、角度,保持產出的一致性)」。專案管理的部分,筆者的角色比較不方便闡述(此一部份由專案管理者來論文比較妥當),倒是相關於開發流程的議題,筆者倒是可以把藉由所觀察到諸多各形的開發型態,以及個人的一些研究、學習、思考與體悟的心得提供給讀者參考之,文中內容會是筆者比較偏以 「主觀意義」 的表達。

變動無常的軟體專案

軟體系統的專案開發,特別的是,需求往往不明確,更何況是經常處於變動中,所以導致專案的範圍與規模無法界定,連帶也引起時程無法估算(人月? 神話吧)。那麼,是不是開發成本的成本也無法預估,而往往也因為成本與時程的低估,更容易導致品質不佳、粗製濫造的軟體系統。

正是由於軟體別於如硬體產業的變動性問題,使得在其它成熟領域的專案管理經驗,並不容易全盤導入至純粹是軟體的系統開發上。若是把軟體開發當成是知識與創新的產業,那麼一成不變且僵化的專案管理方式,並不妥當;除非是將軟體產業當成是軟體工廠,需求固定且明確,工作者(worker) 各司其職,負責實做局部的小功能,再由 「大一點」 的工作者,來組裝成大功能。請記得,這樣的方式,其假設前提是需求不容易變動,工作者也不太需要具備創新獨立思考的能力。

個人是很難相信需求不會變動,同時也認為正是因為軟體的多變性,才造就了更多的好機會,所以軟體的開發,不應該視善變為畏途,反而是把變動看成是理所當然,更是多添了許多的好機會。我們所要作的事情只是,如何將變動抑制或收斂在某一程度可以被控管的範圍內,同時,學會如何在某一問題領域(Problem Domain),重覆性、同質性高的軟體系統,來找出不容易變動的部分,成為系統的框架(framework),或稱之為主結構(Main-Structure)。而容易變動的部分,又是如何從主結構中抽離出來,爾後只花少許的 「工作量(effort)」,就可以輕而易舉的滿足客戶的需求。

很難嗎? 只要有兩個滿足的要素即可:一為開發的資源(包括成本與時程)多一點;另一為團隊對軟體的基礎養成與默契好一點。 但是好像要能滿足這兩點可真是困難,該如何才有可能達成這種 「夢幻」 的要件呢?

這就回到最現實 「人」 的因素了,要能爭取到多一點的開發資源,如果你沒有什麼誘因吸引老闆或業主(兩者可統稱為關係利益人, stakeholder),是不太容易的。專案的領導者總是要有 「實績」 才能讓關係利益人信賴並願意投入資源,而資源越多,當然專案成功的機會就更大。後文會提及,「反覆與漸增(I&I, Iteration and Incremental) 」,會是提升專案開發 「實績」 的好手段。

再探討另外一點,如何才能讓團隊成員對軟體的基礎養成與默契好一點? 默契要好,溝通必然要多,要能溝通多,當然就是要勇於把自己的想法給表達出來,而這些,則是有賴於專案領導者的支援與協調。總之,好的專案領導者是要能懂得 「觀察」 在整個專案開發的過程中,成員之間互動所衍生出的種種問題,然後找出 「解決方案」 來謀和 「人」 的問題;另外回到最根本的是,畢竟這是軟體的開發,軟體的基礎養成功夫不足,當然也不太可能作得好軟體開發,軟體人員持續的學習與成長,更會是軟體產業的命脈。

幾個可能是軟體開發流程的問題點

正是由於 「變動無常」 的軟體開發專案,有些人的想法是想要 「凍結」 住需求,然後依照固定不變的製程,一個階段接續下一個階段以循序式 (Sequential)的開發產出 (artifacts),例如預估一年開發期的專案,三個月的系統分析(SA, System Analysis)、三個月的系統設計(SD, System Design),六個月的實做與測試(Implement and Test),這樣的開發方式稱之為 「瀑布式(Waterfall)」 的開發流程,參考如圖1。 閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal