為避免誤解，我要先聲明，我和神通公司沒商業往來，也沒有利益關係。之所以提出不同的看法，單純是因為在搭乘高鐵的過程中，我認知到高鐵公司的整體管理問題可能比目前所呈現出來的軟體問題更為嚴重，因而想提出不同的觀點，寄望對於這個問題的討論，有機會更深入，也希望對於導入CMMI能否對軟體的品質及專案的績效，能夠有不同方向的討論。

對於TVBS所報導的現象，我同意是存在的，也的確是問題。在思考這個問題的時候，我試著利用CMMI中的一些實做要求，推導高鐵售票系統開發過程的可能限制和問題，希望有機會如果是由我們發展類似高鐵這樣複雜專案時，我們可以不要重蹈覆轍。

在CMMI的Model中，指引許多在進行需求收集和發展時，可以考慮的一些實做方法，包括採用技術展示、專案期中審查、系統雛形、採用問卷進行資料收集等方法，收集、引導及發展顧客需求。以高鐵案的售票系統為例，如果採用CMMI所提供的參考實做方法來收集需求資料，可能會有以下這幾種情況：
1. 顧客（高鐵）完全不知道售票系統的定位，因此在開發這套系統時只要求滿足售票系統的功能性需求，在使用者無明確的操作需求下，系統很可能發展出來後，卻很難使用。
2. 顧客有其他比操作性需求要求更高的需求，例如成本考量、系統安全（付款機制）、發展時程（儘快上線）、技術限制（不管選用歐系或是日系的系統，都會有技術限制），當售票系統進行需求發展和軟體設計時，有關於操作性的需求，便不在優先考量的範圍，系統難以操作也就不足為奇。
3. 在進行售票系統開發時，顧客並沒有要求服務提供者（神通）以顧客（高鐵）以外的最終使用者為需求收集及訪談的對象，單純只是收集來自顧客的需求，因此雖然採取許多CMMI所建議的一些實做方法，由於訪談對象不是最終使用者，造成系統和使用者的需求有差異，也屬正常。
4. 顧客要求神通公司納入一定比例的使用者最為訪談的對象，以作為建立操作性求的依據，神通公司在執行這向活動時，產生專案管理、需求訪談及分析、軟體設計的問題，使得系統完全不符合使用者的要求。

以上所推論的幾種情況，也許是實際發展過程中的現象，也許不是，畢竟只是推論。影響軟體品質的因素有許多構面，軟體開發商的技術及管理能力只是當中的一部分。由於我們都沒有參與這個專案，也只能從外面報導的資訊來探討背後可能的因素。以高鐵案建置過程中，發生的許多問題，包括預算超支、用地取得、時程延遲、通車過程的履勘不過等問題，如果再加上政商間的競爭和合作關係（例如高鐵的部份系統由歐系改為日系），我個人認為一個軟體開發商要在其中扮演好角色，難度本來就很高，如果神通公司沒有導入CMMI，也許情況會更糟。

----------------
台灣應用軟件府份有限公司 葉顯榮

www.tasc.tw