這兩個月，我們顧問團隊，還可真是相當地忙，從 10 月到現在(包括到年底)，幾乎每天都要出去，除了對企業的軟體設計教育訓練、IT 資訊單位專案開發的顧問輔導，還有幾個正在洽談的專案輔導案 …，喔，還有演講與座談會等。嗯，看來「軟體設計顧問」這事業，在我們手上，慢慢已有逐漸紮根，也有許多軟體公司與 IT 單位等越來越比較能認同我們的軟體設計理念，以及所帶給他們所謂的 “最佳實務” 的方式。

以上星期而言，我與 Ringle 竟然一起跑了五個單位，最有意思的是，每個單位的需求範疇與實現的平台都完全不一樣。嘿，這對我而言，實在是樂趣多多，客戶所牽及問題的廣度與深度，讓我得以從各種不同的觀點與角度來思考與回應。我是不太擔心會被 “問倒”，反而是有些擔心客戶不太敢提問問題，有時反而還要我主動來 “引導” 客戶來回應與互動討論。

因為上星期所發生的一些事件實在很有趣也有意思，甚至，還蠻有成就感的，所以還蠻想分享個人的心得與樂趣，藉此也說明，我，以及 Ringle，都很確定一件事： 軟體設計真的很有樂趣，解決問題(問題越大越複雜越好)，是一種享受，而不是折磨。

星期一，是固定到國內某大零售超商的資訊公司，擔任某一個專案的顧問輔導。該專案在我們加入前，據他們說已跑了兩個月，仍然在需求面的分析還沒 “定案”，所以無法轉到 “Coding”。嗯，這已是普遍軟體公司專案開發的 “常態”，我們是從不信這一套，所以輔導一開始就重新 Review 與決定架構與開發設計範圍，然後找一個大 BP(Business Process)，逐漸收斂，以活動圖(Activity Diagram)描述與記錄後，再協助他們依據我們所給的一個簡單 “mapping” 的原則，就可轉出到對資訊系統開發最有效的使用案例 (Use Case)；再來是打開一到兩個的使用案例，利用基本分析類別(analysis class)的框架，利用循序圖來描述出內部結構元素的互動情形；然後… 第四個輔導日就給產出實現使用案例的應用程式碼，還包含了測試案例與功能測試碼等。整個輔導的過程，是還同時負責這些相關設計產出的教育訓練。我們是蠻主張的，從一個小型的實戰專案中，藉由有經驗的顧問，擔任教練的角色，協同作戰，快速跑過整個開發循環，然後從過程中釐出團隊成員彼此間看法與想法的分歧、再慢慢去作 “調和” 的工作，快速開發、快速產出、快速取得回饋，這是我們一而再地強調 “Iteration” 的最佳實踐！

星期二，我們是到淡水附近，國內某家非常大的保險公司，當然也是資訊單位，這兩個單位的 IT 資訊人員可是各約有 100 人左右，規模算是蠻大的。這家保險公司花了數百萬元購買國外某家非常非常知名大廠的 “Business Framework” 產品，光是設計文件就有數百 MB 之多，但，該產品卻並沒有被 “實現(Implementation)” 至某一平台，所以，該單位當然是想盡辦法希望能實用到該產品所提供非常浩瀚的領域知識(Knowledge)，不過，兩年來，該 IT 單位委外其他 ISV 實現的成果一直不佳，無法符合他們的期望。

嗯，在前幾次與該單位的 meeting 會議中，我看過該產品，的確廣度與深度相當地浩瀚，從 Activity Diagram, Use Case, Object Model, E-R Model, Interface Design Model …等，一應俱全。我與 Ringle 看過之後，也相當驚嘆，看來是 “名家” 的作品，直覺的判斷，應該是 Grady Booch 幾年前專案開發的產品。 讚嘆之餘，不過，我是認為，要實現好像沒有想像得那麼難，若連一個案例都沒有被實現出來，應該是分析的手法與角度有些問題。 一般呢，我們在輔導某家客戶之前，總是會由該單位提出案例，我們會利用一個 “prototype” 來實現整個架構與結構的設計呈現，眼見為憑，當然，總是需要證明一下我們的 “實力”，也算是一種試煉，同時也比較能確保若談成輔導案時的一種信賴度。

在進行這一個 prototype 之前，其實前幾星期他們已先找過該產品在國內代理的 “某大廠”，該大廠還委請國外的專家來進行 10 天的輔導與試行開發(與原型開發意義是一樣的)。但，結果仍非他們所期，雖然有完成功能面的需求實作，但，這不是他們想要的，他們要的是，在結構面要能完全支援該 business framework 規格的 Interface Design Model，而，往往一個小小的功能，可是要 “串” 上 10幾20個企業元件，這可還沒有牽涉到平台面的實作物件喔。

早上的會議作了一些其他議題的討論，包括教教她們如何抓出 “essential entity”，然後該如何 mapping 至該 business framework 產品內 E-R Model 的那一部分。嗯，看看樣子，其實她們應該也是沒有期待這次的 prototype 能有所 “成果”，這麼多人，花了那麼多時間，就是一直打不開這個 “潘朵拉密盒”，只有我與 Ringle 當天在該 prototyping 會議，我們又不懂該領域的相關知識，怎麼會有可能給實現出來？ 嗯嗯，我好像一直很樂觀，甚至，並不覺得這有難到無法解開，我是這麼認為，要能找到這把 “關鍵之鑰” 來打開寶盒，從 Domain 的觀點與 IT 平台實作的角度切入，都不太正常，那是個 “Business Framework”，是軟體大師的作品，當然要從 “純” 軟體的角度切入才有可能解開！！

