맨위로가기

V 모델

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

V 모델은 소프트웨어 개발 프로세스 모델의 한 유형으로, V자 형태의 다이어그램을 사용하여 개발 단계를 시각적으로 표현한다. 독일 정부의 공식 프로젝트 관리 방법론인 V-Modell을 포함하여 여러 유형이 있으며, 시스템 개발 수명 주기를 명세(specification) 흐름과 테스팅(testing) 흐름으로 구분하여 각 단계별 활동과 결과물을 정의한다. 검증(Verification)과 유효성 확인(Validation)을 통해 품질을 보장하고 프로젝트의 위험을 최소화하는 것을 목표로 하며, 독일과 미국에서 독립적으로 개발되어 상업 및 국방 분야에서 널리 활용된다.

더 읽어볼만한 페이지

  • 소프트웨어 프로젝트 관리 - 소프트웨어 개발
    소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
  • 소프트웨어 프로젝트 관리 - 애자일 소프트웨어 개발
    애자일 소프트웨어 개발은 1990년대에 등장하여 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 핵심 가치로 삼고 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구하는 소프트웨어 개발 방법론이다.
  • 소프트웨어 공학 - 통합 개발 환경
    통합 개발 환경(IDE)은 코드 편집, 빌드, 디버깅 등 소프트웨어 개발에 필요한 여러 기능을 통합적으로 제공하는 응용 프로그램이다.
  • 소프트웨어 공학 - 소프트웨어 개발
    소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
V 모델
개요
시스템 개발 생명주기의 그래픽
시스템 개발 생명주기의 그래픽
유형시스템 개발 생명주기
개발자독일 연방 국방부
첫 출시1992년
안정화1997년
최신 버전V-Modell XT 2.2 (2018년 3월)
특징
목적프로젝트 실행을 위한 지침 제공
사용 분야소프트웨어 개발, 하드웨어 개발, 기타 시스템 개발
모델 구조
단계요구사항 정의, 설계, 구현, 테스트, 통합
검증 및 확인각 단계별로 수행
문서화상세한 문서 작업 요구
장점
체계적인 접근 방식프로젝트 관리 용이
품질 보증각 단계별 검증으로 품질 향상
위험 감소초기 단계에서 문제점 발견 가능
단점
경직성변경 사항 반영 어려움
문서화 부담과도한 문서 작업 필요
시간 소모각 단계 완료 후 다음 단계 진행
관련 모델
비교워터폴 모델, 애자일 개발
확장V-Modell XT

2. 유형

V 모델은 여러 유형으로 나뉜다. 대표적인 유형은 다음과 같다.

thumb


  • 일반적인 테스팅 (General testing): 국제 소프트웨어 테스팅 자격 기구 재단 커리큘럼에서는 소프트웨어 개발 프로세스 모델로 V 모델을 소개한다.[10] V 모델(V-Modell)은 단일 정의가 없으며, 다양한 변형이 존재한다.[10]
  • V-Modell: 독일 정부의 공식 프로젝트 관리 방법론이다. PRINCE2와 유사하지만 소프트웨어 개발과의 연관성이 더 높다.[6]
  • 미국 정부 표준 (US government standard): 시스템 개발 수명 주기 모델의 일종이다. 영국의 실무자와 테스터가 V 모델로 이해하는 것보다 훨씬 더 상세하고 엄격하다.


현재 버전은 V-Model XT로 불리며, 2005년 2월에 완성되었다. 능력 성숙도 모델 통합(CMMI)과는 직접적으로 경쟁하지 않는다. CMMI는 "무엇을" 해야 하는지를 보여주는 반면, V 모델은 거기에 더해 "어떻게", "언제", "누가" 책임을 지고 수행해야 하는지도 보여준다.

V 모델은 독일 정부 관련 소프트웨어 개발 공정을 규정하기 위해 개발되었다. 소프트웨어 개발 과정에서 수행해야 할 활동과 그 결과물을 규정하고 있다. V 모델은 소프트웨어 개발의 라이프 사이클을 그래픽으로 표현한 것이기도 하다. 자동화된 시스템 검증 프레임워크와 관련된 단계들을 요약하고 있다.

V자형으로 표시되는 개념도의 왼쪽은 시스템의 사양을 기술해 가는 흐름을 나타낸다. 오른쪽은 테스트의 흐름을 나타낸다. 각각 같은 높이에 있는 부분은 개발의 상세 수준을 나타낸다.

V 모델의 구성요소는 다음과 같이 간단하게 요약될 수 있다.

