The V‐Model     1 

Running head: THE V-MODEL LIFECYCLE PROCESS MODEL

The V-Model Lifecycle Process Model:

As a Software Development Standard

Joshua Thacker

Object-Oriented Systems Analysis and Design

Dr. Rhonda Syler

November 1, 2009
      The V‐Model     2 
 

Abstract

The V-Model is an approach to the system development life cycle process that uniquely

combines the advantages of both the predictive and adaptive approaches to developing

information systems and deserves careful consideration when planning a new information

system. It is a generic process model, which means that it is independent of organization and

project type and can be tailored to meet the needs of any project. As with any software

development lifecycle model, there are advantages and disadvantages to the V-Model that should

be taken into consideration when pondering the use of this particular model. This paper

describes the V-Model from a high level view, and explains it in such a way that no previous

knowledge is needed to gain insight from the information provided here.

      The V‐Model     3 
 

The V-Model Lifecycle Process Model:

As a Software Development Standard

There are many approaches to the planning and organization of projects that produce new

information systems. For instance, the waterfall model is a predictive approach to the system

development life cycle that assumes the various phases of a project can be completed

sequentially without returning to the previous phases. There is also the spiral model, which is an

adaptive approach, which cycles over and over again through development of activities until a

project is complete. The V-Model is another approach to the system development life cycle

process that uniquely combines the advantages of both the predictive and adaptive approaches to

developing information systems and deserves careful consideration when planning a new

information system.

Overview

The V-Model was designed by the IABG in Ottobrun, Germany, in cooperation with the

Federal Office for Defense Technology and Procurement, for the Federal Ministry of Defense. It

was conceived in an attempt to standardize software development for the government and the

private sector. The V-Model uses standardized and methodical guidelines in order to obtain

several objectives. These objectives include the reduction of software costs in the entire

lifecycle, the improvement of software quality, and the improvement in communication between

the customer and the contractor. The V-Model is a generic process model, which means that it

is independent of organization and project type and can be tailored to meet the needs of any

project. There are some important advantages that the V-Model offers over other models that

make this approach a favorable selection.

      The V‐Model     4 
 

Three-Level Standardization Concept

Lifecycle Process Model

As shown in Figure 1, the V-Model has three levels: Procedures, Methods and Tool

Requirements. The Procedures level, also known as the Lifecycle Process Model, addresses and

answers the question, “What needs to get done in order to successfully complete the project at

hand?” The Procedures level helps to establish a clear directive as to what activities need to be

performed, the end result of those activities produced at final completion, and the meaning of the

substance obtained from the end result. The execution and results of the activities are exactly

described in great detail (see Figure 2). The Lifecycle Process Model can be extremely complex,

but to simplify matters we can summarize the Procedures level into two concepts; activities and

products. By doing this, we can avoid the complications of dealing with states and

interdependencies of the Activity Schema and the Product Flow Schema. Activities are iterative

actions known as work-steps in the development process. Depending on the level of difficulty,

an activity can be broken down into a sub-activity. The highest level of notion (i.e., a

generalized/broad work-step), is called the main activity, which is deemed as abstraction in

programming. The final outcome of an activity is a product. A product can be a document,

software, or hardware. As aforementioned, a product is the final result of an activity. Products

just like activities can be dissected into smaller more manageable parts called sub-products. A

product undergoes different states as it is generated, and these changes in states can only be

triggered by an activity. As shown in Figure 3, a product can have the following states:

• Planned is the initial state in which the product is conceptualized. The product does not
yet exist but begins to develop and unfold during this state.
      The V‐Model     5 
 

• Processed is the state in which the product begins to take shape. The developer has
complete control of the product and molds it according to the design specifications.

• Submitted is the state in which the developer has finalized the product according to the
organizational requirements. The developer submits the product to the Quality Assurance
team for analysis and review. If the product fails to meet the requirements specifications,
the product is returned to the developer for further processing. If the product passes the
Quality Assurance inspection, it moves to the Accepted state.

• Accepted is the state in which the product receives a version number. The product can
continue to receive modifications and updates through validation from Change
Management throughout its lifetime with new assigned and updated version numbers.

Allocation of Methods

The second level, also known as the Allocation of Methods level (Methods), addresses

and answers the question, “How will the project reach its full completion?” During this level,

certain guidelines (methods) are determined and followed to aid in the completion of the system

development activities addressed in the Procedures level (see Figure 2). The Methods level truly

complements the Lifecycle Process Model by specifying how something is done. Before

specifications are given to determine how something is done, the tasks or projects that need to be

completed must be identified. This level sets the tone by legitimizing the selection and

application of methods for all sub-models. For each activity a method is chosen and documented

in the project manual.

Functional Tool Requirements

The third level, also known as the Functional Tool Requirements, addresses and answers

the question, “What tools will be used to follow the guidelines to perform these activities?”

