The V-Modell XT Applied Model-Driven and Document-Centric Development

L-6

The V-Modell XT Applied Model-Driven and

Document-Centric Development
Andreas Rausch1, Christian Bartelt1, Thomas Ternit1 and Marco Kuhrmann2
1

Technische Universitt Kaiserslautern, Gottlieb-Daimler-Strae,

67663 Kaiserslautern, Germany
{rausch, bartelt, ternite}@informatik.uni-kl.de
2
Technische Universitt Mnchen, Boltzmann-Str. 3,
85748 Garching, Germany
kuhrmann@in.tum.de

Abstract. Whether an object-oriented or an agile approach the new V-Modell

XT fulfils many requirements. By changes in structure, it offers an overall view
of the system development and it solves the tightrope walk between power and
simplicity by tailoring a project perfectly. As is usual with a development process, the V-Modell XT expects creating and maintaining a set of crucial documents. Modern development approaches follow a more model-driven approach.
In the talk a short overview of the V-Modell XT is given. Then it is shown how
one can apply a model-driven development approach and generate and maintain
development documents in conformity with the V-Modell XT.

Introduction

In the face of the high impact of computer science on economy and administration,
the creation of IT systems still comes with a high level of uncertainty. A quarter of all
IT projects are cancelled before completion with dramatic consequences for all participants. Almost half are significantly behind schedule, budget or suffer from incompleteness [1, 2].
This current situation is not acceptable. The success rate, the productivity, and the
cost efficiency in terms of development, maintenance, and operation of IT systems
have to be increased. Standard process models like the Rational Unified Process
(RUP) [3] or the V-Model XT [4, 5] can contribute to alleviating this situation.
Those process models capture best practice knowledge, offer the possibility to acquire and use this knowledge, and last but not least provide an outline for training
young software engineers. Several studies give empirical evidence on such benefits.
Once a standardized process model is correct implemented within an organization
quality, productivity, and success rates are significantly increased [6].
Looking at software development, established methods and technologies are available. Process models support managers as well as developers in ordering and carrying
out typical activities to create the necessary artifacts. In this paper we want to give an
example for the practical application of a well defined process model combined with a
Model-driven approach. The V-Modell XT, we introduce in section 2, is a metaIII 131

L-6

The V-Modell XT Applied Model-Driven and Document-Centric Development

model-based, document-oriented, modular and extensible process model. We want to

present, how to integrate the V-Modell XTs products with Model-driven approaches.
We present an approach based on usual CASE- and Development-Tools in section 3.

The V-Modell XT A brief Introduction

The V-Modell is the German system development and lifecycle process model standard for federal administration and defense engineering projects. The V-Modell regulates the system development and maintenance process; it defines binding sets of
activities and artifacts, and accompanying processes such as quality assurance, configuration management, and technical project management. It is publicly available
and many companies have successfully adopted it.
In 2002, the most recent update of the V-Modell dated back to 1997. Many new
innovations in software engineering were missing, as were quality attributes of the
process model. Consequently, a project was initiated to analyze the drawbacks and
improvement potentials for the current V-Modell, and to develop a new redesigned
version called V-Modell XT. At the end of 2004 the new V-Modell XT was established within the federal administration, military engineering projects, and companies
as the new development process standard [7].
2.1

Meta-model as basis for the process model

The V-Modell XT is a generic process model based on a well-defined formal metamodel. The V-Modell can be applied to different project constellations. Hence, it is
necessary to customize the V-Modell to certain project settings. This customization
called tailoring is one of the first and most critical activities of a V-Modell user.
Tailoring in the context of the V-Modell XT means the selection of one of the supported project types, the process modules to be applied, and the strategy for project
operation to be used. All these meta-model concepts will briefly be introduced in the
following.
2.2

Process Modules

As shown in Fig. 1, a process module encapsulates a set of products, activities, and

roles. Products represent the What of a project, meaning all (provisional) results, like
documents, source codes or physical components. We want to focus documents later
in this article. Activities are the How part. They are directly assigned to products.
Every activity completes exactly one product. There are no activities defined that do
not complete any product. Finally, roles represented in Fig. 1 show the described
relations as well.
A process module contains a specific set of products, activities, and roles relevant
to a specific process area. All contents of a process module have content dependencies on each other. Thus, for example, the relevant contents for project management

III 132

The V-Modell XT Applied Model-Driven and Document-Centric Development

L-6

are collected in a separate process module; relevant contents for software development are collected in another process module, and so on.

Fig. 1. Simplified model of a process module. The gray-colored classes are the core elements of
the V-Modell XT representing the meta-model as well.

