SDLC V-Model

SDLC V-Model

V-모델은 프로세스가 V자 모양으로 순차적으로 실행되는 SDLC 모델의 한 유형이다. 확인 및 검증 모델이라고도 한다. 각 해당 개발 단계에 대해 테스트와 연관성을 기반으로 한다. 각 단계의 개발은 직접적으로 해당하는 테스트 단계와 연결된다. 다음 단계는 이전 단계가 완료된 후에만 시작된다. 즉, 각 개발 활동에는 해당하는 테스트 활동이 있다.

 

V-Model은 소프트웨어 개발 프로세스의 체계적이고 시각적인 표현을 제공하는 SDLC(소프트웨어 개발 수명 주기) 모델이다. "V"의 두 다리는 소프트웨어 개발 프로세스가 요구사항 수집 및 분석에서 설계, 구현, 테스트 및 유지보수에 이르기까지 진행되는 과정을 나타내는 "V" 모양의 아이디어를 기반으로 한다.

 

V-모델은 소프트웨어 개발에 대한 선형 및 순차적 접근 방식을 따르는 소프트웨어 개발 모델이다. 

다음 단계로 구성된다.

• 요구사항 수집 및 분석: V-Model의 첫 번째 단계는 소프트웨어에 대한 고객의 요구 사항을 수집하고 분석하여 프로젝트 범위를 결정하는 요구 사항 수집 및 분석 단계이다.
• 시스템 설계: 설계 단계에서는 상위 설계 및 상세 설계를 포함하여 소프트웨어 아키텍처 및 설계를 진행한다.
• 구현: 이 단계에서는 이전 단계에서 만든 설계 사양에 따라 소프트웨어를 개발한다.
• 테스트: 테스트 단계에서 소프트웨어는 고객의 요구 사항을 충족하고 고품질인지 확인하기 위해 테스트를 진행한다.
• 배포: 배포 단계에서는 소프트웨어가 배포되고 사용자에 의해 사용된다.
• 유지관리: 유지보수 단계에서 소프트웨어는 고객의 요구와 기대를 지속적으로 충족할 수 있도록 유지 관리된다.

V-모델은 항공우주 및 국방과 같은 안전이 중요한 산업에서 일반적으로 사용되는 소프트웨어 개발 방법론이다. 이는 V-Model이 포괄적인 테스트를 강조하고 소프트웨어 개발 프로세스를 위한 명확하고 잘 정의된 단계를 제공하기 때문이다.

 

확인(Verification): 코드를 실행하지 않고 수행되는 정적 분석 기법(리뷰)을 수행한다. 지정된 요구 사항이 충족되는지 여부를 확인하기 위해 제품 개발 단계를 평가하는 과정이다.

검증(Validation): 동적 분석 기법(기능적, 비기능적)을 포함하며, 코드를 실행하여 테스트를 진행한다. 검증은 개발 단계가 완료된 후 소프트웨어가 고객의 기대와 요구 사항을 충족하는지 여부를 판단하기 위해 소프트웨어를 평가하는 프로세스이다.

 

그래서 V-모델은 "V" 모양과 같은 형태를 가지며, 확인(Verification) 단계와 검증(Validation) 단계가 V자 모양으로 배치되어 있다. 확인과 검증 단계는 V자 모양에서 코딩(Coding) 단계를 통해 연결되어 있다. 이러한 이유로 이것을 V-모델이라고 부른다.

설계 단계

• 요구사항 분석: 이 단계에는 고객과의 상세한 의사소통이 필요하다. 이를 통해 고객의 요구사항과 기대사항을 이해한다. 이 단계는 요구사항 수집(Requirement Gathering) 단계라고도 한다.
• 시스템 설계: 이 단계에는 제품 개발을 위한 시스템 설계와 완전한 하드웨어 및 통신 설정이 포함된다.
• 아키텍처 설계: 시스템 설계는 다양한 기능을 수행하는 모듈로 분할되며, 내부 모듈 및 외부 시스템과의 데이터 전송 및 통신 방식이 명확하게 이해해야 한다.
• 모듈 설계: 이 단계에서 시스템을 작은 모듈로 분할한다. 모듈의 상세설계는 Low-Level Design (LLD)이라고도 불린다.

테스트 단계

• 단위 테스트: 단위 테스트 계획은 모듈 설계 단계에서 수행된다. 이 단위 테스트 계획은 코드 또는 단위 수준에서 버그를 제거하기 위해 실행한다.
• 통합 테스트: 단위 테스트가 완료된 후 통합 테스트가 수행됩니다. 통합 테스트에서는 모듈을 통합하고 시스템을 테스트한다. 통합 테스트는 아키텍처 설계 단계에서 수행된다. 이 테스트는 모듈 간 연계가 올바르게 이루어지는지 검증한다.
• 시스템 테스트: 시스템 테스트는 기능성, 상호 의존성 및 연계를 포함한 완성된 애플리케이션 프로그램을 테스트한다. 이는 개발된 애플리케이션의 기능 및 비기능 요구사항을 테스트한다.
• 사용자 인수 테스트(UAT): UAT는 운영 환경과 유사한 사용자 환경에서 수행된다. UAT는 배포된 시스템이 사용자 요구사항을 충족시키는지 확인하고 시스템이 실제 환경에서 사용할 준비가 되어 있는지를 검증한다.

