2025 SW공학

IEEE 1012 표준에서 정의하는 V&V(Verification & Validation, 검증 및 확인)는 시스템, 소프트웨어, 하드웨어의 개발 및 유지보수 전 과정에서 산출물이 요구사항에 부합하는지(검증)와, 실제로 의도한 용도와 사용자 요구를 만족하는지(확인)를 조직적이고 체계적으로 평가하는 일련의 프로세스입니다[1][2][3][4][6].

IEEE 1012의 V&V 개념¶

• 검증(Verification): 개발 산출물이 상위 단계의 요구사항, 표준, 규정, 설계 명세 등과 일치하는지 확인하는 활동입니다. 즉, “우리가 올바르게 만들고 있는가?”를 확인합니다.
• 확인(Validation): 완성된 제품이 실제 사용 환경에서 사용자 요구와 의도된 용도에 부합하는지 평가하는 활동입니다. 즉, “우리가 만든 것이 올바른 것인가?”를 확인합니다[1][2].

V&V의 적용 범위¶

• 시스템, 소프트웨어, 하드웨어 전체 생명주기(기획, 개발, 시험, 설치, 운영, 유지보수)에 걸쳐 적용됩니다.
• 신규 개발뿐 아니라, 유지보수, 재사용(레거시, COTS, 비개발품 등)에도 적용됩니다.
• 소프트웨어에는 펌웨어, 마이크로코드, 문서 등도 포함됩니다[1][2][3].

V&V 주요 활동¶

IEEE 1012에서 정의하는 V&V 활동은 다음과 같습니다.

• 분석(Analysis)
• 평가(Evaluation)
• 리뷰(Review)
• 인스펙션(Inspection)
• 평가(Assessment)
• 테스트(Testing)

이러한 활동을 통해 산출물의 정확성, 완전성, 일관성, 추적성, 성능, 안전성 등을 확인합니다[1][2][3][4].

무결성 수준(Integrity Level)¶

• 시스템, 소프트웨어, 하드웨어의 중요도, 위험도, 안전성 등에 따라 4단계 무결성 수준을 정의합니다.
• 무결성 수준이 높을수록 V&V 작업의 강도와 엄격함이 증가합니다.
• 각 무결성 수준별로 최소 수행해야 하는 V&V 작업이 다르게 정의되어 있습니다[2][3][4].

V&V 프로세스 구조¶

IEEE 1012-2016 기준, V&V 프로세스는 다음과 같이 구성됩니다[3][4][6]:

• 공통(Common) V&V 활동: 시스템, 소프트웨어, 하드웨어에 공통 적용되는 일반적인 V&V 활동
• 시스템(System) V&V 활동: 시스템 레벨의 V&V 활동
• 소프트웨어(Software) V&V 활동: 소프트웨어 레벨의 V&V 활동
• 하드웨어(Hardware) V&V 활동: 하드웨어 레벨의 V&V 활동

각 영역별로 단계별(요구분석, 설계, 구현, 시험 등)로 필요한 V&V 작업이 명확히 정의되어 있습니다.

V&V 계획 및 관리¶

• V&V 활동은 독립적으로 수행될 것을 권장하며, V&V 계획(SVVP, Software Verification and Validation Plan)과 결과 보고서 작성이 요구됩니다[5][6].
• 각 생명주기 단계별로 V&V 작업, 방법, 입력/출력, 일정, 자원, 위험, 역할과 책임이 명확히 정의되어야 합니다[5][6].

요약¶

IEEE 1012의 V&V는 제품이 요구사항과 표준에 부합하고, 실제 사용 목적과 사용자 요구를 만족하는지 생명주기 전반에 걸쳐 다양한 방법(분석, 평가, 리뷰, 인스펙션, 테스트 등)으로 체계적으로 확인하는 활동입니다. 무결성 수준에 따라 V&V의 강도와 범위가 달라지며, 모든 활동은 명확한 계획과 문서화가 필수입니다[1][2][3][4][6].

Citations:
[1] https://standards.ieee.org/ieee/1012/7324/
[2] https://www.kns.org/files/pre_paper/37/17S-486%EA%B9%80%EC%A7%84%EA%B5%AC.pdf
[3] https://blog.naver.com/suresofttech/222891168851
[4] https://www.ivvgroup.com/the-new-ieee-std-1012-2016-is-available/
[5] https://www.govinfo.gov/content/pkg/GOVPUB-C13-4681de0278eeec5ff2be27a300771804/pdf/GOVPUB-C13-4681de0278eeec5ff2be27a300771804.pdf
[6] https://www.kns.org/files/pre_paper/50/23A-456-%EA%B9%80%EB%8F%99%ED%9D%AC.pdf
[7] https://blog.naver.com/jackhwang0210/221502204709
[8] https://digital-library.theiet.org/doi/10.1049/pbhe012e_ch8?doi=10.1049%2FPBHE012E_ch8
[9] https://people.eecs.ku.edu/~hossein/Teaching/Stds/1012.pdf
[10] https://sosodev.tistory.com/entry/VV-%EB%8B%A4%EC%96%91%ED%95%9C-%EA%B5%AD%EC%A0%9C-%ED%91%9C%EC%A4%80

