我非常同意Joker所說的：「...以我參與CMMI的經驗，可以確定的是輔導公司的顧問或LA本身並未有涵蓋Level-2/3 的全部工作實務，大部分連Design Review或Change Request都未有過實務經驗，就敢上台輔導，...」云云。

身為一個過程改善顧問，我必須說的是，一般顧問他只是在告訴客戶如何去達到那個框架制度的要求，而不管客戶的基本功如何，客戶自己本身的對於獲利認知為何，以個人服務的公司而言，顧問被要求要尊重客戶的文化，要與客戶維持良好的關係，我們儘可能不去觸及這些問題(否則就會與我之前對另一個合作公司的客戶的老闆說：「我認為你們公司沒有能力導CMMI！」，然後調頭走人)。因為那是客戶自己要負責的。當然，如果客戶有了解工程與專案管理上"How to do"的需求，就需要另外計價提供，或者協助找到好的講師提供教學服務。像去年個人受公司指派到大陸去上幫兩個客戶上Software Estimation及Requirement Development的課程，就是一個例子。所以就算顧問沒有相關工程實務經驗，沒有做過專案、沒有規劃過專案生命週期過程、沒有真正去做過估算，沒有關係，需要的時候找到一個有能力的人提供這些知識、經驗與專業就可以了，但如果顧問說：我不會寫程序文件，我不懂什麼是ETVX，不會訂制度，我不懂得裁適該怎麼做，那才真的是很扯的事。

其實之前我與理事長曾經也談過能不能在協會的網站上公布軟體系統專案執行有瑕疵的軟體公司，但是這個不太容易達成，有主客觀因素影響(例如，甲方不太容易承認專案是失敗的，這是因為除了承辦人的前途外，說專案失敗其實也會波及到長官的政績，所以....像台灣高鐵這種案，因為藏不住所以是不得不承認，要不然真的舉目皆是，不勝枚舉。某專案延宕兩年，應於九十四年底就該驗收，到了九十五年第三季還沒驗收就剪綵啟用，還獲得首長肯定，並且得到兩個有關資訊應用的獎項，系統到現在還有近百項問題待解決而不能驗收，是不是夠諷刺？實質上這不也是失敗的專案？但承辦人會承認嗎？其長官會承認嗎？)，而且可能引發很大的問題，所以這件事就作罷了。

另外我想說的是，去年我到大陸去上課，順便看看他們執行的狀況，我覺得台灣的軟體業真的沒有什麼競爭力了，大陸做得真的是比台灣好。這個產業需要有理想的人去貢獻，例如，大家認為做得不好，或者拿CMMI評鑑是在作秀，大可以前進到第一線去帶領，有機會的話就該去爭取當大案子的專案經理，去說服甲乙雙方去運用良好的工程與專案管理常規在專案裡，然後由有心人士來帶領大家去學習真正的工程與專案管理的精髓，為甲乙雙方帶來制度的利益(不論是在財務方面或者競爭能力上的)。我想總比在這邊談這個不好那個怎樣，現在是有問題沒錯，這個大家都知道，但是解決之道在何處？