我與 Ringle 都是這麼確信，只不過，我比 Ringle 更來得樂觀就是了。中午吃飯時，Ringle 還有些 worry，但，我還是一直很有信心，信心的一個最主要來源就是，我是相信 Ringle 一定可以找到方法切入 prototype 的實作面的。要當場就能展現從浩瀚複雜表象的文檔裡，分析出脈絡，還要能具體實作，這可非 Ringle 莫屬，這我可沒辦法(我能看出問題與茫點，但實作的功力，可是差一大截)，而且，我真的不得不佩服，Ringle 還真是這一行的天才，吃完飯後，他已經想好實現的方法了，而且，一想出來，馬上開始動手，除了利用 EA 定出好幾個層次的 Interface 元件後，找出要實現這一個功能的 operation(每一個 operation，又會呼叫其它的 interface，環環相扣)，然後寫好使用案例，光只是一個查詢功能，就會呼叫到 10 餘顆的 interface，又要 “想像” 來寫出具體實現的物件 …。三個小時，還真讓 Ringle 給完全寫出來了，只差沒有加上與資料庫連結的這一段細部設計。 她們部長(很漂亮與和藹的女生)以及其 SA 這次可真是相當驚嘆，我們所展現出如何分析的手法與思考邏輯，以及如何具體呈現的設計與產出，正是她們所沒有，也正是她們真正需要的，Bingo ！！

總算睜大眼睛了，然後更希望我們能加上與資料庫連結的那一段細部設計與實作，所以再約定了下一個星期再展示算是第二個循環的 prototype。還是 Ringle，只利用星期日的時間一天 “順便” 學一下 Java Spring 與 Hibernate，整個 prototype，實現一個使用案例，從 JSP 到企業元件到資料庫，就給徹底的給實作出來了。 今天早上呢，就是去展示這個 refine 的 prototype，再作一次更細部的解說，大家都很滿意，也都很 Happy，明年度的顧問輔導合作，應該是很有機會創造 “皆大歡喜” 的成果出來的。 還有，這一次也可以說是這幾年來最有成就感的一次，要能 “看到” 一個內部都是完全以interface 為主的企業框架，可真是難得，然後透過我們手裡，而且別人還無法給實現，我們又只利用一到兩天的時間就 “打通” 脈絡，那一種喜悅與成就感，就是擔任軟體顧問職的最大價值了。

好了，回到家後，輕鬆一下，我的 “Relax” 就是玩「魔獸爭霸 3」對戰。工作是順利，但打電玩呢，就是不怎麼順利，又連敗了，這種即時戰略，要手與腦的全能協調，好像不太能適合我勒～

星期三早上，是應邀開車到台中「逢甲大學地理資訊研究所」作個演講。前幾個星期，已安排這天下午三個小時左右的演講，而在以 Email 溝通的過程中，他們的問題，是讓我有些失望，大概就是想找個 “方法論”，找出 “How-to” 來解決他們在專案開發上遇到的種種問題，所以，問題諸如軟體專案從生命週期、分工合作模式、角色等面向，PIM, PSM 等模型該如何區隔 …等。嗯，簡報該如何準備？ 這些問題，好像整理成 50 頁也講不完，但反過來想，好像一頁的簡報也能回答眾多這類所謂 “方法論”、”流程論” 等等這些軟體工程的問題，就決定了，準備一頁簡報來 “應付” 在場聽者的各類問題，而且我還很有信心，所有的線索與答案，都只在這一頁的簡報就能找到的。

我又與 Ringle 一起開車到台中，中二高沙鹿交流道下車，開車過大雅，有個很寬的道路，就給它右轉進去，我知道逢甲的方向在那邊沒錯，但是，進去的是新闢的科學園區，然後走到底就沒路啦。Ringle 馬上 Show 出他的 Treo Palm 手機，有個 ShowMap 導航軟體，指出我們大概的座標，沒想到，沒有地圖顯示中科的道路。真諷斥也真有趣，剛好也讓我想到開場的主題：為什麼國內某家知名 PXGo 的導航軟體，沒有支援 Palm, Symbian 等手機 PDA 系統，為什麼只能開發 MS 相關的應用軟體？

耶？ 大部分的人是這麼認為：西瓜靠大邊，所以當然選擇主流的市場啊！ 問題是，我的意思是，那為什麼不乾脆所有的平台都一起開發？ 為什麼一套產品一定非得要與某個主流平台綁那麼緊，各家平台的實作技術，有這麼困難嗎？

真正的問題在哪裡呢？ 這個導航產品的 “結構面” 不見了啦，根本沒有用心作好 GIS(地理資訊系統) 這個領域的概念分析與分解，而成為真正有效的軟體結構模型。該產品推論應是以專案的方式進行，然後直接從需求面的功能觀點，直接給轉移至與平台緊依的實作面，至於結構面，肯定是給忽略掉了。若是如此，當然無法 “萃取” GIS 這個問題領域的核心，也就是把該領域的重要概念與術語，給表達至軟體的領域模型上，然後再參考要實現的各平台特性，包括 Win Mobile, Palm 等系統，加上平台面的細部設計即可。 咦？ 好像也就同時說明了 PIM 與 PSM 模型的區隔了。

我用一頁的簡報就是以這張圖來作整個流程開發說明的。細節上我想就不再做說明，或者，我應該會寫另一篇文章來專門解釋一張圖的 “涵意”，它可以 “讀出” 相當多的故事與假設點的，同時也代表一件事，從需求面切入與從結構面切入或甚至直接從實作面切入，各有其開發模式，絕對不會是一樣的，而所注重的開發角色與其技能也都不盡相同，那更說明了一個重點，根本就沒有所謂的一種 “標準開發流程” 可以被複製與管理的！！ (未完，待續 ．．．)