Verification 활동의 정의와 목적¶

IEEE 1012 표준에서 Verification(검증)은 개발 산출물(예: 요구사항, 설계, 코드, 문서 등)이 해당 단계의 명세와 요구사항에 부합하는지 확인하는 체계적인 활동입니다. 즉, "우리가 올바르게 만들고 있는가?"를 판단하는 과정입니다[1][2][3][5].

Verification의 주요 활동¶

Verification은 소프트웨어, 시스템, 하드웨어의 생명주기 전 단계에서 반복적으로 수행되며, 다음과 같은 구체적인 활동을 포함합니다.

• 요구사항 리뷰(Requirement Review)
  
  요구사항 명세서가 완전하고, 명확하며, 일관성 있고, 테스트 가능하게 작성되었는지 검토합니다[3].

• 설계 리뷰(Design Review)
  
  설계 산출물이 상위 요구사항과 일치하는지, 논리적 결함이나 누락이 없는지 체계적으로 검토합니다[3].

• 코드 리뷰(Code Review)
  
  소스코드가 설계 명세와 일치하는지, 코딩 표준을 준수하는지, 오류나 결함이 없는지 동료 개발자와 함께 점검합니다[2][3].

• 정적 분석(Static Analysis)
  
  소스코드를 실행하지 않고, 자동화 도구를 활용해 결함, 보안 취약점, 유지보수성 문제 등을 사전에 탐지합니다[2][3].

• 워크스루(Walkthrough)
  
  개발자 또는 테스터가 산출물(코드, 설계, 테스트 케이스 등)을 동료들에게 설명하며 잠재적 문제를 발견하는 비공식적 검토 활동입니다[3].

• 인스펙션(Inspection)
  
  체크리스트와 역할 분담을 통한 공식적이고 구조화된 산출물 검토로, 결함을 체계적으로 식별합니다[3].

• 유닛 테스트(Unit Testing)
  
  개별 모듈이나 함수 단위로 테스트 케이스를 작성·실행해, 각 컴포넌트가 명세대로 동작하는지 확인합니다[2][3].

• 테스트 케이스 및 시나리오 리뷰(Test Case Review)
  
  테스트 케이스가 요구사항을 충분히 커버하는지, 테스트 설계가 적절한지 검토합니다[3].

• 추적성 점검(Traceability Check)
  
  모든 요구사항이 설계, 구현, 테스트에 반영되어 있는지 추적성을 확인합니다[3].

Verification의 절차(프로세스)¶

1. 요구사항 분석: 요구사항의 명확성, 완전성, 검증 가능성 평가
2. Verification 활동 계획 수립: 적용할 검증 기법, 책임자, 일정 정의
3. 산출물 준비: 검증 대상 문서, 코드, 설계 등 준비
4. Verification 수행: 리뷰, 분석, 정적 테스트, 단위 테스트 등 실행
5. 결과 기록 및 결함 관리: 발견된 결함 및 이슈를 문서화하고, 수정 및 재검증 수행
6. 보고 및 승인: 검증 결과를 요약해 이해관계자에게 보고하고, 다음 단계로의 진행 승인

Verification의 특징¶

• 정적 활동이 주를 이룸: 실행 없이 문서, 코드, 설계를 검토하는 활동이 많음
• 개발 각 단계에서 반복적으로 수행: 요구, 설계, 구현, 테스트 등 모든 단계에서 적용
• 결함의 조기 발견 및 비용 절감: 개발 초기에 결함을 발견해 품질 향상과 비용 절감 효과
• Validation과의 구분: Verification은 "제품이 올바르게 만들어졌는가?"를 확인, Validation은 "올바른 제품이 만들어졌는가?"를 확인

요약¶

Verification은 요구사항, 설계, 코드, 문서 등 모든 산출물이 해당 단계의 명세와 요구조건을 충족하는지 반복적으로 검토, 분석, 테스트하는 활동입니다. 이를 통해 결함을 조기에 발견하고, 제품의 품질과 신뢰성을 확보할 수 있습니다[1][2][3][5].

Citations:
[1] https://standards.ieee.org/ieee/1012/7324/
[2] https://www.sqs.es/software-verification-and-validation/?lang=en
[3] https://www.browserstack.com/guide/verification-and-validation-in-testing
[4] https://www.govinfo.gov/content/pkg/GOVPUB-C13-4681de0278eeec5ff2be27a300771804/pdf/GOVPUB-C13-4681de0278eeec5ff2be27a300771804.pdf
[5] https://www.complianceonline.com/resources/software-verification-and-validation-overview-and-must-have-documents.html
[6] https://www.kns.org/files/pre_paper/50/23A-456-%EA%B9%80%EB%8F%99%ED%9D%AC.pdf
[7] https://www.nrc.gov/docs/ML1420/ML14204A406.pdf
[8] https://people.eecs.ku.edu/~hossein/Teaching/Stds/1012.pdf
[9] https://digital-library.theiet.org/doi/10.1049/PBHE012E_ch8
[10] https://blog.naver.com/suresofttech/222891168851

