有無出版社想協助 HSDc. 出版軟體設計相關書籍的?

今年我與 Ringle,都打算整理近年來的一些文章與軟體設計教材的內容,出版成為實體書籍。本來的打算是與 Ringle 一起合著,不過發現到我的寫作與他的 Style 大不相同,其實就不要勉強,各出各的就好了。

其實去年我就打算出版書籍了,一方面是有些忙(藉口啦),另一方面,透過一位朋友的介紹,與某大國內知名出版社的一位編輯洽談。她提到啦,只要是軟體設計、UML 相關內容的書籍,都賣得很差,這從他們出版的一些軟體設計中文譯書的銷售狀況就可以得知。聽起來,好像是希望能出版一些工具類使用操作的書籍,這類型書籍在國內賣得比較好。

當時我可是就沒啥興趣了,國內 How-to 類操作性的資訊書籍,已經蠻多了吧,況且這些內容透過 google 都可以查得到,另外我也實在不擅長寫操作性的書籍。倒是今年想法有些調整,對於初學軟體設計的人來說,有實體工具的操作,佐以基本卻是正則的設計觀念,再加上實做的範例,包括 Model 與 程式碼的對照,未嘗不是一種學習的好方法?

有了這想法後,我也與 Ringle 討論過,他打算先出版一本 UML 觀念導引與實務操作入門的書籍,工具當然是以 EA(Enterprise Architect)為主,而且會延伸談到 EA 的眾多功能實做,包括許多軟體人員最關心的 Code generation,以及 MDA(Model-Driven Architecture), SQL DDL generation, Document generation 等。

內容已寫了十分之九,剩下的是一些細節上的修飾與補充,頁數預計約有 3,400 頁左右。

嗯,就是希望還有哪些出版社願意出版這類型的軟體設計書籍? 另外,除了偏操作性的技術書籍,也希望個人的一些對於軟體設計的想法,尤其偏以架構整體性的思考引導性內容,也歡迎出版社的編輯們能與我聯絡,討論一下比較符合市場的大綱與內容。

聊一下「版本控管」與 「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 的工具呢?

軟體其實還真的蠻有趣 (1)

這兩個月,我們顧問團隊,還可真是相當地忙,從 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 模型的區隔了。

Architecture-Centric Process

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

通過 OMG UML OCUP Fundamental 認證考試

上星期五下午,決定在 「Prometric 國際認證考試中心」 線上報名 OMG UML OCUP 認證考試,預約了今天下午 2:30 在復興南路一段資策會訓練中心考試,然後利用假日,花了兩天的時間 “瀏覽” 一下 UML 2.0 Superstructure 規格,下午就過去把它給通過考試了。

OCUP 認證,共分為三個 level:

  • Fundamental。
  • Intermediate。
  • Advanced。

通過這三級的考試,算是取得了 OMG 國際組織所認可的 UML 專家(Expert)執照(license),但為何要取得 OCUP 認證,有何好處呢? 嘿,官方的 FAQ 說明,非常實際也現實:To take more money!!

不過,對我本身倒是沒啥實質的幫助,我考這個認證的目的只有兩個:

  1. 我本來就很熟 UML,考試就是為了證明這點。
  2. 評估 OCUP 的內容,是否我們顧問團隊可以未來規劃成為 UML 認證課程,協助學員考取認證,並學習適當的軟體知識與技巧,甚而,與 104 等人力銀行合作,協助與輔導取得認證學員謀得更好的工作與職位。

後面這點比較重要,畢竟,提昇大中華地區軟體人員的設計水平,一直是我們 HSDc. 顧問團隊成立的使命之一。