산업적 도전 과제: 산업이 발전함에 따라 기술은 더욱 복잡하고, 점점 더 빠르며, 계속해서 변화하고 있다. 그러나 IT가 아직 초창기였을 때와 같이 적용 가능한 기본 원칙과 개념 집합이 여전히 존재한다.

• 사용자 요구사항을 정확하게 정의하고 개선한다.
• 합의되고 승인된 사용자 요구사항에 따라 애플리케이션을 설계하고 구축한다.
• 개발한 애플리케이션이 승인된 비즈니스 요구사항을 준수하는지 검증한다.

V-모델의 원칙

• 대소 원칙(Large to Small): V-Model에서 테스트는 계층적 관점에서 수행된다. 예를 들어, 프로젝트 팀이 식별한 요구사항은 프로젝트의 상위 설계 및 상세 설계 단계를 수행한다. 각각의 단계가 완료될 때마다 정의되는 요구사항은 더욱 정제되고 상세화 된다.
• 데이터/프로세스 무결성: 이 원칙은 모든 프로젝트의 성공적인 설계에는 데이터와 프로세스의 통합과 일관성이 필요하다는 것을 말한다. 각 요구사항에서 프로세스 요소를 식별해야 한다.
• 확장성: 이 원칙에서는 V-Model 개념이 모든 IT 프로젝트가 규모, 복잡성 또는 기간에 관계없이 수용할 수 있는 유연성을 갖추고 있어야 한다는 것이다.
• 교차 참조: 요구사항과 해당 테스트 간의 직접적인 상관관계를 교차 참조라고 한다.
• 구체적인 문서화: 이 원칙은 모든 프로젝트가 문서를 작성해야 한다는 것을 명시한다. 문서는 프로젝트 개발 팀과 지원 팀 양쪽에서 필요로 하며, 운영 환경에서 애플리케이션을 유지 관리하는 데 활용된다.

왜 선호하는가?

• 모델의 엄격함으로 인해 관리가 용이하다. V-Model의 각 단계에는 특정 산출물과 검토 프로세스가 있다.
• 사전 예방적 결함 추적 – 즉, 초기 단계에서 결함이 발견된다.

언제 사용하는가?

• 요구사항이 명확하게 정의되고 확정된 경우.
• V-Model은 기술 리소스가 충분하고 기술적 전문성이 있는 경우.

장점

- 이 모델은 매우 체계적이며 각 단계는 하나씩 완료된다.

- V-Model은 프로젝트 요구사항이 명확한 소규모 프로젝트에 사용된다.

- 간단하고 이해하기 쉽고 사용하기 쉽다.

- 이 모델은 라이프 사이클 초기에 확인 및 검증 활동에 중점을 두어 오류가 없고 고품질의 제품을 만들 확률을 높다.

- 프로젝트 관리자가 진행 상황을 정확하게 추적할 수 있다.

- 명확하고 체계적인 프로세스: V-Model은 소프트웨어 개발을 위한 명확하고 체계적인 프로세스를 제공하므로 이해하고 진행하기가 더 쉽다.

- 테스트 강조: V-Model은 소프트웨어의 품질과 신뢰성을 보장하는 데 도움이 되는 테스트에 중점을 둔다.

- 추적성 향상: V-Model은 요구 사항과 최종 제품 간의 명확한 링크를 제공하므로 소프트웨어의 변경 사항을 더 쉽게 추적하고 관리할 수 있다.

- 커뮤니케이션 개선: V-Model의 명확한 구조는 고객과 개발 팀 간의 커뮤니케이션 개선에 도움이 된다.

단점

- 높은 위험과 불확실성.

- V-Model은 복잡한 객체 지향 프로젝트에 적합하지 않다.

- 요구 사항이 명확하지 않고 변경 위험이 높은 프로젝트에는 적합하지 않다.

- 이 모델은 단계 반복을 지원하지 않는다.

- 동시에 발생하는 이벤트를 쉽게 처리하지 못한다.

 - 경직성: V-모델은 선형 및 순차 모델이므로 변화하는 요구 사항이나 예기치 않은 이벤트에 적응하기 어려울 수 있다.

- 시간 소모적: V-모델은 많은 문서화와 테스트가 필요하므로 시간이 많이 소요될 수 있다.

- 문서화에 대한 지나친 의존: V-모델은 문서화에 중점을 두어 실제 개발 작업보다 문서화에 대한 지나친 의존으로 이어질 수 있다.