資訊 - 高鐵售票程式一團亂 誰的責任？

[snoopy]

http://taiwan.cnet.com/enterprise/co...0115201,00.htm

杜奕鋒　　2007/02/15

高鐵車售票系統的問題在網路上引發熱烈討論（例如：JavaWorld），其中又以批評多過讚美。其中最讓人詬病的是，高鐵竟出現一個位子被賣三次的事，讓排了一二個小時買到票的乘客氣得冒煙。

對我們這一些稍有經驗的工程黑手而言，真的是不太能接受，這也令我想到在學校教書教到設計或撰寫多人同時線上使用的系統的時候，常碰到一些即使耳提面命，沒經驗的學生還是會犯的錯。所以看到「高鐵車票連三買」的新聞時，第一個反應就是：「呵，這是一個很好的Case Study…」特別是對於學校的那一群學生們，他們總是喜歡用「一人使用系統的程式撰寫習慣」來撰寫「多人同時使用系統的程式」，高鐵的例子，剛好提醒他們這樣搞的下場。

就像任何IT專案一樣，要追究高鐵訂票系統的責任，也可以從三方面來追究：程式設計／開發人員、測試人員、以及專案經理。

系統設計人員與技術人員的責任？

首先，就資料庫層面而言，通常在做資料庫的規劃與分析的時候，對於某些形成「惟一值」的欄位，資料庫的schema 設計者就應該利用資料庫的機制(Unique Key)將之限制，這是從資料庫層面所做的保護機制，可以避免程式人員的疏失而造成資料混亂的現像。

以車票的劃位為例，理論上，每一天的同一班列車上相同的一個位子只會買一次，因此，「日期」加「車次」再加「位子」應該是那個惟一值，在高鐵售票系統的資料庫中，這樣一個組合就應該把資料庫中的Unique Key設起來。當然，高鐵售票系統中的表格情況會是更加複雜，但如果沒有找到一個規範，從資料庫的來進行資料的保護，就很容易造成目前這樣一位三賣的情況。

再來，就是程式開發的部份，寫過多人同時使用的系統都會知道，這樣的系統經常要去處理資源所有權的問題。以高鐵的座位為例，在座位還沒有賣出去的時候，這個座位是不隸屬任何人的。當有買家出現時，通常會先做系統做一次查詢的動作，把所有的未銷售的動作列出來，此時列表當下所有被列出來的車位應該都是沒有隸屬者的。不過由於列表與買家下單購買的時間是有時間差的，所以買家決定購買的同時，該車位有可能已經被其家的買家買走了。

所以程式人員在設計或撰寫這段程式的時候，理論上，程式行為應該在買家下單的同時先立即檢查該車位的是否已經被賣走了，如果沒有被買走，程式才可以下單；如果已經被買走了，程式就應該反應給買家一個錯誤訊息：「對不起，所選擇的座位已經在您猶豫不決、拖拖拉拉的過程中被買走了…」。

因此，高鐵車票會一個位子賣到三次，如果猜測沒有錯的話，問題應該是就出在最後買家下單的那一支程式上面，當買家下單時，那隻程式並沒有去檢查（或檢查的邏輯有問題）車位是不是已經被賣走了。所以在購買人潮多的時候，同一個時間點，有多個人進行車位的列表（列表的時候，反正那一個位子還沒有被買走，所以都統統列出來了），後來這些人又選買了同一個位子（加上這個程式在下單的時候沒有去檢查），所以這些人就在高鐵售票系統的搓和下，修得了百年才有機會同位的因緣。

當然售票系統是有可能還有其它的問題。不過如果上述兩個問題在系統設計與開發的時候有注意到，理論上，不論採用什麼架構、技術或介面（Web、人工售票機、自動售票機…），甚至銷售作業流程被改變了，一個座位被買了三次以上的情況應不致發生，因為不論是那個購買者透過任何的UI介面來下單，檢查位子是否有已經被賣出的程式都會是最後防線。

當然還有一種情況，就是在資訊流程上，下單的資料還沒有透過這支檢查的程式塞到資料庫中時，系統就已經把票列印給客戶。但是這種情況不太常見，因為如果這樣子設計，已經列印給客戶的車票是有可能發生沒有被塞到資料庫內的情形。如此，最慘的情況就是高鐵系統售票系統的帳務資料可能會有問題。

高鐵車位連三賣的問題，第一個要去面對責任的就是這一些資料庫系統、系統設計、以及程式撰寫等技術人員。

修改範本不適合？

有小道消息指出，售票系統是機票系統改的。我並不太確這樣這的消息來源是否正確，不過，基本上我對這點抱持質疑，因為兩者商業行為的作業流程是大不相同的。首先，一班飛機的座位有限，也不像高鐵可能會有站票的情況產生，再加上購票的流程中，機票並不是在購買的當下就將座位劃位給旅客，而是在登機的時候才進行劃位。因此在銷售機票過程中，系統只需要掌握所銷售的機票數量不要超過有限座位的數量即可（而且據我所知，大部份的飛機在機票銷售的時候都還是會預留一些座位，以便不時之需）。同時，由於登機櫃檯人員並不會太多，因此負責同一班機劃位的人員作業上較容易協商（幾個劃位櫃台橋一下就好了），比較不容易有重複劃位的情況產生，即使真的重複劃了位，由於旅客的總量是不可能多於座位的數量，所以比較容易立即幫旅客找到座位。

