從年初到目前參與了幾個IV&V案子的前期作業，發現一個有趣的現象，部分IV&V案的業主似乎對於IV&V的真正意義並沒有完全理解，因此在選商階段就發生了一些有趣的狀況。

V&V其實是一項管理的手段或者方法，在透過一些程序的執行，以確保產品可以滿足要求(驗證)，以及符合使用目的(確認)，驗證與確認也是屬於品質管理的技術方法。IV&V則是將驗證與確認的工作交給與開發單位在財務、技術及管理上沒有關係的單位來執行。驗證與確認並不涉及被交付之產品的技術問題，驗證與確認在透過審查、評估、測試、分析、模擬等等方法，去證實「對的東西，用對的方法，做對了」，但這些對的方法在哪裡？有些來自於客戶的需求、國家標準、國際標準、有些來自於法令規章的要求，因此，如果客戶給的東西「本來就不對」了，那麼經過V&V之後，錯的東西並不會變好，既然不會變好，那為什麼要有這些驗證與確認流程與工作項目？

IV&V透過程序方法，在有效管理的狀況下，相關人員(可以包括客戶、外部評估人員)一起來檢驗交付驗證與確認的產品，如果源頭是對的，在交付驗證與確認的項目發現了不一致的狀況，或者有出入的狀況，那就是一項缺陷或異常事項，這個異常事項就要被提出來控管，直到被修正完畢為止。但是如果源頭就是錯的了，那是完全沒有救的，但是問題是，一定是有人知道它是錯的，才會被判定為「錯」(為什麼不能早點說？因為一開始根本不知道，早知道就早改掉了吧，但是這個時候「歸罪於外」的心態又開始作祟，推給開發者、推給IV&V的人最好了)，如果是經由驗證確認的執行才發現問題，這還算好，如果是使用者最後才發現不對了，那就要好好檢討是那個環節出問題了。如果IV&V的程序與方法沒有錯，大家也是全力以赴地實施被要求的驗證與確認工作事項，那麼顯然問題不太會是在整個過程裡，甚至於是開發的過程，而是最原來的需求就不對了。軟體產品的問題愈早被發現及解決，那麼rework的成本將可以大幅地降低。研究顯示，一個需求階段的問題，如果沒有及時解決，在向後傳遞之後，所造成的漣漪效應(又稱為「軟體雪球效應」)，其矯正的成本將以10倍數地成長，所以這也就是為什麼絕大多數缺乏工程管理的專案都面臨了成本大幅增加，時程嚴重落後的問題，這也就是為什驗證與確認一直被視為工程管理裡面很重要的一項流程。驗證與確認透過一些技術(其中以追溯性為最重要)的協助，去找出問題與不一致性，以防止軟體的需求「愈實作愈錯」的狀況。

反觀現在一些IV&V的業主的想法卻是，在需求或需求相關技術沒有想清楚之時，卻非常急於把建置案委辦出去，然後希望IV&V服務的提供廠商能夠幫忙提供技術性的解決方案。其實，後者算是額外的一些技術服務項目，並不包括在IV&V原來設計的工作範圍之內。若有這樣子的需求，其實在開立IV&V案的RFP之初就應該把所有的需求寫清楚，而以不切實際的想法去找一個管理導向的專業單位，去實作技術顧問服務，並且認為只要是「資訊技術領域」都可以做到「軟體管理領域」的事項，如果真是如此，就不會發生現在的軟體業還需要導入CMMI，建立標準軟體發展流程了。但是我們也要知道，軟體管理這個領域常規的抬頭，目的就是在管理資訊技術所造成的問題，使得軟體的專案可以有機會如期如質地完成。

以上對於驗證與確認的觀念，取自CMMI V1.1，CMMI-DEV V1.2、ISO/IEC 12207、CNS 14837、IEEE Std 1012-2004。
有關V&V與品質管理的關係，請參閱CNS 14837及ISO/IEC 12207

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

有關IV&V的執行準則(Criteria)可參考以下NASA所頒布的文件

http://www.esast.com/Download/ivvcrit.pdf

有的時候業主本身的觀念不正確，也將導致V&V執行上的困難。

因為，產出需求的過程本身並未被經過V&V，卻又要求整個過程要V&V，等V&V發現問題後，才認真的去檢討需求，再修正原來的需求。

但某些軟體的需求一修正，後面的分析、設計等於要重來，這一來一往之間浪費了大量的時間、人力、金錢。

sune0722所談到的並不是更最糟的。我曾經有個經驗，我幫業主(政府機關)寫徵求建議書(RFP)，其中包括了需求、及根據需求而來的品質特性及驗收準則，然而業主卻擔心這些要求廠商做不到，同時也是為了要保命(免得無法驗收)(這個說法亦令我非常感冒)，所以通通被拿掉，可以預判這個專案又將成為另外一個失敗的案例。

像功能性、可靠性、可用性、可維護性等等品質要求，與產品設計會有關係，因此，缺乏這些項目，除了可能造成案子很難驗收之外，也顯示業主顯示缺乏工程規劃能力，另外對於需求沒有做到V&V，則是代表業主內部缺乏良好的委外過程管理制度。

能力成熟度模型的發展過程當中，在美國國會運用立法的程序，要求政府部門在委外上要運用正規的獲取管理作法，這亦指CMMI的發展，亦獲得美國國會的認同，否則，美國美國防部對於SEI的財力支援從何而來？在過去SEI所主導，對於美國國防部所屬單位十多個軟體獲取專案的研究發現，當供應者(乙方)與獲取者(甲方)都不俱備工程管理、專案管理、過程管理的能力的話，專案都會造成災難性的後果，如果供應者有那些能力而獲取者沒有的話，供應者的能力將無法發揮，整個專案的走向都會被獲取者所誤導造成無法驗收或是驗收期延長(但通常獲取者不會承認那是他們的錯誤與無知所造成)，如果獲取者有相關的能力，供應者沒有，儘管結果可能無法預測，但是獲取者可以事先採取一些預防措施，儘可能使專案朝向正面發展。

當然最好的狀況是供應者與獲取者雙方都具備了相關的能力，那麼專案的成功機率是極高的(當然還是可能受到外界的不確定因素及不可抗力的因素影響)。所以獲取者的能力真的非常重要，甚至於較供應者的成熟度更為重要。如果可行，國內立法院應該要透過立法，將這些對於獲取者在工程與管理能力的要求，納入採購法當中，以促進軟體委外服務案的成功，及減少公帑的浪費。

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