本來想,只是 “Fundmental” 基本而已,哪需要準備? 但,就在前兩個禮拜,我一位對 UML 非常熟悉的朋友,也是沒有準備就去應考了,結果當天考完後他打電話給我,他差了四題沒考上! 哇!! 我還以為他應該不是滿分也離滿分很近才對,怎麼有可能沒考過? 他告訴我,完全與想像得不一樣,總共 84 題的題目中,應用題不超過 1/3,其餘全是 UML 術語的基本定義與圖形語法的定義,完全取自於 UML 2.0 Superstructure 規格的定義與說明。重點是,Superstructure 這份規格書實在不是給人看的,內容非常非常地艱澀沈悶,那不是懂不懂的問題而已,而是,唉,我很難解釋,親自下載自行看過就知道啦,”UML User Guide” 這類已經算是很悶的書了,但 Superstructure,絕對比該書還要再悶上 10 倍以上。

這可不是開玩笑的,我考過 20 餘科各類型的認證考試,就屬 OCUP 的認證考試費用最貴了,報考費用是 USD$ 200 !! 折合新台幣約要 NT$6500,沒考過,需要等三個星期後才能再繼續考,連續三次沒過,一年內不得再考。 我可不願意與我的錢過意不去,所以只好勉強自己,花了兩天的時間,靜靜地看過 superstructure 規格,對術語的定義、圖形與語法等有過印象。

我還是要強調,superstructure 實在不是給人看的,你要勉強看它,甚至指望去背它,你會很痛苦,我可不幹這種事。在兩天的準備時間內,我同時參考了比較有些 “人性化” 的 UML 參考書籍,它們對 UML 基本語法的解釋有比較多一點的範例,三本需要參考的書籍:

  • UML Toolkit 2.0。
  • UML Bible 2.0。
  • UML User Guide。

至於 “UML Distilled”, “Applying UML and Patterns” 這兩本最有指標的 UML 經典書籍,對考試基本是沒啥幫助,請記得,OCUP 根本就是在考你對 UML 的術語與圖形元素等語法的定義熟不熟而已,而不是考你如何利用 UML 表達在軟體設計的思考與應用上,完全是兩回事!

舉個例子,什麼叫做 “基本術語” ?:

  1. 什麼是 element?
    Ans: a constituent of a model.
  2. 什麼是 active class?
    Ans: A class whose instances are active objects. and An object that may execute its own behavior without requiring method invocation.
  3. 什麼是 metaclass?
    Ans: A class whose instances are classes. Metaclasses are typically used to construct metamodels.
  4. Which of the following applies to a package? (choose two)
    a. Package is a Namespace.
    b. Package is a packagable element.
    c. Package only helps to organize Class diagrams.
    d. ……
    Ans: a and b

這就叫做 “基本術語” !! 你若沒有研讀 superstructure,有誰會知道這些?

當然,還有它會列出許多 UML 的圖形元素,讓你去辨識並回答它,例如,畫了一個循序圖(Sequence Diagram),然後要你指出哪一個是 “Lifeline”,嘿,UML Toolkit 那本書還寫錯呢,可不是垂直下來的那條虛線,而是利用四方形線條框起來,裡面寫了物件名稱:類別名稱 那個圖形才是(“UML Distilled” 是將它稱為 participant)。你若對每一種圖的基本元素認識不夠清楚,你根本不知道該如何選擇,又如有一題:在 activity 圖形中,其中方塊符號的圖形,被哪兩個圖形元素同時來使用? (Ans: Decision and Merge)。

有些應用題,尤其是使用案例圖,一次考好幾題,都是同樣的圖形,然後會問你在 Actor 與 Use Case, Use Case 與 Use Case 之間的關係,你若對 <<include>> , <<extend>> 這種語法與其本質不熟的話(甚至它還搭配了繼承的關係),這幾題就全泡湯了,該應用題型我記得很清楚,我會把它給獨立以另一篇文章來討論之。

當然,硬要讀 superstructure 還是有訣竅的,就是謹記,規格書內的所有術語,包括 element, relatioship, namespace, association, multiplicity, classifier, package, constraint …等,全都是類別(Class),而這些類別的關連組合,包括 assocation, aggregiation/composition, gereralization/specialization 關係等,就成為一張張各個 “特定功能” 的類別圖了。所以,你要能對 “類別” 的抽象化要能有相當的體會,看這份規格,才會有感覺。

