我在網路上看了諸多評論「高鐵訂票系統」重複訂位相關問題的文章與討論串，大部分的 IT 人，謾罵聲不斷，認為該檢討承包系統開發的廠商；也有一小部份人提出自己的看法與建議的解決方案。這非常好，系統的不穩定性造成民眾的不便，本來就該有人監督，廠商也應該虛心接受眾多人所給予的建議。個人並不打算批判，以擔任軟體架構顧問的角度來看此事件時，先找出根本的問題是什麼，然後再提出具體的解決方案。我打算分兩篇文章論述，一篇為觀念篇；另一為實作篇。觀念部分，希望能就系統的結構性來探討；實作部分則會提出整個系統分析設計的過程與實作碼的產出，同時也打算模擬數千至數萬人同時訂票的情境與意外的處理，應該是盡量會接近原廠商所使用的平台(J2EE Solution)。當然，個人更是歡迎，若有機會，原廠商可以找我們過去聊聊，我們絕對很樂意效勞，也願意更進一步說明我們所診斷出來的問題，並且提供開出的處方為何。
一般看待高鐵訂票系統之所以出問題，原因有二：
- 經營者的看法與實際使用有落差：
持這種觀點的人，主要是著眼在經營者提出利用「飛機訂票系統」的觀念來實做高鐵的訂位，實際上並不恰當，飛機的訂位主要是預定「航班」，而實際的劃位則必須在各自的機場櫃臺進行Check-in，這與高鐵的座位預售，明顯有相當大的差距。 - 實做平台的考量上，未考慮到分散式交易：
這種看法大多是資訊專業人員的看法，也就是說，由於未考慮到各售票單位(包括櫃臺以及售票機)對於某一個已訂位的位置的交易，造成在同一時間內，多個售票單位可以販售同一個位置的現象，這主要是屬於「Transaction Lock」的問題。
事實上，這兩個問題都是存在的，然而，這卻不是造成高鐵訂票系統出問題的「主要原因」！ 無論是持哪種看法，其實都是「見樹不見林」，忽略了整體軟體設計最重要的核心 – 「軟體結構」的問題。
先從第一個觀點說起：
使用者需求本來就是會不斷地變動，然而，身為軟體設計人員，在開始進行系統分析設計時，本來就應該要想到「使用者需求」是「暫時」的，然而，重點應該是在於軟體結構本身，能不能夠充分地配合使用者需求的變動而有所彈性；因此，把系統出問題怪罪到使用者需求的變動，是軟體設計人員的「墮落」！
從上述的例子來說，使用者雖然在一開始就提出了不正確的需求，但是，當管理者在上線前一、兩個月就發現了這個「重複訂位」的問題，軟體設計人員卻沒有辦法在這段期間內修復這個問題，這很明顯地，並非是單純的「需求變動」而已，勢必是整體的軟體結構發生了大問題，造成了「地基不穩」，以致於「挖東牆補西牆」，永遠沒有辦法確實解決這個問題。
再從第二個觀點來看：
Transaction 的問題，其實是資訊系統管理面「最基本」的問題，套用前述的觀點，怎麼有可能在一、兩個月前發現這個問題，卻拖了一、兩個月都沒有辦法解決，這也很明顯地，勢必是在結構上出了嚴重的問題，以致於根本沒有辦法對症下藥。
那麼，軟體結構究竟是出了什麼問題呢？ 以下，我們就上述兩個現象分別來說明：
第一個現象主要是軟體的整體結構不夠穩定，而且缺乏彈性，因此，當使用者的「企業規則」(Business Rule)有所變動時，系統沒有辦法快速因應。
這很明顯地，是設計人員在設計系統時，並沒有針對企業的應用系統結構進行良好的分析，致使在捕捉系統的「本質性物件(Essential Object)」時，出了大問題。本質性物件沒有辦法捕捉好，自然而然對於整體系統的未來彈性，就很容易出嚴重的問題。什麼叫「本質性物件」呢？ 其實就是無論企業的作業流程(Process Flow)或是企業的使用者需求(User Requirement)如何變動，但是其基本的結構都不會輕易改變的那些重要概念(Essential Concept)，就是所謂的本質性物件。
我們以高鐵訂票系統為例，其本質性物件其實非常單純，我們以 UML 標準的 類別圖(ClassDiagram)來表達：
（點擊圖片鏈接看原圖）圖、高鐵訂購系統的核心結構
從這張圖中，其實就可以看出個端倪：
左下角的兩個物件：Seat 與 班次，主要是由高鐵人員自行維護的相關基本資料，然而，所有的重點應該在於「訂票交易」與「訂票Demand」這兩個物件上。
從訂票交易來說，其只要能夠提供起站及下車站給「訂票Demand」的物件，不管究竟是像飛機的依班次決定是否有空位；或是像現在高鐵實際營運的依特定座位決定是否有空位，其實，該訂票Demand物件只要回答「可不可以訂位」就可以了！
至於其實做的相關細節，應該都被隱藏在「Specific 班次」以及「SpecificSeat」兩個子型態(SubType)的物件中。
這樣設計的結構最大的好處是：
當我們發現未來高鐵的軟硬體設施真的如同飛機一樣，可以讓乘客先行訂位，之後才在各自搭乘的櫃臺進行「Check-in」以確認其真實的位置，此時，我們只要再重新「Plug-in」「Specific 班次」的物件到高鐵的訂票系統中就可以了！
至於第二個問題，則是整體 IT 結構規劃的問題。也就是說，由於沒有對整體的系統結構作一個有效的區分，而導致 系統面 與實際 問題領域(ProblemDomain) 面糾纏不清，大幅增加了整體應用系統的複雜度與管理成本。這個部分的問題，其實可以用 “Boundary-Control-Entity” 的 分析層次的設計框架 來予以解決。關於實作的相關設計議題，我們留待實作篇再來討論。
先前台灣IBM搞砸台灣高鐵的訂票系統, 我被公司外派過去替他們收爛攤的時候, 那些Marty Hsu、Simon Chen、Archer Hwang做不出來還每天都吠給一堆人聽, 說他們叫做IBMer如何怎樣, 都不做最後搞砸了整套系統, 還把責任亂推, 為了要封我嘴還找全勝文化、凌群、水啟動、耐特普羅的人來圍事, 才被我把他們最後簽收的文件、函給影印寄給一大堆公司、國內外政府, 比如 :
院首長電子民意信箱答復第100002246號
您好：台端陳述意見，本部已錄案參處。感謝您的來信。
部長 毛治國
如有任何疑問請回信至以下信箱：交通部民意信箱並可點選下方連結針對該陳情案填寫滿意度調查表：
http://pub.motc.gov.tw/public/intereyes/eyes00ee.nsf/0/6652258BF977F6274825785300305752?editdocument
我不清楚台灣的IT軟體業有什麼資格對著我這個非IT軟體工程師大放厥詞的, 反正現在都已經寄到不知道哪些國外機構政府去了, 就看台灣人的IT軟體業叫做什麼臉!!!
Hi, 您太激動了些，我也不太清楚您想表達的是？ !^^
Hello Chen Youn Nan:
我是不會去區分何謂業務 or 技術；理論 or 實務的，真理是在哪裡，就看我們怎麼去認識、體認它而已。
學品管、學 CMMI/PMP 等，我更會憂心，因為軟體的那個 “根本” 都越來越少人重視啦，而反而從管理著手？ 這不是很奇怪嗎？
Hello Kenming Wang：
真巧剛好有個女兒也讀小四,也很愛美術,射手座人緣好.
首先要感謝貴公司勇於提供許多資訊,讓我獲益良多,也要跟Wang老師承認,我是壞學生,觀念仍停留在上一代LKK的”結構式分析設計”.
所以UML等到現在都只局限畫看看,沒有實際運用,去年我也購買EA6.1,但就是沒去用,真的很對不起!
我原本計劃要學UML課程,今年先去上東海大學張文貴教授的”軟體專案核心技術文件”兩天,發覺自己欠缺更多軟體專業知識,依舊不會寫文件,
於是9月就參加26期的軟體品質保證師課程(SQA),發現同學不到12個,老師都感到台灣軟體界沒希望.
許多非常優秀的講師都飛到大陸去當講師,門庭若市滿坑滿谷的學員.學CMMI,學PMP,學SE一大堆.
祈望自己明年能順利考到生平第一張軟體品保師執照,好好救一救我們公司,不過課程中也沒有教如何寫文件.
知道有PMP/SDP/SRS/SDD/SQA/STP/SUM/STR….以及IEEE XXXX 與ISO….的龐大規範!還真難.
我並非技術出身,而是軟體業務(當年被許多同仁瞧不起的Sale),加上多年公司管理的失敗經驗,目前仍舊在努力學習中.
[以下是我們公司最近要去臺北醫學院某場次演講的大綱,供應平台是由”慧智達”公司設計 ]
預定2007/12/09發表,我代表公司支持慧智達公司產品與服務,同時更希望政府能大力參與並支持開發者的立場.
我的主題是:”社區藥局的資訊管理”,以我個人的內容公怖給後輩優秀的軟體從業人員,祈望能對台灣軟體業保持希望,
軟體產品能更上一層樓.
————————————————————————————————————————————————-
“社區藥局藥品供應平台及最佳服務模式試辦計劃成果發表會”-2007/12/09 下午3:00-先勁陳勇男經理發表”社區藥局的資訊管理” 大綱
壹.前言
感謝廖處長,王處長,王理事長,在座藥業前輩先進,讓我們先勁公司有機會參與這次成果發表會,同時也祝福試辦計劃能持續發展與擴大影響力,
幫助更多藥局與用戶達成計劃最終目標.
貳.先勁簡介
先勁公司成立於1996年,主要客戶以國內連鎖藥局,社區藥局為主,客戶群達1千餘家,遍佈台灣本島與金門澎湖.
自我介紹:
1991年當國喬電腦公司軟體銷售業務/主任/副理
1993年到龍王科技業務部當經理,推銷當時最熱門的通關自動化報關系統
1994年離職,當年又結婚,到處打工.
1995年母親生病住院,每天都在醫院照顧順便寫程式,進而成立個人工作室,第一個月營業額2840元賣出一張電腦辦公桌,
一年只賣兩套軟體共9萬多元收入,老婆在外當會計小姐月薪1萬8,養我一年.母親年底過逝.
1996年3月成立先勁資訊有限公司,年底客戶數超過百家
2007年客戶數已達千家
最慘的一次在2000年網際網路泡沫化,員工相繼離開,解散一家網路公司,借錢度日,好不容易苦撐過來.
參.市場現狀
1.傳統藥房逐漸淘汰,現代化藥局經營模式掘出.
2.重視藥師專業領域與企業管理.
3.以大吃小,以快吃慢,藥業財團化.
4.違反商業或道德,游走法律邊緣中南部地下電台與非法藥品.
5.藥師法規與健保問題,強烈影響藥局生計.
肆.資訊管理的角色
1.目前社區藥局的資訊管理開發商超過10家,搶食5000家藥局中的3000家(2000家仍未電腦化).
2.資訊系統以三大功能為主,分別為庫存,門市銷售,健保申報.
3.資訊系統演進早期以正確(庫存,毛利,營業額)為主,進化到精確(分析周轉率,目標達成率),到策略性RFM/CRM/最優化模式or 即時反應系統.
4.資訊系統要滿足使用者或老闆,進而服務顧客會員,金錢防弊預防員工犯罪,更高層次為協助增加藥師專業減少藥害,為社區民眾用藥安全把關.
5.資訊系統品質與服務,以ISO的PDCA為政策,重視軟體工程與風險,有永續經營的態度,用最高道德為用戶把關.
肆.願景
1.金門823砲戰之後,有一位服役在軍醫院的藥師,在太陽下山前用力地踩著腳踏車,急忙對巷弄的門牌號碼,一心一意要把中午醫官開錯劑量的患者找出來,免得出人命.
2.2003年的桃園某家地區醫院當月有個糊塗的藥師連續在一個月內包錯藥給3個患者,害老闆買水果出面道歉,嚇得在半年內結束藥局外包營業.
3.2007年更O醫院醫師給小孩用藥開錯劑量,超過N倍,讓醫院院長親自招開記者會道歉.
4.2007年11月,桃園某藥局,使用先勁系統,在調劑完印藥袋前,2微秒內畫面出現”藥品交互作用2級警告”,藥師印出要求患者至診所投訴改藥,免得出人命.
資訊系統願景是要學習英國,早已在2000年左右,在醫師與藥師的操作系統上加上專業的藥物調劑警示系統,經由年齡,體重,溫度,身份(小孩/孕婦/老人),藥品交互作用等,
成功把開錯藥,開錯劑量,包錯藥等錯誤率降至最低.而且有經費不斷改良精進.
肆.建言
1.希望政府相關單位不同計劃(一致性)能夠服務最終顧客,即是民眾.
2.開放醫療藥業資訊系統或資料庫等專案申請,以利專業開發公司能夠協助政府服務最終顧客,即是民眾.例如:藥品交互作用資料/藥袋警語外觀等網站資源.
3.把資訊服務另外給予相關業者實質或實際獎勵措施,讓業者能更投入更多資源與資金,為藥業服務.
Hello Chen Youn Nan：
正因為個人相當注重軟體的品質，甚至我可能比一般人重視的程度還更甚者呢。
也因為如此，我才花了如此多的時間花在軟體結構的設計思考上—它正是影響軟體品質的最根本所在。但因為它是隱性，使得軟體人員，包括 PM，看不出它的精髓，而以為影響軟體品質好壞在於專案管理上。
對於什麼是架構、結構，設計文件、專案管理等議題，個人倒是也有一番研究，若您有興趣，我倒是很願意與擔任資深系統開發的您交換心得。 畢竟，我們應該理念都是一樣的—軟體的滿意度與品質有關，個人深表贊同的。而這也是我為什麼花了如此多的時間在架構、結構等設計思考上。可惜，一般系統分析與專案管理者對此知之甚微，這要花上太多時間來研究、學習、體悟等，業界太過重視速食文化了，包括一般表象專案管理。
您真的有興趣討論此議題，真的我很樂意與您見面與您討論的，甚至，若有貴單位可以提出的系統分析或者您所提的承包商品保設計文件等，我倒是可以提供一些看法的，我想我應該分辨得出該設計文件的假設點、好壞甚而真偽的。
非討論空談而已，若您認為我這邊是可以經過 “Certified” ，當然，見面對談就可以得知這一點的。我更是樂意有機會能與您一起合作的，我相信，既然我們都重視品質的話，應該是能開發出高品質的系統。 🙂
高鐵的售票系統另一面見解:
聽說當初高鐵歐洲顧問公司要求高鐵的售票系統承包廠商,要寫許多文件,其中包括{軟體品質保證計劃書 },
但該公司外包給國內某家顧問公司撰寫英文版的品保書,所以歐洲顧問很滿意這份品保計劃書,首先第一個通過,
接下來國內顧問公司問高鐵的售票系統承包廠商是否要導入此軟體品保流程,卻被高層拒絕!
敝人開發系統長達13年之久,一直在追求最新的技術與架構,最新才去上軟體品質保證的課程,
發現過去常常因為時程問題趕工,沒有留下必要的文件,沒有充分的測試,更沒有品質計畫….,
讓bug一直存在且曾經造成3套軟體上市失敗,讓公司損失金額達五六百萬,產品推出時間延宕長達3年,
由此可見軟體開發不僅是技術或架構層次,也是軟體工程所謂:品質成本,當預防成本與鑑定成本=0,則將來的失敗成本就是個災難!
您的見解也許專注在技術面,但是忽略一點,軟體的設計仍然忽略不了品質,高鐵的問題,損失的金額應該超過千萬以上,
如果您是老闆,或是高層主管是否更需知道,軟體的滿意度是跟品質有關.
網路訂票爛透了
不知怎麼能弄到這麼爛
同樣是網路訂票
台鐵的系統用起來順暢人性
這個高鐵真不知如何去形容
訂了半個多鐘頭都顯示系統忙碌
要這些人幹什麼???
還不如給國家省點錢算了!!!!!!!!!!!!!!!!!
I will be there.
http://sourceforge.net/forum/forum.php?forum_id=629818
Welcome Adempiere Multi-Language forum…
Chinese forum
Please google key word
[Sourcefroge][Adempiere]
sourceforge.net/projects/adempiere
我們是Sourcefroge中最閃耀的開放源碼專案
Then chek forum Language chinese
這是我們JavaBase SOA-ERP/CRM 的家
全球視野的溫馨小館
我們有十多國的語系
歡迎你共同探討
熱烈歡迎
StevenChen 大師
管理科學在資訊應用領域
哲學家
亞伯.陳
敬上
SourceForge.net: ADempiere Bazaar-
Adempiere is an ERP Bazaar for Open Source Developers that contribute improvements of Compiere, CRM, Shopfloor, POS, Helpdesk, Financials Accounting, Supply Chain, Knowledge and Business apps in an open and unabated fashion. …