Verification과 Validation은 오래전부터 산업계에서 사용되어 오고 있는 용어라서 각각의 배경, 시대에 따라 그 의미가 조금씩 다르기도 하고 자주 혼용해서 쓰입니다. 이번 기사에서는 이들 용어를 정리해 봅니다.
검증과 확인의 의미
전통적으로 Verification은 ‘검증’으로 번역합니다. 반면, Validation은 ‘유효성 검증’, ‘유효성 확인’, 또는 ‘타당성 확인’으로 번역되는데, 여기서는 ‘확인’으로 하기로 합니다. 참고로 Confirmation은 ‘확증’으로 합니다.
검증은 규격/명세에 부합되는지를 확실히 하는 과정(Process)입니다. (Conform to specification). 한편, 확인은 의도된 용도가 충족되는지를 확실히 하는 과정(Process)입니다. (Fulfill the intended use).
아래 그림은 구현물과, 그것의 요구사항 및 설계와의 관계를 표현합니다. 시스템 계층 원리에 따라 구현물은 시스템이 될 수도 있고 그것의 구성요소 중 하나(예, 소프트웨어 또는 하드웨어 등)가 될 수 있습니다만 여기서는 편의 상 시스템이라고 합니다.
그림을 보면, 시스템(구현물, Implementation)과 그것의 요구사항(Requirements)이 있고 그것을 충족하는 설계(Design)가 있습니다. 시스템의 요구사항은 그 시스템을 필요로 하는 사용자 또는 상위 시스템의 니즈로부터 도출됩니다.
과정 1번은 시스템 또는 구성요소가 그것의 요구사항에 부합하는지를 보이는 것으로서 ‘검증’이라고 할 수 있습니다. 과정 2번은 설계가 요구사항에 부합하는지를 보이는 과정이므로 ‘검증’ 입니다. 과정 3은 시스템 또는 구성요소가 그것의 설계에 부합하는지를 보이는 과정으로서 역시 ‘검증’입니다.
개발 활동에서 검증은 서술된 요구사항과 부합하는지를 결정하기 위해, 설계를 포함한 일련의 활동 결과를 검토하거나 시험하는 프로세스와 관련됩니다. 구현된 시스템은 서술된 요구사항을 충족하는지 검증됩니다. 그렇지만 요구사항을 충족하는 시스템이라 할지라도 실제 사용자나 상위시스템이 운용하기에는 적합하지 않을 수 있습니다. 그러므로 시스템 개발의 완전한 성공 여부를 알기 위해 이를 확증하는 것은 필수적입니다.
사용자 또는 상위 시스템이 의도한 용도(intended use)가 있을 것이고 시스템이 그것을 충족하는지를 보이는 과정이 확인(Validation) 입니다. 그러므로 확인은 주로 최종 구현물을 대상으로 실제 의도한 사용 환경(intended environment)에서 수행됩니다. 그러나, 개발 생명주기동안 요구사항, 설계를 대상으로 확인 프로세스를 수행할 수 있습니다. 이것은 각각 요구사항 확인(Requirements validation), 설계 확인(Design validation)이라고 합니다. 이것들은 경쟁력 있는 개발을 위해서 매우 중요한 활동들이며 반드시 수행되어야 합니다.
아래 표는 Verification과 Validation을 항목별로 비교한 내용입니다.
하지만 일부 의견에서는 소프트웨어의 경우 소스코드를 실행하지 않고 검증하는 영역이 Verification이고, Validation은 소스코드의 실행이 반드시 되어야 한다고 이야기하고 있습니다. 이러한 내용은 Verification을 매우 좁은 의미로 해석을 한 내용이며, Automotive-SPICE® 나, ISO 26262, ISO/SAE 21434에서 요구하는 Verification 의미에는 적절하지 않을 수 있습니다.
표준에서의 정의
참고로 표준에서 정의된 내용을 옮겨 봅니다.
검증 (Verification)
명시된 요구사항이 충족되는지 객관적인 증거의 제공을 통한 확증 (Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled) [ISO/IEC 12207, 15288, 25000]
주어진 개발 단계의 제품이 그 단계의 시작에서 부과된 조건을 만족하는지 결정하기 위해 시스템이나 구성요소를 평가하는 프로세스 (the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase) [IEEE STD 1012]
Validation
생명주기 정황에서 시스템이 그것의 의도된 용도, 목적과 목표를 달성할 수 있다는 확신을 보장하고 얻어 내는 활동들의 집합 (In a life cycle context, the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals and objectives) [ISO/IEC 12207, 15288, 25000]
소프트웨어와 그것의 관련 제품이 각 생명주기 활동의 끝에서 소프트웨어로 할당된 시스템 요구사항을 만족하는지, 올바른 문제를 해결하는지, 의도된 용도와 사용자 니즈를 만족하는지 증거를 제공하는 과정 (the process of providing evidence that the software and its associated products satisfy system requirements allocated to software at the end of each life cycle activity, solve the right problem, and satisfy intended use and user needs) [IEEE STD 1012]
결론
‘검증’은 다음 물음에 대한 답을 하는 과정입니다. “제대로 만들고 있는 것인가? (Make the thing right?)”
그러면, “제대로 된 것을 만들고 있는 것인가? (Make the right thing?)”에 대한 답을 하는 과정은 ‘확인’입니다.
참고 문헌
- ISO/IEC 12207:2008 (IEEEStd12207-2008), Systems and software engineering — Software life cycle processes
- ISO/IEC 15288:2008 (IEEE Std 15288-2008), Systems and software engineering — System life cycle processes
- ISO/IEC 25000:2005, Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE
- IEEE Std 1012-2004 IEEE Standard for Software Verification and Validation.
- Requirements Engineering Fundamentals, 2nd Edition, Klaus Pohl and Chris Rupp, 2015, rockynook