The V-model is a graphical representation of a systems development lifecycle. It is used to produce rigorous development lifecycle models and project management models. The V-model falls into three broad categories, the German V-Modell, a general testing model, and the US government standard.

The V-model summarizes the main steps to be taken in conjunction with the corresponding deliverables within computerized system validation framework, or project life cycle development. It describes the activities to be performed and the results that have to be produced during product development.

The left side of the "V" represents the decomposition of requirements, and the creation of system specifications. The right side of the "V" represents an integration of parts and their validation. However, requirements need to be validated first against the higher level requirements or user needs. Furthermore, there is also something as validation of system models. This can partially be done on the left side also. To claim that validation only occurs on the right side may not be correct. The easiest way is to say that verification is always against the requirements (technical terms) and validation is always against the real world or the user's needs. The aerospace standard RTCA DO-178B states that requirements are validated—confirmed to be true—and the end product is verified to ensure it satisfies those requirements.

Validation can be expressed with the query "Are you building the right thing?" and verification with "Are you building it right?"

Types 
There are three general types of V-model.

V-Modell 
"V-Modell" is the official project management method of the German government. It is roughly equivalent to PRINCE2, but more directly relevant to software development.  The key attribute of using a "V" representation was to require proof that the products from the left-side of the V were acceptable by the appropriate test and integration organization implementing the right-side of the V.

General testing 
Throughout the testing community worldwide, the V-model is widely seen as a vaguer illustrative depiction of the software development process as described in the International Software Testing Qualifications Board Foundation Syllabus for software testers. There is no single definition of this model, which is more directly covered in the alternative article on the V-Model (software development).

US government standard 
The US also has a government standard V-model which dates back about 20 years like its German counterpart. Its scope is a narrower systems development lifecycle model, but far more detailed and more rigorous than most UK practitioners and testers would understand by the V-model.

Validation vs. verification 

It is sometimes said that validation can be expressed by the query "Are you building the right thing?" and verification by "Are you building it right?" In practice, the usage of these terms varies.

The PMBOK guide, also adopted by the IEEE as a standard (jointly maintained by INCOSE, the Systems engineering Research Council SERC, and IEEE Computer Society) defines them as follows in its 4th edition:
 "Validation. The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification."
 "Verification. The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation."

Objectives 
The V-model provides guidance for the planning and realization of projects. The following objectives are intended to be achieved by a project execution:

 Minimization of project risks: The V-model improves project transparency and project control by specifying standardized approaches and describing the corresponding results and responsible roles. It permits an early recognition of planning deviations and risks and improves process management, thus reducing the project risk.
 Improvement and guarantee of quality: As a standardized process model, the V-model ensures that the results to be provided are complete and have the desired quality. Defined interim results can be checked at an early stage. Uniform product contents will improve readability, understandability and verifiability.
 Reduction of total cost over the entire project and system life cycle: The effort for the development, production, operation and maintenance of a system can be calculated, estimated and controlled in a transparent manner by applying a standardized process model. The results obtained are uniform and easily retraced. This reduces the acquirer's dependency on the supplier and the effort for subsequent activities and projects.
 Improvement of communication between all stakeholders: The standardized and uniform description of all relevant elements and terms is the basis for the mutual understanding between all stakeholders. Thus, the frictional loss between user, acquirer, supplier and developer is reduced.

V-model topics

Systems engineering and verification 
The systems engineering process (SEP) provides a path for improving the cost-effectiveness of complex systems as experienced by the system owner over the entire life of the system, from conception to retirement.

It involves early and comprehensive identification of goals, a concept of operations that describes user needs and the operating environment, thorough and testable system requirements, detailed design, implementation, rigorous acceptance testing of the implemented system to ensure it meets the stated requirements (system verification), measuring its effectiveness in addressing goals (system validation), on-going operation and maintenance, system upgrades over time, and eventual retirement.

The process emphasizes requirements-driven design and testing. All design elements and acceptance tests must be traceable to one or more system requirements and every requirement must be addressed by at least one design element and acceptance test. Such rigor ensures nothing is done unnecessarily and everything that is necessary is accomplished.

