V 모델
IT 위키
더 많은 작업
- V-Model; V 모델
- 폭포수 모델을 확장하여 각 개발 단계에 대응하는 테스트 단계를 짝지어 V자 형태로 표현한 소프트웨어 개발 생명주기 모델
V 모델은 왼쪽 가지에 요구분석에서 코딩까지 내려가는 개발(분해) 단계를, 오른쪽 가지에 단위 테스트에서 인수 테스트까지 올라가는 테스트(통합) 단계를 배치한다. 같은 높이에 있는 단계끼리 짝을 이루며, 왼쪽 단계의 산출물이 오른쪽 대응 테스트의 기준(테스트 베이시스)이 된다. 따라서 테스트 계획과 테스트 케이스를 개발 초기부터 작성할 수 있어 결함을 조기에 발견하는 데 유리하다. 독일 연방정부는 이를 공공 IT 사업의 표준 절차 모델인 V-Modell XT로 발전시켜 운용하고 있다.
요구분석 ←────────────────→ 인수 테스트
\ /
시스템 설계 ←──────→ 시스템 테스트
\ /
상세 설계 ←──→ 통합 테스트
\ /
코딩 ←→ 단위 테스트
| 개발 단계 | 대응 테스트 | 테스트가 확인하는 것 |
|---|---|---|
| 요구분석 | 인수 테스트 | 사용자 요구와 업무 목적을 충족하는가(사용자·발주자 관점) |
| 시스템 설계(아키텍처 설계) | 시스템 테스트 | 전체 시스템이 기능·비기능 요구사항 명세를 만족하는가 |
| 상세 설계 | 통합 테스트 | 모듈 간 인터페이스와 상호작용이 설계대로 동작하는가 |
| 코딩 | 단위 테스트 | 개별 모듈(함수, 클래스)이 명세대로 동작하는가 |
문헌에 따라 시스템 설계를 아키텍처 설계와 구분하거나, 시스템 설계를 통합 테스트에 대응시키는 등 단계 이름과 개수가 조금씩 다르다. 핵심은 상위 단계일수록 상위 수준의 테스트와 대응한다는 점이다.
V 모델은 검증(Verification)과 확인(Validation)을 명확히 구분한다.
| 구분 | 질문 | 내용 | 주요 활동 |
|---|---|---|---|
| 검증(Verification) | 제품을 올바르게 만들고 있는가? | 각 단계 산출물이 이전 단계의 명세와 표준에 맞는지 확인 | 리뷰, 인스펙션, 워크스루, 단위·통합 테스트 |
| 확인(Validation) | 올바른 제품을 만들고 있는가? | 최종 제품이 사용자의 실제 요구와 사용 목적을 충족하는지 확인 | 시스템 테스트, 인수 테스트, 사용자 시연 |
V자의 왼쪽 가지 안에서 단계 간 일치를 따지는 것이 검증이고, 오른쪽 위로 올라가며 사용자 요구 충족을 따지는 것이 확인이다. 검증과 확인을 개발 조직과 독립된 제3자가 수행하는 것을 IV&V(Independent Verification and Validation)라고 한다.
| 구분 | 폭포수 모델 | V 모델 |
|---|---|---|
| 구조 | 단계가 일렬로 진행 | 개발 단계와 테스트 단계를 V자로 대응 |
| 테스트 위치 | 구현 뒤 한 단계로 취급 | 테스트를 여러 수준으로 세분하고 각 개발 단계에 연결 |
| 테스트 설계 시점 | 구현 이후 | 대응 개발 단계에서 미리 설계 |
| 강조점 | 단계별 산출물과 순차 진행 | 검증·확인과 품질 보증 |
| 공통점 | 순차적이며, 요구사항 변경에 유연하지 않다 | |
- 장점
- 단계별 산출물과 대응 테스트가 명확하여 관리와 추적이 쉽다.
- 테스트 설계를 앞당겨 요구사항·설계의 결함을 조기에 발견할 수 있다.
- 요구사항과 테스트 사이의 추적성이 높아 안전·신뢰성이 중요한 시스템에 적합하다.
- 단점
- 요구사항이 초기에 확정되어야 하며 변경 대응이 어렵다.
- 동작하는 소프트웨어가 개발 후반에야 나온다.
- 문서화 부담이 크고 반복·점진적 개발에는 맞지 않는다.
- 요구분석↔인수 테스트, 시스템 설계↔시스템 테스트, 상세 설계↔통합 테스트, 코딩↔단위 테스트 대응
- 검증(올바르게 만드는가)과 확인(올바른 것을 만드는가)의 구분
- 폭포수 모델 대비 테스트 강조, 순차 모델로서의 한계