Each process module is an independent unit. It is individually changeable or extendable. The essential, static contents of the V-Modell XT are contained in the process modules. All products, activities, and roles do not contain any formal specification
or limitation for the projects execution or the products creation process.
2.3

Strategies for project operation

A projects execution is usually very complex. To enable reliable planning and controlling of a project, an ordered process has to be worked out. To support the users,
the V-Modell XT includes a catalog of so-called strategies for project operations
(SPO). SPOs contain the dynamic parts of the V-Modell XT. An SPO (Fig. 2) defines
the coarse frame for the traceable project operation. The V-Modell XT contains a set
of so-called decision points. Each decision point defines a set of products that have to
be finished. Hence, an SPO defines a set of decision points and an order across this
set to outline how the project has to be operated.
Decision points can be reached multiple times. For example, the V-Modell XT for
example predefines SPOs for Incremental System Development, Component-based
System Development or Agile System-development. Each SPO contains of a subset
of decision points and a specific order. This order is specified as End-Before-End,
which means that in principle, all steps can be started at the beginning of a project,
but a certain step can only be finalized if the previous one is finalized, too. The finalization of a project stage is marked by a decision point (see Fig. 2).
A decision point is, in principle, a milestone in a project, where the projects current state is evaluated. As shown in Fig. 2, a set of products is assigned to each deci-

III 133

L-6

The V-Modell XT Applied Model-Driven and Document-Centric Development

sion point. These products have to be in the finished state, which shows that these
products were tested during the quality assurance process. Looking at these products,
the project management has to decide whether the current stage can be finished successfully or not. Typical decision points are Project engaged or System specified.

Fig. 2. Model of the relations between project types, SPOs and process modules. Each project
type defines mandantory and optional process modules an implies at least one SPO consisting
of a set of decision points. Each decision point has a set of products in the finished state
assigend.

2.4

Project types

Obviously there exist dependencies between SPOs and process modules. The decision
points of an SPO refer to the products to be finished. These products can be located in
different process modules.
As mentioned above, the V-Modell XT is a generic process model that has to be
tailored before it can be applied in a project. During tailoring it has to be guaranteed
that a reasonable combination of process modules and SPOs will be selected.
Therefore, as shown in Fig. 2, the V-Modell provides project types. A project type
characterizes typical project settings like server-side system development. Each project type defines a reasonable combination of mandatory and optional process modules as well as a selection of corresponding SPOs.
2.5

Tailoring

Tailoring is one of the most important concepts of the V-Modell XT at all. It enables
that the V-Modell XT can be trimmed in order to fit a specific project so that all necessary products have to be created and no unnecessary activities are carried out [4, 5].
During the tailoring process, the user can select from a set of process modules. The
selected process modules contain all relevant products; activities and so on (refer to
Fig. 1 and Fig. 2). Users will only select process modules matching the current appli-

III 134

The V-Modell XT Applied Model-Driven and Document-Centric Development

L-6

cation profile. Selecting process modules and defining the projects type, the user will
be presented a collection of strategies for project operation he can choose from.
Let us give an example: When a software system has to be developed, process
modules for a hardware environment are not necessary and therefore should not be
used. On the basis of these identified attributes, necessary activities and products for
the specific project are automatically identified [4, 5]. Not selected attributes are not
taken into account.

Fig. 3. Tailoring mechanism. Starting with a project idea, the projects characteristics can be
specified using an application profile. The tailoring process will result in a reduced, projectspecific V-Modell XT including only products, roles, activities and a set of strategies for project operation fulfilling the projects requirements.

The resulting project specific V-Modell (Fig. 3) in general consists of a subset of

the available process modules of the complete model and is usually smaller in size.
Thus only project relevant activities will be carried out within a project.

Model-driven and document-centric development

In this section we want to focus Model-driven and document-centric approaches and

how to integrate them in a V-Model XT project. Beside the project type, the ideas we
will present now, mainly address server-side software development projects.
3.1

Document-centric approaches

The V-Modell XT is a document-centric process model. The document-centric approach has advantages and disadvantages. The advantages of an approach realized by
the V-Modell XT are for example:

III 135

L-6

The V-Modell XT Applied Model-Driven and Document-Centric Development

x Clearly defined documentation and content structure eases the orientation in a

complex project.
x Standardized and unique naming conventions are of advantage for finding information, quickly. This increases a projects transparency and comparability.
x Standardized repository structures enable centralized storage and thus simplified
version management.
So document-centric approaches have obvious advantages but require carefully
handling in other fields, like consistency management. If projects become large, the
assurance of the documents consistency is a special challenge. On the other hand,
consistent documents are one of the most important prerequisites for a long-living
systems maintenance, its operation or extension.
3.2

