從年初到目前參與了幾個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

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