捷運內湖線的問題不到一天之內就確定可由電源雙迴路方式解決。為何當初設計時並未考量雙迴路的設計?請問如果要對應到CMMI領域，應屬於何項PA?如果捷運局具備有CMMI-ACQ Level 5以及龐巴迪也具備CMMI-DEV Level 5是否就可避開此次UPS燒毀之情事發生?

的確，如果該問題在發生一天之內就可以找到解決方案，那麼顯然這個問題就不應該會發生！

而如果要從CMMI的角度來看這個問題，雙方並不需要俱備CMMI ML5，而是，只要是ML3以上的公司，都應該要有避免這些問題發生的能力。CMMI ML3的RD、TS、RSKM及DAR等等這些PA，在系統發展上，是具有指導的作用沒錯，但是，就算沒有CMMI這個Model，這些事情也不該發生。

答案很簡單，SW-CMM(始於1987，穩定於V1.1-發表於1993年)或CMMI(V1.1發表於2002年)都是1987之後的事情，但是，與這些問題相關的過程領域，早在沒有CMMI/SW-CMM的時代就已經存在，並在工程能力良好的公司裡被實踐。否則何以太空梭可以上得了太空(1981/4/12首航)，台北市捷運木柵線可以通車(通車時間是1996/3/28)(使用法國成熟的技術)、許許多多良好的設備與系統被製造出來呢？

所以，根本不需要因為捷運出了狀況才來討論是否具備了CMMI就能避免這些問題。因為問題的重點，在於背後的工程方法是否被實踐！就如同Albert兄一直在倡導的--資訊軟體品質從業人員的道德與專業倫理守則的落實。如果專案人員、工程人員，為了業主的績效，而縮短了需求發展、產生技術方案、驗證解決方案之可行性、技術風險管理(國內現在在談CMMI的RSKM，只談風險管理的程序，多半只是做做樣子，能應付評鑑就好，根本不談技術風險的管理方法，而談FMECA的，更是稀有動物)，選出最適當的解決方案等等的時間，因為這些工作要產生許許多多的Scenario然後去試驗、評斷每種Scenarios可能發生故障與風險，要花費很多的時間，每任首長的任期是一定的，為了要有績效，大家就看著辦囉。

所以由此看來，要為木柵內湖線捷運癱瘓負責的，恐怕該是原來的決策者，及汲汲於績效的長官們吧。

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

原來內湖線電力系統是這家公司設計的：

http://www.mitac.com.tw/news258.htm

神通電腦公司93年承接捷運新蘆線電子票證專案，就已經涵蓋了內湖線場站的票務系統，接著又與外商龐巴迪合作，負責內湖線電力及通信系統工程。神通自動化事業群副總蔣台方表示，捷運內湖線是我們在交通運輸工程領域經營多年之後，首度同時跨足自動收費、電力、通信、環控四大系統，因此具有重大的意義，而且內湖線要與木柵線介接，整合工程難度相當高，對我們也是一大考驗。

原來這是一家CMMI ML3的公司，96年時全公司通過CMMI ML3，聽說現在正努力於CMMI ML5。
也難怪，才會用軟體開發與試運行的過去的不成熟觀念在做捷運系統。
沒驗收就可以營運？！台北市政府是不是有這種奇怪的習慣呢？

沒驗收就營運？還好是在地上走軌道的捷運，如果是在空中飛行式的捷運，就好玩了。
不知道他們的可靠度意思是什麼，為什麼要實際載人營運來算，是不是把乘客受傷時的急救程序也算進來？如果是，得趕快發生危急生命的事故，否則就測不出來了！

UPS是一備援設備，連備援設備都燒毀了，問題應該並不單純才對，而為UPS再做一條備援迴路，恐怕也不是真正正確的解決方案。
照說如捷運這麼複雜、關鍵性的系統，其每個組件個別的可靠度都會高達99.99%以上，而且，設計的壽期都會是兩萬個小時以上(以捷運的營運模式，一天使用18個小時，連續使用37個月(三年的時間)才會發生故障，如果不到兩萬小時，就比個人電腦上的硬碟還差了)，湊在一起之後，幾個月就掛了，很難說是個別的組件的問題，應該是整個系統設計上有瑕疵。
註：如果每個組件達不到可靠度99.99%以上，那麼全系統要達到可靠度99%，根本就是個不可能的要求。而在個別組件達不到99.99%的可靠度，全系統更不可能透過設計提升，並超過這個值。以目前的情況來看，不找到真正的原因徹底解決，而最後的報告顯示可靠度達到甚至於超過99%，可以肯定的是，這決不是透過工程的方法做到的。

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

內湖線是一項大型系統工程專案，其中也包括有軟體項目。由美國政府採購資料所知，將CMMI Level3納入RFP之選商需求中會產生違反採購法之情事，廠家也會提出抗告。在已經廢除的DOD 5000.2R C5.2.3.5.6.1.5 美國國防部採購指示文件中當初確實是有將S/W-CMM Level-3納入選商條件之ㄧ，但其全文事實上是有包括其他甲方可接受的相近似的評鑑標準，或是乙方提出甲方可接受的無評鑑標準下之避險管控措施都可接受。但若由美國採購實例所知，有相當多的案例是規範於簽約後ㄧ年或專案結束前，該專案之流程必須達到CMMI-Level 3且訂定於SOW中，以個人印象所知美國空軍的F-15航電軟體模擬測試系統更新案即要求達到S/W-CMM Level 5的水平。因此國內業者何妨向捷運局提出參用此項方式對於內湖線進行成熟度評鑑。如果流程有問題，那就是屬於系統性失效，其矯正成本將非常的高(可參考Sommerville之System Engineering)，如果系統流程是在Level-3以上，則可能發生隨機性失效之機率就較高，可採用調整檢修間距或更換系統件頻率將可適度的降低失效機率。
國內業者何妨藉此案例將CMMI的市場導入政府大型專案於專案執行中提供成熟度評鑑服務之機制，應該較易為業者所接受且無採購法適用之疑慮。
另外於國外有機構提出適用於軌道產業之CMMI架構，其差別處在於將原有CMMI V1.2之內容加入Reliability、Availability、Maintenability、Safety四項PA，前述PA主要內容是參考MIL-STD-882C、EN-50126、EN-50128、EN-50129標準。

