1. 2001年美國國會總主計局(GAO)針對國防部有關系統與軟體改善提出建議報告，該報告中建議SEI之IDEAL Models並列舉SW-CMM之相關內容；但美國國防部企圖以改進DOD 5000.2R(已更名為Defense Acquisition Guidebook)方式達成SW-CMM Level-3(或相近似models)以滿足Software Process Improvement部分(但僅針對研發案金額超過美金$3.65億或採購金額超過美金$21.9億之計劃)；在DOD 5000.2R增列Software Management章節，並明述承約商須具有SEI所發展或由採購單位認可同等Model之Level-3能力，若承約商無法達到前述目標應提出Risk Mitigation Plan，前述之Level-3 appraisement效期為2年；GAO在報告之page 35頁亦提到“Software Capability Maturity Model® (SW-CMM®), was designed to assist organizations in improving software development and maintenance processes.”，未提到Acquisition Phase之適當方法；

2. 由於前述報告未得到國防部正面回應，2002年12月2日通過之美國國會2003年度國防授權法案（National Defense Authorization Act for Fiscal Year 2003）針對前述之缺失提出SEC. 804. Improvement of Software Acquisition Processes，責令(mandate)國防部執行重大武器系統採購計畫(Major Defense Acquisition Program)須進行軟體籌獲過程改善，同時在Section 804附註Major Defense Acquisition Program之定義應參用美國聯邦法典section 139(a)(2)(B) of title 10, United States Code之解釋，意即研發案金額超過美金$3億或採構金額超過 $18億者。

3. Section 8條列應執行事項有
(1) 對於software acquisition planning, requirements development and management, project management/ oversight, 及risk management.等程序應有文件紀錄；
(2) 對於計劃執行效能應進行度量評估暨進行持續改善；
(3) 採購專案之關鍵執行工程人員應具有適當之經驗與軟體採購訓練；
(4)每一軍事採購單位應確實遵循既訂採購程序與需求執行軟體相關專案採購；

