小弟得思考一下，再繼續這個討論串的意義、必要性，對於讀者的幫助會有多大。
小弟現在大抵對我國政府軍購案的問題又獲得了一些理解。我想，小弟大概只能為這個討論串，做個結語：吾人該與時俱進，深度學習，旁徵博引。

有任何獲取方計畫/專案經理，在規劃CSCI的發展時把Formal Review/Audit(2167A的4.1.2)刪除，那真是太勇敢了，我如果是他/她的長官，我會叫他/她回家好好反省反省吧。當然，把審查與稽核砍掉，代表軟體在發展時，是完全不會用到MIL-STD-1521B (Technical Reviews and Audits for Systems, Equipments, and Computer Software)的。但是這亦代表，獲取方放任供應方(合約商)恣意胡為，完全不予控制的意思。這就跟現在許多政府部門資訊業務委外專案有何分別？他們在發展期間對相關發展文件、技術文件，合約商的工作完全不聞不問(文件最多改改typo、wording、標點符號)，只管--程式寫好了沒？--寫好了，我們開始測試吧...，又有何差別？裁適，有許多原則，但對於這種在專案中不做不可的活動，是不會全盤刪除的，而是在執行頻率、深度與範圍去做一些調整。

美國軍方的文件，如果沒有新增或修改，就不會有版本的問題，或也不需要改版。MIL-HDBK-881(1998)與881A(2005)就有很多地方不同，包括連長的樣子都不大一樣。軟體工程有關的美軍標準1679->2167->2167A->498，一路走來，多有變革，環境變了，相應指導文件(DoDD, DoDI)多了，從業人員亦該隨之成長。就像美國軍方亦在隨之成長一樣，進入了裁適自ISO/IEC 12207-1995(E)的IEEE/EIA 12207-1996，到現在，透過IEEE，直接與ISO/IEC 12207:2008接軌，因為ISO/IEC 12207:2008亦即全等於IEEE STD 12207-2008(ISO標準直接將兩者家標準的識別符放在一起)。而文件標準裡IEEE/EIA 12207.1由ISO/IEC 15289所取代(請參閱ISO/IEC 12207-2008中IEEE部分的前言)，未來IEEE/EIA 12207.2將會由新版本的ISO/IEC TR 15271所取代。

1679/2167/2167A/498/ISO/IEC 12207在沒有計畫/專案時，亦可以存在，其存在之目的，就是在描述一個軟體生命週期全程(或僅發展部分的生命週期)過程而已，是一份描述性的文件，在給讀者一個標準的軟體生命週期過程的完整印象(具有對從業人員的教育意義)。當然，透過一些方式進入專案時，又是另外一回事了。

在1994年時Dr. Jerome G. Lake在Program Manager, September-October 1994寫了一篇DO WE NEED THE STATEMENT OF WORK? (我們真的需要工作條款嗎？)其結論如下：
Current SOWs are redundant, not well-prepared, and lead to confusion and inefficiencies in providing high-quality products and services with orrect performance features at an affordable price and on time. The time for acquisition reform is now. One place to start is with the SOW.

This exposition challenges the conventional wisdom which dictates that a SOW be utilized to guide the performing activity in a contractual effort. Reform in acquisition requires a challenge to this thinking. I have asserted that a lengthy SOW is no longer needed. I have justified this assertion for acquisitions that have a specification, WBS, and CDRLs, and that require a SEMP, with an accompanying SEMS. The synergy of these documents, with other management documents and plans, provides necessary and sufficient information to guide performing activities in accomplishing a contractual effort, and to provide enough information to tasking activities to track and assess an effort.

Radical ideas often create entrenchment by those who want to protect established and conventional methods. I challenge you to reflect on the arguments presented herein. I trust that such reflection will alter your mind-set on the need for a lengthy SOW associated with a contractual effort for development of a system, large or small, new or incremental. Where my logic has holes in it resulting from my lack of knowledge, don’t prematurely throw away the ideas initiated herein. To my arguments, add your ideas and any needed documents available to the program office to help reduce the need of, and reliance on, lengthy SOWs.

Finally, until management directs the radical change encouraged herein, perhaps as you prepare your next SOW you will reflect on this article. Remember to flow the SOW from the WBS, use MIL-HDBK-245 as a guide, and tailor references in Section III. We just might get better SOWs.
而在此頁一個框框中的文字是： "The existence of specifications, CDRLs and WBS dictionary tasks in the RFP/contract are not sufficient to justify eliminating the SOW as structured today." (規格、CDRL及WBS字典工作的存在，在今天並不足做為消去RFP/合約結構中之SOW的正當理由)。

在今日MIL-HDBK-245 (245C，年份為1991)依然存在，而且改版至MIL-HDBK-245D (1996，之後即無新版本，245D也沒有canceled)。依然作為美軍計畫之合約SOW發展之指導。當然，前後版本之間必定有些改進吧。

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