對於國內而言，CMMI是條漫長的路，也特別艱難。主要認為速度可以彌補能力上的不足，快速可以帶來先求有再求好的"改善"時空。這種心態不只存在於開發者，也普遍存在於獲取者，而且更可歎的是，獲取者與開發者並不會從一次又一次的失敗經驗中汲取教訓，總認為每一個事件都是個案，相互間沒有關聯性，檢討的時候，不論供需方，均是歸責於外。
獲取方以SW-CMM/SE-CMM/CMMI-DEV首先將矛頭指向了開發者，指出開發者應該做到事情，而開發者心有不甘，透過代理人從CMMI-Acquisition Module(AM)到CMMI-ACQ，指出獲取者也該做好的事情。
一個專案的成功，實則有賴於供需雙方的共同合作，訂出大家應該做的事情，以及做事的程序與方法，雙方共同從合約上各盡本份。
現在大家在談CMMI-DEV或者CMMI-ACQ，都強調了過程，但是真正屬於「品質需求」的部分則不夠注重，更不在意實現「品質需求」的程序、方法與技術，那麼，就算大家都是CMMI-DEV與CMMI-ACQ五級的公司，大家看到的會是投入更多的改善成本，但是，能獲得多大的效益和人類(含業主)與環境的利益，恐怕大家都感受不到的。

說明：品質需求裡，即包括了Reliability、Availability、Maintenability、Safety等等，對於軟體品質需求也有許多的細節，有興趣的從業人員可以參考ISO/IEC 9126、ISO/IEC 25010及ISO/IEC 25030等標準。

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

依據大眾捷運法，捷運系統在營運之前必須先通過初勘與履勘作業，請問初勘與履勘應屬於CMMI那一PA? 由媒體所知內湖線在未完成測試前即宣告完成且通過履勘，履勘與系統測試二者之關連性為何?

內湖線為何三天兩頭停駛？ 龐家驊：仲裁糾紛埋遠因
更新日期:2009/08/13 00:07 【記者許志煌卅台北報導】
捷運木柵內湖線究竟發生了什麼問題？不然，怎會三天兩頭停駛？交通部高速鐵路工程局前局長龐家驊認為，木柵內湖線停駛的原因，早在木柵線時期就已經埋下，現在的問題應該是過去的馬特拉與後來的龐巴迪系統軟體整合的問題。
繼七月十日、八月六日兩度發生停駛事件之後，捷運木柵內湖線昨天下午又陷入停駛狀態。在原來的捷運局長常岐德為示負責請辭獲准，新的局長陳樁亮十一日剛剛接任的第二天就出現停駛，似乎說明木柵內湖線停駛問題依然還沒有找到解決的辦法。
龐家驊指出，現在木柵內湖線總計使用兩套系統。原本木柵線營運時的軟體，也就是馬特拉系統，當時並沒有做好完整的交接工作，而是捷運公司自己後來想辦法解決，「自認國內軟體工程師很厲害，可以把一些無法得自於馬特拉的東西，自行設法補充」。
他說，原本的馬特拉軟體，當然必須依據新的龐巴迪系統設計需求，例如配合龐巴迪通訊要求進行修正，但是，軟體整合是一項很大的工程，可以說比硬體工程還大。他舉例提及，先前台灣高鐵公司售票系統因為軟體問題，老是出現「光怪陸離」的情況，即使處理十個月卻依然沒有把問題搞好。
龐家驊認為，軟體整合的東西沒有經過上線，就不知道問題會出在哪裡？等到上線之後，又突然發現所有的訊號統統消失。所以，他說，捷運木柵內湖線的問題，應該就是軟體整合的問題。
他表示，現在若馬特拉系統與龐巴迪系統要完成整合，很多介面必須要雙方開誠布公，大家需要配合才能夠做得非常好，否則未來還是會有問題。他說，當時，捷運木柵線是因為有仲裁的糾紛，所以問題始終沒有處理好。現在，龐巴迪系統進來，兩個系統要轉換成一個系統，軟體整合若依然沒有弄好，就會發生行控中心無法掌握列車行蹤以致停駛，這也絕對是可以預料。

很想看看這些系統的營運概念說明書(OCD)、系統/子系統規格書(SSD)、系統架構說明書、軟體需求規格書(SRS)、軟體設計說明書(SDD)、到底寫了些什麼，FMECA有沒有做、報告的內容與相關的解決方案是什麼。那麼大的系統、也算是關鍵性系統了，花了那麼多錢，這些文件都沒有的話，也沒有製作任何的Mock-ups，或者根本是應付了事，沒有做該做的模擬、評估、審查，而只是拼命寫軟體，然後實際到系統上去Run，讓實際的環境將問題暴露出來，說這是個工程專案，真的是令人懷疑。再者，這幾次的問題，有沒有完整的維修紀錄，包括軟體工程作法上要求的問題管理、變更管理、組態管理的相關紀錄是不是全部都有。商業機密應該不是問題，問題在於包括龐巴迪在內的團隊成員，可能都沒有正規的系統工程與軟體工程的能力與素質，而不敢攤在陽光下讓全民來檢視吧。

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