The two streams

Specification stream 
The specification stream mainly consists of:
 User requirement specifications
 Functional requirement specifications
 Design specifications

Testing stream 
The testing stream generally consists of:
 Installation qualification (IQ)
 Operational qualification (OQ)
 Performance qualification (PQ)

The development stream can consist (depending on the system type and the development scope) of customization, configuration or coding.

Applications 

The V-model is used to regulate the software development process within the German federal administration. Nowadays it is still the standard for German federal administration and defense projects, as well as software developers within the region.

The concept of the V-model was developed simultaneously, but independently, in Germany and in the United States in the late 1980s:

 The German V-model was originally developed by IABG in Ottobrunn, near Munich, in cooperation with the Federal Office for Defense Technology and Procurement in Koblenz, for the Federal Ministry of Defense. It was taken over by the Federal Ministry of the Interior for the civilian public authorities domain in summer 1992.
 The US V-model, as documented in the 1991 proceedings for the National Council on Systems Engineering (NCOSE; now INCOSE as of 1995), was developed for satellite systems involving hardware, software, and human interaction.
 The V-model first appeared at Hughes Aircraft circa 1982 as part of the pre-proposal effort for the FAA Advanced Automation System (AAS) program. It eventually formed the test strategy for the Hughes AAS Design Competition Phase (DCP) proposal. It was created to show the test and integration approach which was driven by new challenges to surface latent defects in the software. The need for this new level of latent defect detection was driven by the goal to start automating the thinking and planning processes of the air traffic controller as envisioned by the automated enroute air traffic control (AERA) program. The reason the V is so powerful comes from the Hughes culture of coupling all text and analysis to multi dimensional images. It was the foundation of Sequential Thematic Organization of Publications (STOP)  created by Hughes in 1963 and used until Hughes was divested by the Howard Hughes Medical Institute in 1985.
 The US Department of Defense puts the systems engineering process interactions into a V-model relationship.

It has now found widespread application in commercial as well as defense programs. Its primary use is in project management and throughout the project lifecycle.

One fundamental characteristic of the US V-model is that time and maturity move from left to right and one cannot move back in time. All iteration is along a vertical line to higher or lower levels in the system hierarchy, as shown in the figure.  This has proven to be an important aspect of the model. The expansion of the model to a dual-Vee concept is treated in reference.

As the V-model is publicly available many companies also use it. In project management it is a method comparable to PRINCE2 and describes methods for project management as well as methods for system development. The V-model, while rigid in process, can be very flexible in application, especially as it pertains to the scope outside of the realm of the System Development Lifecycle normal parameters.

Advantages 
These are the advantages V-model offers in front of other systems development models:

 The users of the V-model participate in the development and maintenance of the V-model. A change control board publicly maintains the V-model. The change control board meets anywhere from every day to weekly and processes all change requests received during system development and test.
 The V-model provides concrete assistance on how to implement an activity and its work steps, defining explicitly the events needed to complete a work step: each activity schema contains instructions, recommendations and detailed explanations of the activity.

Limitations 
The following aspects are not covered by the V-model, they must be regulated in addition, or the V-model must be adapted accordingly:

 The placing of contracts for services is not regulated.
 The organization and execution of operation, maintenance, repair and disposal of the system are not covered by the V-model. However, planning and preparation of a concept for these tasks are regulated in the V-model.
 The V-model addresses software development within a project rather than a whole organization.

See also 
 Engineering information management (EIM)
 ARCADIA (as supporting systems modeling method)
 IBM Rational Unified Process (as a supporting software process)
 Waterfall model of software development
 Systems architecture
 Systems design
 Systems engineering
 Model-based systems engineering
 Theory U

References

External links 

 
 
 

Software project management
Systems engineering
V 모델(V-model)은 소프트웨어 개발 프로세스로 폭포수 모델의 확장된 형태 중 하나로 볼 수 있다. 아래 방향으로 선형적으로 내려가면서 진행되는 폭포수 모델과 달리, 이 프로세스는 오른쪽 그림과 같이 코딩 단계에서 위쪽으로 꺾여서 알파벳 V자 모양으로 진행된다. V 모델은 개발 생명주기의 각 단계와 그에 상응하는 소프트웨어 시험 각 단계의 관계를 보여준다.

