前面多位先進與前輩提了很多精闢的觀點，讓吾人增長不少見識。不過個人想以一個比較淺顯的觀點，來提出個人對這個問題的看法。

吾以為IEEE 12207 (或CNS 14837)它在規範從事與軟體有關的工作者的“做事方式”，它是代表的是“需求”(對做事方式的需求)。它像一把尺，用了它工作者才會知道成功的軟體系統專案中誰應該要做什麼事，也才會知道當下進行的或過去的專案中少做了什麼。不用它，就不會知道這些，就不會有長進。

現今與軟體有關的工作，不論是籌獲、供應、開發、維護或營運，都不是一個人所能勝任，一定要集合眾人的智力才能克其功。任何一個組織把眾人找齊後，若沒有一套程序把這些眾多的人與事有效地結合，這些人就是烏合之眾，只會把事弄得“一團亂”(CMMI Level 1的特徵)，而成就不了什麼的。所以，CMMI(不論AM、ACQ或IPPD) 提供的是任何一個“組織”要能夠把有關“系統”或“軟體”的“事情做好”，所須具備的各種“組織能力”與其“成熟度”。更簡約的說法是：它提供的是改善“組織能力”成熟度的地圖。依其完成後，組織就具有某種程度(“成熟度”)“滿足”前述“需求”(IEEE 12207)的“能力”。

然而，“組織能力”是建構在“個人能力”之上的。如果，構成組織的成員不具備“個人能力”，組織是不可能有能力的。所以，每個從事與軟體(或系統)有關的組織中的每一位成員，都必須具備他在組織中扮演的角色所需要的“個人能力”。它是以軟體工程與系統工程中的各種知識為基礎的。

所以，個人以為不論籌獲方、供應方或者開發方要真正改善其“組織能力”，必須三管齊下(標準、CMMI與個人能力)，缺一不可。而且，要在實際的專案中能發揮效用，又必須找到相當的對手。正如，成熟的男人要和成熟的女人結合，才有可能生出健康的小孩一樣。成熟的籌獲方與成熟的供應方(或開發方)才能“如質”、“如期”和“如預算”的完成軟體系統專案。

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

當初我在國防部執行專案所使用的IEEE SESC軟體工程標準彙編(紙本，共四大冊)，就是透過國內的代理公司購得。另外，國防部本身在當時的國防部採購局，其實也有提供各種標準的線上查詢與下載服務，這是由國防部付費，設於軍網內部。

個人於離開國防部後，則是透過ISO及IEEE等網站，用信用卡付費購買電子檔。所以個人認為取得的問題應該不是重點。

重點在於學校老師們重視不重視這些標準的運用，我所遇過的一些老師，許多是看不起這些工程標準的，甚至於認為這些標準完全沒有價值，如果老師們重視這些標準的意義與價值，實在可以產生非常大的影響力。

就算是在標準委員會裡，我個人的感覺是，這些工程過程標準受到重視的程度，在委員老師們的眼中，也是「僅供參考」，你告訴他們你會將這些標準用在專案與產品開發上，他們也會認為你非常的不可思議...。

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

1.Rockman99 所言“吾人不應去強調「推CNS 14837好，還是推CMMI-AM、CMMI-ACQ」才對，而應該是兩者兼俱。”若能將工程發展標準與評鑑標準之從屬關係予以釐清， 對於國內IT業的成熟度將更有助益，可惜的是中國大陸可以搜尋到代理販售IEEE-STD-XXX的網站（因為有需求所以有市場），但國內則無，因此要推動工程發展標準的路途尚有待努力；

