龐巴迪正努力於修改內湖線的軟體，捷運局也表示事涉對方商業機密所以無從了解。

捷運局陳椿亮表示，龐巴迪提出的改善方案，有些在每天電聯車夜間收班後進行，有些需要較長時間修改與測試；龐巴迪已感受到台北市民的不耐與責難，關鍵軟體版本已修正，希望能提升系統運轉的穩定度。
捷運公司副總經理沈志藏表示，軟體版本修正後，要跑久一點才知問題是否再出現，約一周就知道效果，時間短看不出問題，整個自動控制系統要慢慢調。
　陳椿亮表示，軟體修正牽涉商業機密，都是龐巴迪人員自己動手，捷運局與捷運公司人員只學到皮毛。

但依據CSQA所公佈的國際上通過CMMI評鑑家數所知，台灣在2008年8月共計通過88家，位居世界第7名，加拿大共計通過43家，位居世界第14名，我門的能力遠在加拿大之上，為何國內業者不自行開發新版捷運控制系統軟體，除可解決內湖線的問題，甚至於可外銷全世界。

Joker兄的想法很有創意，問題是台灣88家通過CMMI的廠商是否能捫心自問一下，工程能力是否真的提升了？初次通過CMMI ML3，只能代表形式上的"制度"有了吧，至於品質與工程能力真的有提升，應該是一段時間(至少兩年)之後再來個複評，而且是有延續性的，比較剛取得認證時到兩年之後的期間，是不是真的成長了、品質真的一次做的比上一次好，還是仍舊有一搭沒一搭，客戶要求了才做，客戶不要求，文件連寫都不寫。如果是這等水準，恐怕還是走不出國際吧。Joker想點評的應該是這個吧。

也許編程人員及軟體工程人員的技術能力夠強，但是人員的基本素養不夠才是最大的問題。

也許在我們的資訊軟體從業人員裡，有些人聽過IEEE有本SWEBOK Guide (Software Engineering Body of Knowledge Guide)，這本Guide現在也成為ISO的標準；這本指引收錄了一個軟體工程師，在大學四年畢業並有四年工作經驗後，應該具備之知識領域(KA)的知識(本指引共202頁)，本指引的1個KA指向的知識體系參考資料大約共有5500頁(每個KA有500頁，這是當初寫作該指引時下的限定，其實有些KA的材料不只500頁)(四年的正統教育+四年工作經驗+所有KA參考材料的知識+道德與倫理的考核，才能真正成為一個專業的"軟體工程師")。問題是，現在這11知識領域的知識具備的人有多少？可能就連"軟體需求"這個知識領域裡的知識都不夠充足，更不用提軟體設計KA與軟體建構(Software construction)KA，都有類似的問題。這樣的話，即使取得了CMMI ML5都不太可能進入國際市場，並帶入商機。

或許，除了導入CMMI之外，我們的軟體工程人員，也該好好從編程工、或資訊軟體工，提升至專業的軟體工程"師"才行。

----------------
引文:

台北市近年來在南港軟體園區或是市區內見到日益增多的印度人，在天母地區甚至於增加了數家印度餐廳，應該是拜藉由CMMI取得全球軟體委外市場的印度軟體工程師駐台工作人員日增所致。理論上排名全球CMMI第7的台灣，也應該在世界上相當多的國家提供類似印度軟體工程師的境外服務的機會，但似乎從未聽過有類似的新聞；依排名而論，台灣也應該有能力作出比排名第14的加拿大品質更佳的軟體系統。因此才會構想出政府何不藉內湖線的機會讓國內具CMMI 的業者，設計自有版本的捷運控制系統，既可解決系統問題又可向世界展示Made in Taiwan的實力。

但由其他專家所提供的反應以及由網路蒐尋所知，不禁要問：
難道排名第7的台灣真的與排名第3的印度會有如此的差距?
難道排名第7的台灣做不出比第14的加拿大更佳的產品?

國內自92年開始即有數家公司取得了CMMI的認證，但近日上網搜尋大部分取得CMMI認證的上市公司，股價並未如一般所知因為CMMI可大幅提升品質之下，讓公司營業額大增、股利增加、股價增加的預期效應。但在數家公司的經驗分享，卻又都出現令人驚艷的效益。
究竟CMMI帶給國內產業哪些效益?
政府輔導部門是否有真正去調查？或是
僅任由輔導公司藉此取得國內的商機(政府的輔導補助金)，卻讓國內的業者進不了國際市場。每一家取得CMMI證照的公司，似乎都是以政府的標案為主，鮮少有國際客戶（印象中近年來僅有2個國際案例）。甚至於要懷疑國內的廠家能否依據ieee-1012寫出英文版的VVP文件?國內有專業的代寫中文版CMMI文件顧問公司，但國際上未曾聽說有專業代寫文件的顧問公司，這也可能是CMMI-for-Taiwan的獨特產業。

如果真的如Rockman99所言“台灣88家通過CMMI的廠商是否能捫心自問一下，工程能力是否真的提升了？”，可能真的是出乎我預期的情境，難道台灣的CMMI與世界的CMMI有GAP？政府推動單位應對於CMMI體系，進行客觀的效益評估了。
如果推動一項政策無助於品質的提升，倒不如放棄此項政策，否則只是增加廠家的支出。

如果你是一家CMMI Level 2以上的公司，且國外有客戶決定委託你發展類似捷運號誌控制系統，請問你是否有能力撰寫一份英文版的Project Management Plan、Verification and Validation Plan、Configuration Management Plan、Software Requirements Plan、Risk Management Plan、…..。
如果你是國內輔導CMMI的LA，請問你是否寫過上述文件？

捷運系統的問題不純為軟體，其多半屬"系統工程"領域，要(較低端的)軟體業來承擔未免太沉重。

舉個例，捷運系統裡有太多的控制工程(Control Engineering)領域該處理的事(例如速率控制、煞車)...得先解決了(例如速率控制、煞車的)控制技術問題，才能讓軟體(如果有的話)幫你去實作，此時才有所謂"軟體工程"的問題.....現代系統是有許多軟體(且佔去大半)，然吾人並不能因為軟體的比例高而把問題全賴給軟體

控制工程解決不了的(速度控制)問題(哪怕只是調整系統參數)，休想靠"強而有力"的軟體工程幫你擦屁股....

引文:

您的這串問題似乎有點"問題"

首先，捷運號誌控制系統的業主，並不一定會要求承包者執行V&V，事實上，過去許多的系統籌獲案顯示，V&V往往不會交由系統承包者負責

和FCA/PCA類似，在還沒有軟體工程/CMM/CMMI的年代便已有許多系統之籌獲案有V&V工作...

其次，Software Requirements Plan是個很奇怪的東西
是不是請您重新定義一下那是啥？

再者， Project Management Plan(PMP)、Configuration Management Plan(CMP)以及Risk Management Plan(RMP)其實是可以整合成一份(交付文件)的

若以其中的Risk Management 言，多年前已有學者針對北捷的RM進行相當深入的研究並有論文發表

上述諸工作(如CM)，會做的自然就會寫Plan，PM、CM、RM都屬管理，可併成管理計畫書；而V&V偏工程，可單獨出Plan，亦可併入工程的管理計畫書