V 모델은 소프트웨어 개발의 각 단계마다 상세한 문서화를 통해 작업을 진행하는 잘 짜인 방법을 사용한다. 또한 테스트 설계와 같은 테스트 활동을 코딩 이후가 아닌 프로젝트 시작 시에 함께 시작하여, 전체적으로 많은 양의 프로젝트 비용과 시간을 감소시킨다.

검증(Verification) 단계들

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

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

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

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

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

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

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

유효화(Validation) 단계들

단위 테스트 
V 모델 방식의 소프트웨어 개발에서 단위 테스트는 테스트 프로세스의 첫 단계이다. 소프트웨어 개발 전문가인 Barry Boehm에 따르면, 단위 시험 단계에서 오류를 수정할 경우, 고객에까지 오류가 전달되었을 때에 비해 수백 배의 수정 비용을 절감할 수 있다.

단위 테스트 시에는 에러를 줄이기 위한 의도로 작성된 코드에 대한 분석을 진행한다. 또한 코드가 효율적으로 작성되었는지, 프로젝트 내에 합의된 코딩 표준을 준수하고 있는지도 검증한다. 대개 이 단계에서의 테스트는 화이트박스 테스트이다. 모듈 설계 단계에서 준비된 테스트 케이스를 이용하며, 코드를 개발한 개발자가 직접 수행한다.

통합 테스트 
통합 테스트 단계에서는, 각각의 모듈들을 통합하여, 통합된 컴포넌트 간의 인터페이스와 상호작용 상의 오류를 발견하는 작업을 수행한다. 대개 이 단계에서는 테스트는 블랙박스 테스트(Black box testing)이며, 따라서 코드를 직접 확인하는 형태는 아니다. 아키텍처 설계 단계에서 준비된 테스트 케이스를 사용하여 테스트가 진행되며, 일반적으로 개발자가 진행한다.

시스템 테스트 
시스템 테스트는 실제 구현된 시스템과 계획된 사양(specifications)을 서로 비교하는 작업이다. 실제 환경과 유사한 환경에서 테스트를 진행한다. 이 단계에서 시스템 테스트에 대한 설계가 시스템 설계 문서로부터 도출되어 사용된다. 때로 시스템 테스트는 자동화 도구를 이용하여 자동화된다. 모든 모듈을 통합한 후에, 시스템 레벨의 에러들이 이 테스트 단계를 통해 발견될 수 있다. 개발자와 다른 별도의 테스트팀에 의해 수행된다.

인수 테스트 
인수 테스트는 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 "확신(Confidence)"을 얻는 작업이다. 이 단계에서 결함을 찾는 것은 인수 테스팅의 주 목적이 아니다. 이 테스트는 시스템을 배포하거나 실제 사용할만한 준비가 되었는지에 대해 평가한다. 하지만 대규모의 통합 테스트를 시스템에 대한 인수 테스트 이후에 실행할 수 있기 때문에 인수 테스팅이 반드시 최종 단계 테스팅이라고는 할 수 없다. 인수 테스팅의 전형적인 형태는 사용자 인수 테스팅, 운영상의 인수 테스팅등이 있다.

같이 보기 
 시스템 개발 생명주기
 제품 생명주기 관리

더 읽을 거리 
 Roger S. Pressman:Software Engineering: A Practitioner's Approach, The McGraw-Hill Companies, 
 Mark Hoffman & Ted Beaumont: Application Development: Managing the Project Life Cycle, Mc Press, ISBN-10: 1883884454
 Boris Beizer: Software Testing Techniques. Second Edition, International Thomson Computer Press, 1990,

외부 링크 

 A paper by Christian Bucanac
 소프트웨어 생명주기와 식스시그마(The SDLC and SixSigma)
 중소규모 DB 응용을 위한 소프트웨어 생명주기(SDLC for small and medium DB applications)

소프트웨어 공학
소프트웨어 프로젝트 관리