2.另一項值得思考的是由推動CMMI 的US DOD一份文件，足以斟酌有關Acquisition Process Improvement的着力方向：
（a）在美國國防部Defense Acquisition Guidebook Chapter 4有以下一段話：Acquisition programs shall be managed through the application of a systems engineering approach that optimizes total system performance and minimizes total ownership costs.
(b)另外在9.1.6. Systems Engineering and T&E 有以下一段話：
Systems engineering is discussed in depth in Chapter 4 of this Guidebook. In essence, systems engineering is a process to transform required operational capabilities into an integrated system design solution. As the design solution evolves, a verification component of the systems engineering process must provide confidence that the design solution properly addresses the desired capabilities, as intended.
因此有關Acquisition Process Improvement的推動除了考量諸如IEEE/EIA-12207軟體工程標準與CMMI-ACQ評鑑標準外，更應該由系統工程標準着手，事實上在ISO/IEC-12207的編輯者Raghu Singh於ISO/IEC-15288的簡介資料即曾說過“Need to place 12207 under a system standard”；

3.當軟體工程考慮到與採購過程有關的Users Needs或Operational Capabilities時，有必要藉助系統工程的需求工程(Requirements Engineering)以確認真正的Problems、Needs、與Requirements，否則後續的Process再如何成熟都無助於專案的失敗，但Requirements Engineering迄今似乎尚無標準可參考，僅有各採購單位的Guidelines可供參考，但若參考CMU/SEI-2005-HB-006　Software Acquisition Planning Guidelines對於採購人員應有相當助益；

4.一般IT合約都專注於functionality，但是CI的Quality attributes事實上已經包含interoperability、security、safety、dependability（such as MTBF、MTTR、..）、disposability、等，已不再是Software Engineering所能全部涵蓋（參考ISO/IEC DTR 19760 page 46），因此更需要藉助System Engineering方能避免rework的發生。

個人就經驗提出一些淺見。

當初在執行國防部辦公室自動化專案時，PMO被要求要以ISO/IEC 12207來執行專案。
由於大家都沒有經驗，看著獲取過程所描述的條文，每一個字句都看懂了，但要怎麼執行？
依照標準的指示，PMO要先找出客戶的需求、訂定獲取的策略；定需求的時候，可以援引5.3發展過程，而進入5.3發展過程後，從5.3.1至5.3.13又是一堆條文，條文每個字都懂，怎麼做又是大問題了，發展需求的學弟常常問到一些問題，談到需求、品質、談可靠度、談可用性，這些怎麼做，結果又回到基本的系統工程、軟體工程及ISO、IEEE、MIL的相關標準，我們從那些文件裡去研究這些東西該怎麼產生。那個案子的計畫作為階段，是在民國八十九年及九十年初，大家才剛開始要談CMMI-v1.02，當時主要還是SW-CMM，SW-CMM不像CMMI還有一些子常規、典型工作產品之類的東西那麼好用。所以，我們都是看著條文自我學習，繞了很多的路子，但也學到更多的東西。光做這些事件，了解條文、學習把需求寫出來，我們的PMO花了半年以上的時間。

談CNS 14837是對的方向，因為從採購法的角度必需如此，但是對於獲取者而言，如果你只知道一個獲取的過程，還有一些支援的過程那是不夠的，因為你還不知道該怎麼操作很多事情，怎麼樣去做控管、或者解決問題、你必須要建立起完整而成熟的能力，方可奏效，否則，光談一個過程可能華而不實，而且也可能因此誤用了過程裡的活動或工作項目。

而最進所看到的一些例子，不成熟的獲取者才是專案殺手。但是熟讀CNS 14837並不代表你會是一個成熟的獲取者，一個成熟的獲取者應該是該標準所述及的要求都能恰到好處地執行。如何知道有那些該做呢，CMMI-AM或CMMI-ACQ應該獲得這些知識較快速而完整的途徑，但光「知」仍然不夠，應該透過CMMI-AM或CMMI-ACQ的導入，做獲取能力的完整學習、建立與制度化，才是上策。

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

alexyin兄之博學真是令人讚嘆，對於美國政府部門與軍方的一些相關標準與要求具有深厚的認識，實為吾輩軟體知識工作者學習之榜樣。

個人對於這些亦有一些淺見，在此提出來就教並與先進分享。