我是用很輕鬆的態度來看這份規格的,對於每一個重要術語,如同前述,我會看過一遍,然後轉到 “Semantic” “Notation” 與 “Presentation Options” 看其說明,看過就好,不去背它,有點印象即可。畢竟,OCUP 如同其它認證考試,都是選擇題,只要讓我有點印象,”大概” 就可以推理猜出來了。要去背它,我說過,你會很痛苦,一個星期也看不完,算起來 foundmental 部分也有 200 餘頁,不算少,我在兩天之內把這些部分全看過一遍,應該算是瀏覽性的閱讀吧。對了,若在每一個術語最後部分有附 Examples,一定要用心看它,這最重要!! 有許多的考題會來自於此。

考試的題目總共有 84 題,其中四題不計分,那四題? 我也不知道,大概像這種問題:OMG 的全名是什麼? 這種應該不會計分吧。 (有人還以為全名是 “Object Model Group” ,當然不是,是 “Object Management Group”) 考試時間是 90 分鐘,全部選擇題,其中單選與複選題大約各佔一半左右吧。
每一題都可以 “mark” 起來,等到回答至最後一題可以再選擇【Review】那些被 “mark” 的問題重新選擇。我那位朋友最有趣,他一看到第一題就 mark 起來,然後再翻下一題又 mark 起來,下一題還是,結果… 每一題他都沒把握,到最後幾乎所有時間都用完了,也沒時間 review “mark” 的那些問題。

我算是考認證的老手了,回答選擇題,我幾乎是以 “直覺式” 作答,”大概” 覺得這答案看起來比較順,就給它點選下去了,然後點【Next】繼續下一題作答,如此速度很快,84 題我大概花了約 50 分鐘就做完了,然後花了約 10 餘分鐘 review 我所 mark,約有 20 題的題目。反正,都是憑感覺,好像很少有我覺得很篤定一定會答對的題目。還算不錯,考完後還剩約半小時的時間,我也懶得待在裡面,點選【End】後分數馬上跳出來,84 題,及格題數是 46 題,我答對 61 題,而且在每一大部分都很平均,16 題約錯 3~4 題,算是過得無驚無險。

我是在資策會的數位教育訓練中心考試的,我已經有快五年的時間沒有再考所謂的認證,才知道現在什麼東西都不能帶進考場內,包括筆、白紙、電子辭典、甚至手機,都不能帶進去。考題當然全都是英文,所以,可是要對英文字彙,尤其是術語,要先能看懂才行的呢,我好像有一題,某個單字就看不懂,還是關鍵字,害我在那邊猜好幾分鐘。

其中還有個大問題,考試中心是使用 Windows 中文系統,竟然有些英文題目內某些單字會變成亂碼,尤其是 <<include>>, <<extend>> 這些都變成亂碼了,相當麻煩,去抗議也沒用,倒不如多花些時間用力去猜,考完後再去抗議也不遲。對了,請記得使用滑鼠不要用他們提供的滑鼠墊,根本滑不動,我用力滑了 20 幾題後才發現把滑鼠墊拿開直接在桌面移還比較順手。

OCUP 的考試算是 “black box”,不像國內已經考爛掉如 MCSE/MCSD, SCJP …等,有一堆考古題。全部沒有考古題! 甚至在官方網站也沒有提供範例題,你得要真槍實戰,真要對 UML 有些了解才能去考。

對了,除了還有兩個 level 的考試外,我打算下次先考 IBM Rational 的 UML 認證,它的題目就活很多了,我在 “Object Design” Forum 有看過其範例題,這好像比較對我的胃口,我喜歡題目長長的,然後考你的是需要思考在軟體設計應用面的,不要定義與語法,那是給 UML 工具廠商考的,一般軟體設計人員,根本沒必要花那麼多時間在這些無聊的術語與定義上。