4. Section 804責令國防部應於該法案生效日起120天內開始執行，因此國防部各採購單位配合Section 804完成下列措施：
(1): 成立Software Acquisition Process Improvement Program (SAPIP)，
(2): 重新訂定諸如Acquisition Guideline之採購指引，
(3): 參用實獲值工程ANSI/EIA-748-A-1998 EVMS進行效能監控，
(4): 各單位依據需要分別選用CMMI、SA-CMMR、FAA-ICMM、或混合使用以配合SAPIP執行Acquisition Process Improvement，(所選用類型極為繁雜；因此國防部認為有必要規劃CMMI-based acquisition model，此即後續CMMI-ACQ之發軔；先期規劃有CMMI Module for Acquisition，其對象係針對system project offices/program managers (http://www.sei.cmu.edu/acquisition/acquisition.html))；

5. CMMI-ACQ係緣自於美國國會認為對於重大武器採購有必要改善其軟體採購程序，因此Section 804之影響並未蔓延至諸如交通部等其他部門；同時國防部各相關採購單位皆建置有人力充足之工程人員，足堪對於QA、CM、VV、Requirement Development、Technology Solution、…等工程需求進行評估(MIL-STD-xxx就是由此等單位分別制定的)，但一般部會則無此人力，採購金額也不若國防系統般浩大，因此Section 804目前並未影響其他部會有關IT系統採購之Process Improvement，由Section 804所衍生之CMMI-ACQ是否將為其他部會所接受，目前尚待觀察，畢竟其採購環境差異極大；

6. 美國國防部各單位經此Section 804之壓力下對於CMMI的應用已較過去更為成熟，諸如在Space and Missile Systems Center部門的Software Acquisition Instruction之(1)2.1.4.3.1. If Contractor A is CMMI level 5 in PC networking, it does not mean they are CMMI level 5 in navigation. (2) 2.1.4.3.2. Or if the prime contractor is CMMI level 4 and a subcontractor is CMMI level 1, then the team as a whole may function at level 1.，分別說明一家公司或部門的CMMI Leveling是不能套用於全部domain的，整個競標團隊的CMMI Leveling應以最低者為Level mark；

7. 採購之成熟度並不在於前述之CMMI-ACQ或相關Acquisition guidebook，因為既使熟讀CMMI-ACQ或Acquisition Guidebook仍無法填寫在採購過程(Solicitation)的採購法RFP文件，但採購法對於採購之成熟度具有相當的影響，美國採購法FAR全文有1923頁(國內是346頁)，美國各部會所可能遇到的採購品項、工程、產品、…皆在FAR文件中有相關章節敘述，(1)例如在FAR PART 34—MAJOR SYSTEM ACQUISITION，即針對前述類似Major Defense Acquisition Program的採購方式，可依據Acquisition Plan拆成34.005-3 Concept exploration contracts.、34.005-4 Demonstration contracts.、34.005-5 Full-scale development contracts.、34.005-6 Full production.等四個階段的合約，每一階段合約的RFP的標的物都不同、與R/D有關的可引用PART 35—RESEARCH AND DEVELOPMENT CONTRACTING、與諸如高鐵有關的合約可引用PART 36—CONSTRUCTION AND ARCHITECT-ENGINEER CONTRACTS、與維護或顧問有關的可引用PART 37—SERVICE CONTRACTING，(2)在報價方式如果是買現貨件COTS可引用PART 14—SEALED BIDDING(最低價格，即COSTING CONTRACT)、如果是具有研發過程PART 15—CONTRACTING BY NEGOTIATION (議價、最以利標，即PRICING CONTRACT)、或依據合約不同的標的物分別引用PART 16—TYPES OF CONTRACTS的不同計價方式，(3)但在RFP章節所要敘述的Requirements，則隨PM個人功力是否能將Pre-Acquisition的諸如Mission Needs Statement、Concept of Operation、Analysis of Alternative、…等轉換成RFP的不同章節，將可決定一般所謂的需求完整性的要求，但此部份目前無STANDARD可參考，須由各部會自行依據採購環境自行訂定Unique Guidebook，因此引用PART 14的RFP內容與PART 15的RFP內容有極大的差異，能否視之等同為同一Leveling，值得存疑。

據聞經濟部工業局繼投資推動 CMMI 軟體品質輔導計畫後，最近也開始規劃推動政府資訊機關導入 CMMI-ACQ 評鑑，我認為經濟部工業局的長官及其學者顧問們至少應該看看 Alexyin 的這篇文章，瞭解美國目前發展 CMMI-ACQ 的時空背景與適用環境。

經濟部工業局的長官們可能是聽到導入 CMMI 評鑑的軟體業者們擔心政府機關採購作業相對不成熟，因此希望提升政府機關資訊服務委外採購作業的成熟度，用意雖然良好，但是我同意 Fred 的看法: 以目前國內資訊單位的成熟度而言，就連經濟部依據 ISO/IEC 12207 編譯公布的國家標準 CNS14837 ，目前都沒幾個政府機關依照政府採購法第 26 條採用於資訊服務委外的現況下，究竟目前導入 CMMI-ACQ 是否陳義過高了呢 ?

我也呼應 Fred 的意見，如果政府資訊機關要導入 CMMI-ACQ 評鑑，可以先從每年或許還有不少經費辦理大型資訊服務委外的經濟部國營事業先行試辦，或者考慮像美國一樣，先從某些國防資訊機關的大型資訊服務委外專案先實施。

另外，我想提醒經濟部工業局的長官們: 當初投資推動 CMMI 品質輔導計畫的政策目標不是要提升台灣軟體產業的國際競爭力嗎 ? 廠商他們怎麼還是在這個日趨萎縮國內政府市場這個小格局裡打轉呢 ?

1993年個人在美國參加軟體轉移（Lockheed Martine Fort/Worth），當時的美方顧問在聊天中提到部門剛通過S/W-CMM Level 3.5，他進一步開玩笑解釋沒有所謂的Level 3.5，雖沒有達到Level-4但優於Level-3所以SEI戲稱為Level 3.5；其後從未聽過該公司的顧問提到任何有關 S/W-CMM的事情以及看過任何海報、口號，1999年12月該部門通過Level 4，在公司網頁也見不到任何狂賀的資訊，但印象最深刻的是在專案計畫的佈告欄中每週會固定更新各項度量分析資料，最常見的是軟體各Components的Coding、Component Testing、Integration Testing的進度與落後百分比曲線、建構管理中的Change Request（CR）執行現況、以及計劃開始所產生的CR曲線（CR沒有收斂的話，就是Cost Overrun、Schedule Delay、Incomplete Performance的前兆，Incentive Fees也將跟着減少）、Manpower曲線（很少聽說要加班）；

2002年台灣CMMI火紅，我再次前往Fort/Worth拜訪朋友，與負責近10億美金的專案負責人、工程部門主管、資深工程人員聊天，但沒有人對於CMM與CMMI有任何印象，當我進一步解釋之後，對方表明他們工程部門只需要依照PMP中訂定的Standards與部門的Procedures進行規劃與文件撰寫即可，ISO、CMM、CMMI、731、15504、..等Assessment或Appraisal是屬於EPG的事情，當EPG做完Gap Analysis之後再去訂定相關補強的Procedures與Template進行Process Improvement， Engineering Team依據人力與時程配合執行；基本上是按照諸如IEEE-12207、IEEE-15288、MIL-STD-498、MIL-STD-973、..等標準做事情，而不是按照CMM 的評鑑標準做事情；

在台灣的CMMI Level-x公司你幾乎看不到Standards（僅有CMMI的Assessment Standard文件）、在布告欄也見不到各項度量分析資料、你所能見到的是隨時要加班，下一次安排CMMI參觀之旅建議你安排美國公司而非印度公司，你將能有深刻的感受。