吾竊以為不論CNS 14837, ISO/IEC 12207, IEEE/EIA 12207.0, MIL-STD-498, CMMI及相關的流程改善技術文件，其目的乃嘗試從工程與管理流程的標準化，做好流程的品質，透過具有品質的流程以保障由該流程產生之工作產品或最終產品的品質。
任何一個單位，撇開像MIL-STD-498、IEEE/EIA 12207.1、IEEE S2ESC及ISO所提供的一些文件產品的標準不說，有誰拿到這些所謂最佳實務的集合後，可以做對事情的，但是，又有誰不做這些標準或規範所陳述的最佳實務，卻可以把事情做好的？政府部門固然有其所謂的採購法，各單位也有其內部的採購規定，有誰可以保證使用了這些採購規定能把事情做好了？採用標準的好處是，這些是已經過許多國家、政府或業界實踐的流程及最佳實務的集合。但是政府的採購法或是政府單位自訂的採購規定來說，有多少人可以拍胸脯保證，絕對沒有問題，更何況在實行的時候人員素質又大大影響了整個專案或產品的最終結果。

光推動CNS 14837是否足夠？誠如alexyin所提到，我們就以籌獲單位要寫SOW最起碼要寫SOO這件事來說好了，為什麼做不好，一個原因是不知道要做這些事，另外一個是，不論是SOW或是SOO吧，CNS 14837或ISO/IEC 12207裡並沒有，但是在CMMI-Dev 1.2、CMMI-ACQ draft、CMMI-AM v1.1裡均提及了SOW，很多單位甚至於根本不知道SOW會從WBS而來，所以連WBS發展的觀念也是錯的。但是這些在CNS 14837或者ISO/IEC 12207及IEEE/EIA 12207.0裡是沒有提到的。缺乏這些東西，要能把案子包出去做，是件很危險的事，造成一大堆難以驗收的案子。再者CNS 14837標準及其相同標準裡為了保持彈性，只談到要「做某項任務，然後其結果要document下來」，卻沒有指明是什麼樣的文件，當然IEEE/EIA 12207.1是提及了，但是這些是IEEE的說法，在ISO/IEC TR 15271 (CNS 14950)給的名稱又不一樣。所以，在不知道的狀況下，也就不會去深究到底這些事該怎麼做，因此絕大多數的籌獲單位，只當兩種人，第一種是文抄公，專找別人的RFP來抄抄寫寫，在籌獲專案開始後，變成第二種人，專出一張嘴的人，全憑感覺管理籌獲專案。這只是讓註定失敗的專案，失敗得更徹底。

吾人不應去強調「推CNS 14837好，還是推CMMI-AM、CMMI-ACQ」才對，而應該是兩者兼俱。吾人應以CNS 14837中的籌獲流程為「經」，以CMMI-AM、CMMI-ACQ裡的最佳實務為「緯」，去提升籌獲管理單位的能力。CNS 14837裡的籌獲流程其實是一個完成籌獲管理工作的路徑圖，或者是尋寶圖，而CMMI-AM、CMMI-ACQ裡提供的是相對於這個路徑圖上每一個里程碑、提示、標定物及應採取的行動(例如，向左走十五步，然後向右轉....)，或攻克一些障礙的技術與方法(例如專案規劃、風險管理、專案監督與管制)。這些有沒有用？有這些，不一定保證成功，但沒有這些，可以保證一定不成功！懷疑嗎？把成功的專案的所作所為，與這些標準與規範的最佳實務比較一下就知道了。但在失敗的專案裡，一定幾乎找不到這些最佳實務的影子。

1.就個人專案管理實務經驗而言，CMMI-ACQ、CMMI-AM、SA-CMM、IEEE/EIA-12207四者對於Acquisition Process本身並無多大助益；但IEEE-12207對於Acquirer或Program Manager，在Post Acquisition階段對於Supplier & developer各項相關Development Process的project monitoring確實有幫助，因為標準有助於讓甲乙雙方對於Review、Audit、Test、Documents、…等事項取得溝通平台以便後續驗收之進行，事實上ISO/IEC-12207就是為了International Market所訂定，但國內IT業迄今為止仍堅持標準文件僅適用於飛機與飛彈之設計，自然與International Market無緣；