구분내용
사양 책정사용자 요구 사항 사양, 기능 사양, 설계 사양(상세 사양)
테스트 실행인수 테스트, 운용 테스트, 성능 테스트


2. 1. V-Modell

V 모델은 독일 정부의 공식 프로젝트 관리 방법론으로, PRINCE2와 유사하지만 소프트웨어 개발과의 연관성이 더 높다.[6] "V"자 형상의 표현을 사용하는 핵심 속성은 V의 왼쪽에서 생성된 산출물이 V의 오른쪽에 있는 테스트 및 통합 조직에 의해 허용 가능한지 여부에 대한 증거를 요구하는 것이다.[7][8][9]

thumb

현재 버전은 V-Model XT로 불리며, 2005년 2월에 완성되었다. 능력 성숙도 모델 통합(CMMI)과는 직접적으로 경쟁하지 않는다. CMMI는 "무엇을" 해야 하는지를 보여주는 반면, V 모델은 거기에 더해 "어떻게", "언제", "누가" 책임을 지고 수행해야 하는지도 보여준다.

V 모델은 독일 정부 관련 소프트웨어 개발 공정을 규정하기 위해 개발되었다. 소프트웨어 개발 과정에서 수행해야 할 활동과 그 결과물을 규정하고 있다. V 모델은 소프트웨어 개발의 라이프 사이클을 그래픽으로 표현한 것이기도 하다. 자동화된 시스템 검증 프레임워크와 관련된 단계들을 요약하고 있다.

V자형으로 표시되는 개념도의 왼쪽은 시스템의 사양을 기술해 가는 흐름을 나타내고, 오른쪽은 테스트의 흐름을 나타낸다. 각각 같은 높이에 있는 부분은 개발의 상세 수준을 나타낸다.

V 모델은 주로 다음과 같은 작업으로 구성된다.

  • 사양 책정
  • 사용자 요구 사항 사양
  • 기능 사양
  • 설계 사양(상세 사양)
  • 테스트 실행
  • 인수 테스트
  • 운용 테스트
  • 성능 테스트

2. 2. 일반적인 테스팅 (General testing)

국제 소프트웨어 테스팅 자격 기구 재단 커리큘럼에서는 소프트웨어 개발 프로세스 모델로 V 모델을 소개한다.[10] V 모델(V-Modell)은 단일 정의가 없으며, 다양한 변형이 존재한다.[10]

thumb

2. 3. 미국 정부 표준 (US government standard)

미국 정부 표준 V 모델은 시스템 개발 수명 주기 모델의 일종이다. 영국의 실무자와 테스터가 V 모델로 이해하는 것보다 훨씬 더 상세하고 엄격하다.

V 모델의 개념도


현재 버전은 V-Model XT로 불리며, 2005년 2월에 완성되었다. 능력 성숙도 모델 통합(CMMI)과는 직접적으로 경쟁하지 않는데, CMMI는 "무엇을" 해야 하는지를 보여주는 반면, V 모델은 "어떻게", "언제", "누가" 책임을 지고 수행해야 하는지도 보여주기 때문이다.

V 모델은 독일 정부 관련 소프트웨어 개발 공정을 규정하기 위해 개발되었으며, 소프트웨어 개발 과정에서 수행해야 할 활동과 그 결과물을 규정하고 있다. 또한 소프트웨어 개발의 라이프 사이클을 그래픽으로 표현한 것이자 자동화된 시스템 검증 프레임워크와 관련된 단계들을 요약한 것이다. V자형으로 표시되는 개념도의 왼쪽은 시스템의 사양을, 오른쪽은 테스트의 흐름을 나타내며, 각각 같은 높이에 있는 부분은 개발의 상세 수준을 나타낸다.

3. 검증과 유효성 확인

V 모델에서는 검증(Verification)과 유효성 확인(Validation)을 구분하여 사용한다. 유효성 확인은 "올바른 것을 만들고 있는가?"라는 질문으로, 검증은 "올바르게 만들고 있는가?"라는 질문으로 표현되기도 한다. 하지만 이러한 용어의 사용은 다양하다.

PMBOK 가이드는 IEEE에 의해 표준으로 채택되었으며(INCOSE, 시스템 공학 연구 위원회 SERC, IEEE 컴퓨터 학회가 공동으로 유지 관리함) 제4판에서 다음과 같이 정의한다.[17]


  • '''유효성 확인:''' 제품, 서비스 또는 시스템이 고객 및 기타 식별된 이해 관계자의 요구 사항을 충족하는지에 대한 보증. 종종 외부 고객과의 수용성 및 적합성을 포함한다. ''검증''과 대조된다.
  • '''검증:''' 제품, 서비스 또는 시스템이 규정, 요구 사항, 사양 또는 부과된 조건을 준수하는지 여부에 대한 평가. 종종 내부 프로세스이다. ''유효성 확인''과 대조된다.