Within this level, the system requirements (functional characteristics) that the tools must have to

complete the delegated activities within various processes are identified (see Figure 2). These

system requirements are based solely on the policies and procedures that are used by the
      The V‐Model     6 
 

Organization to manage the business. The Functional Tools Requirements also legitimize the

selection and application of tools for all sub-models. It not only complements the Lifecycle

Process Model but supports the Allocation of Methods level by using one or more tools. A tool

is defined as a, “software product/support that facilitates the development, modification, and

maintenance of models or components required for the success of the IT system” (Satzinger,

Jackson, & Burd, 2004).

Functional Sub-model Concept

As shown in Figure 1, the V-Model also has four sub-models. All three levels (i.e.,

Procedures, Methods, and Tool Requirements) of the V-Model are structured according to the

sub-models functional principals. Each sub-model consists of activities and generates products.

The activities and products are interdependent of each other to achieve the project goal. Products

are never stagnant and continue to be molded as the project grows – continuously being refined,

updated, and detailed throughout the activities. This modification process can continue to occur

as long as the version number is updated. As shown in Figure 4, the four sub-models are:

Project Management (PM), System Development (SD), Quality Assurance (QA), and

Configuration Management (CM).

Project Management

Project Management assists in the planning, monitoring, and controlling of the system

development project while passing information to the other sub-models. This sub-model states

that staff members play an important role in the planning of the activities. The staff members

should help with the estimating and deciding of the time schedule. Each Project Management

sub-model has a job selection and project members are matched with specific roles. Project

Management is comprised of 14 main activities:

      The V‐Model     7 
 

1. Project Initialization consists of creating a project specific V-Model. The organizational

framework is planned and documented in a project plan. The framework is solely based
off of the project manual.

2. Placement/Procurement evaluates the feasibility requirements by reviewing the requests

for proposals by subcontractors.

3. Contractor Management ensures all contracts are satisfied.

4. Detailed Planning utilizes the specifications in the project manual and establishes a
detailed plan for the project.

5. Cost/Benefit Analysis each solution proposal is evaluated according to its cost benefit
analysis and a profitability solution is developed.

6. Phase Review validates the project status according to the planned documentation.

7. Risk Management detects and mitigates project risks with prevention measures.

8. Project Control controls the flow and progress of the project.

9. Information Service/Reporting allows information to be available to stakeholders.

10. Training/Instruction trains all active project participants to ensure they have the
necessary knowledge to fulfill their roles.

11. Supplying Resources assesses the needed resources for project completion.

12. Allocation of work orders initiates job sections by the work orders.

13. Staff Training introduces project members to their job sections where they are informed
and trained in order to complete their tasks.

14. Project Completion consists of writing a final project report which contains all project
experiences.

System Development

System Development is the second sub-model and it controls the activities in the

development of the system project. System Development places a high emphasis on off-the-
      The V‐Model     8 
 

shelf components. Off-the-shelf components are given special attention in the System Design

phase. Feasibility studies are performed based on requirements and off-the-shelf components are

assessed. System Development is comprised of eight activities:

1. System Requirements Analysis is a specification from an external point-of-view (i.e., user

specifications).

2. System Design deals with the conception and integration of the system architecture.

3. SW/HW Requirements Analysis updates the operational and technical requirements with
regard to the software and hardware requirements.

4. Preliminary SW design involves the designing of the software architecture, interface

description, and integration plan.

5. Detailed SW Design elaborates and fine-tunes the integration description and software
architecture while the specifications, details for modules, components, and database are
created.

6. SW Implementation shapes the modules, components, and databases into a compiled and
executable form.

7. SW Integration realizes and incorporates the modules, components, and databases in

several steps.

8. Transition to Utilization ensures tasks in the system are operational in the intended
environment.

Quality Assurance

Quality Assurance is the third sub-model. It attests to the quality of the activity and

product requirements and ensures the other sub-models are informed and comply within

specified standards before acceptance is validated. This sub-model assesses the products and

processes of a given project and operates in the short-run. Since the V-Model is a project

process model and not an organizational process model, there are no long-run plans dealing with
      The V‐Model     9 
 

continuous improvements. It compares the products and processes with plans, standards, and

definitions. Quality Assurance is comprised of five activities:

1. QA Initialization coordinates the procedural and organizational scope and all

specifications are documented in a QA plan.

2. Assessment Preparation contains the criteria, definition methods, test cases, environment,
and produces the assessment plan.

3. Process Assessment of Activities assesses the processes to ensure they are sufficient.

4. Product Assessment assesses the product. The product is either accepted and enters the
accepted state or it is rejected and goes back to the processed state.

5. QA Reporting evaluates the number of problems, severity of problems, classification of

problems, the cause of problems, and documents all in an assessment report.

Configuration Management

Configuration Management is the fourth sub-model and it guarantees that a product can

be uniquely identified by asserting control modifications and integrity parameters that manage

