Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

VModel

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 26

Competence, Creativity, Know-how

IABG Information Technology


Partner for standardized Software Development

V-Model
Lifecycle Process Model

Brief Description
The V-Model as Software Development Standard
– the effective way to develop high-quality software –

The V-Model as Software Development Standard


Configuration Management
Quality Assurance
The Three-Level 2. Methods Software Development
Standardization Concept "How is this to be achieved?"
Project Management

Today, the necessity for What is to be determined here is


standardization in software Procedure
with which methods the activities
development is undisputed; laid down for the first level are to
buzzwords such as "engineering be carried out and which
software development" are quoted Methods
presentation means are to be
daily. used in the results.
Less unique is the answer to the Tool
question how detailed and on which 3. Tool Requirements Requirements
Three levels of standardization
level standards are to be applied in a There is an activity description for
concrete project. "What is used to do something?"
each activity in a kind of task
The value of a standard here is the What is determined here is which description. There is a document
extent to which the following functional characteristics the description for each document,
objectives can be achieved with the tools have to have, which are to which defines the structure and
help of standardization measures: be used in the development of contents of the document.
• reduction of software costs in the software. Possible Applications of the
entire lifecycle, V-Model
On all levels, the regulations are
• improvement/warranty of The V-Model was developed from a
structured according to activity
software quality, variety of applicative aspects. The
areas:
• improvement in communication focal points of use are:
• software development,
between customer and • Contractual Basis
contractor. • quality assurance,
In this instance, the scope of
The standardization concept of the • configuration management, delivery of the software and the
German Federal Authorities pursues • project management. completeness of the software
this objective by regulations on three documentation are clearly
levels: For each level, a development
standard was drawn up by the defined.
• procedure, Federal Authorities. • Work Instruction
• applicable methods, The lifecycle process model
serves as guideline and concrete
• functional requirements applied In this overview, the lifecycle process
work instruction for software
to tools to be used. model (V-Model) is described as the
standard for the first level. It development with its detailed
The individual standardization levels descriptions of the activities and
regulates the software development
regulate the following situations: documents.
process in a uniform and binding
1. Procedure way by means of activities and • Communications Basis
products (results), which have to be By means of the description of
"What has to be done?" taken into consideration during the documents and the provision
What is to be determined here is software development and the of a glossary, it serves as the
which activities have to be carried accompanying activities for quality basis for mutual understanding
out in the process of the assurance, configuration manage- and reduces frictional losses
development of software, which ment and project management. between customer, user,
results have to be produced in contractor and developer.
this process and which are the
contents that these results have
to have.

2
The V-Model in the Public
Authorities Domain
The lifecycle process model was
originally developed by IABG in
Ottobrunn, near Munich, in
cooperation with the Federal Office
for Defence Technology and
Procurement in Koblenz, for the
Federal Ministry of Defence. It was
taken over by the Federal Ministry of
the Interior for the civilian public
authorities domain in summer 1992.
Hence a uniform standard for the
whole range of public authorities
exists.
The V-Model in Industrial
Use
The provisions of the lifecycle
process model are strictly
organizationally impartial. It is
restricted exclusively to the technical
development process. Therefore, the
lifecycle process model is not only
suitable as the development
standard in public administration but
also in industry. It already has been
taken over and is used as the
company standard by a number of
companies and is used both by
software and system houses and
also by users from many other
different areas such as

Federal Ministry of the Interior

Planning and Realization


of IT-Projects

V-Model
Software Lifecycle Process Model
August 1992

KBSt

V-Model cover page


for the civilian area
• banks,
• insurance companies,
• car manufacturers,
• manufacturing industry,
• energy producers.
The use of the lifecycle process
model in the industrial domain is
made considerably easier by the fact
that its use is free of license fees. It
is non-proprietary and not copy-
protected, which means that the
lifecycle model can be copied as
often as is wished for one's own use
without infringing licence regulations.

General Directive 250

Software-Development Standard
for the Federal Armed Forces

V-Model
Software Lifecycle Process Model
August 1992

