議題來源：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的查驗後，該構型管理計畫也是會被訂為專案裡構型管理工作的「基準」的。

以上請參考

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

CM內的Baseline需要透過「聯合技術審查」(像SSR或CDR)完成，那請問「聯合技術審查」可以被視為V&V嗎？

在談這個問題前，我們應該先了解與這個問題有關的一些定義。

※ 審查是將軟體產品呈現給專案人員、管理者、使用者、客戶、使用者代表、或其他有利害關係的各方，以獲取評論或核准所進行的過程或會議。

※ 技術審查，是一個對產品進行評論或是否核准的會議或過程，這個產品是屬於技術領域有關的，例如需求規格書、設計說明書、測試個案與測試程序(測試計畫是管理性計畫，其審查屬於「管理審查」)。

※「聯合技術審查」是對技術文件(與資訊)的評論或核准過程，但是是由合約甲乙雙方派出代表，共同擔任主席的方式進行(所以叫「聯合」)。

※ 驗證在檢驗交付驗證的對象是否符合「前一個階段」所加諸其上的「要求(requirements)」的過程；確認在檢驗交付確認的對象產品是否滿足「預期用途(intended use)」及「使用者需要(user's needs)」。

審查是V&V用來達到了解接受V&V之產品狀況的一種「方法」，但是就這樣把「聯合技術審查」當成V&V其實是有些不妥的，因為V&V本身的執行上還有至少四種不同嚴謹程度的執行方式--由甲方找的第三者來實施(古典型IV&V)、由乙方主包商找的第三者來實施(修改型IV&V，但是客觀性較古典型遜色)、由開發團隊中不執行(接受V&V之)產品開發工作的人來實施(內部型IV&V)、以及由開發小組的人員自己來實施(內嵌型V&V)。在觀念上，客戶或者是使用者代表，並不一定會參與V&V的工作，當然，要參加也是可以的。

「審查」過程本身除了「評論產品」的角度外，還有「核准產品」的角度，但是V&V中的審查，是「評論」的角度，運用「審查」從追溯性、一致性、風險、關鍵性、資訊安全等等觀點來「評論」交付V&V的產品，等到沒問題了，再提交給「有權核准的人員或組織」來「審查」(以獲得「核准」)。

個人不建議直接將兩者劃上等號，因為這樣很容易誤導，在實際工作實行上，也會造成缺乏彈性、有效性、或者客觀性等問題。

在實際上的做法上：甲方可以把所有的V&V工作，由乙方來執行，在「聯合技術審查」時，只要看看做的結果(對產品審查的結果紀錄)就決定能不能核准產品(以「核准」為目的的審查)，允不允許進入下一個開發階段。當然甲方若為了慎重起見，而且，早在決定專案期程的時候，就已經決定「聯合技術審查」的作法是以聯席會議的方式來執行所有技術文件審查(還要包括檢驗產品做出評論)，而設定了較長的專案期程，那麼這樣的「聯合技術審查」，會含有V&V的概念在裡面。

如果對於「聯合技術審查」只做「核准」，而擔心「最終產品可能不符合使用者需要」，其作法上可以是，由甲方在合約裡要求派代表參加乙方開發團隊的審查(同儕審查)，這樣除可以確保需求實現的一貫性，亦可以讓開發單位採取正規的工程方法進行開發工作，早期確認需求、維持產出的一貫性、可追溯性，如此方可以減少缺陷，降低重工的成本。畢竟採取非正規方式，由程式撰寫開工，以期儘早獲得結果，通常這樣的專案，幾乎可以說，都是以失敗收場(或許驗收了，但是灰頭土臉，時間比預計的時間超出將近一倍，一年的案子做到快兩年，也許，甲方說：「不罰」，事實上，時間的拖延才是最大的懲罰，因為多出來的人事與營運成本、無法執行新案的機會成本、及人員無法透過正規工程作法獲得成長的機會成本等等成本的總和，絕對比「不罰」的損失更大)。

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