Model-driven approaches

For assuring documents consistency from the software development point of view,
Model-driven [8] approaches are of advantage. So lots of information and data about
development artifacts like code or models are available to architects and developers.
So for example source code can be the basis for an architecture model (this approach is used by Borland and Microsoft). Structured and connected texts can be the
basis for requirements models and both types of models can be connected and transformed into each other. The transformation of models is one of the most interesting
approaches of designing and developing systems. Most popular is the Model-driven
Architecture approach, published by the Object Management Group [9].
3.3

Model-driven approaches and the V-Modell XT

Both approaches have their advantages. In the following we want to present possibilities to couple both approaches making maximum use and outline their advantages by
avoiding the disadvantages.
As we pointed out during the previous sections, the V-Modell XT is a documentcentric approach. V-Modell XT products have defined structures. Requirements for
example are always on the same place in the specification sheets. Because of the
structure is well known, it is possible to edit products automatically and free of side
effects because other sections wont be touched.
Development-supporting tools like CASE-Tools or integrated development environments (IDE) can work using an underling model or a modeling language like UML
[9]. Usually code can be generated from models. The idea we want to present here is
not only to generate code but additional specification information as well. So for
example an architect can design a systems architecture using a design tool like Borland Together using UML diagrams. Using an UML-model it becomes possible to
check and validate the design. The same way it is possible to define interfaces for
components to generate code from.
After the design a generator can be used either to transform the models into source
code or to generate documentation (Fig. 4). Documentation can be diagrams or speciIII 136

The V-Modell XT Applied Model-Driven and Document-Centric Development

L-6

fications. The documentation can be generated directly into the V-Modell XTs specification documents (Fig. 4).

Fig. 4. Relation between the modeling level and the V-Modell XTs documentation structure.
Requirements are captured using CaliberRM; architecture models are designed using Together.
The models are used to fill the corresponding sections of a V-Modell XTs specification products.

Both models and documents can be versioned. Because of the clearly defined
structure of the V-Modell XTs products it is possible to generate products contents
in a very specific way. So for example if a components specification has changed,
not the whole documentation needs to be updated, but only the parts describing this
very component.

Summary

The V-Modell XT is a process model developed to target projects to be finished in

time, in budget and with the specified functionality. It is based on a document-centric
approach to improve projects transparence and to provide a uniform communication
base. But this approach includes a big challenge: the assurance of the products consistency, especially in large projects is not trivial.
Model-driven approaches for software development seem to address this problem
using abstractions in different models. Architecture descriptions or requirements can
be collected, designed and managed using specialized tools. Generators enable the
export to different formats using model transformations. Code or documentation can
be the results.
Combining Model-driven approaches with the well structured V-Modell XT, project members are enabled to work out their artifacts using tools like Borland Together
or Microsoft Visual Studio 2005. Coupling generators to these products enables project managers to generate the project and system documentation and specification. So
the advantages of both approaches are applied. The disadvantages are widely avoided,

III 137

L-6

The V-Modell XT Applied Model-Driven and Document-Centric Development

for example using models to handle a projects consistency and complexity. So developers can use up-to date model-based development methods and tools without waiving the luxury of automatically generated, standardized documents. A solid integration into the used tools of a potentially heterogeneous IT infrastructure is one of the
first and important steps, as well as having a specialized organizational development
process model available.

References
1. Standish Group International, Inc.: CHAOS: A Recipe for Success. 1999
2. K. Bergner, M. Broy, K. Moll, M. Pizka, A. Rausch, T. Seifert.: Erfolgreiches Management
von Softwareprojekten, Informatik Spektrum 27:5, Springer-Verlag, 2004, 419-432.
3. P. Kruchten.: The Rational Unified Process, An Introduction. Addison-Wesley, 2nd Edition,
2000
4. A. Rausch, M. Broy.: Das V-Modell XT, dpunkt.verlag, 2006
5. V-Modell XT. Definition and documentation on the web, http://www.v-modell-xt.de
6. J. Mnch and J. Heidrich. Software project control centers: concepts and approaches. The
Journal of Systems and Software, 70, 2004, 3-19
7. Projekt WEIT - Weiterentwicklung des Entwicklungsstandards fr IT-Systeme des Bundes
auf Basis des V-Modell-97, http://www.v-modell-xt.de, 2003
8. Th. Stahl, M. Vlter: Modellgetriebene Softwareentwicklung, dpunkt.verlag, 2005
9. Object Management Group (OMG), http://www.omg.org

III 138