高鐵的情況不同，高鐵的載客量大（每台波音七四七的載量也大概才400個人），售票的方式也比較多元，例如自動售票機（呵，我們大概不可能買機票還用自動售票機買票吧？），並且停駛的車站也多（大概很難找到一架飛機在飛往目的地的途中有六個停駛站的，更不用說，這一些站都會有乘客上下），所以如果高鐵的售票系統是採用機票的售票系統來改的，那這一個售票系統勢必會需要做大幅度—而且很大--調整、重新分析，並逐一改寫。寫過程式的人，或多或少都會知道，與其要Programer改別人寫的程式，說不定自己重寫一個還比較快。

當然，還是有可能有一些因素（商業、政冶因素……）造成這個售票系統是用飛機的售票系統來改的，但即使是這個樣子，在修改系統範本的過程中，稍有經驗的系統分析師或程式撰寫者應該都很容易發現這些系統需求上的差異。重新分析需求、修改架構，適時地給客戶建議，並調整系統到可用，避免這種一位賣到三次的情況。(請繼續閱讀下一頁)

[snoopy]

高鐵售票程式一團亂 誰的責任？


沒有測試到嗎？

不論系統是改別人的、還自己開發的、大包商負責的、還是小包商負責的、老鳥設計撰寫、或是菜鳥設計撰寫的，理論上，在系統上線前應該會經歷一連串的測試。主要分成系統開發時以及上線前的測試：每一個小模組修改或撰寫完的時候，程式設計師會針對自己所撰寫或所修改的程式來進行測試；一堆模組撰寫或修改完成並且組合後，系統分析師就會介入測試這些模組組合在一起後是不是有問題需要被調整。最後，當整個系統完成後還會有幾次的壓力測試。


基本上系統廠商為了保障自己的商譽，所以自己內部可以會先針對系統的弱點（因為系統是自己設計的，所以自己會比較清楚弱點在那邊）進行壓力測試。等到一切都沒有問題了，才會把系統交付到客戶的手中，再依客戶所提的需求來進行壓力測試。


經過了這麼多的測試，沒有測出系統重複給位的問題，這是誰的問題？首當其衝的，高鐵應該要負第一個責任，但說老實話，我不覺得高鐵的責任最大，User之所以為User就是因為他沒有能力成為Developer。或者換一個角度來說，高鐵的主力應該是focus在他在高速鐵路的經營管理上面，這才是他們的專業。因此系統維運應該是高鐵系統技術部門的責任，但談到系統開發，他們沒有那麼熟悉倒是可以被接受的。


「測試」是系統開發中重要的一環，個人設計撰寫的程式，都免不了要自己先小測一下；而多人共同開發的系統程式，測試就更不可或缺，以避免初期規劃上的瑕疵。不過，測試的廣度與深度會隨著測試者本身的經驗有很大差異；同樣的系統、同樣不是自己撰寫的程式，有些測試者沒有辦法發現系統中的漏洞，可是較有經驗的測試者往往一測就可以抓出一些罕為人知的問題。


台灣的系統廠商有時候會很不重視這一個測試這一個環節，因為「測試」本身看起來並不具生產力，所以往往是程式寫完了就直接丟給使用者去測，但不幸的，使用者並不一定十分了解這一個系統規劃，因此測試的時候，也頂多UI（User interface，使用者操作介面）測一測看有沒有順就好了，至於系統運作上的盲點，一般的使用者是沒有能力去測的。




所以問題還是回歸到系統開發廠商身上，測試人員是否有足夠的經驗來規劃及進行系統全面性的測試？還是他們只是跟一般的使用者一樣，使用者介面測一測就放行了呢？如果真的測得夠深入，方式也夠全面，那為什麼會有重複劃位的情況產生呢？我想台鐵售票系統這個案例不只在系統設計與開發上是一個好的提醒，也在「測試」的這一件事上是一個好的教案。


是故，談到高鐵售票系統的測試，ㄟ…我相信高鐵人員應該是有測過，也應該對UI做了很多調整—所以他們才可以在維運後，很順利地操作系統、很用力地賣票，甚至連賣出重複劃位（而且還劃了三次）的票還渾然不知。


只不過，開發廠商的測試人員可能也對會有話要說：「…專案經理交待的測試我都做了啊！…」


專案經理的責任？


專案管理中，專案規格確認與風險掌握是專案成敗的關鍵因素。所以理論上，在專案規格的部份，專案經理或多或少會參與系統分析師的作業以確保規格上沒有瑕疵；而在風險管理的部份，專案經理應該盡可能地把可能造成風險的例外狀態的預想出來，以做好風險的管理，必要時透過測試的規劃以減少例外狀況的產生。