2.IEEE-12207的5.1 process述及Acquisition Process包括有Request-for-Proposal preparation，但是當你熟讀前述四份標準，你仍然無法完成RFP文件所要求的諸如Statement of Works(SOW)或Statement of Objectives(SOO)的內容(美國政府合約鼓勵買方僅撰述SOO，由乙方撰寫SOW與CDRL)，ISO或IEEE也尚未訂定有關SOW與SOO的標準，因此僅能參考MIL-HDBK-245D；

3.IEEE/EIA-12207已為美國國防部所接受以取代MIL-STD-498，但此項取代僅包括“software development and documentation”，因此在IEEE-12207的Acquisition、Supply、Operation、Maintenance or T等四項Process 並未取代其他Standards，詳參考http://www.dacs.dtic.mil/awareness/broadcasts/broadcast22-MIL-STD-498.shtml ；美國國防部也接受競標商在Proposal中提出IEEE/EIA-12207標準作為軟體發展之Life Cycle Standard ，參考 http://phillips.rmc.ca/courses/493-2000/lectures/19-standards-2.ppt 之page 11；

4.ISO/IEC-12207或IEEE/EIA-12207的Supply與Development Process都是發展端或乙方執行之參用標準，如果要確認執行過程是否落實，就必須委由丙方依據ISO/IEC TR 15504-1 進行Assessment（通常由甲方在RFP中律定），因此(1)甲方可以在RFP中規定執行標準、或(2)乙方在Proposal中建議執行標準，簽約後乙方在PMP文件或是在SRS文件Section 2：Referenced documents. 中，條列參用IEEE/EIA-12207作為軟體發展標準，俾供stakeholders配合參用；

5.CMMI由美國軍方所推動，軍用系統的Acquisition程序所應參用的資料為(1)需求管理：CJCSI 3170、CJCSI 3180、(2)籌獲管理：DoD Directive 5000.1、DoD Instruction 5000.2、Federal Acquisition Regulation (FAR)、DoD 5000.2-R，(2)必需將(1)所確認的需求轉換為RFP文件，全部過程與CMMI-ACQ、CMMI-AM、SA-CMM、IEEE-12207無關，轉換過程注定專案的成敗，2006年美國政府管考辦公室或國家審計總署(Government Accountability Office GAO)針對國防部23項主要武器系統發展計劃(MAIS)進行檢討，有數項成本增加幅度在30%-166%之間，時程延後幅度在23-48個月之間（在推動CMM/CMMI近7年之後），其主要問題發生在PM未能確認需求不夠明確之事實，而未選用Evolutionary Acquisition and Spiral Development（EASD）Model，但這個問題在項目1.的四份文件中無法提供資料，在項目5.(1)、5.(2)則有；

