검사와 타당성 검증

검증과 검정(영어: Verification and validation)은 소프트웨어 프로젝트 관리와 테스트 그리고 작성에서 소프트웨어 시스템이 사양을 만족하는지와 이것이 의도된 목적을 만족시키는가를 검사하는 과정이다. 이러한 과정은 소프트웨어 품질 조정으로 불리기도 한다. 이 과정은 소프트웨어 개발주기로써 보통 소프트웨어 시험관의 책임감이다.

• 의료기기 규격에선 verification을 검증(IEC60601-1, ISO 14971)으로, validation을 유효성 확인 내지 인증(IEC62366)으로 번역한다.[1]

정의

검사는 제품 디자인이 의도된 사용을 만족시키거나 의도된 사용에 적합한지, 즉 소프트웨어가 사용자의 요구를 만족시키는지를 검사한다. 이 행위는 활발한 테스트와 다른 형태의 검사를 통해 이루어진다.

검사와 검증은 헷갈리기는 하지만 같은 개념이 아니다. Boehm은 간단명료하게 차이점을 설명했다.

• Verification: Are we building the system right?

검증 : 우리가 제품을 올바르게 빌드하고 있나? (이것은 디자인과 코드를 검사하는 정적인 방법이다. 소프트웨어 검사는 인간기반의 문서와 파일의 검사이다.)

• Validation: Are we building the right system?

검정 : 우리가 올바른 제품을 빌드하고 있나? (이것은 실제 제품을 검사하고 테스트하는 동적인 과정이다. 소프트웨어 검증은 항상 코드실행을 수반한다.)

능력 성숙도 모델(CMMI-SW v1.1)에 따르면,

• 소프트웨어 검사 : 개발단계의 제품이 단계의 시작부분에서 부과된 조건을 만족시키는지를 결정하기 위해 소프트웨어를 평가하는 과정이다.
• 소프트웨어 검증 : 소프트웨어가 특정 요구조건을 만족시키는가를 결정하기 위해 개발과정 중, 또는 끝에 소프트웨어를 평가하는 과정이다.

다시 말해 소프트웨어 검사는 제품이 요구조건과 디자인 사양에 따라 빌드 되었는지를 확실하게 하는 작업인 반면에, 소프트웨어 검증은 제품이 정확하게 사용자의 필요를 충족시키는가와, 사양이 애당초에 올바랐는지를 확실하게 하는 작업이다. 소프트웨어 검증은 ‘올바르게 빌드하고 있는가’를 확인한다. 소프트웨어 검증은 ‘올바른 것을 빌드하고 있는가’를 확인한다. 소프트웨어 검사는 제품이 제공되었을 때 그것의 의도된 용도를 만족하는지를 확인한다.

테스트의 관점에서

• 잘못 : 코드 안에서의 잘못 또는 빠진 기능
• 실패 : 실행 중 잘못의 발현
• 오작동 : 시스템 사양에 따른 제품의 특정 기능 불 충족

관련개념

검사와 검증은 둘 다 소프트웨어 품질보장의 개념과 관련되어 있다. 하지만 이것들만으로는 소프트웨어의 품질을 보장할 수 없다. (계획, 추적성, 형상관리 그리고 소프트웨어 개발의 다른 측면이 요구된다.)

모델링과 시뮬레이션(M&S)의 공동체 안에서는 검사와 검증 그리고 인증의 정의는 비슷하다.

• M&S 검사는 컴퓨터 모델과 시뮬레이션, 즉 모델과 시뮬레이션의 실행, 그리고 그것들의 관련정보가 개발자의 개념 설명과 사양을 정확하게 나타내는 가에 관한 결정과정이다.
• M&S 검증은 모델과 시뮬레이션, 즉 모델과 시뮬레이션, 그리고 그것들의 관련정보가 의도된 용도의 관점에서의 현실세상을 정확히 표현하는가에 관한 정도의 결정과정이다.
• 인증은 모델 또는 시뮬레이션이 특정 목적에 사용될 수 있는가에 관한 공식적인 검증이다.

M&S 검사의 정의는 정확도에 초점을 맞추는데 M&S는 이 정확도로 현실세계에서의 의도된 용도를 나타낸다. M&S 정확도의 정도 측정은 M&S가 현실의 근사치이기 때문에, 그리고 정확도는 대개 근사치의 정도가 의도된 용도에 적합한지를 결정하는데 중요한 역할을 하기 때문에 필요하다. M&S는 소프트웨어 검증과 대조가 된다.

방법의 분류

무결점의 수행능력이 완전히 중요시되는 임무수행에 필수적인 소프트웨어 시스템에서는 시스템의 올바른 작동을 확인하기 위해 정형기법을 사용할 수도 있다. 하지만 임무수행에 필수적이지 않은 소프트웨어 시스템에서는 정형기법이 아주 돈이 많이 드는 것으로 밝혀졌고 소트웨어 V&V의 대체 가능한 방식이 찾아져야만 한다. 이런 경우에서는 종종 통사론적 방법이 사용된다.

테스트 사례

테스트 사례는 과정 안에서 사용되는 도구이다. 테스트 사례는 제품이 사용자의 필요에 따라 빌드 되었는가를 결정하기 위해 소프트웨어 검사와 소프트웨어 검증을 위해 준비될 수 있다. 검토와 같은 다른 방법들은 소프트웨어 검증을 준비하기 위해 제품생산 초반에 사용될 수 있다.

독립적인 검사와 검증

소프트웨어 검사와 검증은 종종 개발팀의 세분화된 그룹에 의해 이루어진다. 이러한 경우에 그 과정은 독립적인 검사와 검증 또는 간단히 IV&V로 불린다.

제어환경

검증과 검정은 법이 규정된 산업에서 필요 준수를 만족시켜야 하는데, 법이 규정된 산업은 정부단체에 의해, 또는 산업 행정부의 권위에 의해 이끌어진다. 예를 들어 FDA는 소프트웨어의 버전과 패치가 유효한지를 요구한다.

참고 자료

1. Boehm, B.W. (1989). "Software Risk Management". IEEE Computer Society Press.
2. Jump up to: a b c "Department of Defense Documentation of Verification, Validation & Accreditation (VV&A) for Models and Simulations". Missile Defense Agency. 2008.
3. Jump up ^ "General Principles of Software validation; Final Guidance for Industry and FDA Staff" (PDF). Food and Drug Administration. 11 January 2002. Retrieved 12 July 2009.
4. Jump up ^ "Guidance for Industry: Part 11, Electronic Records; Electronic Signatures — Scope and Application" (PDF). Food and Drug Administration. August 2003. Retrieved 12 July 2009.
5. Jump up ^ "Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-the Shelf (OTS) Software" (PDF). Food and Drug Administration. 14 January 2005. Retrieved 12 July 2009.
6. 1012-2012 IEEE Standard for System and Software Verification and Validation. 2012. doi:10.1109/IEEESTD.2012.6204026. ISBN 978-0-7381-7268-2. *Tran, E. (1999). "Verification/Validation/Certification". In Koopman, P. Topics in Dependable Embedded Systems. Carnegie Mellon University. Retrieved 2007-05-18.
7. Menzies, T.; Y. Hu (2003). "Data mining for very busy people". IEEE Computer 36 (1): 22–29. doi:10.1109/MC.2003.1244531.