相關參考資訊:
ˇOCUP Certification FAQ
ˇUML Superstructure Specification, v2.0
ˇOCUP Coverage Map(PDF)
ˇOCUP Exams Info

論 3P (Project, Package, Product)

國內從事 “企業(Enterprise)” 軟體的獨立開發廠商(ISV),大致可以分為三種營利的模式:

  • Project (專案)。
  • Package (套件)。
  • Product (產品)。

算起來,應該約有 80% 以上的開發廠商是以專案開發為主的(Project-based)。專案,顧名思義,會偏以滿足單一任務的工作性質,服務的對象也偏以單一的客戶為主,目的就在於能達成客戶對資訊系統的期望,而這些期望,也就是系統所提供的服務與功能—軟體開發廠商所負責承諾來實現,並換取實質的回饋報酬。

我們都知道,最為難的就是如何能滿足客戶的期望,因為,客戶的期望一直在變;又,競爭的因素,專案性質的資訊系統開發總是被要求在最短的時間,以最少的成本來完成,自然,種種不合理的要求,品質當然也就不佳。

請記得,開發端與客戶端是要能達成一種實質交易上的平衡,而開發端投入許多的心力與人力,來服務單一的客戶,卻換取開發端認為不合理的報酬,當然這種交易的結果也就無法讓雙方都能協調滿意的了。

只賣給一家客戶,即使開發 ERP 系統拿到 200 萬元,開發端都還認為是慘賠,因為人月的實質負擔實在不敷成本。一般專案性質的軟體開發總是存在一個根本問題:無法達成軟體的大量複製!

專案的規模除非夠 “肥”、專業領域夠 “精”,否則,對開發與客戶端都很難取得實質交易的平衡。我還記得,閱讀 XP (Extreme Programming) 的書籍,Kent beck,軟體業界的大師,所涉及參與的專案,諸如航空班機的控管系統,開發預算都是高達數千萬、數億美金以上,開發的週期要高達好幾年以上 …。我覺得,若要開發專案,作這種才有機會有實質的回饋、人生也會活得比較有成就感吧?

ERP 系統可否大量複製呢? 嗯,我們在世貿軟體展,可以看到國內許多的軟體廠商展出 ERP 系統的產品,可真便宜,數千至數萬就可以買到了。站在該軟體廠商的角度,活用軟體的大量複製,方向是對的,如此才有可能將成本壓低,才能服務眾多需要的客戶,售價自然也就可以大幅降低了。只可惜,這些 ERP 系統實在不能稱為產品(Product),最多最多,只能稱為套件(Package)而已。

套件與產品如何區別? 每一次我到軟體展時,遇到漂亮的展售小姐解說 ERP 功能時,我只會問一個問題:可不可以將 SQL Server 換成 MySQL? 幾乎一致的回答是不行。我還只是問實體平台的變更而已喔,還沒有問到,若我要求某一個 ERP 系統所沒有的功能或需要變更業務流程時,該如何客製化(Customize)呢?這問題我連問根本也不想問,因為可想而知,作不到!

套件的特性是,它提供了預先定義好的功能(pre-defined)給客戶,然後利用 “參數(parameters)”,讓客戶來自行 “微調” 系統功能;若是客戶單位要求的是套件沒有的功能、企業規則或企業流程的話,當然就要找原開發廠商,然後回到 “專案” 的型態來開發新的功能。

專案要作的是滿足客戶的需求,但期望客戶的需求變動不要太頻繁;套件則是提供預先定義好的需求給客戶,但其假設點是客戶的要求不多、規模不大(這也就是國內的 ERP 廠商的客戶鎖定在中小企業的原因)。兩者的根本問題是:彈性度不足,無法提供 Enterprise 層級的資訊系統,有效的客製化與變動性管理!

