軟體驗證(Verification)和確認(Validation)的目標是要找出軟體產品中的缺失並移除缺失，以期軟體產品能夠符合顧客品質的要求，因此有效的驗證與確認工作，對軟體產品品質的確保有莫大的助益。在衡量驗證與確認的效能時，多數的研究採用缺失移除效能(Defect Removal Effectiveness, DRE)做為度量指標，蒐集軟體開發階段與產品上市之後所發現的缺失數目，以評估開發階段所執行之驗證與確認的有效性。然而，缺失移除效能很明顯地是個落後指標(lagging indicator)，必須等待產品交付給客戶一段時間後，才能夠反應出驗證與確認工作執行的品質。因此若僅僅仰賴落後指標，將會產生無法即時反應缺失的風險，疏漏了潛在的產品缺失至顧客使用者的手中，而造成巨額的不良品質成本。
平衡計分卡認為，績效的衡量必須適當地整合落後指標與領先指標，而領先指標衡量的對象為當下的行動與績效的驅動因子。能力成熟度整合模式 (Capability Maturity Model Integration, CMMI) 的「流程與產品品質保證」流程領域強調必須同時客觀地評估流程與產品的品質。基於以上的想法，本研究提出除了評估軟體產品缺失外，也必須同時評估偵測移除軟體缺失的流程－也就是「驗證」與「確認」。因此為了客觀地評估驗證與確認的作業流程，本研究設計了驗證與確認活動的查核表、回饋量表與一系列的度量指標集 (Software Metrics)，支援驗證與確認活動的執行，蒐集驗證與確認活動的度量值資料，與評估驗證與確認活動的完整性與適切性；再配合分析工作產品在驗證與確認活動時所發現的缺失，軟體開發專案得以在工作產品交付給客戶之前，有系統地評估工作產品的品質，從而擬定合適的品質改善策略與協助專案做合適的決策。

The aim of Verification and Validation is to detect software defects and remove them, and further ensure that the delivered software product meets users' quality requirements and operation expectation. Thus, effective verification and validation processes can benefit a lot to the quality of software products. When measuring the effectiveness of verification and validation activities, most existing researches used the defect removal effectiveness (DRE) as an indicator. Such an indicator needs the defect data removed within the development phases and after the delivery. However, it is obvious that DRE is a legging indicator and its value can only be computed a certain time period after the software delivers to users. If this is the only indicator to rely on, there would be risky that the project team is unable to reflect the real effectiveness of verification and validation processes in time. The project team might leak potential software defects to customers and thereby cause a huge amount of cost of poor quality.
One of key concepts of Balanced Scorecard is to balance lagging indicators with leading indicators, which attempt to quantify future results based on current actions and performance drivers. The “Process and Product Quality Assurance” process area in CMMI model emphasizes that both processes and work products should be objectively evaluated. Based on the above thought, this thesis proposes that besides evaluating software defects, we must also evaluate the defect detection and removal processes, which are Verification and Validation. Therefore, in order to objectively evaluate the verification and validation activities, the thesis presents the observation checklists for evaluating verification and validation activities, scoring questionnaires for getting the feedbacks on performing verification and validation activities, and a set of software metrics for measuring verification and validation activities. The proposed checklists, questionnaires and software metrics can help to collect the measurement data, and analyze the completeness and adequacy of the verification and validation activities. Together with the defect data found and fixed in the verification and validation processes, software project is able to systematically analyze the quality of work products before they are delivered to customers. And project managers can accordingly develop appropriate quality improvement strategy and also make adequate decisions in the improvement of the verification and validation processes.

