V-모델은 소프트웨어 개발 및 테스트를 위한 프로세스 모델로, 종종 전통적인 폭포수 모델의 변형으로 간주됩니다. 선형 소프트웨어 개발 프로세스에서 서로 병합되는 표준 폭포수 모델의 수명 주기 단계와 비교하여 V-모델의 테스트 단계는 모든 단계와 병렬로 수행됩니다.
폭포수 모델은 개발 중에 보다 정의된 테스트 단계로 보강되었으며 시각적으로 V자 모양으로 배열할 수 있습니다. “V”는 또한 프로세스 모델을 설명하는 “검증 및 검증 모델”을 의미합니다.
그 책 임베디드 시스템 및 제품 개발 및 관리 – 방법, 기술, 도구, 프로세스 및 팀워크 Kim R. Fowler와 Craig L. Silver는 V-모델의 검증 및 검증 구성 요소를 다음과 같이 정의합니다.
“검증은 제품이 요구 사항 메트릭을 충족하는지 확인하기 위해 설계된 일련의 객관적인 테스트이며, 유효성 검사는 제품이 원래 의도를 충족하는지 확인하는 것을 목표로 합니다.”
개략적으로 V-모델 내의 단계는 검증 및 검증 단계 모두에서 프로그래밍에서 위쪽으로 흐르며 V를 형성합니다.
V 모델의 세로축은 SDLC(Software Development Life Cycle)에서 완성된 소프트웨어 제품까지의 거리를 나타냅니다. 요구 사항의 정의는 V-모델의 최상위에 있으며 프로그래밍은 기초를 형성합니다. 가로축은 완성된 소프트웨어에서 가장 먼 요구 사항 정의가 있는 타임라인을 나타냅니다.
가로 및 세로 축은 시간 또는 프로젝트 진행률(왼쪽에서 오른쪽으로)과 추상화 수준을 나타냅니다.
소프트웨어 개발을 위한 절차적 모델로서 V-modell은 입력과 양식 데이터 또는 두 구성 요소 사이의 양방향 데이터 바인딩을 제공하는 JavaScript 프레임워크 지시문인 Vue v-modell과 혼동해서는 안 됩니다.
모든 슈퍼히어로와 마찬가지로 모든 좋은 소프트웨어 개발 방법론이나 프레임워크에는 고유한 Origins 스토리가 있습니다. 팀 와일킨의 책에 따르면 SysML/UML을 사용한 시스템 엔지니어링 2017년부터 프로세스 모델은 원래 공공 부문에서 시스템 개발 프로젝트를 계획하고 구현하기 위한 방법론으로 독일 국가를 위해 개발되었습니다.
독일의 영향은 시스템 엔지니어링과 유사한 방식으로 소프트웨어 개발 수명 주기를 체계화하는 V-모델의 특정 접근 방식에서 볼 수 있습니다. 처음 출시된 V-Modell 97은 원래의 방법론이 더 이상 현대 소프트웨어 개발 프로젝트에 적합하지 않다는 합의에 도달한 후 2004년에 V-Modell XT(Extreme Tailoring)로 업데이트되었습니다.
2004년부터 현재의 V-모델 XT는 이전 V-모델 97을 기반으로 합니다. 구형 V-모델이 더 이상 최신 기술이 아님이 7년 후에 밝혀지면서 모델이 수정되었습니다. 더 이상 최신 기술과 방법을 지원하는 데 적합하지 않았습니다.
V-Modell XT는 정의된 역할, 제품 및 프로젝트에 따라 사용자 지정할 수 있는 활동으로 구성된 도구 상자입니다. 규칙은 접근 방식이 논리적이고 일관되게 유지되도록 합니다.
기존 접근 방식에서 소프트웨어 개발 수명 주기의 단계는 폭포수 모델과 동일합니다.
- 요구 사항 정의 및 사양
- 기능적 시스템 설계
- 건축 설계
- 부품 설계
- 프로그램 작성
코딩은 V-모델의 기초이며 테스트 단계가 구성 요소 테스트로 시작되기 전에 개발 주기의 마지막 단계입니다.
- 단위 테스트
- 통합 테스트
- 시스템 테스트
- 수락 테스트
프로그래밍 전과 도중의 4단계에 대한 간략한 소개:
방법론이나 프레임워크에 관계없이 모든 소프트웨어 개발 프로젝트의 첫 번째 단계는 소프트웨어의 유용성과 기능, 더 간단하게는 소프트웨어가 수행해야 하는 작업을 결정하는 것입니다. 프로그램의 범위는 사용자, 앱의 스폰서/소유자 및 기타 모든 관련 당사자를 포함하여 프로그램 사용에 영향을 미치는 모든 이해 관계자에 의해 결정됩니다.
기술은 인터뷰, 시장/사용자 조사, 소프트웨어가 조직 내 사람, 프로세스, 수익 또는 비용에 미치는 영향에 대한 분석이 될 수 있습니다.
그런 다음 요구 사항은 수집된 정보를 기반으로 정의되며 최종 제품이 준수해야 하는 상위 요구 사항 문서로 컴파일됩니다.
요구 사항 정의는 소프트웨어 시스템의 기능에 영향을 미칩니다. 필수 기능, 기능에 액세스하는 사용자 인터페이스, 사용자 스토리, 워크플로 및 데이터 구조가 이 단계에서 정의됩니다.
시스템 테스트 계획 및 문서는 이 단계에서 생성되며 이후 단계에서 실행할 시간이 더 많이 남습니다.
기능적 시스템 설계 다음에는 아키텍처 설계가 뒤따릅니다. 이 단계에서는 일반적으로 다양한 잠재적인 기술적 접근 방식을 제안하고 기술적, 재정적 장점과 단점을 기반으로 결정을 내립니다.
높은 수준의 기술 스택은 요구 사항 정의 또는 기능적 시스템 설계 중에 이미 결정되었을 수 있지만 데이터베이스 기술 및 호스팅 사양(예: 퍼블릭, 프라이빗 또는 하이브리드 클라우드, 각 공급자 등)과 같은 세부 사항은 아키텍처에 지정되어 있습니다. 설계.
이 정보는 또한 통합 테스트의 설계 및 문서화를 가능하게 합니다.
각 구성 요소의 기본 세부 사항은 구성 요소 설계에 지정됩니다. 상호 작용에 대한 세부 정보를 포함하여 모든 기능과 이를 구성하는 구성 요소에 대해 설명합니다. API 및 데이터베이스 테이블과 같은 백엔드 구성 요소도 문서화되어 있습니다.
API 인터페이스 사양 및 자세한 구성 요소 설명 덕분에 이제 구성 요소 테스트도 생성할 수 있습니다.
이 주요 단계에서는 모든 구성 요소 세부 정보로 구성되고 복잡한 소프트웨어 시스템의 모든 기능을 실현하는 데 필요한 실제 코드가 작성됩니다. 프런트엔드 및 백엔드 소프트웨어 개발자는 프로젝트에 대해 미리 결정된 코딩 언어, 특정 프레임워크 또는 라이브러리를 사용합니다.
개발 프로세스의 초기 단계에서 설정된 모든 사양은 코드 및 소프트웨어 개발 도구를 통해 실현됩니다.
개발 단계에 수반되는 네 가지 테스트 단계에 대한 간략한 설명:
단위 테스트는 지정된 특성에 따라 작동하는 소프트웨어 시스템을 구성하는 가장 작은 구성 요소를 확인하는 역할을 합니다. 프로그래밍 언어에 따라 컴포넌트는 모듈, 유닛 또는 클래스로 정의될 수 있습니다. 단위 또는 클래스로 정의될 때 이 단계는 단위 테스트가 아니라 단위 또는 클래스 테스트라고 합니다.
단위 테스트는 구성 요소의 출력이 해당 사양이 주어진 입력에서 예상되는 것인지 확인합니다. 버그나 기타 결함을 더 잘 찾기 위해 테스트는 개별 구성 요소를 격리하고 종속성 또는 다른 구성 요소와의 인터페이스와 독립적으로 검증해야 합니다.
단위 테스트는 일반적으로 PyUnit, JUnit, JEST, Jasmine 등과 같은 자동화된 Selenium 테스트 프레임워크를 통해 수행됩니다.
단위 테스트는 아키텍처 효율성(메모리 소비, 메모리 소비 등)과 같은 비기능적 측면과 기능뿐만 아니라 코드 복잡성 및 문서 품질을 포함한 유지 관리 측면을 확인하는 데에도 사용할 수 있습니다.
구성 요소를 개별적으로 테스트하고 확인한 후 통합 테스트를 통해 올바른 기능과 통신을 확인합니다. 이 단계는 건축 설계와 관련이 있습니다. 통합 테스트는 소프트웨어 내에서 구성 요소 그룹 또는 더 넓은 하위 시스템이 어떻게 함께 작동하는지 확인하는 데 사용됩니다.
사양, 시스템 아키텍처, 사용 사례 또는 워크플로 설명을 기반으로 통합 테스트를 개발할 수 있습니다.
시스템 테스트는 기능적 시스템 설계에서 수행됩니다. 시스템 테스트는 전체 소프트웨어 시스템의 기능과 브라우저 또는 하드웨어와 같은 외부 시스템과의 통신을 확인합니다. 여기에서 모든 호환성 문제를 발견해야 합니다.
요구 사항 정의 단계에 해당하는 승인 테스트는 최고 수준의 추상화에서 실행됩니다. 비즈니스 리더 또는 최종 사용자와 같이 개발 프로세스의 후반 단계에 직접 관여하지 않을 수 있는 이해 관계자가 여기에 참여할 수 있습니다.
시험은 일반적으로 사용자 환경과 관련이 있으며 소프트웨어가 로딩 시간, UX 품질 등과 같은 비기능적 요구 사항뿐만 아니라 가장 중요한 비즈니스 요구 사항을 충족하도록 설계되었습니다.
대부분의 승인 테스트는 대부분 수동입니다.
V-모델의 장점은 표준 워터폴 방법론에 비해 간단한 적용과 테스트 절차에 중점을 둔다는 것입니다. 선형 프로세스 모델은 대체로 반복적이고 유연한 접근 방식으로 대체되었습니다. 그러나 일반적으로 고정된 가격과 잘 정의된 요구 사항이 있는 단순한 소프트웨어 개발 프로젝트에는 여전히 V-모델을 위한 자리가 있을 수 있습니다.
- 위상이 선형으로 닫혀 있는 비교적 견고한 모델입니다.
- 요구 사항이 명확하고 잘 문서화되어 있는 소규모 프로젝트에 적합합니다.
- 간단하고 이해하기 쉽고 사용하기 쉽습니다.
- 단계별 결과 및 검증 절차가 명확하여 관리가 용이합니다.
V-모델은 본질적으로 폭포수 접근 방식과 동일한 이유로 최신 소프트웨어 개발에서 점점 더 적게 사용됩니다. 프로세스 모델은 모든 요구 사항이 라이프 사이클의 개념적 또는 예비 단계에서 이미 결정되었다고 가정합니다.
특히 더 복잡한 소프트웨어 시스템의 경우 일반적으로 그렇지 않습니다. 요구 사항, 설계 및 평가는 종종 최종 통합 및 승인 전에 여러 번 반복됩니다. 많은 소프트웨어 제품의 경우 소프트웨어 제품 반복은 일정한 주기입니다.
현재의 현실은 애자일 소프트웨어 개발에 속하는 다양한 프레임워크가 현재 소프트웨어 개발을 지배하고 있는 이유입니다.
V-모델의 약점은 다음과 같이 요약할 수 있습니다.
- 복잡하고 객체 지향적인 소프트웨어 애플리케이션에는 적합하지 않습니다.
- 장기 및/또는 진행 중인 반복 소프트웨어 프로젝트에는 적합하지 않습니다.
- 요구 사항이 변경되는 소프트웨어에는 적합하지 않습니다.
- 이 모델은 일단 검증 단계가 시작되면 이후의 설계 및 기능 변경을 어렵게 만듭니다.
- 작동하는 소프트웨어는 선형 수명 주기의 후반에만 생성됩니다.