V-model (development standard)

from Wikipedia, the free encyclopedia

The V-Modell is a process model for IT development projects in the Federal Republic of Germany.

V-Modell is a registered trademark of the Federal Republic of Germany. The “V” in the term “V-Modell” does not stand for “procedure”, but rather visualizes the idea of ​​juxtaposing specification and dismantling with implementation and integration. This general approach was proposed as the V-model in the late 1970s. In the meantime, the V-Modell XT not only supports this approach, but also many other approaches (e.g. agile system development ).

The first V-model was developed in 1986 by the then federally owned company IABG . Initially it was intended for IT projects in the public sector in Germany, but it is now also used in the private sector.

In contrast to classic phase-oriented process models, only activities and results are defined in the V-Modell and no strict chronological sequence is required. In particular, the typical acceptances that define the end of a phase are missing . Nevertheless, it is possible to map the activities of the V-model on a waterfall model or a spiral model, for example .


The military origin

In 1986 the Federal Ministry of Defense started two projects

  • Software development environment for information systems (SEU-IS) and
  • Software development environment for weapon and weapon deployment systems (SEU-WS)

with the following goals:

  • To make the costs over the entire software development and maintenance process transparent and consequently also to limit them.
  • To guarantee a minimum standard for software quality through suitable measures or to further improve it.
  • To achieve greater independence from individual providers by comparing offers from third parties.
  • Standardize the development of software in-house and make it more transparent.

In principle, process models from NATO allies would also have come into question, such as the American standard DoD STD 2167 A or the more recent MIL-STD-498 or the French standard GAM T 17. However, a detailed examination of these models showed that they were unable to meet all requirements. The decision was therefore made to develop an in-house product, which in 1988 - as a result of the SEU-WS project - produced the first version of the V-model. The findings from the SEU-IS project were then integrated into this by April 1990 and the improved version of the V-model was established by the Federal Minister of Defense as a development standard for software creation in the Bundeswehr by decree of February 1991.

The civil V model

Since other federal authorities were confronted with similar problems, the V-Modell was handed over to the Federal Government's Coordination and Advice Center for Information Technology in the Federal Administration (KBSt) at the end of 1991 with the task of creating a civil version of the V-Modell . This work was completed in August 1993 and the resulting uniform version of the V-Model was published and laid down by the Federal Minister of Defense and the Federal Minister of the Interior.

V-model 97

New software development approaches (e.g. object orientation, etc.) made it necessary to revise the V-model, especially since it was very much tailored to the "classic software development approach" up to this point. As a result, the V-Modell '97 was published in June 1997, which has since been recommended for use in all software development in the federal administration.

V-model XT

The V-Modell 97 was replaced in February 2005 by version 1.0 of the V-Modell XT (XT = Extreme Tailoring , English "to tailor" = tailor) in the course of new findings in software development .

The main change points are here

  • the V-model can be adapted to the respective needs (= tailoring). In order not to produce excessive additional work when handling small and medium-sized projects, the V-Modell defines cancellation conditions for these project sizes that reduce the amount of activities and products to the necessary extent.
  • Involvement of the client: Until now, the specifications were geared towards the contractor. Now there are also process modules for the client.
  • Stronger modularization: The four previous sub-models no longer exist in this form, but only process modules from which the concrete process model of a project is put together (“tailoring”).
  • Stronger orientation towards agile and incremental approaches: "Moving from how to what ." The V-Modell XT does not stipulate any regulations about the chronological sequence of process modules. The focus is on the products created and not on the documentation as with RUP .

The V-Modell XT is provided by the Federal Government Commissioner for Information Technology . The current version can be found here. Further information as well as an annual exchange of experiences is provided by the ANSSTAND e. V. (representation of interests of the users of the system development STANDards V-Modell) made available on the homepage of the V-Modell representation of interests.

On May 15, 2012 the V-Modell-XT version 1.4 was published. It consists of:

  • Documentation in pdf and html format
  • Editor for editing the XML files
  • Project assistant to adapt the generic V-model to the needs of a specific project ('tailoring').

For the 10th anniversary of the V-Modell-XT-Version 2.0 was published in August 2015.

Version 2.2 was released on April 10, 2018.

Version 2.3 was released in March 2019.

Process modules and the V-model core

A process module covers a specific task that can occur as part of a development project. The products to be developed within this task definition (the process module), the activities through which the individual products are created, and the roles involved or responsible for the individual products are specified. The individual process modules are each self-contained. Dependencies and cross-relationships between the process modules are explicitly defined by the V-Modell. The V-Modell combines a number of similar activities for these process modules. There are a total of 22 of these process modules, some of which are used in all projects. These are therefore referred to as the V-model core. This includes:

  1. PM : project management
  2. QS : quality assurance
  3. KM : configuration management
  4. PA : Problem and Change Management
Mandatory process modules depending on the project type
AG = client; AN = contractor
Process module V-model core System development project (AG / AN) System development project (AG) System development project (AN)
Project management X X X X
quality control X X X X
Configuration management X X X X
Problem and change management X X X X
System creation X X
Requirements definition X X
Delivery and acceptance (AN) X X
Delivery and acceptance (AG) X X
Conclusion of contract (AN) X
Conclusion of contract (AG) X

