Ringle 的新書 ─ 「UML 協同開發管理」，順利的話，應該是這個月就會出版了。 本書的序言還特別邀請我們曾經輔導過，包括企業 IT 資訊部門主管，以及軟體開發公司教育課程培訓承辦人、專案經理等。 由於先前輔導時的合作均相當愉快，且對 Ringle 嚴謹且甚為專業的能力給予相當肯定，所以請之協助寫序時，都相當樂意來背書。

我這裡就先列出該書部份的序言內容。 其中也有美女好朋友們的加持，而且好不容易獲得她們的首肯，願意提供美美的照片放在序言內。不過不知道新書出版時會不會有含照片？ 有的話也算創舉，想必銷路會賣得更好。 😉

~序的開始~該怎麼開始才好呢？

生平以來第一次很榮幸的接到Ringle老師的邀請，幫忙推薦~ 以小女子我的經驗：

公司在去年 (2008 年)針對技術同仁們進行一系列的Java 與UML技術培訓課程，聘請了Ringle與其顧問團隊擔任課程的專業講師，規劃長達七個月的訓練。

過程中在每次上課時看到他們用心教學及互動，課前或課後也都會互相溝通關於學員的學習狀況及如何改正微調後續的教學方向，讓我在執行時非常順利及安心。 課程結束後學員們對課程的滿意度平均值也是相當不錯，所以在此特別謝謝他們對課程的用心。

同時也恭喜Ringle將教材、專案開發與顧問輔導時的經驗等等撰寫成書，對於期望應用物件導向原理於開發實務的朋友來說，一定會是一本很好的重要學習指南喔。

HiTrust 教育訓練培訓專員 Vivi Wang

「UML」這名詞，對於從事軟體設計的工作者來說一定非常熟悉，但我相信一定有很多軟體設計師和我有一樣的心路歷程，對於坊間介紹 UML 的書籍不勝枚舉，拿起這些書籍在看的當下，也許有時是懂非懂，有時心神領會，甚而也可頭頭是道的講出這十三張圖個別的用途，然而每當在開發專案欲實際應用「UML」圖形來表達各開發階段的層次時，就會開始充滿疑惑 ……

「這兩個 Use Case 的關係應該是什麼? Association? Generalization?」、「抓出來的 Use Case 怎麼像是系統功能?」、「循序圖到底要表達到多細節?畫的人好辛苦，看的人也好累!」，「活動圖表達出來的像是資料流程圖?」，最後的結果就是，畫出的UML自己也不知道對還是錯，變相為只是為了文件交差，而非開發團隊的溝通工具，完全扭曲了「UML」這個Language的用途，這是在我從事軟體開發多年來，在每家公司皆會遇到的情況。

直到任職的公司，請了 HSDc. 來輔導專案開發，在參與輔導的過程中，Ringle 將過去我對「UML」的誤解─不具實質意義的理論工具，完全導正回來，重新認識每張圖的本質意義，一步一步將真實的專案，協同開發團隊以「UML」溝通進而實作出來。

舉個例來說，以前對「Use Case」的畫法，就是拉幾個「小人形」和「小圈圈」，寫上每個「圈圈」代表的功能，再用「框框」把「圈圈」圍起來就完成了，在團隊溝通間表達出的意思就是「這個系統有哪些功能！」，更不知道「圈圈」的背後還要描述「正常流程」這回事，說起來真是汗顏，把「UseCase」的用途─使用者心中的期望，完全曲解了。

經過了 HSDc. 顧問群的輔導之後，讓我對每每陷入泥沼的軟體開發，重新有了熱情與動力，在軟體設計之餘，感嘆坊間關於「UML」與「團隊開發」的書籍總是不平易近人，也許是大師們的著作內容層次過高，讓軟體開發初學者無法心領神會的參透「UML」本質，將理論正確的實際應用在專案中。

終於Ringle在各方遊說之下，將其多年來的軟體設計及顧問輔導的經驗，集結成書，以故事性的訴說，引導讀者進入模擬的專案角色之中，步驟性的繪製出「UML」圖形，淺顯易懂的了解各種「UML」圖形的本質與繪製方式。

書中的第二、三部份再採實作方式，以案例實際帶領讀者，補捉企業流程、找出使用案例、撰寫使用案例與測試案例、實現使用案例、程式開發、部署，可確實了解完整的團隊軟體開發流程與建構管理的種種面向，閱讀起來不僅易懂更讓人有恍然大悟之感，是適合軟體開發團隊中各種角色閱讀的一本實用書。

博暉科技 專案經理 Erin Fang

三年前因負責一個小型系統的發展，帶領一組團隊開發並藉此進行人員培訓，專案初期就遇到需求無法有效整理出來的窘境，專案最後雖然順利完成，心中卻埋下了一連串的問號？