V-Model cover page


for the defense area
V-Model on the European
Level
An English translation of the lifecycle
model was completed for use in
international projects. This is also
the subject of an EC project (EURO-
METHOD), which was started in
1989 with the aim of surveying
software engineering methods and
their harmonization. The German
representative in the EC Committees
is the Federal Ministry of the Interior.
In view of the Ministry's own use of
the V-Model, it has tabled it as the
German standardization contribution
at the European level.

Specific Consideration of
Special Usage Aspects
The V-Model takes into
consideration:
• the requirements for certification
of software according to IT-sec-
urity criteria;
• the particular features of detailed
information modelling as required
for the development of informa-
tion systems;
• the interactions between software
and procedure definition, as
these are to the fore in the
development of information
systems;
• the particular features of critical
realtime software, as they are
used especially in embedded
computer systems (ECS)
applications;
• the interactions between software
and hardware in the development
of ECS software.
V-Model and QA Standards
The V-Model fulfils the requirements
of the NATO standards AQAP-13/
AQAP-150 as software development
and quality assurance standards
when used in the defence
technology field.
In the whole public authorities dom-
ain, the most significant technical
"Minimum Requirements for Use of
Information Technology" of the
Federal and State Audit Offices are
fulfilled when the V-Model is applied
correctly.
In the industrial environment, the
application of the V-Model
guarantees the fulfillment of the
technical requirements of the
Standards in the ISO 9000 series (in
the software-related interpretation of
ISO 9000-3) and thus is of
assistance and a basis for ISO 9000
certifications.

V-Model Safety and


Security
The V-Model contains regulations
which are necessary for the
development of "critical" software.
The term criticality refers on the one
hand to aspects included in the term
"safety" and, on the other hand, to
confidentiality aspects (security).

The current valid IT-Security Criteria