6.SA-CMM迄今尚無相關Maturity Profile發表（可能僅有美國政府管考辦公室或國家審計總署GAO參用），CMMI-AM有部份軍用單位在依據國會責令成立的Software Acquisition Process Improvement Program (SAPIP)程序書中訂定為Self-assessment之依據，CMMI-ACQ則尚未成熟（為了國會的804大法所制定），但無論是SA-CMM、CMMI-ACQ、或CMMI-AM三者都不是採購單位的執行標準(而是評鑑單位的執行標準)，採購單位的執行標準如項目5所列之文件(美國國防部以外的政府部門亦訂定有相似之程序書，如交通部的http://www.dot.gov/ost/m60/tamtar/tar.htm 與 http://fasteditapp.faa.gov/dot/do_action?do_action=ListTOC&contentUID=1 )，如果將評鑑單位執行標準當成工程執行標準，將發生托福考了600分，但卻無法撰寫商業書信的窘況，國內的CMMI-Level 3/5公司不仿參考3323052所撰寫的“CMMI Level 2/3 公司前進國際市場練兵時間到了”一文，自我練兵一番就可以體會要切入International Market的成熟度是否與CMMI相匹配；

7.(1)推動IEEE/EIA-12207等系列標準確實有其急切性與嚴重性，以供工程部門參用，且應優於推動CMMI、(2)對於採購方面更需由各部會自行制定涵括項目5與6的對等文件以及修改採購法供採購部門依循（無法訂定統一的標準），先忘了CMMI-ACQ、CMMI-AM、SA-CMM吧。

不知Fred能不能具體說明一下，實作CMMI-AM與CNS 14837有何不同？我想才不會誤導大家。
------------------------------------------------
Fred在此提到這兩個模式，想必應該很有軟體委外管理的經驗才對，是否能夠就您的經驗，結合CMMI-AM, CMMI-ACQ及CNS 14837來說明一下，到底他們有什麼差異，還有用那一種才是經濟又實惠的模式呢？

敬請賜教！ 。

我的論述重點並不在於拿 CNS 14837 與 CMMI-ACQ 或 CMMI-AM 做比較，而是在於提醒籌獲組織導入 CMMI-ACQ 或 CMMI-AM 的適宜環境與時機需要作審慎的考量。

既然執行籌獲的活動時，這些「應該做的事情」是一樣的，為什麼目前我們自己的國家標準 CNS 14837 都還沒有被成功推廣採用的環境下，卻又另起爐灶呢 ?
再一次重申:
我並非排除國內某些資訊組織或許可以依其需要研究導入 CMMI-AM 或 CMMI-ACQ 的可行性，但是對於大多數的資訊組織而言，還是先把國家標準 CNS14837 好好落實執行再說吧 !

若各位想瞭解國家標準 CNS14837，可到這個網站的 [ 電子報短文集 ] 下載，至於 CMMI-ACQ 或 CMMI-AM，也可以在這個網站的[ 新進檔案 ] 區去下載朱老師的文章。

Fred的論述似乎與之前某位學者在一次研討會場合裡的論述是相類似的 -- 拿ISO/IEC 12207與CMMI做比較(我相信手中有協會所發軟體品質專文集的讀者，應該讀過祕書長所寫的觀念導正文章，蘋果與橘子的比較)。拿CNS 14837與CMMI-ACQ或者CMMI-AM做比較，實際上根本沒有掌握到這兩者本質上的差異。

CNS 14837是軟體生命週期流程的描述，從軟體以時間順序的角度在描述該做的事，而CMMI-AM及CMMI-ACQ談的是不同成熟度的籌獲組織，在執行籌獲的活動時，應該要做那些事。而這些「應該做的事情」是一樣的。所以兩者之間並沒有任何競爭的關係，這些比較是提供顧問的構機基於商業競爭考量所提出來，聰明的讀友應該能夠看透這些訴求的本質才對。

無論 CMMI-AM 也好，CMMI-ACQ 也好，以目前國內資訊單位的成熟度而言，就連依據 ISO/IEC 12207 編譯公布的國家標準 CNS14837 目前都沒幾個政府機關依照政府採購法第 26 條採用於資訊服務委外的現況下，究竟目前導入 CMMI-AM 是否陳義過高了呢，更何況是 CMMI-ACQ ( 大家請參考本討論區 Alexyin 的 CMMI-ACQ 背景介紹吧 )。

我並非排除國內某些較成熟的資訊組織或許可以研究導入 CMMI-AM 或 CMMI-ACQ 的適當性，但是對於大多數的資訊組織而言，還是先把國家標準 CNS14837 好好落實執行再說吧 !

貴協會過去以來積極推廣國家標準 CNS14837 的使用，但似乎還需要再努力，因為還有很多資訊組織根本不知道 CNS14837 是什麼 !