1. 需求提出者雖長期於相關領域任職，提出的需求卻是片段且不連貫。
2. 這些不連貫的資訊要如何有效歸納為需求，才不會出現雞同鴨講的情形？
3. 如何在分析、設計、開發的過程中，需求變動的一致性要如何維持？
4. 專案採用物件導向程式語言，專案成員要如何迅速掌握、運用？
5. 專案有時程壓力，要如何進行紓解，讓專案在可控的範圍內順利執行？
6. 那些部分可以委外進行，委外同時，自身應該要做好那些準備？

…..

同時，專案過程中，會產出各式的文件。系統分析文件記錄企業的業務活動、準則、系統需求，設計文件則描繪實踐系統的方法、步驟，產出這些大量的文件需要可觀的人力，若無法達到「有效溝通」的目的，就會造成時程延宕、品質不佳、成本居高不下等現象出現，失敗的專案當然又多一個出來。

文件另一方面而言，被視為企業的重要資產，當然希望能有效的保存、運用，但常因相關主事者的習慣、喜惡而產出各種不同形式的文件，保存的方式也各有不同，降低文件的流通性及可利用性，最後散落各地。雖可作為系統維護者的參考資訊，但真正要解決問題時仍舊需要去閱讀大量的程式碼，才能確實理解系統的處理規則，維護人力也會大量增加。文件的因欠缺「標準化」、「可閱讀性」、「有效運用」…，並未真正成為企業的資產，這些都是我們嘗試要解決的課題。

偶然的機會中接觸了「信仁軟體設計有限公司」的顧問團隊，經主管的支持，邀請他們分享在軟體分析、設計、開發的心得。爾後請他們在一個小型的研究專案中提供顧問服務，藉以進行人員培訓。在為期四個月的顧問服務期間，透過運用UML塑模方式進行專案需求分析、設計、驗證等過程，確實體驗到信仁顧問團隊在整合「理論」與「實務」上的功力。

後來，我們嘗試在其它的專案上導入UML分析設計的作法，利用「使用案例圖」來捕捉客戶需求並界定系統範圍。「循序圖」來描繪系統內部的運作，產生程式碼框架，利用這些程式碼框架來做為外包開發的基礎。「活動圖」與客戶確認相關的業務流程。使用EA做為我們專案團隊的共同文件製作平台。作法上，我們並未使用UML全部塑模圖形，而以專案團隊可以善加運用的為主。文件的「溝通性」是我們所專注的重點，如果純粹為了UML而使用UML，必會產生反效果，這不是我們所樂見的。經由這些嘗試的過程，我們逐漸歸納出適用於自己專案推動的文件規範與溝通模式，成功的完成任務。

本書作者「賴信仁（Ringle）」即為輔導我們領略「理論」與「實作」合而為一的顧問之一，經過三年的時間，他將輔導客戶的心得整理成冊，透過「信仁醫院」的模擬案例，帶領讀者由「企業流程」->「系統需求」->「領域模型」->「系統結構（鉅觀與微觀）」->「系統實作」等步驟，探討UML在系統分析及設計的相關議題。全書的用字淺顯易懂，沒有技術書籍的艱深用語，反而像是在敘述一件故事的發展並且對於故事的內容分析其原由一般。

讀者可先以瀏覽的方式快速閱讀一次，然後把書放在隨手可得之處，利用空檔閒暇之時輕鬆翻閱，從萬物依存的角度來檢視「系統」、「企業」、「人」三者間存在的關連，在軟體開發的工作上能提供另一種思考的方向及層次。另外雖然本書是以物件導向的觀念來說明UML的分析設計作法，但其分析設計的手法並不一定非得拘泥在採用物件導向為開發語言的專案中，讀者可以嘗試在傳統結構式語言中加以運用變化，同樣可以清晰的勾勒出系統的全貌與領域模型。

某大物流業資訊中心 軟體資深專員 盧祐正

欣見軟體界一本好書出版。

Ringle 是我認識的「架構師」中一直有自己特色及獨立思考的「大無尾熊」，在與之合作之相關專案，發現其個性溫厚，包容力超強，設計實作速度快到有時候連我都不免好奇怎麼會有如此天賦，常常發現與之合作的其他架構師都遭遇跟不上他速度的窘境，直到最近難得找到另外一隻小無尾熊，一起研製成長。

在克明的鼓勵，以及我們期望 Ringle 把這上天給的恩賜的能力100%發揮出來整理成書，造福社會更多需要這門知識的夥伴後，這本「UML協同團隊開發」終於誕生。

懷著興奮的心情在拜讀這本書後，可以很輕易的發現 Ringle 係按照以架構為中心的軟體本質精神，並以案例實戰演練不斷的透過循環與漸增的方式引導讀著，以架構觀點在讀這本書時，發現該書不只是單純了理論基礎，而是經過很多實戰經驗累積而成，這是一本讓有興趣的往「軟體架構師」生涯發展的架構師們，可以真正於每次的任務或專案中實戰演練的好書。

個人欣見其努力扎根，也同時盼望與祝福軟體產業蓬勃發展，喜見其成功，特為之此序，祝賀台灣軟體產業在全世界發光發熱。

企業架構師協會台灣分會 執行長 宋敏如