引文:
為避免被誤導，讀者可以再回MIL-HDBK-287的MIL-HDBK-287第19頁，"4.3.5 Where are tailoring decisions specified?"小節中。而且建議讀者最好手上就有MIL-HDBK-287與DOD-STD-2167A (雖然都已被美國軍方cancel掉，但仍舊很有參考價值)，可以實際翻出來對照(連小弟typo都歡迎拿出檢討、指正)。
a. Statement of Work. Tailoring decisions for standard are specified in the contract SOW. A typical tailoring statement is:
The contractor shall comply with all requirements of DOD-STD-2167A with the following exceptions:
4.1.2 Delete entire paragraph
4.2.9 Delete reference to software development files
etc.

本段是教導DOD-STD-2167A及MIL-HDBK-287的使用者，裁適後該納到那裡。這裡是指這些裁適決策(亦即裁適結果)，會納到SOW中。當然一旦這些裁適決策納到SOW中時，那麼他們就成為SOW中的一項，這時才會成為Statements of work的一部分。注意後列這段話，正因為是在合約/RFP的SOW寫了"The contractor shall comply with all requirements of DOD-STD-2167A"，這個時候，DOD-STD-2167A，才與SOW發生關聯，"The contractor shall comply with all requirements of DOD-STD-2167A"是SOW的一個項目，但是DOD-STD-2167A本身是不是SOW呢？當然不是，它是與計畫/專案工作(tasks)、過程(processes)有關之requirements的來源。納在合約/RFP中的此項SOW，是指示contractor要遵循(comply with)這些(DOD-STD-2167A中的)requirements去完成其工作，達到計畫/專案的目標，後段"with the following exceptions:"，指示contractor遵循時所要去掉相對的requirements項目。若 RCI@Taiwan 要說因此DoD-STD-2167A繼承那段話的屬性(是為合約/RFP中的SOW)，而成為"標準SOW"，似乎也太牽強，這麼說的其理由可以參看美國聯邦法規法典(Code of Federal Regulations)：
TITLE 48 - FEDERAL ACQUISITION REGULATIONS SYSTEM (聯邦獲取法規制度, FARS)
CHAPTER 3 - HEALTH AND HUMAN SERVICES
SUBCHAPTER B - COMPETITION AND ACQUISITION PLANNING
PART 307 - ACQUISITION PLANNING (獲取規劃)
307.7106 - Statement of work. (工作條款)
其對於工作條款的觀點來判斷了。

註：
Statement of work - 指單純的一項工作條款敘述；Statements of work - 指SOW文件。
就像Specification指一項規格，Specifications指規格書；Description指一項說明，而Descriptions指說明書。

引文:

基本上MIL-HDBK-287附錄A是一份可以直接用於專案中的"Tailoring Worksheet"，既然是一份裁適工作表，把所有的裁適時該考慮的項目都列出來是必要的。但是，這是份工作表，基於其格式使然，所有項目必須全列，以相同的方式呈現，所以沒有所謂是不是能否"排除被"D"掉"的問題(儘管每一個項目的前面欄位都有"K D R"字樣，是格式所要求的一貫性的標示而已，參見MIL-HDBK-287, 第51至62頁)，我認為"不能排除被"D"掉"這句話是一項誤解。舉例來說，從發展的角度(DOD-STD-2167A之存在，就是為了軟體發展)來看，試試將"4.1 software development management"之4.1.1(軟體發展過程)、4.1.2(正規審查/稽核)、4.1.3(軟體發展規劃)、4.1.4(風險管理)、4.1.9(矯正措施過程)刪掉("D"掉)看看....。如果有，那必定是個失敗的案子。我們要談可以"D"掉，那麼舉的例子，必定是"D"掉之後，專案還是可以成功才行(就工程本身的努力，政治力介入不算)。

附帶一提：CMMI的使用者，在自己公司的工程/工程管理制度建立後，公司裡的裁適指引，可以依樣畫葫蘆，弄一份自己公司工程/工程管理制度用於專案時的裁適工作表，當然，其所提列的項目得源自公司的practices，而不是DOD-STD-2167A。(這麼做時，公司本身也能審視自己公司的CMMI制度是不是夠強大，夠不夠應用於各種類型的軟體發展專案了)

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