V 모델은 독일 정부 관련 소프트웨어 개발 공정을 규정하기 위해 개발되었다. 소프트웨어 개발 과정에서 수행해야 할 활동과 그 결과물을 규정하며, 소프트웨어 개발 라이프사이클을 그래픽으로 표현한 것이다. 자동화된 시스템 검증 프레임워크와 관련된 단계들을 요약하고 있다.

V자형으로 표시되는 개념도의 왼쪽은 시스템의 사양을, 오른쪽은 테스트의 흐름을 나타낸다. 각각 같은 높이에 있는 부분은 개발의 상세 수준을 나타낸다.

사양 책정 부분은 주로 사용자 요구 사항 사양, 기능 사양, 설계 사양(상세 사양) 등의 작업으로 구성된다. 테스트 실행 부분은 주로 인수 테스트, 운용 테스트, 성능 테스트 등의 작업으로 구성된다.

3. 1. 검증 (Verification)

V 모델에서 검증(Verification)은 "올바르게 만들고 있는가?"라는 질문에 답하는 과정이다. PMBOK 가이드는 IEEE에 의해 표준으로 채택되었으며(INCOSE, 시스템 공학 연구 위원회 SERC, IEEE 컴퓨터 학회가 공동으로 유지 관리함) 제4판에서 다음과 같이 정의한다.[17]

  • '''검증'''. 제품, 서비스 또는 시스템이 규정, 요구 사항, 사양 또는 부과된 조건을 준수하는지 여부에 대한 평가. 종종 내부 프로세스이다. ''유효성 확인''과 대조된다.


즉, 검증은 각 개발 단계의 산출물(요구사항 명세서, 설계 문서 등)이 정해진 기준과 절차를 준수하는지 확인하는 활동이며, 주로 내부적인 관점에서 수행된다.

3. 2. 유효성 확인 (Validation)

시스템 테스트는 실제 구현된 시스템과 계획된 사양을 비교하는 작업이다. 실제 환경과 유사한 환경에서 테스트를 진행하며, 시스템 설계 문서를 바탕으로 테스트 설계를 도출한다. 자동화 도구를 이용하기도 한다. 모든 모듈을 통합한 후 시스템 레벨의 오류를 발견할 수 있으며, 개발자가 아닌 별도의 테스트 팀이 수행한다.[17]

인수 테스트는 시스템이나 시스템의 일부, 또는 특정 비기능적 특성에 대해 "확신"을 얻는 작업이다. 결함을 찾는 것이 주 목적은 아니며, 시스템 배포 및 사용 준비가 되었는지 평가한다. 사용자 인수 테스팅, 운영상의 인수 테스팅 등이 여기에 해당한다. 하지만 인수 테스트 이후에 대규모 통합 테스트를 실행할 수도 있으므로, 인수 테스팅이 반드시 최종 단계는 아니다.[17]

IEEE에서 표준으로 채택된 PMBOK 가이드 (INCOSE, 시스템 공학 연구 위원회 SERC, IEEE 컴퓨터 학회 공동 유지 관리) 제4판에서는 다음과 같이 정의한다.[17]

  • '''유효성 확인:''' 제품, 서비스 또는 시스템이 고객 및 기타 이해 관계자의 요구 사항을 충족하는지에 대한 보증. 주로 외부 고객과의 수용성 및 적합성과 관련된다. ''검증''과 대조된다.
  • '''검증:''' 제품, 서비스 또는 시스템이 규정, 요구 사항, 사양 또는 부과된 조건을 준수하는지 평가하는 것. 주로 내부 프로세스이다. ''유효성 확인''과 대조된다.


4. 목적

V 모델은 프로젝트 계획 및 실현에 대한 지침을 제공하며, 다음과 같은 목표를 달성하고자 한다.

thumb


  • 프로젝트 위험 최소화: 프로젝트의 투명성과 관리를 개선하여 위험을 줄인다.
  • 품질 개선 및 보장: 표준화된 프로세스 모델로서, 결과물이 완전하고 원하는 품질을 갖도록 보장한다.
  • 총 비용 절감: 시스템의 개발, 생산, 운영 및 유지 보수에 대한 노력을 투명하게 계산, 추정 및 제어할 수 있다.
  • 의사소통 개선: 모든 관계자에게 표준화되고 통일된 용어와 절차를 제공하여 상호 이해를 돕는다.