the generated products. Configuration Management is comprised of four activities:

1. CM Planning defines the organizational framework, needed resources, and tools by

documenting them in the CM plan.

2. Product and Configuration Management administers the product library and the
configuration of the entire system.

3. Change Management manages changes in three steps: (1) change is requested and
registered; (2) change is evaluated for acceptance or rejection; (3) if changes are
accepted, they are then implemented and all affected by new change are informed.

4. CM Services aid in the project development (i.e., catalog software products, coordinating
interfaces, backups, release management, and recording project history).
      The V‐Model     10 
 

Considerations

Advantages

Model. Perhaps the most important advantage that the V-Model has over other models is

that it is organizational and project independent so that each project - at start - can be tailored

into a specific “Project V-Model” (see Figure 5). The fact that end-users participate and play a

crucial role in the development and maintenance of the V-Model is a key advantage since it

ensures that the final product is tailored to the needs of the actual users. Lastly, there is a high

level of control before actions are taken place on the system, as a change control board meets

once a year to process all received requests.

Methods. The V-Model offers a limited number of highly defined and described

methodologies that aids the project manager in quick selection of methods best suited to

complete the project goals. These methodologies support both structured and object-oriented

system development.

Tools. The tools provided in the V-Model are tested and proven and have shown high

levels of productivity with prior projects. A collection of tools are organized so that the

developer can better fulfill completion of the product according to their functional and non-

functional requirements. The selection of tools depends on the definition of the system

requirements, and each tool is chosen according to which requirement it fulfills.

Disadvantages

Model. The V-Model addresses the development of software within a given project

rather than an entire Organization, meaning that once the project has reached completion, the V-

Model ceases to exist. Also, sub-models cover all aspects of an activity but only from a high

level view. Once the project team reveals the conceptual level, there are no principles to follow.
      The V‐Model     11 
 

Lastly, it is easy to assume a thorough review and inspection has been done but there are no

measurable guidelines outlined in the V-Model for the inspection process.

Methods. While offering, a limited number of methods is an advantage in the selection

process, it neglects to offer all of the potential methods that could have been used – consideration

for other options is not available.

Tools. The System Development Environment in the V-Model includes guidelines for

hardware development; however, there are no hardware tools defined or described by the V-

Model.

Summary

In summary, the V-Model is a software development lifecycle process model that

incorporates aspects from both the typical Waterfall (predictive) and Unified Process (adaptive)

models. As shown in Figure 6, the model can be represented as a “V” shape where on the top of

the left side are the high level concepts. As one descends down the “V” through the definition of

sequence and elaboration of detail (verification), the testing techniques associated with the

design are shown. At the base of the “V”, begins the coding phase. The model considers coding

and testing during this phase of the software development process equal. As one ascends up the

right side of the “V” through the assembly and performance assurance sequence (validation), the

requirements specifications are defined and subsequently a product is completed, implemented,

and maintained.
      The V‐Model     12 
 

References

Forsberg, K., & Mooz, H. (1998). System Engineering for Faster, Cheaper, Better. California:

Center for Systems Management, Inc.

Forsberg, K., & Mooz, H. (1992). The Relationship of System Engineering to the Project Cycle.

Engineering Management Journal (No. 3), 36-43.

Graham, D. (2002, July 1). Architecture & Design. Retrieved October 10, 2009, from Dr.

Dobb's: http://www.ddj.com/architect/184414873

IABG Information Technology. (2009). V-Model. Retrieved October 12, 2009, from IABG:

http://www.iabg.de/infokom/software_einfuehrung/v-modell_en.php

IABG Information Technology. (n.d.). V-Model Lifecycle Process Model. Retrieved October 12,

2009, from IABG: www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc

Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2004). Object-Oriented Analysis and Design

with the Unified Process (1st ed.). Course Technology, Cengage Learning.

Schuppan, V., & Rußwurm, W. (2000). A CMM-based evaluation of the V-Model 97. In

Software Process Technology (Vol. 1780/2000, pp. 69-83). München, Germany, Europe:

Springer Berlin / Heidelberg.

V-Modell®XT authors and others. (2006). V-Modell® XT, Version 1.3 English. Retrieved

October 1, 2009, from Fundamentals of the V-Modell: http://v-modell.iabg.de/v-modell-

xt-html-english/index.html#toc0
      The V‐Model     13 
 

Figure 1. Cube architecture representation of the Three-Levels of Standardization with

Functional Sub-Models
      The V‐Model     14 
 

Figure 2. General structure of questions a given level addresses in the V-Model

      The V‐Model     15 
 

Figure 3. A transition of states a product goes through caused by activities

      The V‐Model     16 
 

Figure 4. Functional Sub-model framework

      The V‐Model     17 
 

Figure 5. Contractual and Technical aspects associates with tailoring

      The V‐Model     18 
 

Figure 6. Overview of the Technical aspect of the System Development Project Cycle