Products and Activities

The V-Modell defines a series of documents called products . These are made up of individual topics (chapters). Products that have a strong context in terms of content are in turn assigned to the same product group .

Document status and its transitions

Every defined product goes through four states :

  1. planned
  2. in processing
  3. submitted
  4. accepted

whereby the following transitions between these states are possible:

Activities that change products are called activities ; these in turn are made up of individual sub-activities , each of which then deals with exactly one topic . Activities with related content are in turn combined into activity groups. For each activity it is precisely recorded which products it needs or changes and which work steps are necessary to bring about the desired modification. For this purpose, a product flow and processing are defined for each activity . While the product flow describes from which activities the required input products come with which status, in order to then be passed on in a modified form or modified status to a subsequent activity, the processing contains more precise instructions for carrying out the activity.

The time sequence of the activities results from the availability of the required (partial) products in a certain state.

Taken together, there are 35 roles and over 100 different products in the V-Model XT, which are being worked on within the 22 process modules. The continuation of the project is decided on the basis of a total of 21 decision points, of which the four decision points project approved , project defined , iteration planned and project completed belong to the V-model core. Decision points represent milestones, when they are reached, based on the current project status, a decision is made to continue the project. This decision is made by a steering committee .

See also


To the V-Model 97

  • Wolfgang Dröschel, Walter Heuser, Rainer Midderhoff, (Eds.): Incremental and object-oriented procedures with the V-Model 97. Oldenbourg, Munich 1998, ISBN 3-486-24276-8 .
  • Wolfgang Dröschel, Manuela Wiemers: The V-Model 97. The standard for the development of IT systems with instructions for practical use . Oldenbourg, Munich 1999, ISBN 3-486-25086-8 .
  • M. Reinhold, B. Oestereich, P. Hruschka, N. Josuttis et al .: Successful with object orientation: process models and management practices for object-oriented software development . Oldenbourg, Munich 2001, ISBN 978-3-486-25565-2 .
  • Contribution by Markus Reinhold to: Leichte procedural models: Rational Unified Process 2000 versus V-Modell'97 - A Comparison of the two most common used Process Models in Germany . Shaker Verlag , 2001, ISBN 978-3-8265-8577-7 .
  • Contribution by Markus Reinhold to: Practical suitability of process models: Specification of large IT systems - Integration of Requirements Engineering and UML based on V-Model'97 . Shaker Verlag, 2003, ISBN 978-3-8322-1330-5 .

To the V-Modell XT

  • Christian Bartelt, Thomas Ternité, Matthias Zieger: Model-based development with the V-Model XT , in: OBJEKTspektrum 05/2005, PDF .
  • Reinhard Höhn: The V-Model - a success story from authorities , in: OCG-Journal 05/2004.
  • Dirk Niebuhr, Andreas Rausch: Successful IT projects with the V-Model XT , in: OBJEKTspektrum 03/2005, PDF .
  • Andreas Rausch, Stephan Höppner: V-Modell XT - an introduction , in: Software Quality Management Volume 3, ed. by Stephan Höppner, 2005, Logos-Verlag, Berlin, ISBN 3-8325-0798-1 .
  • Andreas Rausch, Manfred Broy: The V-Model XT - Basics, Experience and Tools. dpunkt.verlag, Heidelberg 2007, ISBN 3-89864-335-2 .
  • Andreas Rausch, Manfred Broy, Klaus Bergner, Reinhard Höhn, Stephan Höppner: The V-Model XT. Basics, methodology and applications. Springer, Heidelberg 2007, ISBN 3-540-30249-2 .
  • Jan Friedrich, Ulrike Hammerschall, Marco Kuhrmann, Marc Sihling: The V-Model XT. For project managers and QA managers - compact and clear. Springer, Berlin; Heidelberg 2008, ISBN 978-3-540-76403-8 .

Web links

Individual evidence

  1. Dr. Marco Kuhrmann: V-Model XT. May 28, 2015. Retrieved June 29, 2017 .
  2. What does the "V" in "V-Modell XT" stand for?
  3. Archived copy ( Memento of the original from July 15, 2011 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.iabg.de
  4. http://www.everyspec.com/DoD/DoD-STD/DOD-STD-2167A_8470/ DOD-STD-2167A_8470
  5. http://www.everyspec.com/MIL-STD/MIL-STD+%280300+-+0499%29/MIL-STD-498_25500/
  6. Website of the V-Modell XT
  7. ^ Homepage of the V-Modell interest group
  8. IT Commissioner of the Federal Government | V-model XT. Retrieved July 10, 2017 .
  9. V-Modell® XT 2.2 Release Notes. Retrieved December 17, 2018 .
  10. Dirk Israel: V-Modell XT - new release 2.3 | WEIT eV - Association for the further development of the V-Modell XT. Retrieved on June 19, 2019 (German).
  11. tu-clausthal.de: V-model roles and products