那高鐵售票系統的「一位三賣」算是「例外」還是「常態」呢？這就是這一個案例有意思的地方。售票系統「一個位子不可以賣三次」這個規範，對於老經驗的技術人員而言根本是 common sence ，所以有可能不會在規格(spec.)上特別去規範，對風險管理與測試規劃的部份，因為是「common sence」所以理論上它是一個「常態」，因此具有規劃經驗的專案經理應該不會把這樣的「常態」條列在風險管理之中。


這個案子很「神」的地方就在於一般被認為是「常態」卻成了「例外」。不過，如果專案經理的經驗夠豐富，一開參與軟體規格制定的時候，他就會事先意識到這樣的問題，所以即使是視為「common sence」而沒有特別定義在文件中，也會利用先前的規格制訂作業或之後的壓力測試來把這個問題突顯出來。


在什麼樣的情況，專案經理會沒有注意到這些問題呢？第一種、在專案經理過度信任系統設計、開發、測試人員。第二種就是專案經理其實沒有足夠的軟體開發專業知識或經驗以至於他有足夠的敏感度來「發現」這個問題。我不是很確定高鐵售票系統的開發廠商所面臨的是什麼樣的難處，不過，上述的第二種情況是滿值得被探討的。 （未完，請繼續最後一頁）

[snoopy]

假設一個專案經理沒有軟體開發實作的專業技術與知識（或許他的專業經驗是在硬體建置上），但他很擅長人際溝通，懂得時程安排，也很會做文件，也有PMP的証照。請問這種專案經理可以把軟體專案帶好嗎？我個人覺得這是有待商榷的。或許他可以安排時間（不過，這個秘書也可以做）、也或許他很會做文件（一個專業編輯會做得比他好），但在軟體技術上有需要去決策或協調的時候，他有辦法在從技術的角度成為大家溝通或協調嗎？當然，就更不用談去「發現」隱藏在專案背後的風險了！如果他所帶是一個很有實力的團隊，那他或許可以做得很好，因為在技術上，這些團隊的成員可以成為他的支柱。反之，如果他的技術團隊技術不甚高明，甚至沒有經驗，那相對地，他的專案品質也會相對的下降。


沒有技術的深度與經驗來配合，而只仰賴以溝通、協調與文件撰寫能力來管理專案的專案經理會是我所擔心的。然而這卻是台灣資訊業的普遍現象，沒有人願意做黑手工程師，大家都想去做專案經理，聽說有家公司，剛畢業的學生就可以做專案經理的，甚至還聽說，因為工程師很怕搞技術，所以讓他轉成打雜的專案經理（那時候，還是菜鳥工程師的我真的恨不得昭告世人說我是一個很遜的工程師）。他們並不一定沒有辦法勝任，而是他們往往不能發現隱藏在專案後面的風險。


人員的素質才是關鍵


就我所知，負責開發高鐵售票系統的系統廠商有通過CMMI認證。哇，這樣不是讓CMMI或PMP權威性遭到質疑？我並不是確定是否完全照表操課，專案經理妥善使用PMP中所提到的技術，並且完全遵照CMMI來完成整個系統的開發。不過，不論有沒有，依目前的情況，說CMMI或PMP是用來唬人騙錢是不公平的。舉個例子，飛機起飛的時候，理論都會有一個起飛的標準流程，但如果起飛失敗了，我們可以說是那個標準流程有問題嗎？


當然標準流程是有可能會被修正，不過，飛機起飛的失敗，有可能是天候因素、也有可能是飛機跑道有異常狀況、甚至是機場塔台的錯誤資訊等因素所造成的。其中，往往「飛行員」才是成功起飛與否的關鍵。好的飛行員在惡劣的環境下，他仍然會有機會成功飛上天空，而經驗比較不足的飛行員則可能因著一點其它外在的因素就起飛失敗。但我們並不會說這次的起飛失敗是因為標準流程的問題。


我無意為CMMI或PMP辯護，不過CMMI或PMP有能力規範的應該是在流程及管理層面的事物，規範出好的流程與溝通模式以方便大家做事。但有些東西本來就很難規範，例如：工程師與系統分析師的經驗值、或者測試人員與專案經理的深度。


所以，高鐵車位連三賣的事情，我不覺得它可以說明CMMI行不通或者証明開發廠商沒有照表操課。因為有可能該廠商真的乖乖地每一個流程都跑過了，但就是他們的人員在經驗上可能比較缺乏這種多人使用系統開發的經驗，再加上測試人員沒有想到這方面的問題，而疏忽這個細節才引發這場烏龍事件。


不過，高鐵這個案例倒提醒了我們另外一件事：不要太迷信CMMI或PMP--好的人員素質才是成功的關鍵。想想看，同樣在CMMI的流程規範下，如果換上另外一組比較有經驗的技術人員？測試人員？或者專案經理呢？或許就會是另一個故事了。從上述的討論中，我們會發現，技術人員、測試人員以及專案經理三者之一，只要其中之一（其它兩者都可以不需要）有意識到這問題，其本上就不會有「一位三賣」的情況了。