議題來源：liangh

CM的目的在達到產品的完整性，而V&V是透過逐次、階段式或階層式地對產品(工作產品)做查核(check)與檢驗(examine)，以使最終的產品符合需求(verification)與符合使用目的(validation)。在實際運用上，V&V還含有風險管理的性質(請參閱：IEEE std 1012-2004)。

我們曾經談過，CM的幾項活動是：構型(建構)識別、構型管制、狀態記述(status accounting)、審查/稽核、及發行管理等。

這些過程(V&V、CM)中的活動裡，常用到的技術就是審查、檢視、核對、稽核等。但是共同使用這些技術，並不表示這些之間有強烈的關聯性存在，因為在產品開發的前期，沒有程式產出之前，是無法執行動態測試的，因此靜態的活動(看似沒有加值作用的工作，實質上可以儘早發現缺陷的存在，降低rework的成本，而rework成本通常會佔掉全部開發成本的50%以上，能省下來就是賺錢了，所以大家應該要多多利用才對)就變得非常重要了，而這些技術也會讓每個支援性過程看起來都非常類似。

因為V&V與CM工作各有所司，但如果一定要說關聯的話，我想是先後次序關係吧。其實CM裡的版本管制及基準訂定(baseline)所賦予的版次識別編號，是根據審查通過、沒有問題的構型項目來賦予的，但是CM的過程裡，baseline的工作(task)裡並不需要去做以提出評論為目的的審查工作，而是去看這個構型項目的通過審查(評論，V&V的結果的紀錄，包含風險分析、關鍵性分析、危害分析等等)的結果紀錄，以前我在執行專案的做法是，經過聯合技術審查(像SSR或CDR)(這與V&V中的審查工作有重疊)的文件，我在回覆給廠商的文當中，我通常會帶到一段話：「本文件(項目)已通過審查，並訂為產品發展之基準，請貴公司督導開發團隊據此執行產品發展工作。」。廠商收到這份公文之後，賦予該構型項目最新的版本(修訂)版次，填寫文件中的修訂史略(revision history)，然後置於構型管理系統裡管制，在系統裡將此構型項目的編號建立起來、將其狀態欄位改為「baselined(訂為基準)」，以及訂為基準的時間(可以是公文的時間，或是審查通過的時間，這個甲乙雙方有共識即可)。

狀態記述有一部分的資訊是彙整這些審查通過的核准紀錄而來的。構型管制的CCB(性質是「(需求)變更的管理審查會」)及審查/稽核裡的功能性與物理性構型稽核，則是用到一些通用的審查及稽核的流程。

根據IEEE Std 1012在需求V&V工作針對完整性層級屬於3及4的產品，要執行構型管理評鑑，其主要目的只是在看看專案的構型管理過程/計畫，是否完整、充分、合宜，當然通過這些V&V的查驗後，該構型管理計畫也是會被訂為專案裡構型管理工作的「基準」的。

以上請參考

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