현재 버전은 V-Model XT로 불리며, 2005년 2월에 완성되었다(http://www.v-modell-xt.de). 능력 성숙도 모델 통합(CMMI)과는 직접적으로 경쟁하지 않는다. CMMI는 "무엇을" 해야 하는지를 보여주는 반면, V 모델은 "어떻게", "언제", "누가" 책임을 지고 수행해야 하는지도 보여준다.

V 모델은 독일 정부 관련 소프트웨어 개발 공정을 규정하기 위해 개발되었다. 소프트웨어 개발 과정에서 수행해야 할 활동과 그 결과물을 규정하고 있으며, 소프트웨어 개발 라이프사이클을 그래픽으로 표현한 것이기도 하다. 또한 자동화된 시스템 검증 프레임워크와 관련된 단계들을 요약하고 있다.

V자형으로 표시되는 개념도의 왼쪽은 시스템의 사양을, 오른쪽은 테스트의 흐름을 나타낸다. 각각 같은 높이에 있는 부분은 개발의 상세 수준을 나타낸다.

사양 책정 부분은 주로 다음과 같은 작업으로 구성된다.

  • 사용자 요구 사항 사양
  • 기능 사양
  • 설계 사양(상세 사양)


테스트 실행 부분은 주로 다음과 같은 작업으로 구성된다.

  • 인수 테스트
  • 운용 테스트
  • 성능 테스트

4. 1. 프로젝트 위험 최소화

V 모델은 표준화된 접근 방식을 명시하고 해당 결과 및 책임 역할을 설명함으로써 프로젝트 투명성과 프로젝트 관리를 개선한다. 이를 통해 계획 편차 및 위험을 조기에 인식하고 프로세스 관리를 개선하여 프로젝트 위험을 줄일 수 있다.

4. 2. 품질 개선 및 보장

V 모델은 표준화된 프로세스 모델로서, 제공될 결과물이 완전하고 원하는 품질을 갖도록 보장한다. 각 개발 단계별로 정의된 중간 산출물을 조기에 확인할 수 있다. 균일한 제품 내용은 가독성, 이해력 및 검증 가능성을 향상시킨다. 체계적인 테스트를 통해 최종 시스템의 품질을 확보한다.[1]

4. 3. 비용 절감

V 모델은 표준화된 프로세스를 명시하여 시스템 개발, 운영 및 유지보수에 필요한 노력을 투명하게 예측하고 관리할 수 있게 한다. 이를 통해 전체 비용을 절감할 수 있다. 결과는 균일하고 쉽게 추적할 수 있어, 구매자가 공급업체에 대한 의존성을 줄이고 후속 활동 및 프로젝트에 대한 노력을 줄일 수 있다.

4. 4. 의사소통 개선

모든 관계자(사용자, 구매자, 공급업체, 개발자 등)에게 표준화되고 통일된 용어와 절차를 제공함으로써 상호 이해를 위한 기초를 마련한다. 이를 통해 관계자 간의 마찰 손실을 줄여 원활한 의사소통을 지원한다.

5. V 모델의 구성 요소

V 모델은 크게 두 개의 흐름으로 구성된다. V자형으로 표시되는 개념도의 왼쪽은 시스템의 사양을 기술하는 흐름이고, 오른쪽은 테스트 흐름이다. 양쪽에서 같은 높이에 있는 부분은 개발의 상세 수준이 같음을 나타낸다.[2]

thumb

V 모델은 다음과 같이 구성된다.


  • 명세 (Specification) 흐름: 시스템 개발 초기 단계로, 사용자 요구사항을 분석하여 구체적인 시스템 사양을 정의한다.
  • 사용자 요구 사항 명세
  • 기능 요구 사항 명세
  • 설계 명세
  • 테스팅 (Testing) 흐름: 개발된 시스템의 품질을 검증하는 활동으로, 다양한 수준의 테스트를 통해 시스템 결함을 발견하고 수정한다.
  • 단위 테스트
  • 통합 테스트
  • 시스템 테스트
  • 인수 테스트

5. 1. 명세 (Specification) 흐름

요구사항 분석 단계에서는 개발될 시스템에 대한 요구사항을 시스템 사용자의 필요를 분석하여 얻는다. 이 단계는 목표로 하는 이상적인 시스템이 수행해야 할 기능에 대해 고민하는 단계이다. 그러나 이 단계에서는 소프트웨어가 어떻게 설계되고 구현될 것인지는 다루지 않는다. 통상적으로 이 단계에서는 사용자를 만나 기능에 대한 의견을 청취하고, 이를 사용자 요구사항 문서로 생성한다.

사용자 요구사항 문서는 일반적으로 사용자가 기대하는 시스템의 기능적 요구사항, 물리적 요구사항, 인터페이스 요구사항, 성능 요구사항, 데이터 요구사항, 보안(security) 요구사항 등을 기록한다. 이 문서는 비즈니스 분석가가 시스템에 대해 이해한 바를 사용자와 협의할 때 이용되는 문서이기도 하다. 또한 시스템 설계 단계에서 설계자에 대한 지침으로 사용되기 때문에, 사용자는 이 문서를 주의 깊게 검토해야 한다. 통상적으로 사용자 수락시험에 대한 설계는 이 요구사항 분석 단계에서 이루어진다. 기능적 요구사항과 비기능적 요구사항 항목을 참고할 수 있다.

시스템 설계 단계에서 시스템 엔지니어는 사용자 요구사항 문서를 면밀히 검토하여 개발할 시스템에 대해 분석하고 이해한다. 또한 시스템 엔지니어는 사용자 요구사항을 구현 가능성과 필요한 기술들을 파악한다. 만약 요구사항 중 어느 한 가지라도 구현이 불가능할 경우, 이에 대해 사용자에게 알린다. 문제점이 발견되면 해결 가능할 경우, 변경 사항을 반영하여 요구사항 문서를 수정한다.

그러한 과정을 거쳐 개발 단계를 위한 청사진이 될 소프트웨어 기술서(software specification document)가 생성된다. 이 문서는 일반적인 시스템 구성과 메뉴 구조, 자료 구조 등을 기술한다. 또한 기술서는 비즈니스 시나리오에 대한 예나 샘플 윈도, 이해를 돕기 위한 보고서 등을 추가로 포함할 수 있다. 엔티티 다이어그램(entity diagrams)이나 데이터 목록(data dictionary)과 같은 기술자료 또한 설계 단계에서 산출된다. 그에 더하여 시스템 테스트를 위한 문서도 이 단계에서 준비된다.

컴퓨터 아키텍처 및 소프트웨어 아키텍처 설계 단계를 합쳐서 고수준 설계라 부른다. 아키텍처를 선택함으로써 만들어지는 베이스라인은 일반적으로 모든 구현될 모듈 항목과 그 간략한 기능을 정의하고, 모듈 간의 인터페이스, 관계, 의존성을 기술하며, 필요한 데이터베이스 테이블, 아키텍처 다이어그램, 적용기술 내역을 기술한다. 또한 이 단계에서 통합 테스트에 대한 설계가 이루어진다.

모듈 설계 단계를 다른 말로 저수준 설계라 부른다. 아키텍처 설계 단계에서 정의된 모듈 항목을 더 세분하여 각각의 모듈에 대한 기술을 작성하며, 이를 이용하여 프로그래머들이 코딩을 시작할 수 있도록 만들어 준다.

이 단계에서 작성될 저수준 설계 문서 또는 프로그램 명세서에서는 각 모듈의 상세한 기능 로직을 의사 코드 (pseudocode)를 이용하여 기술하고, API 명세를 통해 의존성 관련 이슈를 포함하여 각 모듈의 모든 인터페이스 상세 사항을 기술하며, 각 모듈의 에러 코드와 메시지를 기술하며, 각 모듈의 입력과 출력을 기술하며, 필요할 경우 모듈에서 사용하는 데이터베이스 테이블의 구조와 요소별 타입과 크기 또한 기술한다. 또한 이 단계에서는 단위 테스트를 위한 케이스와 절차가 설계된다.

사양 스트림은 주로 다음으로 구성된다.[2]

  • 사용자 요구 사항 명세
  • 기능 요구 사항 명세
  • 설계 명세

5. 2. 테스팅 (Testing) 흐름

V 모델에서 테스팅은 개발된 시스템의 품질을 검증하는 활동이다. 주로 다음과 같은 작업들로 구성된다.

  • 단위 테스트: 테스트 프로세스의 첫 단계이다. 화이트박스 테스트 방식으로, 모듈 설계 단계에서 준비된 테스트 케이스를 이용하며 코드를 개발한 개발자가 직접 수행한다. 코드 분석, 효율성 검증, 코딩 표준 준수 여부 등을 확인한다. 소프트웨어 개발 전문가 배리 보엠(Barry Boehm)에 따르면, 단위 테스트 단계에서 오류를 수정하면 고객에게 오류가 전달되었을 때보다 수정 비용을 수백 배 절감할 수 있다.[2]
  • 통합 테스트: 각각의 모듈들을 통합하여, 통합된 컴포넌트 간의 인터페이스와 상호작용 상의 오류를 발견한다. 블랙박스 테스트 방식으로, 아키텍처 설계 단계에서 준비된 테스트 케이스를 사용하여 테스트가 진행되며, 일반적으로 개발자가 진행한다.
  • 시스템 테스트: 실제 구현된 시스템과 계획된 사양(specifications)을 비교한다. 실제 환경과 유사한 환경에서 테스트를 진행하며, 시스템 설계 문서로부터 도출된 시스템 테스트 설계를 사용한다. 자동화 도구를 이용하여 자동화되기도 한다. 모든 모듈을 통합한 후 시스템 레벨의 에러를 발견하며, 개발자와 다른 별도의 테스트팀이 수행한다.
  • 인수 테스트: 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 "확신(Confidence)"을 얻는 작업이다. 결함을 찾는 것이 주 목적은 아니며, 시스템을 배포하거나 실제 사용할만한 준비가 되었는지 평가한다. 사용자 인수 테스팅, 운영상의 인수 테스팅 등이 있다.


테스팅 스트림은 일반적으로 설치 적격성 평가(Installation Qualification, IQ), 운영 적격성 평가(Operational Qualification, OQ), 성능 적격성 평가(Performance Qualification, PQ)로 구성된다.[2][13][14][5]

V 모델은 요구 사항 중심의 설계 및 테스트를 강조한다. 모든 설계 요소와 인수 테스트는 하나 이상의 시스템 요구 사항으로 추적 가능해야 하며, 모든 요구 사항은 최소 하나의 설계 요소와 인수 테스트로 해결되어야 한다. 이러한 엄격함은 불필요한 작업이 수행되지 않고 필요한 모든 것이 수행되도록 보장한다.[2][13]

6. 응용 분야

V 모델은 독일과 미국 등 다양한 분야에서 활용되고 있다. V 모델의 개념은 1980년대 후반 독일과 미국에서 독립적으로 개발되었다.

6. 1. 독일 연방 정부

V 모델은 독일 연방 정부 내에서 소프트웨어 개발 프로세스를 규제하는 데 사용된다. 현재까지도 독일 연방 정부와 국방 프로젝트, 그리고 해당 지역의 소프트웨어 개발자들에게 표준으로 사용되고 있다.[19]

6. 2. 미국



현재 V 모델은 상업 프로그램과 국방 프로그램 모두에서 널리 사용되고 있다. 주로 프로젝트 관리[13][14] 및 프로젝트 수명 주기 전체에 사용된다.

미국 V 모델의 한 가지 기본적인 특징은 시간과 성숙도가 왼쪽에서 오른쪽으로 이동하며, 시간상 뒤로 돌아갈 수 없다는 것이다. 모든 반복은 그림과 같이 시스템 계층 구조의 더 높거나 낮은 수준으로의 수직선에 따라 이루어진다.[13][14][5] 이는 모델의 중요한 측면임이 입증되었다. 이 모델을 듀얼-Vee 개념으로 확장한 내용은 참고 문헌에서 다루고 있다.[13]

V 모델은 공개적으로 사용할 수 있으므로 많은 회사에서도 사용한다. 프로젝트 관리에서 이는 PRINCE2와 유사한 방법이며, 프로젝트 관리 방법과 시스템 개발 방법을 설명한다. V 모델은 프로세스 측면에서 엄격하지만, 특히 시스템 개발 수명 주기의 일반적인 매개변수 범위를 벗어나는 범위와 관련하여 적용 면에서 매우 유연할 수 있다.

V 모델은 1982년경 휴즈 항공기에서 처음 등장했으며, FAA 첨단 자동화 시스템(AAS) 프로그램의 사전 제안 노력의 일환이었다. 이는 결국 휴즈 AAS 설계 경쟁 단계(DCP) 제안의 테스트 전략을 형성했다. 이는 소프트웨어의 잠재 결함을 표면화하기 위한 새로운 과제에 의해 주도된 테스트 및 통합 접근 방식을 보여주기 위해 만들어졌다. 이러한 새로운 수준의 잠재 결함 감지의 필요성은 자동화된 항로 교통 관제(AERA) 프로그램에서 구상한 대로 항공 교통 관제사의 사고 및 계획 프로세스를 자동화하려는 목표에 의해 주도되었다. V가 매우 강력한 이유는 모든 텍스트와 분석을 다차원 이미지에 연결하는 휴즈의 문화에서 비롯된다. 이는 1963년 휴즈에서 만들어 휴즈가 하워드 휴즈 의학 연구소에 의해 1985년에 매각될 때까지 사용된 간행물 순차적 주제 구성(STOP)의 기초였다.[20][21]

미국 국방부는 시스템 엔지니어링 프로세스 상호 작용을 V 모델 관계로 설정한다.[22]

1991년 국립 시스템 공학 협의회(NCOSE, 1995년 이후 INCOSE) 회의록에 기록된 미국 V 모델[5]은 하드웨어, 소프트웨어 및 인간 상호 작용을 포함하는 위성 시스템을 위해 개발되었다.

6. 3. 기타

V 모델은 공개적으로 사용 가능하므로, 많은 회사에서 활용한다. 프로젝트 관리 측면에서 V 모델은 PRINCE2와 유사한 방법으로, 프로젝트 관리 방법과 시스템 개발 방법을 설명한다.[13][14]

7. 장점

V 모델은 다른 시스템 개발 모델에 비해 다음과 같은 장점을 제공한다.

thumb


  • V 모델은 능력 성숙도 모델 통합(CMMI)과는 다르게 "어떻게", "언제", "누가" 책임을 지고 수행해야 하는지도 보여준다.
  • 독일 정부 관련 소프트웨어 개발 공정을 규정하기 위해 개발되었으며, 소프트웨어 개발 과정에서 수행해야 할 활동과 그 결과물을 규정하고 있다.
  • 소프트웨어 개발 라이프 사이클을 그래픽으로 표현하고, 자동화된 시스템 검증 프레임워크와 관련된 단계들을 요약하고 있다.
  • V자형 개념도의 왼쪽은 시스템 사양 기술, 오른쪽은 테스트 흐름을 나타내며, 같은 높이는 개발 상세 수준을 나타낸다.


사양 책정 부분은 주로 사용자 요구 사항 사양, 기능 사양, 설계 사양(상세 사양) 작업으로 구성된다. 테스트 실행 부분은 주로 인수 테스트, 운용 테스트, 성능 테스트 작업으로 구성된다.

7. 1. 사용자 참여

V 모델 사용자는 V 모델의 개발 및 유지보수에 참여한다. 변경 관리 위원회는 V 모델을 공개적으로 유지 관리한다. 변경 관리 위원회는 매일 또는 매주 회의를 개최하여 시스템 개발 및 테스트 중에 접수된 모든 변경 요청을 처리한다.[23]

7. 2. 명확한 지침

V 모델은 활동 단계별로 구체적인 지침과 작업 절차를 제공하여 개발 프로세스를 표준화하고 작업의 효율성을 높인다.[24] 각 활동 스키마에는 지침, 권장 사항 및 활동에 대한 자세한 설명이 포함되어 있다.[24]

8. 한계점

V 모델은 다음과 같은 한계점을 가지고 있다.


  • 서비스 계약 체결을 규제하지 않는다.[25][26]
  • 시스템의 운영, 유지 보수, 수리 및 폐기에 대한 조직 및 실행은 V 모델에서 상세하게 다루지 않는다. 다만, 이러한 작업에 대한 개념 계획 및 준비는 규제한다.[25][26]
  • V 모델은 전체 조직이 아닌 프로젝트 내의 소프트웨어 개발을 다룬다.[25][26]

8. 1. 서비스 계약 관련 내용 부재

V 모델은 서비스 계약 체결을 규제하지 않는다.[25][26]

8. 2. 운영 및 유지보수 관련 내용 제한적

시스템의 운영, 유지 보수, 수리 및 폐기에 대한 조직 및 실행은 V 모델에서 상세하게 다루지 않는다. 그러나 이러한 작업에 대한 개념 계획 및 준비는 V 모델에서 규제된다.[25][26]

8. 3. 소프트웨어 개발에 초점

V 모델은 주로 프로젝트 내의 소프트웨어 개발을 다룬다.[25][26] 능력 성숙도 모델 통합(CMMI)과는 직접적으로 경쟁하지 않는다. CMMI는 "무엇을" 해야 하는지를 보여주는 반면, V 모델은 거기에 더해 "어떻게", "언제", "누가" 책임을 지고 수행해야 하는지도 보여준다.

V 모델은 독일 정부 관련 소프트웨어 개발 공정을 규정하기 위해 개발되었다. 소프트웨어 개발 과정에서 수행해야 할 활동과 그 결과물을 규정하고 있다. V 모델은 소프트웨어 개발의 라이프 사이클을 그래픽으로 표현한 것이기도 하다. 자동화된 시스템 검증 프레임워크와 관련된 단계들을 요약하고 있다.

thumb

V자형으로 표시되는 개념도의 왼쪽은 시스템의 사양을 기술해 가는 흐름을 나타낸다. 오른쪽은 테스트의 흐름을 나타낸다. 각각 같은 높이에 있는 부분은 개발의 상세 수준을 나타낸다.

사양 책정 부분은 주로 다음과 같은 작업으로 구성된다.

  • 사용자 요구 사항 사양
  • 기능 사양
  • 설계 사양(상세 사양)


테스트 실행 부분은 주로 다음과 같은 작업으로 구성된다.

  • 인수 테스트
  • 운용 테스트
  • 성능 테스트

참조

[1] 간행물 "Clarus Concept of Operations" http://www.itsdocs.f[...] Federal Highway Administration (FHWA) 2005
[2] 웹사이트 "The Dangerous & Seductive V Model" http://www.clarotest[...] 2013-01-09
[3] 논문 System Engineering for Faster, Cheaper, Better http://www.incose.or[...] Center of Systems Management
[4] 웹사이트 The SE VEE http://www.gmu.edu/d[...] SEOR, George Mason University 2007-05-26
[5] 간행물 "The Relationship of Systems Engineering to the Project Cycle" http://www.csm.com/r[...] First Annual Symposium of the National Council On Systems Engineering (NCOSE) 1991-10
[6] 웹사이트 "V-Modell site (in German)" https://www.cio.bund[...] 2020-07-10
[7] 문서 German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model 1992-08
[8] 웹사이트 Fundamentals of the V-Modell http://v-modell.iabg[...] 2024-11-17
[9] 웹사이트 V-Modell XT, Part 1: Fundamentals of the V-Modell http://ftp.uni-kl.de[...] 2024-11-17
[10] 웹사이트 "International Software Testing Qualifications Board – Foundation Level Syllabus" http://www.istqb.org[...] 2013-01-09
[11] 웹사이트 Systems Engineering for Intelligent Transportation Systems https://ops.fhwa.dot[...] US Dept. of Transportation 2007-06-09
[12] 웹사이트 "US Dept of Transportation, Federal Highway Administration. Systems Engineering Guidebook for ITS" https://www.fhwa.dot[...] 2013-01-09
[13] 서적 Visualizing Project Management John Wiley and Sons 2005
[14] 간행물 Systems Engineering Handbook Version 3.1 International Council On Systems Engineering (INCOSE) 2007-08
[15] 웹사이트 BUILDING ON A LEGACY: RENEWED FOCUS ON SYSTEMS ENGINEERING IN DEFENSE ACQUISITION http://www.dau.mil/p[...] 2016-04-14
[16] 웹사이트 Using V Models for Testing https://insights.sei[...] 2013-11-10
[17] 서적 IEEE Guide--Adoption of the Project Management Institute (PMI(R)) Standard a Guide to the Project Management Body of Knowledge (PMBOK(R) Guide)--Fourth Edition https://ieeexplore.i[...] 2011-06
[18] 문서 Systems Engineering Fundamentals Defense Acquisition University Press 2001
[19] 웹사이트 V-Model Lifecycle Process Model http://www.v-modell.[...] v-modell.iabg.de 2015-12-24
[20] 웹사이트 Sequential Thematic Organization of Publications (STOP) https://www.scribd.c[...] 2015-12-24
[21] 서적 Sustainable Development Possible with Creative System Engineering Lulu.com 2008-01-01
[22] 웹사이트 A New Systems Engineering Model and an Old, Familiar Friend; Figure 2 V-9 Process Interactions http://www.dau.mil/p[...] Defense AT&L 2006-04
[23] 웹사이트 Further Development of the V-Modell (broken link) http://v-modell.iabg[...] v-modell.iabg.de 2015-12-24
[24] 웹사이트 Overview of the Activity Model of the V-Modell (broken link) http://v-modell.iabg[...] v-modell.iabg.de 2015-12-24
[25] 웹사이트 Limits of the VModel http://v-modell.iabg[...] v-modell.iabg.de 2015-12-24
[26] 문서 The V-Model http://www.bucanac.c[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com