Validation 활동의 정의와 목적¶

IEEE 1012 표준에서 Validation(확인)은 개발된 시스템, 소프트웨어, 하드웨어가 실제 사용자 요구와 의도된 용도를 충족하는지 평가하는 활동입니다. 즉, "우리가 올바른 제품을 만들었는가?"를 판단하는 과정입니다[1][3][5].

Validation의 주요 활동¶

Validation은 주로 최종 산출물(제품, 시스템, 소프트웨어 등)이 실제 환경에서 사용자 기대와 요구를 만족하는지 확인하기 위해 수행되며, 다음과 같은 구체적인 활동을 포함합니다.

• 사용자 요구 검토(User Needs Review)

  • 개발된 시스템/소프트웨어가 실제 사용자 요구와 기대를 충족하는지, 사용 목적에 적합한지 평가합니다.

• 수용(인수) 테스트(Acceptance Testing)

  • 실제 운영 환경 또는 사용자 환경에서 제품을 시험하여, 명시된 요구사항과 사용 목적을 만족하는지 확인합니다.
  • 고객, 사용자, 도메인 전문가 등이 직접 참여하는 경우가 많습니다.

• 현장 시험(Field Testing) 및 베타 테스트(Beta Testing)

  • 실제 사용 환경에서 제품을 제한적으로 배포하여, 사용자 피드백을 수집하고, 실사용에서의 문제점을 확인합니다.

• 프로토타입/시제품 평가(Prototype Evaluation)

  • 제품의 초기 버전이나 프로토타입을 통해, 주요 기능이 사용자 요구에 부합하는지 조기에 확인합니다.

• 시나리오 기반 평가(Scenario-based Evaluation)

  • 실제 사용 시나리오를 활용해, 제품이 다양한 실제 상황에서 적절히 동작하는지 평가합니다.

Validation의 특징¶

• 사용자 중심 활동: Validation은 고객, 사용자, 도메인 전문가 등 실제 이해관계자가 반드시 참여해야 하며, 이들의 피드백이 핵심입니다[5].
• 실제 환경과 용도에 초점: 제품이 실제로 사용될 환경, 목적, 업무 흐름에서 요구를 충족하는지 확인합니다.
• 동적 테스트가 주를 이룸: 실제 제품을 실행하거나, 실환경에서 시험하는 동적 테스트 활동이 Validation의 핵심입니다.
• 공식적/비공식적 방법 모두 활용: 인수 테스트처럼 공식적인 시험뿐 아니라, 베타 테스트, 사용자 평가 등 비공식적 방법도 포함됩니다.

Verification과 Validation의 비교¶

Validation의 절차(프로세스)¶

1. Validation 계획 수립: 어떤 사용자 요구와 사용 시나리오를 검증할 것인지 정의
2. 테스트 및 평가 수행: 인수 테스트, 현장 시험, 사용자 평가 등 실행
3. 피드백 및 결함 관리: 사용자 피드백, 발견된 문제점 기록 및 분석
4. 결과 보고 및 승인: Validation 결과를 고객/이해관계자에게 보고, 제품 인수 결정

요약¶

Validation은 개발된 제품이 실제 사용자 요구와 의도된 용도에 적합한지, 즉 "올바른 제품"이 만들어졌는지를 실제 환경과 사용자 관점에서 평가하는 활동입니다. 인수 테스트, 현장 시험, 사용자 평가 등 다양한 방법을 통해, 제품의 실질적 가치와 적합성을 최종적으로 확인합니다[1][3][5].

Citations:
[1] https://standards.ieee.org/ieee/1012/7324/
[2] https://www.ivvgroup.com/the-new-ieee-std-1012-2016-is-available/
[3] https://en.wikipedia.org/wiki/Software_verification_and_validation
[4] https://www.govinfo.gov/content/pkg/GOVPUB-C13-4681de0278eeec5ff2be27a300771804/pdf/GOVPUB-C13-4681de0278eeec5ff2be27a300771804.pdf
[5] https://pvs-studio.com/en/blog/posts/0049/
[6] https://people.eecs.ku.edu/~hossein/Teaching/Stds/1012.pdf
[7] https://digital-library.theiet.org/doi/10.1049/pbhe012e_ch8?doi=10.1049%2FPBHE012E_ch8
[8] https://blog.naver.com/suresofttech/222891168851
[9] https://www.kns.org/files/pre_paper/37/17S-486%EA%B9%80%EC%A7%84%EA%B5%AC.pdf
[10] https://blog.ansi.org/2018/10/ieee-1012-2016-verification-validation-vv/