那麼,該具備什麼樣的特性才 “夠格” 稱之為 “產品(Product)” 呢? 答案就是理出專案與套件的共同問題:讓系統更有彈性!

為什麼客戶端需要更換資料庫系統與應用伺服平台? 因為成本、效能、穩定性等考量。
為什麼客戶端需要客製化? 因為需求就是一直持續性地變動。

即使有領域專家的協助、即使有超炫的使用者介面、即使提供的是更棒更完善的功能,這些仍是沒有用的,因為,客戶永遠都會有第 101 個意想不到的需求!

既然如此,就乾脆讓客戶端可以自行開發他們的需求,未嘗不可! 學學 MS 的 .NET Framework、Java 陣營的 J2EE Framework,以上兩者提供的是作業系統層級的框架(System-level frameworks),而開發如 ERP 產品,就是提供企業層級的框架(Business-level frameworks),讓開發者視需求的變動與要求,而在既有的基礎建設(Infrastructure)上,加工快速建置新的功能。

企業層級的 Framework,除了提供共用的資料庫、共用的企業流程,還要能提供白箱的 Open-APIs 與原始碼,以及黑箱的 “企業元件(Business Components)”,來供其客製化客戶單位的功能。難不難? 非常地困難! Business Framework 的設計與開發,需要能結合領域專家、軟體專家、與平台面的 IT 專家,共同合力協助,才有可能完成的。這也是為什麼國外頂級的 PDM((Product Data Management)產品與國內某些軟體公司所開發號稱的 PDM 產品,價格為何能差到數百萬元之多吧。

對了,Open-source 的許多企業層級的專案,可否稱之為產品? 個人是不以為然,還是無法到這樣的層次。但,Open-source 卻靠兩種方式,來達成如同產品的性質:

  • 頻繁的改版。
  • 提供原始程式碼(Source-codes)。

這是一種非常有意思與另類的作法,此時,軟體廠商反而不是賣產品,而改以提供 “服務(services)” 的方式來計價收費了。

軟體業有這麼難待嗎?

這個禮拜,有三位網友透過 msn 告訴我,他們要離職了;也有兩位網友告訴我他們打算離開軟體專業開發的領域,其中一位打算投入網路服務事業,我個人也衷心祝福並支持他能圓夢,不過,覺得可惜的是,這麼好的一個人才,軟體業竟然無法留住他?

其中一位女孩子,是 PM,認識她不到一年半的時間,好像已經換了 3~4 個工作。我問她,公司有那麼難待嗎?她的回答很有趣:不會啊,只是,所有的人都跑了,只剩我一個人,同時要接四個案子。又有另外一個說,工作上的前輩們很不錯,也會提攜後進,他覺得學到很多,但是,公司欠他兩個月薪水,不得已只好離開。

我也常碰到好幾個專案經理,經常需要換工作,待遇如何,嗯,有少數一、兩個有超過 6位數(月薪),但絕對是作得要死要活,為何要離開?負責的專案作不下去了,只好離開。而所遇到的軟體技術人員,除非待在外商或硬體業的 MIS 單位,否則很難超過6位數,而且,隨著年紀越大,會越不吃香,因為技術學習的能力會降低。

我在想,國內的軟體事業為何如此難待? 而且,隨著大陸這邊越強,國內的軟體專業人員會更難待,因為,專長並沒有互補,而是競爭,專案的管理與製程的管理是否會是互補? 我也覺得奇怪,代工業的模式是否適用於與大陸的合作呢?

大環境有問題? 政策有問題? 專業的定位與方向有問題?
硬體代工在國內是這麼地成功,也獨領風騷二十餘年了,但是,同時間發展的軟體事業,似乎沒有同步發展起來?

說真的,對軟體要沒有熱情,在這些大前提不佳的情況下,還真的不容易留在這個圈子裡,然後,要想辦法如何利用軟體的專業實現財富自由與求得幸福快樂的人生,看來是更難實現。

軟體思維顧問

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

Personal