Software Process Models The V-Model is Dead. Long Live the V-Model!

The V-Model has been around for a pretty long time. Is it outdated? Is it possible to adapt the model towards more agile methodologies? There are some surprising answers to these questions.

Anbieter zum Thema

Axivion GmbH

Introduction

This paper does not concern itself with the German Vorgehensmodell which is correctly, but sometimes confusingly, also known as the V-Model. This German Vorgehensmodell gives guidance and rules for realisation of German government projects. This paper introduces a simple V-Model. Based upon part of this a simple information model is presented in order to structure the main part of the discussion in this paper. Each level of the left side of a V-model is described. A V-model is a static model that helps to structure a system into smaller parts, and does not introduce any sequence of creation of specifications or implementation.

Bildergalerie

A Simple Information Model

Purpose: to simplify the structuring of specifications of systems, their component parts, and the verification and validation thereof. Consider the simplified information model shown in the form of a V. The left side represents requirements (things to achieve), and the right side represents planned verification (checking that the thing is produced right), and validation (checking that the right thing is produced).

Let´s concentrate on the left side, so that the right-hand side is not considered here. The right-hand side is important but is outside the scope of discussion here. The right-hand side is where the plans to integrate parts are documented and intended verification and validation are specified. The boxes in the simple information model represent documents that are specifications, e.g. Customer Requirements Specification.

The numbers at each level are used as a short-hand reference for simplification of referring to a specific level on the information model, or to a specific type of specification e.g. the Customer Requirements Specification is level 1. The numbers do not represent a sequence or level of detail. Each level consist of the definition of responsibility e.g. the role of System Architect, the definition of a process to achieve the aim of each level e.g. Specify System Architecture, and the definition of a work-product e.g. System Architectural Specification. These 3 things are summarised by the use of a number to refer to the definition of responsibility, process, and work-product.

The specifications may even all be worked on at the same time.

Considering each Level

Purpose: to better understand each level of a V-model, and their effects on each other. The sequence of these sub-chapters, and the numbering thereof, does not denote a sequence of creation of the specifications.

Level 1 Customer Requirements Specification

Purpose: to enable a common understanding of a Customer’s needs and wishes.

Customer wishes are documented. We shall call this type of information level 1. The Customer is responsible for this. The work might be done by other experts, but the customer retains responsibility. The customer may wish for anything. So quite naturally and correctly the Customer Requirements Specification might, from time-to-time, restrict the solution.

Level 2 System Requirements Specification

Purpose: to enable a common understanding of a commitment to supply a particular solution as required by the Customer Requirements Specification

A Supplier documents what they have committed to supply. We shall call this type of information level 2. At this point compliance or non-compliance with the customer wishes are documented. The System Analyst is responsible for this. The work might be done by other experts, but the System Analyst retains responsibility.

The System Architect will be involved to ensure that what is promised by the System Analyst is feasible within the resources available.

(ID:44547210)