(ITSEC) are fulfilled with respect to
their regulations for the development
process by the application of the V-
Model. Certification of the software
developed in this way has been
considerably facilitated.
Where and How Obtainable The necessary user influence on the The Change Control Board is
maintenance and change process of obliged, according to its standing
The V-Model can be obtained from the V-Model is guaranteed by a orders, to deal thoroughly with all
the following places in Germany: Change Control Board with annual incoming change requests which are
• BMVg – FÜS I -1 meetings. It consists out of submitted to it.
Postfach 1328 representatives of industry
associations and public authorities. Explanatory Appendices to
D-53003 Bonn
(for the defense domain)
the V-Model
• Bundesanzeiger- Besides the actual regulations part,
Verlagsgesellschaft mbH the V-Model contains three
Postfach 10 05 34 appendices:
D-50445 Köln
(volumes 27/1 and 27/2 of the • Appendix 1 "Explanations to the
KBSt-publication series, civilian V-Model-Application". This
version) explanatory section provides
• IABG, Dept. ITE background information and
Einsteinstr. 20 facilitates familiarization.
D-85521 Ottobrunn • Appendix 2 "Explanations of the
(civilian and defense versions) Products". Detailed explanations
To facilitate use in projects, the V- to the required content are given
Model is available not only as hard- for each product (software, doc-
copy but also on diskette and ument) defined in the V-Model.
magnetic tape.
• Appendix 3 "Specific Public
Authority Supplements". This
Participation of the appendix is different for the
Users in the Development defense domain and civilian
and Maintenance of the V- domain. Basically what is
Model presented here is how the V-
Model is to be applied in
conjunction with the valid
Both the industrial and the public superordinate regulations in the
authority users of the V-Model were respective domain (e. g. global
involved in the development and phase framework in the defense
maintenance process by the technology domain and "Special
convening of expert groups. Contractual Regulations for
Federal and State authorities
(BVB)" in the civilian domain).
Adaptation to the Project Needs: "Tailoring"

An outstanding feature of the V-


Model is its universal validity and its
company and project independence.
It is therefore independent in terms
of the area where it is used. To use it
for a specific project, individual
decisions have to be taken with
respect to which activities and
documents are necessary for the
project for factual reasons. In each
case, superfluous mountains of
paper, senseless documentation, but
also the lack of important documents
are to be avoided. This project-
specific adaptation is called
"Tailoring".
Tailoring is conducted in two stages:
• In the "contractual tailoring",
which is carried out before
conclusion of the contract and
start of the actual project, a
selection of the necessary
activities and products is to be
undertaken. In addition, special
"deletion"-conditions are
established under which certain
activities which were held to be
essential at the beginning can be
deleted under particular
circumstances in the course of
the project. The resulting subset
of the V-Model is laid down
together with further agreements
in the Project Manual. This
Project Manual is an important
part of the contract.
The contractual tailoring is also
important even if a project is not
externally awarded but is an in-
house development.
• The "technical tailoring", the
deletion conditions laid down in
the Project Manual are evaluated
and it is decided, which of the
activities contained in the Project
Manual are to be conducted. This
occurs continuously during the
project.
V-Model as Contractual
Basis
So that comparability of all offers
with respect to the kind of project
execution and documentation is
comprehensively guaranteed, the
project-specific adaptation of the V-
Model for external contractual
awards is undertaken before
tendering begins.

V-Model

Contractual Tailoring
at project initialization

Selection of required collection of all other


activities and products important regulations for the
project

Project Manual
Technical Tailoring
conducted during the project

Following of the project specific implementing conditions.


Decide what activities and products have to be carried out/produced

Project Plan

Steps in Tailoring
The Project Manual thus compiled
defines the scope of the project to be
realized by the contractor (and his
sub-contractors). The Project
Manual therefore becomes the
uniform action basis and guideline
for all participants in the project.
As particular project characteristics
for certain application areas are the
same in public authority and industry
use, easy applicable forms for
activities and product
recommendations are proposed as
standardized pre-tailoring for
frequent project types. Thus the
tailoring procedure can be
considerably simplified.

selection recommendations
or deletion conditions
Use of the V-Model in Projects

Organizational Embedment
The V-Model knows different roles
which are defined by the necessary
experience, knowledge and
capability for the project tasks.
The allocation of roles to activities in
the V-Model is described in a matrix
for each of the sub-models SWD,
QA, PM and CM, whereby several
roles can be allocated to one person.
These regulations make no
statement concerning the fulfillment
of the roles by organizational units or
persons. Thus the independence of
the V-Model from organizational and
project-specific boundary conditions
is achieved.
The allocation of roles to
organizational units/persons has to
be carried out individually at the start
of the project.

Support of the Users When


Using the V-Model
In order to support the users of the
V-Model and other software
standards, IABG has concluded a
cooperation agreement with
Deutsche-System-Technik GmbH
(DST) in Kiel/Bremen. As part of IT-
Application Support, both companies
support the V-Model users with
• training,
• introduction and
familiarization,
• company-specific adaptation,
• appraisal of development
documentation.
Offer of Training
A series of tried and experienced
training concepts exist for the
implementation of the V-Model with
the adequate degree of detail for the
user needs.

Tool Support for the Life


Process Model
The application of the V-Model can
be considerably facilitated by the use
of tools.
The functionality of such tools should
comprise at least
• tailoring,
• guidance through the project
activities and
• generation of documents.
For this purpose, the software
development tools are to be adapted
to the activities and documents of
the V-Model.

SWD Project Manager


Assistant Project Manager
System Analyst
System Designer
Project Assistant PM
DP Analyst
DP Designer QA Manager
SW Analyst QA Contact
SW Designer Quality Assessor QA
Programmer QA Assistant

Support Consultant
Applications Consultant CM Manager
Configuration Administrator
HW Consultant CM
Representative for Data
Technical Author
Protection and Security

Roles in the V-Model


Increasingly, tool manufacturers are Degree of Maturity of the V- firms, which are active in both the
integrating the activities and Model defense technology and commercial
products of the V-Model into their domains, used the V-Model for
tools as a result of the wide use of software projects. Against the back-
the V-Model in the defense area, Work on the V-Model has been ground of the trials and the repeated
Federal public administration and going on since 1986. From about the updating, taking the experience into
industry. beginning of 1990, pilot trials in consideration, what can be
projects were begun, before it was determined is that the V-Model can
made obligatory for the defense area be seen as sophisticated and
by the Federal Ministry of Defence in approved.
February 1991. At that time, many
Structuring the V-Model in Submodels

The V-Model is structured into


functional parts, so-called
submodels. They comprise the
software development (SWD),
quality assurance (QA),
configuration management (CM)
and the project management (PM).
These four submodels are closely
interconnected and mutually
influence one another by exchange
of products/results.
.

Software-
A2 P2 A5 P6 A7
Development
Quality
A3 P3
Assurance
Configuration
A4 P4
Management
Project-
A1 P1 A6 P5
Management
Example for the activity and product flow within the four
submodels
• PM plans, monitors and informs
the submodels SWD, QA, and
CM.
• SWD develops the system or
software.
• QA submits quality requirements
to the submodels SWD, CM and
PM, test cases and criteria and
assures the products and the
compliance of standards.
• CM administers the generated
products.

Interaction of the Submodels


The V-Model describes in detail the
interfaces between the submodels
SWD and QA, as software quality
can only be ensured by the
consequent application of quality
assurance measures and by
checking if they are complied with.

PM
plans

controls/
monitors

informs

QA
provides SWD
QA requirements develops
methods system/
documentation

assesses
Of particular relevance for real-time the V-Model this is considered a development and assessment can
software is the criticality, that is, the quality requirement and is precisely be adapted to the different levels of
classification of software with regulated. Mechanisms are criticality of the software.
respect to reliability and security. In proposed how the expenditure for

CM
administers
– configurations
– products
– access rights
– changes
Submodel "Software Development" (SWD)

The submodel SWD regulates Implementation (SWD 6) SW Integration (SWD 7)


which activities are to be carried out
during software development, and
• Conversion of the programming • Integration of modules to
when which products(documents, specifications to statements of components and of components
code) are to be prepared. the (chosen) programming to the SWCI.
language, informal assessment of
The submodel SWD comprises the developed code and
following main activities: implementation of a database (if
System Requirements Analysis existing).
and Design (SWD 1)
• Description of the requirements
of the system and its
environment. Conduction of a
threat and risk analysis, System

development of a security SWD 1


System
SWD 9

concept. Delivery of a user level System Requirements Requirements Analysis System


Integration
and Design
model of functions/data/ objects. System Design
System Integration

Structuring the system into Plan

subsystems, segments or
configuration items. DP Requirements SWD 2 SWD 8
Segment
Manual
DP Design
Information
DP Requirements Analysis and DP Integration Plan DP DP Integration
Requirements Analysis
Design (SWD 2) and Desgin

• Description of the requirements


of a DP segment and its
environment, development of a SW Requirements
SWD 3
SWCI
Program
Documents

security model, structuring the SW Requirements Integration (SWCI)

Analysis
segment into its SW and HW
configuration items (SWCI,
SWD 7 SWCI
HWCI).
SW Inte-
SW Requirements Analysis gration
Program Documents
SWD 4
(SWD 3) SW Architecture
Interface Design
(Component)


SWCI Integration Plan Preliminary Component
Description of the requirements Design
Integration

of a SWCI and its environment. Component

Preliminary Design (SWD 4)


• Structuring of the SWCI in SW
components/modules/database, Data-Dictionary SWD 5
Program Documents
SW Design
specification of the interfaces and Detailed
Design
(Module)

interaction of its elements.


Detailed Design (SWD 5)
• Description of the components Module
SWD 6
and modules with respect to the
real implementation of their Implementation Legend:
functions, the data administration Proof
activities
and error handling up to a (see QA)
SWD
programming specification. Activity

Activities and Products in the


Submodel SWD
DV Integration (SWD 8)
• Integration of the different SW
and HW configuration items to a
DP segment.
System Integration (SWD 9)
• Integration of the subsystems (if
existing) and segments to the
system.
Submodel "Quality Assurance" (QA)

The submodel QA regulates the Product Assessment (QA 4)


tasks and functions of the quality
assurance within the software • The product assessment takes
development process. place in two steps: assessment
In contrast to the informal with respect to the formal criteria
assessment of the submodel SWD and the contents of the product.
the procedures established in the The SW code is to be assessed
submodel QA ensure the fulfillment according to the Assessment
of the requirements which are Specification and Procedure.
specified in the documents System The result is recorded in an
Requirements, DP Requirements, Assessment report.
and SW Requirements of the Phase Review (QA 5)
submodel SWD.
The regulations however, do not • The purpose of the phase review
affect (as it is also the case for the is to decide, if the next SWD
other submodels) organizational main activity can be started.
stipulations.
The submodel comprises the
following main activities:
QA Initialization (QA 1) QA 1
QA Initialization

• The QA initialization defines the Setting up QA Plan


Setting up Assmt. Plan

organizational and procedural


framework in the QA Plan and QA Plan
the assessment plans.
Assessment Plan

Process Assessment of Activities


(QA 2) QA 3 QA 2
Assessment
Process Assmt.


Preparation
of
During the process assessment Def. of Assmt. Methods Activities
and Criteria
what is checked, is if prescribed
Def. of Assmt. Environment
procedures are complied with
during the performance of Def. of Assmt. Cases

specific activities. Generation of Assmt.


Procedure QA 5
Phase
Assessment Preparation (QA 3) Review

• The preparation of assessment


includes the set up of Assmt. Specification

Assessment Specification and


Assessment Procedure
Procedure and the completion of QA 6

the Assessment Plan by the Off-the-shelf-


Product Assmt.
Assessment Environment. The
QA 4
assessment criteria must be Product Assessment
defined so that an assessment of Determining Assessability
successful performance can Product
Assessing Contents of a
subsequently be evaluated. Product QA 7
QA Reporting

Assessment Report

Activities and Products in the Submodel QA


What has to be determined is if Off-the-shelf Product Assessment QA Reporting (QA 7)
all planned products are available (QA 6)
in the form required, if costs and • The Assessment Reports are to
schedules have been complied • This assessment shall indicate, if be evaluated in regular intervals
with and if the following activities the quality requirements are according to specified criteria and
are properly planned. fulfilled by a non-developmental the results submitted to PM.
product.
Submodel "Configuration Management" (CM)

The submodel CM ensures that all


products are uniquely identifiable,
that interrelations and deviations of
different versions or variants of a
configuration remain evident and
that any product changes can be
made only in a controlled manner.
The submodel CM comprises the
following main activities:
CM Initialization (CM 1)

• The CM initialization regulates


the organizational and procedural
framework within the CM Plan.
Furthermore, the resources
(product library, tools) are to be
provided.
Configuration Administration
(CM 2)

• The configuration administration


comprises the administration of
products, configurations and
rights. The administration of a
configuration is handled via the
Configuration Identification
Document (CID), which provides
an overview of the structure of
the configuration and the actual
state.
Change Management (CM 3)

• Error reports, problem reports,


proposals for improvement, etc.
are recorded and administered
and submitted as change
requests. The Change
Management monitors the
change procedure.
The implementation of a change
itself is carried out according to
the regulations of the V-Model.
Data Backup (CM 4) CM review ement,
Reportin s and releva
• Backups within the project are g (CM 5) for nt
due at fixed times and scope. inform reports
• For ation are to
prepari of the be
ng the project genera
phase manag ted.

Project Plan

Project Manual

CM 1
CM Initialization
Change Request

Creating CM-Plan
Setting up CM

CM 3
Change
Management

CM-Plan Change Evaluation

Decision about
Change Procedure and
Initialization of Change
Change according to
V-Model
Completion of Change

Product
CM 5

CM Reporting

CM 2
Configuration
Administration Product
Library

Product Initialization
Configuration
Initialization
Product Archivation CM 4
Configuration
Identification Document Data Backup
Configuration Update
Allocation of Access Rights
Data-Dictionary Data Administration

Activities and Products in the Submodel CM


limiting respec
Submodel "Project conditi t of
Management" (PM) ons
are to
project
organi
be zation,
determ cost,
ined baselin
The interface - as the es,
submode to project- interna basis milesto
l PM external l for the nes,
regulates units and cooper tailorin sched
the tasks project- ation g, that uling
and internal as well is, the and
functions roles, the as the project person
of the project interfa - nel
project represent ce to specifi planni
managem atives and custo c ng.
ent within the project mer adapta Furthe
the informatio and tion of r-more
software n center. subco the V- a
developm ntracto Model. presel
The
ent r are to The ection
submodel
process. be Project of a
PM
These fixed. Plan develo
comprises
regulation For the include pment
the
s do not project s enviro
following
affect the manua prelimi nment
main
organizati l nary has to
activities:
onal specifi planni take
structures Project c goals ng in place.
in any Initializati and
way and on (PM 1) Statement of
V-Model
Work
are
different • The
PM 1
from the initializ Project Initialization Contract

function of ation
the regulat
Project Plan Project Manual
system es the
managem organi QA Plan

ent. zation PM 2.1


Initialization of Main Activity
al and
The tasks proced
determine ural Project Plan
d in the frame
submodel work in PM 2.2
Report Docum. Work Order
PM a Monitoring Main Activity

comprise Projec
the t Plan Project History Report Docum.
planning, and in
control a Proj- PM 2.3
and ect Completing Main Activity
monitorin Manua
g of l. The Activities andProject
Products in the Submodel PM
Plan Report Docum.
project- modali
internal ties of Project History
activities, the
the project PM 3
Project Completion

Final Report
Project Monitoring (PM 2)

• Within the scope of project


monitoring, the project
management has to take account
of detailed planning, monitoring,
and control as well as information
service on the activity and
subactivity level. These means
form the framework around the
individual subactivities of a
project including the parts
· initialization
· monitoring
· completion.
Project Completion (PM 3)

• At the end of a project, a final


report has to be submitted which
includes a summary of the course
of the project, an explanation of
the results achieved, and a
comparison between actual
status and the intended plan.
The Advantages at a Glance

Advantages of the Process


Standardization The V-Model

 Improved communication among the  is complete


persons involved in the project all functional areas (Software Development,
 Uniform procedure in public authorities Quality Assurance, Configuration Management,
and commissioned industry and Project Management) are covered

 Guarantee of better product quality  provides concrete assistance


contains many instructions and
 Productivity increase by the reduction of recommendations; gives detailed explanations
familiarization and training times on special problems and on the individual
necessary task results
 More precise calculation of new
projects using standardized procedures  is sophisticated
participation of users from industry and public
 Less dependencies on persons and companies authorities in the generation and in the change
process of the V-Model

Reduction of Maintenance and  is balanced/not manufacturer-specific


Change Problems  good acceptance
no influence or dominance of industrial
lobbyists
 Decrease in maintenance cases
resulting from improved product  supports when tendering
quality the complete presentation of the development
documents and the tailoring procedure
 Decrease in the maintenance effort provides good support in the awarding of the
resulting in the existence of an contract process
adequate software documentation
and an easier understanding  public controlled updating
because of the uniform structure further development under the supervision of a
Change Control Board with industry and public
authority representatives

IABG  wide application spectrum


Industrieanlagen- as a result of the application in the whole
Betriebsgesellschaft mbH defense domain, the whole public
Einsteinstr. 20 administration area and by the industrial
D-85521 Ottobrunn IT-suppliers, a wide application area is
Telephone +49-89-6088-2369 or -2368 guaranteed
Telefax +49-89-6088-3355 or
-3418
Telex 5 24 001
Your Contact:
Version: February 1993
in Ottobrunn: Tel. +49-89-6088-3921
Release: 1995

You might also like