Editing V-model

{{Short description|Graphic of a systems development lifecycle}}
{{For|the version specific to software development|V-model (software development)}}
[[Image:Systems Engineering Process II.svg|thumb|420px|The V-model of the systems engineering process.<ref name="FHWA 05">[http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/14158.htm ''Clarus Concept of Operations''] {{Webarchive|url=https://web.archive.org/web/20090705102900/http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/14158.htm|date=2009-07-05}}, Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005.</ref>]]
{{Software development process}}

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.<ref>[http://www.clarotesting.com/page11.htm#coherence "The Dangerous & Seductive V Model"] {{Webarchive|url=https://web.archive.org/web/20190915230955/http://www.clarotesting.com/page11.htm |date=2019-09-15}}, accessed January 9, 2013.</ref>

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.<ref name="VPM" /><ref name="INCOSE" /><ref>{{cite journal|year=1998|title=System Engineering for Faster, Cheaper, Better|url=http://www.incose.org/sfbac/welcome/fcb-csm.pdf|publisher=Center of Systems Management|author=Forsberg, K., Mooz, H.|archive-url=https://web.archive.org/web/20030420130303/http://www.incose.org/sfbac/welcome/fcb-csm.pdf|archive-date=April 20, 2003}}</ref><ref>{{cite web|url=http://www.gmu.edu/departments/seor/insert/robot/robot2.html|title=The SE VEE|publisher=SEOR, George Mason University|access-date=May 26, 2007|archive-url=https://web.archive.org/web/20071018220159/http://www.gmu.edu/departments/seor/insert/robot/robot2.html|archive-date=October 18, 2007|url-status=dead|df=mdy-all}}</ref><ref name="Original">Forsberg, K. and Mooz, H., [http://www.csm.com/repository/model/rep/o/pdf/Relationship%20of%20SE%20to%20Proj%20Cycle.pdf "The Relationship of Systems Engineering to the Project Cycle"] {{Webarchive|url=https://web.archive.org/web/20090227123750/http://www.csm.com/repository/model/rep/o/pdf/Relationship%20of%20SE%20to%20Proj%20Cycle.pdf |date=2009-02-27 }}, First Annual Symposium of the National Council On Systems Engineering (NCOSE), October 1991</ref> 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.<ref>[https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html "V-Modell site (in German)"], accessed July 10, 2020.{{Dead link|date=November 2024}}</ref>  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.<ref>German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model, August 1992</ref><ref>{{cite web |title=Fundamentals of the V-Modell |url=http://v-modell.iabg.de/v-modell-xt-html-english/349ffba5c5cda0.html#toc12 |access-date=17 Nov 2024}}</ref><ref>{{cite web |title=V-Modell XT, Part 1: Fundamentals of the V-Modell |url=http://ftp.uni-kl.de/pub/v-modell-xt/Release-1.1-eng/Dokumentation/pdf/V-Modell-XT-eng-Teil1.pdf |access-date=17 Nov 2024}}</ref>

=== 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.<ref>[http://www.istqb.org/downloads/viewdownload/16/15.html "International Software Testing Qualifications Board – Foundation Level Syllabus"], accessed January 9, 2013.</ref> 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. 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.<ref>{{cite web | url=https://ops.fhwa.dot.gov/publications/seitsguide/seguide.pdf | title=Systems Engineering for Intelligent Transportation Systems| publisher=US Dept. of Transportation|page=10| access-date=June 9, 2007}}</ref><ref>[https://www.fhwa.dot.gov/cadiv/segb/index.cfm "US Dept of Transportation, Federal Highway Administration. Systems Engineering Guidebook for ITS"], accessed January 9, 2013.</ref><ref name=VPM>Forsberg, K., Mooz, H., Cotterman, H. ''Visualizing Project Management,'' 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.</ref><ref name=INCOSE>International Council On Systems Engineering (INCOSE), ''Systems Engineering Handbook Version 3.1,'' August 2007, pages 3.3 to 3.8</ref><ref>{{cite web
| url = http://www.dau.mil/pubscats/PubsCats/AR%20Journal/arj53/Redshaw53.pdf
| title = BUILDING ON A LEGACY: RENEWED FOCUS ON SYSTEMS ENGINEERING IN DEFENSE ACQUISITION
| access-date = 14 Apr 2016}}</ref><ref>{{cite web
| url = https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html
| title = Using V Models for Testing 
| date = 10 November 2013 
| access-date = 14 Apr 2016}}</ref>

== Validation vs. verification ==
{{Main|Verification and validation|Validation (drug manufacture)}}

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.

[[A Guide to the Project Management Body of Knowledge|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:<ref name="pmboked4">{{cite book | date = June 2011 | url = https://ieeexplore.ieee.org/document/5937011 | access-date = May 25, 2021 | doi = 10.1109/IEEESTD.2011.6086685 | page=452 | isbn = 978-0-7381-6817-3 | title = 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 }}</ref>
* "'''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 ==
[[Image:Systems Engineering and Verification.jpg|thumb|320px|Systems engineering and verification.<ref>Systems Engineering Fundamentals. Defense Acquisition University Press, 2001.</ref>]]

=== 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.<ref name = "FHWA 05"/>

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.<ref name = "FHWA 05"/><ref name=VPM/><ref name=INCOSE/><ref name=Original/>

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.<ref name = "FHWA 05"/><ref name=VPM/>

=== 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 ==
[[Image:VPM3e Vee with detail.gif|thumb|320px|Off-Core alternatives (illustrating upward and downward iterations and Time and Maturity dimension). Source - K. Forsberg and H. Mooz 2004<ref name=VPM/><ref name=Original/>]]
The V-model is used to regulate the software development process within the German federal administration. Nowadays{{when|date=January 2023}} 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.<ref name=GermanOriginal>{{cite web|url=http://www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc|title=V-Model Lifecycle Process Model|publisher=v-modell.iabg.de|access-date=December 24, 2015|archive-url=https://web.archive.org/web/20160303204644/http://www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc|archive-date=March 3, 2016|url-status=dead|df=mdy-all}}</ref>
* The US V-model, as documented in the 1991 proceedings for the [[International Council on Systems Engineering|National Council on Systems Engineering]] (NCOSE; now INCOSE as of 1995),<ref name=Original/> 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) <ref name="scribd">{{cite web |url=https://www.scribd.com/doc/2019286/Sequential-Thematic-Organization-of-Publications |archive-url=https://web.archive.org/web/20080203133138/http://www.scribd.com/doc/2019286/Sequential-Thematic-Organization-of-Publications |archive-date=February 3, 2008 |url-status=dead |title=Sequential Thematic Organization of Publications (STOP) |access-date=December 24, 2015 |df=mdy-all }}</ref> created by Hughes in 1963 and used until Hughes was divested by the [[Howard Hughes Medical Institute]] in 1985.<ref>{{cite book | title = Sustainable Development Possible with Creative System Engineering|isbn=978-0615216300|last1=Sobkiw|first1=Walter|date=2008-01-01|publisher=Lulu.com }}</ref>
* The US Department of Defense puts the [[systems engineering]] process interactions into a V-model relationship.<ref>{{cite web 
| url = http://www.dau.mil/pubscats/PubsCats/atl/2006_03_04/mar-apr06.pdf
| title = A New Systems Engineering Model and an Old, Familiar Friend; Figure 2 V-9 Process Interactions
| publisher = Defense AT&L
| page = 51
| date = Apr 2006
| access-date = 7 Apr 2016}}</ref>

It has now found widespread application in commercial as well as defense programs. Its primary use is in project management<ref name=VPM/><ref name=INCOSE/> 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.<ref name=VPM/><ref name=INCOSE/><ref name=Original/>  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.<ref name=VPM/>

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 [[Systems development lifecycle|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.<ref name="VModelChange">{{cite web|url=http://v-modell.iabg.de/v-modell-xt-html-english/db09fe25265517.html#toc34|title=Further Development of the V-Modell (broken link)|publisher=v-modell.iabg.de|archive-url=https://web.archive.org/web/20110423005924/http://v-modell.iabg.de/v-modell-xt-html-english/db09fe25265517.html#toc34|archive-date=April 23, 2011|url-status=dead|access-date=December 24, 2015|df=mdy-all}}</ref>
* 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.<ref name="VModelActivities">{{cite web|url=http://v-modell.iabg.de/v-modell-xt-html-english/dbe1fba6c7da92.html#toc797|title=Overview of the Activity Model of the V-Modell (broken link)|publisher=v-modell.iabg.de|archive-url=https://web.archive.org/web/20110719043340/http://v-modell.iabg.de/v-modell-xt-html-english/dbe1fba6c7da92.html#toc797|archive-date=July 19, 2011|url-status=dead|access-date=December 24, 2015|df=mdy-all}}</ref>

== 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:<ref name=VModelLimits1>{{cite web|url=http://v-modell.iabg.de/v-modell-xt-html-english/446bfd42664fda.html#toc9|title=Limits of the VModel|publisher=v-modell.iabg.de|access-date=December 24, 2015|archive-url=https://web.archive.org/web/20110521043950/http://v-modell.iabg.de/v-modell-xt-html-english/446bfd42664fda.html#toc9|archive-date=May 21, 2011|url-status=dead|df=mdy-all}}</ref><ref name=VModelLimits2>Christian Bucanac, [http://www.bucanac.com/documents/The_V-Model.pdf The V-Model]</ref>

* 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 (engineering)|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 ==
{{Reflist}}

== External links ==
{{Commons category|V-models}}
* {{cite web |url=http://g2sebok.incose.org/app/qualsys/view_by_id.cfm?ID=INCOSE%20G2SEBOK%203.30&ST=F |archive-url=https://web.archive.org/web/20070927005332/http://g2sebok.incose.org/app/qualsys/view_by_id.cfm?ID=INCOSE%20G2SEBOK%203.30&ST=F |archive-date=2007-09-27 |title=INCOSE G2SEBOK 3.30: Vee Model of Systems Engineering Design and Integration |website=g2sebok.incose.org |publisher=[[International Council on Systems Engineering]]}}
* {{cite web |url=http://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html |title=Das V-Modell XT |website=cio.bund.de |publisher=[[Federal Office for Information Security]] (BMI) |language=de}}
* {{cite web |url=https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html |title=Using V Models for Testing |date=11 November 2013 |website=insights.sei.cmu.edu |publisher=[[Software Engineering Institute]], [[Carnegie Mellon University]]}}

{{Systems Engineering}}

[[Category:Software project management]]
[[Category:Systems engineering]]