I. 中文部分
[1] Robert S. Kaplan, David P. Norton 著，朱道凱 譯，「平衡計分卡：資訊時代的策略管理工具」，臉譜文化，民國88 年。
[2] 克勞斯比（Philip B. Crosby）著，陳怡芬 譯，「不流淚的品管」，天下文化，民國84 年。
[3] 史蒂芬。柯維（Stephen R. Covey）著，顧淑馨 譯，「與成功有約」，天下文化，民國84 年。
[4] Jack J. Phillips, Timothy W. Bothell, G. Lynne Snead 著，劉孟華譯，「專案管理計分卡：評估專案管理解決方案的最佳策略工具」，臉譜文化，民國94 年。
[5] 陳俊彥，「以量化軟體度量指標支援CMMI 模式的導入與評鑑」，碩士論文，國立台灣科技大學資訊管理研究所，民國91年。
II. 英文部分
[6] International Standard Organization, “ISO/IEC 12207: 1995, Information Technology – Software Life Cycle Processes”, 1995
[7] IEEE-SA Standards Board, “IEEE Standard for Software Verification and Validation”, IEEE Std 1012-1998, 1998
[8] Carnegie Mellon University Software Engineering Institute, “Capability Maturity Model Integration v1.1”, CMMI–SW/SE, Continuous representation, 2002
[9] Carnegie Mellon University Software Engineering Institute, “The Capability Maturity Model: Guidelines for Improving the Software Process”, Addison-Wesley, 1994
[10] IEEE Standards Board, “IEEE Guide for Software Quality Assurance Planning”, IEEE Std 730.1-1995, 1995
[11] IEEE-SA Standards Board, “IEEE Standard for Software Quality Assurance Plan”, IEEE Std 730-2002, 2002
[12] IEEE-SA Standards Board, “IEEE Standard for Software Test Documentation”, IEEE Std 829-1998, 1998
[13] S. Kan, “Metrics and Models in Software Quality Engineering”, Second Edition, Addison Wesley, 2003
[14] A. Abran, J. W. Moore, P. Bourque, R. Dupuis, & L. L. Tripp, “Guide to the Software Engineering Body of Knowledge: 2004 Version”, IEEE Computer Society, 2004
[15] Institute of Electrical and Electronics Engineers, “IEEE Standard Dictionary of Measures to Produce Reliable”, IEEE Std 982.1-1988, June, 1988
[16] Fagan, M. E., “Design and Code Inspections to Reduce Errors in Program Development,” IBM Systems Journal, Vol. 15, No. 3, 1976
[17] Jones, C., “Programming Productivity”, New York: McGraw-Hill, 1986
[18] Dunn, R. H., “The Quest for Software Reliability”, in G.G. Schulmeyer & J.I. McManus (Eds.), Handbook of Software Quality Assurance, pp. 342–384, Van Nostrand-Reinhold Company, New York, 1987
[19] Daskalanatonakis, M. K., “A Practical View of Software Measurement and Implementation Experiences within Motorola”, IEEE Transactions on Software Engineering, Vol. SE-18, 192
[20] Ebenau, R. G. & Strauss, S. H., “Software Inspection Process”, New York: McGraw-Hill, 1994
[21] Members of the Assessment Method Integrated Team, “Standard CMMI® Appraisal Method for Process Improvement (SCAMPISM), Version 1.1: Method Definition Document”, Carnegie Mellon University, CMU/SEI-2001-HB-001, December 2001
[22] Ferguson, J., “Updated SCAMPISM A Practice Characterization and Aggregation Rules”, SEISM Appraisal Program Communication, SCAMPI-N-0013, Carnegie Mellon University, October 2005
[23] International Standard Organization, “ISO/IEC TR 9126-2: 2003, Software Engineering – Product Quality – Part 2: External Metrics”, 2003
[24] International Standard Organization, “ISO/IEC TR 9126-3: 2001,
Software Engineering – Product Quality – Part 3: Internal Metrics”, 2001
[25] T. W. Williams, M. R. Mercer, J. P. Mucha, and R. Kapur, “Code coverage: what does it mean in terms of quality?”, Proceedings of the Annual Reliability and maintainability Symposium, pp 420-424, Philadelphia, PA, USA, January 2001
[26] Watts S. Humphrey, “Introduction to the Team Software Process”, Addison Wesley, 2000
[27] Watts S. Humphrey, “PSP: a self-improvement process for software engineers”, Addison Wesley, 2005
[28] D. H. Besterfield, C. Besterfield-Michina, G. H. Besterfield, M. Besterfield-Sacre, “Total Quality Management”, third edition, Pearson Education, 2003