V 모델 (V-Model) 정의 (소프트웨어 공학)

V 모델은 시스템의 품질을 보장하기 위해 검증 및 테스트 단계를 강조하는 소프트웨어 개발 모델입니다. 테스트를 더 강조하는 폭포수 모델의 수정된 버전입니다. 폭포수 모델은 문서 중심이지만 V 모델은 각 개발 단계를 검증하는 데 중점을 둡니다.

테스트에 중점을 둔다는 점에서 모델 내 각 테스트 단계의 세부 사항을 검토하는 것이 특히 중요합니다. 오늘은 각 단계의 주요 활동과 테스트 방법에 대해 자세히 살펴보겠습니다.

1. V모델 정의

해당 모델에서 왼쪽은 소프트웨어 개발 생명주기(SDLC)이며, 오른쪽은 소프트웨어 테스트 생명주기(STLC)입니다. 또한, 이 모델 전체적으로 V자 모양과 유사하여 V-모델이라는 명칭이 사용되고 있습니다

V-모델은 구조화된 접근 방식을 따르는 소프트웨어 개발 프로세스이며 프로젝트 초기에 자세한 문서 및 테스트 활동을 포함하여 프로젝트 비용과 시간을 줄입니다. 이 모델은 현재 소프트웨어 개발 수명 주기에서 가장 널리 채택되는 접근 방식이며 각 개발 단계는 동시에 병렬로 수행되는 해당 테스트 단계에 해당합니다. 유효성 검사 및 확인 모델로 알려진 이 모델은 폭포수 모델과 마찬가지로 프로젝트가 완료될 때까지 선형 방식으로 진행되는 일련의 단계를 설명합니다.

(1) 이 모델은 소프트웨어 공학에서 시스템의 검증과 테스트 작업에 중점을 둔 모델로 개발
(2) 소프트웨어 테스트는 개발 과정의 전 단계에서 밀접하게 연계
(3) 각 단계에서는 적합한 테스트가 진행

2. V 모델 용어설명

• SDLC (Software Development Life Cycle):
SDLC는 소프트웨어 개발 수명주기로, 고품질의 소프트웨어를 설계하고 개발하기 위한 일련의 활동입니다. SDLC는 '개발'이라는 용어를 사용하지만 코딩 작업뿐만 아니라 테스터와 이해 관계자의 작업도 포함합니다. SDLC에서는 테스트 케이스를 작성합니다.

• STLC (Software Test Life Cycle):
STLC는 소프트웨어 테스팅 수명주기로, 테스터가 방법론적으로 소프트웨어 제품을 테스트하기 위한 일련의 활동으로 구성됩니다. STLC는 '테스팅'이라는 용어를 사용하지만 테스터뿐만 아니라 개발자도 참여해야 하는 경우도 있습니다. STLC 테스트에서는 사례가 실행됩니다.

• 폭포수 모델:
Waterfall 모델은 순차적인 소프트웨어 개발 활동의 여러 단계로 나눠진 모델입니다. 각 단계는 SDLC 단계에서 특정 활동을 수행하도록 설계되었습니다. 폭포수 모델의 테스트 단계는 시스템 구현이 완료된 후에 시작됩니다. 테스트는 SDLC 내에서 수행됩니다.

• 확인 (Verification):

소프트웨어 제품이 사용자의 요구사항에 맞게 설계되고 있는지, 객관적인 증거 자료를 통해 확인하는 과정입니다. 이는 요구사항 문서와 설계서 등 소프트웨어 생명주기에서 생성된 자료를 바탕으로 이루어집니다

• 검증 (Validation):

소프트웨어 제품이 사용자의 요구사항을 충족하는지 확인하는 과정으로, 실행 파일이나 소스 코드 형태 등 제품 실행을 수반합니다. 따라서 소프트웨어 제품의 실행 과정에서 검증이 이루어지게 됩니다.

※ Verification & Validation

구분	확인 (Verificaiotn)	검증 (Validation)
테스트 방식	코드리뷰, 인스펙션 (Inspection, Peer Review) 정적인 테스트 과정	제품 또는 소프트웨어 동작 (단위, 통합, 인수 등) 동적인 테스트 과정
테스트 대상	설계문서, 소스코드	만들어진 제품, 소프트웨어
테스트 관점	개발자 (Internal)	사용자 (External)
테스트 시점	초기 개발단계, 설계단계 (개발 단계 이전)	전체 개발 주기에서 단계별 완료 시점(개발중간) 혹은 개발완료 시점
목적	요구사항이 실제 작동하는지 요구사항데로 개발하는지 검증	설계도가 제대로 된것인지 요구사항대로 개발되었는지 검증
대상	제품 생산 활동	생산된 제품 대상

3. V 모델 특징 (장단점)

1) V 모델 장점

• V 모델은 작고 간단한 프로젝트에 적용하기 쉽고 효율적인 접근 방식입니다.
• 테스트 계획 및 디자인과 같은 많은 테스트 활동이 초기에 수행되므로 많은 테스트 시간을 절약할 수 있습니다.
• 대부분의 결함과 버그는 프로젝트 개발 초기에 발견되므로 최종 테스트에서 이러한 문제가 발생할 가능성이 적습니다.

2) V 모델 단점

• 프로젝트 초기에 오류를 예측하는 데 더 많은 시간이 소요될 수 있습니다. (불필요한 문서 생성)
• 프로세스 진행 중에 변경사항이 생길 경우 대처하기 어렵습니다.
• 개발 중간에 변경 사항이 있으면 테스트 문서 및 요구 사항 등 모든 부분에서 변경이 어려울 수 있습니다.