我們的甲方不夠成熟，我覺得才是問題的最大決定因素。以美國軍方為例，美國軍方長久以來一直做一件事情：由美國軍方制訂標準，要求業界去遵循，美國軍方還成立國防獲取大學(Defense Acquisition University, http://www.dau.mil)，來提升獲取的相關能力。反觀我們國內的環境又是如何呢？

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

我呼應林秘書長前文的意見，透過 貴協會網站過去的討論，相信大家對於 CMMI 推導與評鑑存在的問題應該已經多有瞭解，但僅談論問題與解析病理是於事無補的，現在大家應該要討論的是改善問題的藥方 !

我綜合各位先進前面的討論，認為現在當務之急需要檢討改善的課題包括：
(1) 如何提升 CMMI 輔導結案的品質 ?
(2) 如何確保 CMMI 通過評鑑的品質 ?
(3) 如何健全企業主導入 CMMI 評鑑的正確觀念 ?
(4) 如何改善資訊委外機關的成熟度 ?
(5) 儘速公佈通過 CMMI 評鑑之企業及其評鑑組織範圍的詳實官方資訊，以免魚目混珠 !
(6) 打破文憑主義的迷思－「文憑不是檢驗真理的唯一標準」，雖然通過 CMMI 評鑑應該代表其具有一定的成熟度，但其是否落實執行還是需要輔以其它務實的要求，何況 CMMI 評鑑還有三年效期的限制。文憑主義是創造「補習文化」的溫床 !

CMMI與框架沼澤（Frameworks Quagmire）

1.197x年末198x初美國國防部面對層出不窮軟體問題制定出軟體流程標準，其目的希望能由買方角度增加賣方在Process方面的透明度，俾儘早對於不良流程採取改善措施。因此1985年制定了DOD-STD-2167，雖然在1968年有海軍公佈的DOD-STD-1679 Weapon System Software Development Standard，但因為DOD-STD-2167包括有生命週期之文件撰述說明Data Item Description （DID），可將之歸類為流程標準（Process Standards）框架（Framework）。此等框架包括後續產生之MIL-STD-498、ISO/IEC-12207、ISO/IEC-15288、EIA-632….等。彼時所制定之標準皆以 “shall”規範承約商必須執行之事項或工作，所以從Proposal角度解讀Standard，只要看到shall一字就應該有相對應的traceability以及報價。

2.所謂框架，如果以1999年頒定Federal Enterprise Architecture Framework (FEAF)的定義為“A logical structure for classifying and organizing complex information.”。但無論何種Process Standards，皆難以敘述專案起頭之Problems and Needs，以致經常發生RFP之需求（Requirements）與使用單位之需要（Needs）有偏異之現象，因此美國管理與預算辦公室(Office of Management and Budget，OMB)針對聯邦政府單位採購資訊系統時規定必須將需要(needs)、資訊系統功能(information content)、及資訊系統技術能力(information technology capabilities)予以串接在一起；由於各行政單位之資訊系統有其Domain之差異性，因此衍生有聯邦政府企業資訊架構框架(FEAF)、國防資訊架構框架(DODAF)、財政部企業資訊架構框架(TEAF)、…。一般專案所將完成的Products，以及發展該等專案所應引用的Process Standards皆屬於AF之下的Components，但一般不會包括以下所敘述的Appraisal Method（Assessment Standard）、Maturity or Capability Model。事實上對於美國政府資訊系統採購，現在已不個別敘述Frameworks，因為整個資訊系統架構已提升為Architecture Framework （AF），Software也以Software Intensive Systems of Systems (SISOS)來取代，整體架構框架（AF）集中在ISO/IEC-9126的Interoperability。

3.在DOD-STD-2167文件亦包括有 “5.8 Software Quality Evaluation”之章節，其後在新版之DOD-STD-2167A將之分離另訂DOD-STD-2168，可歸類為品質標準（Quality Standards）之框架。此包括後續產生之ISO-9000、TL-9000等。

4.但在日趨複雜之流程標準、甲方希望了解賣方是否落實流程標準、或乙方希望確認公司執行流程標準之能力等因素下產生了由第三者對於乙方進行評鑑之需求，此需求包括有評鑑標準(Assessment Standard) 或稱之為評鑑方法（Appraisal Method）的框架，此包括有ISO/IEC-15504、EIA/IS-731、SCAMPI、CBA IPI、SDCE、..，以及成熟度或能力模式（Maturity or Capability Model），此包括有xx-CMM、CMMI-xx、FAA-ICMM、…。

5.另有於不屬於上述四種的Frameworks，但對於工程執行、專案合約等可歸於執行方法且會影響專案組織架構的文件，歸之為導引（Guidelines），此包括有PSP、TSP、RTCA DO-178B、Six Sigma、PSM、…。(美國政府的採購層次為Policy→ Requirements→ Guidance→ Technical Standards)。

6.在陸續產生各種Quality Standards、Appraisal Method (Assessment Standard)、、Maturity or Capability Model、Guidelines以及架構框架(AF)等環境下，已讓甲乙雙方陷入極度困擾之狀況，因此 www.software.org 於1997年繪製出Frameworks Quagmire，並於2001年於IEEE Computer Society發佈新版The evolution of Frameworks Quagmire ( http://g2sebok.incose.org/app/qualsys/view_by_id.cfm?ID=INCOSE%20G2SEBOK%205.1410&ST=F) 。如果你可以由上圖體會作者以顏色區隔出Process Standards、Quality Standards、Appraisal Method (Assessment Standard)、Maturity or Capability Model、Guidelines等之差異，就達到作者希望你不會陷入泥沼（Quagmire）之用意，也將易於了解Standards與Maturity or Capability Models/Appraisal Method之關係以及差異或關係。

7.SEI教材中亦引用上圖http://www.sstc-online.org/Proceedings/2002/SpkrPDFS/WedTracs/p931.pdf 但可惜SEI除拿掉代表 Frameworks 分類的顏色註解，甚且將原有Framework屬性予以混淆，如原屬於Quality Stds的DOD-STD-2168被混入代表Process Stds的綠色類別，所以你若未參考原圖仍將持續陷在Quagmire中(SEI本身似乎已陷入泥沼之中)。但由SEI的圖中可以確定的是持續保持有Process Standards與Quality Standards，CMMI 並不能取代IEEE/EIA-12207、ISO-9000等Standards。當你聽到國內產、官、學、研在推動CMMI時使用“CMMI為國際間普遍認同的一種軟體開發程序標準”之措詞 ( http://www.moeaidb.gov.tw/portal/ePaper/mail/SendPaperReview.jsp?num=43) ，你就可以體會該措詞適宜與否或可視之為笑話一則（對於國內而言實等於輔導單位將該圖的Process Stds、Quality Stds予以刪除）。但其更大的風險在於無Process Standards、Quality Standards環境下，大力推動Appraisal Method (Assessment Standard)、Maturity or Capability Model甚且誤導產業界將CMMI視為發展標準，等於將國內IT產業帶入泥沼之中（產生無法脫身的困境，甚且已將國內資訊業帶入Fred Brooks 1975年所撰述The Mythical Man Month一書之Tar Pit的境界）。

8.Standards一辭不可濫用，其定義可參考美國政府文件OMB Circular A-119 （CMMI是在美國採購環境下之產物，所以最好以美國的定義做解釋）；由採購角度觀之，甲方的RFP Requirements僅需敘述“What to do”，不要過度侵入設計領域，乙方要在Proposal中Propose出“How to do”的Technical Standards，否則無助於整體採購品質之提昇。

請問以下這一則新聞是否意指軟體若有問題全部是開規格一方的責任:


高鐵售票機出狀況∼　神通：規格高鐵開　我們只是承包商
更新日期:2007/01/04 12:11 記者:記者陳曉藍卅台北報導

高鐵售票才上路狀況頻頻，對於售票機的問題，負責建置系統之一的神通電腦方面表示，目前只知道3日在板橋站找零出狀況的那台機器，現在所有的工程師都已出動維修，對於神通電腦最近成為媒體焦點，神通方面也相當無奈地說明，所有規格都是高鐵開出，神通只是系統承包商之一而已。

神通電腦企畫處劉慈明表示，目前僅知道板橋站的一台機器找零出問題，維修人員已在現場待命，因為現場媒體、民眾太多，根本沒辦法拆機器檢查，到底是出來什麼狀況，只能緊急把現金功能停掉。

對於媒體指稱，高鐵售票機訂位方式太過緩慢，訂票系統穩定性不佳，頻頻當機，再加上信用卡交易困難，顯示高鐵公司委託神通設計的系統相當「落伍」。

對此，劉慈明說，神通電腦是經營系統整合廠商，也只是高鐵的系統承包廠商之一，所有機器的規格與需求都是高鐵方面開出，神通電腦只是根據高鐵開出的規格來做，指稱神通「落伍」是不公平的，應該詢問開出規格的高鐵才對。

由於高鐵通車引起對於導入CMMI是否能夠改善軟體及系統發展品質的許多討論，大多指向負責軟體開發的神通公司，看法也多偏向負面。我在上週四(3/22)剛好搭乘高鐵到南部，過程中的一些經驗，想要借用這個論壇發表，希望提出一個不同的觀點，讓討論導入CMMI是否有幫助這個議題，可以有進一步討論的空間。

上週四上午08:30我到高鐵的台北車站準備買票到南部，在抵達自動購票機前，有一位小姐已經在買票。我約略等了二十分鐘後，這位小姐還是沒有買完票，最後放棄買票，終於輪到我買票。買票前我知道09:15有一班車，但是當我輸入起迄地點後，指顯示出10:15一班車，沒有其他資訊，由於不確定情況下，我放棄買票，到櫃台查詢清楚後再回來買票。回來時有位先生比我先到，約過個幾分鐘後，他轉過來問我「這台機器收不收現金？」我抬頭看那台自購售票機，上面標示著「信用卡及金融卡」二種購票的付款方式。

以上這些並不完全是軟體設計的問題，售票機在售票過程中沒有提供充分的參考資訊，使購票者無所適從，是軟體設計的問題，但消費者不看高鐵所提供的購票資訊，是消費者的消費習慣所造成的錯誤，和軟體設計無關。

當我購完票之後，持票要進入車站，票是掃過了，但是門卻沒開！我問現場服務人員，他說他也不知道，我只好再問另一位服務人員，他說我的票卡放錯面，所以無法進入。同樣的，既然票卡放錯面，機器不應該可以解讀，又是屬於軟體的設計問題。但是服務人員一問三不知，卻和軟體設計無關。

終於，票卡放對正確的那一面了，但是還是不能進去。我再問服務人員是何原因，他說我的票必須要到09:15之後才能進去，現在只在外面等，可是現場座位有限，也沒有其他的去處，只好在現場等到09:15之後在入場。這是政策的問題，也和軟體設計無關。

我約略在09:50時回到出入口，刷卡順利進入，這個時候卻找不到位置坐。我試著下到月台後車，被服務人員阻止，說要到10:10才能下去月台，現在只能在上面等，這樣我又站著等了20分鐘，才下到月台。在等候這段時間，我端詳著高鐵的現場服務人員，從穿著、舉止到服務的方式，無一表現稱得上專業，我不禁要問高鐵的唯一訴求難道只是「高速」而已，沒有其他？

整個旅程，從我到車站，最終抵達目的地時已經超過四個小時，還好我當天不趕時間，否則鐵定來不及。

從上述的這些情況，我毋寧說「台灣高鐵營運的品質才是最大的問題，軟體設計問題只是這個問題冰山的一角」。種種跡象顯示「這是個拼湊的服務」，以一個軟體產業的從業人員的角度來看，我會說「即使做到CMMI Maturity Level 10」也不能解決這個問題，何況神通公司也不過通過CMMI ML3。我當時心中浮現一個想法「還好神通公司是一個通過CMMI ML3評鑑的公司，如果是其他軟體公司，這個專案很可能不會能夠在此時上線，甚至上線後問題會更多」。

CMMI的需求發展與需求管理二個流程領域可以提供解決軟體設計過程中「收集與引導需求」和「管理需求變更」問題的方向，但不能解決來自於管理階層對於整體營運及管理想法的度確定性和不成熟性。套用CMMI成熟度的概念，台灣高鐵目前的營運及管理還在CMMI ML2的階段，但顧客對於服務品質的期望卻已經在CMMI ML4之上了。一個成熟的軟體開發公司可以採用成熟的軟體發展管理的方法，協助顧客成功的開發及建置軟體應用系統，但無法跨越顧客，發展出超出顧客目前認知及能力的軟體系統。

CMMI不是萬靈丹，將高鐵軟體系統的問題全部規怪罪於神通公司是不切實際的。如果還人說「導入CMMI不能解決軟體開發的績效和品質問題」，我會說「至少CMMI是到目前為止，被印證最能夠引導建立解決軟體發展管理機制模式」，在其他更有效的模式、標準或是方法被證明有用之前，我建議不要將時間花在爭論「導入CMMI能不能解決軟體開發的績效和品質問題？」將時間投入在「如何利用CMMI建立能夠解決軟體開發的績效和品質問題的機制和方法。」

對於許多發表正面或是負面看法的業界先進們，不知道是否在發表看法前，是否乘坐過高鐵？我建議不妨找個時間實體體驗一下，也許會有不同的看法。

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

www.tasc.tw

挺有趣的想法。
那請問以下TVBS新聞所報導高鐵營運第一天的新聞，是否屬於軟體的問題?

TVBS新聞：
高鐵預售票今天首度開賣，結果一個上午，狀況頻傳。不是刷卡機不能使用，就是售票系統當機。排隊買票一個人平均半個小時以上，民眾甚至氣得向高鐵發言人抗議，場面相當混亂。
http://forum.news.yam.com/disingle.php?tid=507857

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

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

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

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

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

www.tasc.tw

“成熟的男人與成熟的女人，比較有可能生出健康的寶寶”，反過來說“生出不健康的寶寶，卻有可能是因為：男人、女人、環境或過程有問題”。

高鐡自動售票系統所發生的問題，高鐡與神通當然都脫不了關係。不過，以一個“軟體工程師”的身份，我更關心的是：神通在這個專案中，是否如實地表垷出“通過CMMI Level 3的組織”應有的組織成熟度？換句話說：如果是換成國外(或者任何)一個其它通過CMMI Level 3的組織，來執行這個專案的話(暫時假設没有語言、文化上的問題)，得到的結果會比目前的好嗎？如果，不會比目前更好(或者更糟)，那就表示神通已充分地展現了應有的組織成熟度。反之，如果會得到比較好的結果，那麼就表示神通在某些方面出了差錯。

犯錯其實並不可怕，也不可耻。重要的是吾人，能不能坦然面對錯誤，並從中學習到由書本中學不到的寶貴經驗。不知那個人或單位能促使神通出來(或者神通在適當的時機願意主動出來)，分享他們在這個專案中所學到的東西。此事果真有幸，能夠成真，將是吾人最大的福報之一，神通與那個人(或單位)也將功德無量。

軟體品質協會資深管理師 周茂松 敬上

換了一家公司，公司有了CMMI-SW/SE Level 3，主管都相當的志得意滿。上週美國一家公司來參訪，卻讓公司鬧了些許笑話，該美商公司打算參與國內的國防系統標案，國內軍備局要求採用Integrated Product Team進行專案管理，公司在推動CMMI時也曾一併研讀與IPPD相關章節，因此相當有自信能滿足美商的關切事項，但幾個問題問下來卻讓公司鬧了些許笑話：
1)What is the relationship between PIPT and CWBS?
2)Who are the members of PIPT?
3)What is the play role for Acquirer in PIPT?
4)What is the reasonable size of PIPT?
5)How Project Manager define the authority of member of PIPT?
6)How to monitor the Cost、Schedule、and Performance of PIPT?
7)What is the relationship between PIPT and PWBS?

附帶一提的IPT包括有OIPT、WIPT、PIPT，WBS有分CWBS與PWBS，這也是我們鬧的笑話之ㄧ，因為我們只知道IPT與WBS。
煩請國內的CMMI專家提供前述答案，供本公司補考用。

美商的建議是"CMMI is not engineering discipline, the development capabilities should be based on engineering discipline"，也許Level-3公司尚必須補強某些基礎工程。

以上問題可以參考以下文件可以獲得一些想法：
1. MIL-HDBK-881 Department of Defense Handbook, Work Breakdown Structure.
2. DoD Guide to Integrated Product and Process Development
3. DoD Integrated Product and Process Development Handbook

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