4. V모델 단계 및 활동

▣ Verification

1) 요구사항 분석 (Requirement Analysis) :

요구 사항 분석에는 사용자 요구 사항을 분석하고 사용자 요구 사항 문서를 작성하여 시스템 요구 사항을 수집하는 작업이 포함됩니다. 이 문서에는 기능, 물리적, 인터페이스, 성능, 데이터 및 보안 요구 사항이 포함되어 있으며 시스템 설계 단계에서 설계자를 위한 가이드 역할을 합니다. 사용자 수용 테스트를 위한 설계도 이 단계에서 수행됩니다. 이 단계는 클라이언트의 필요와 기대를 이해하기 위해 클라이언트와 발생한 전체 커뮤니케이션을 기록합니다. 이 단계를 요구 사항 수집이라고 합니다.

2) 시스템 설계 (System Design) :

시스템 설계는 시스템 엔지니어가 시스템을 분석 및 이해하고 소프트웨어 사양 문서를 작성하는 곳입니다. 이 문서는 시스템 구성, 메뉴 구조, 데이터 구조 및 비즈니스 시나리오의 예를 설명합니다. 엔터티 다이어그램 및 데이터 사전과 같은 설명 데이터도 생성되고 시스템 테스트를 위한 문서가 준비됩니다. 시스템 설계를 정교화하고 소프트웨어 제품 개발을 위한 세부적인 H/W 및 통신 인프라를 확보하는 단계입니다.

3) 아키텍처 설계 (Architecture Design) :

아키텍처 설계와 소프트웨어 아키텍처 설계는 함께 고급 설계 단계를 형성합니다. 아키텍처 기준은 모듈 항목, 해당 기능, 인터페이스, 관계 및 종속성과 필수 데이터베이스 테이블 및 기술 세부 정보를 정의합니다. 통합 테스트를 위한 설계도 생성됩니다. 팀 설계자는 시스템 설계를 기능이 다른 구성 요소로 분할했습니다. 핵심 모듈과 외부 세계(다른 하위 시스템) 간의 데이터 교환도 기록됩니다.

4) 모듈설계 (Module Design) :

저수준 설계라고도 하는 모듈 설계는 모듈 항목을 더 세분화하고 각 모듈에 대한 설명을 작성하여 프로그래머가 코딩을 시작할 수 있도록 합니다. 각 모듈의 자세한 기능 논리, 인터페이스 세부 사항, 오류 코드 및 메시지, 입력 및 출력, 데이터베이스 테이블 구조를 설명하는 저수준 설계 문서 또는 프로그램 사양이 생성됩니다. 단위 테스트를 위한 사례와 절차도 이 단계에서 설계됩니다. 팀 설계자는 시스템 설계를 기능이 다른 구성 요소로 분할했습니다. 핵심 모듈과 외부 세계(다른 하위 시스템) 간의 데이터 교환도 기록됩니다.

▣ Validation

1) 단위 테스트(Unit Test) :

개별 모듈(기능, 서브루틴, 구성 요소)의 기능을 확인하여 논리적 오류를 감지하고 세부 설계 사양에 따라 올바르게 구현되었는지 확인하는 테스트 프로세스입니다. 개발자는 모듈 개발 작업을 하면서 UTP(단위 테스트 계획)를 준비합니다. 여기에는 프로그래밍/모듈 수준에서 버그를 발견하기 위해 실행되는 시나리오가 포함됩니다.

2) 통합 테스트(Integration Test) :

모듈 간 인터페이스를 검증하고 개별 모듈 통합 시 발생할 수 있는 오류를 확인하는 테스트 프로세스. 주로 모듈 간의 적절한 상호 작용과 올바른 작동을 위한 적절한 연결을 확인하는 데 중점을 둡니다. 단위 수준 유효성 검사를 마친 후 통합 테스트가 발생합니다. 여기에서 팀은 구성 요소를 통합하고 시스템을 검증합니다. 통합 테스트는 Architecture 설계 단계에서 실행됩니다. 이 방법은 요소 간의 통신을 확인합니다.

3) 시스템 테스트(System Test) :

개별 모듈을 통합한 후 전체 시스템이 제대로 작동하는지, 사용자 요구 사항을 충족하는지 확인하는 테스트 프로세스입니다. 단위 수준 유효성 검사를 마친 후 통합 테스트가 발생합니다. 여기에서 팀은 구성 요소를 통합하고 시스템을 검증합니다. 통합 테스트는 Architecture 설계 단계에서 실행됩니다. 이 방법은 요소 간의 통신을 확인합니다.

4) 인수 테스트 (Acceptance Test) :

사용자가 시스템을 승인하기 전에 시스템이 예상대로 작동하고 사용자 요구 사항 문서에 지정된 요구 사항을 충족하는지 확인하는 테스트 프로세스입니다. UAT는 프로덕션 수준 환경에서 발생하는 테스트 활동입니다. 전달된 제품이 클라이언트 요구 사항을 충족하고 프로덕션에서 실행할 준비가 되었는지 확인합니다.

오늘은 구조화된 접근 방식을 통해 소프트웨어 버그 및 결함의 가능성을 최소화하면서 제품의 품질을 향상시킬 수 있는 "V 모델"에 대해 알아보았습니다.