V Model Guidelines

Your use of this document is subject to the Terms of Use governing Enterprise Business
Intelligence Roadmap. The information contained in this document is proprietary information of
Cognos Incorporated and/or its licensors and is protected under copyright and other applicable
laws. You may use the information and methodologies described in this document 'as is' or you
may modify them, however Cognos will not be responsible for any deficiencies or errors that
result from modifications which you make. Copyright 2005 (c) Cognos Incorporated. All Rights
Reserved.
V Model

The V-Model is a proven, industry standard framework that defines the standard development life
cycle. It requires that each major deliverable is verified and validated in an attempt to identify
problems as early as possible and ensure that specifications are complete, correct, and adhere to
relevant standards. Testing ensures that the specifications are properly and correctly
implemented and that the solution meets the business and performance requirements.

Validation. Doing the right thing:

o Checks that output deliverables satisfy the requirements specified in a previous
phase s input deliverables.
o Ensures that the work product is in scope, contributes to the intended benefits,
and does not have undesirable side effects.
o Is performed by inspecting, simulating, or prototyping.
Verification. Doing it the right way:
o Checks that a deliverable is correctly derived and internally consistent.
o Checks that output and the process conform to the standards.
o Is performed by inspecting and reviewing.
Testing. Right things working right:
o Checks that a specification is properly implemented.
o Is performed by executing the code.

The V-Model saves time and money in development while increasing the result quality and the
delivery reliability. Adhering to the V-Model leads the way to a substantially decreasing the
number of errors found in production after each release. Quality is designed into the system
rather than tested into the system.

Test Phases
A phase refers to major development process steps in a project s lifecycle: analyze phase, build
phase, design phase etc. It also refers to different phases of tests: component test phase,
assembly test phase, system test phase, etc.

2/14/2006 Page 2 of 4
This is the industry-standard V-model that the project follow

Operational
Operational
Readiness
Readiness
Test
Test

Test
Sponsor
Sponsor
Goals
Verify User
User
Goals and
and Acceptance
Acceptance
Expectations
Expectations Test
Test

Requirements
Requirements System
System Test
Test
Application
Integration
ApplicationIntegration
Business
Business Functional
FunctionalTechnical
Technical
Performance
Performance Test
Test
V
al
id Assembly
Assembly
at Design
Design Test
Test
e

Component
Component
Build
Build Test
Test

The V-Model diagram above shows how the test phases fall into the development phases. The
test planning tasks are performed on the left side of the V-Model within the plan, analyze, design,
and build phases. The test execution tasks appear on the right side and belong to the build
(component , assembly, system, and user acceptance tests), and deploy (operational readiness
test) phases. The early test execution tasks (component and assembly tests) focus on confirming
the design and programming/configuration, and later ones focus on achieving overall functional
and technical requirements.

Operational Readiness Test (ORT). Tests the production environment s readiness to

handle the new system. It is made up of three components:
o Operations test. Verifies that the correct functionality, architecture, and
procedures are defined and implemented to allow production support teams to
run, maintain, and support the system in production in accordance with common
practice or defined SLAs, where applicable.
o Deployment test. Verifies that all components of the system are collated and can
be correctly deployed to the production environment in the time required.
o Deployment verification test. This test verifies that the system is correctly
installed and configured in the production environment. The test planning is
performed as part of the Prepare for Migration task and the test execution is
performed in the deploy phase.
User Acceptance Test (UAT). Ensures that the users and stakeholders are satisfied with
the solution. Only after this test is complete can the product be released. It allows the
end users to complete one final review of the system prior to deployment. The test
planning is performed in the analyze phase during which the user requirements are
defined. The test execution is performed in the build phase.
Product test. Sometimes called system test, tests that all business requirements are met
by the system. It can be broken down into two separate tests for systems with multiple
applications (for example, enterprise integration)

2/14/2006 Page 3 of 4
 o Application product test. Tests the business requirements met by each individual
application.
o Integration product test. An end-to-end test of the business requirements across
all applications and platforms. Upon successful completion of the application
product test, integration product test can occur. The test planning is performed
in the analyze phase during which all requirements are defined. The test
execution is performed in the build phase.
Performance test. Ensures that the system is capable of operating at the load levels
specified by the performance requirements and any agreed upon Service Level
Agreements (SLAs). The test planning is performed in the analyze phase during which
the performance requirements are defined. The test execution is performed in the build
phase.
Assembly test. Tests the interactions of related application components to ensure their
proper function when integrated. The test planning is performed in the design phase
during which the application designs are created. The test execution is performed in the
build phase.
Component test. Tests each individual component of the application. The test planning
is performed in the build phase when components are created by programming or
configuration .The test execution is performed in the later part of the build phase after
the application components are ready for use.

For each of the above testing phases, a test planning task (e.g., Plan Assembly Test, Plan System
Test etc.) creates a repeatable Test Plan deliverable. This repeatable Test Plan can be executed
by resources with little or no experience with the application under test. From a
product/regression test standpoint, such a repeatable Test Plan is essential. It allows the
engagement to allocate its usually scarce functional experts to other development tasks without
sacrificing the quality of the product/regression test.

Entry/Exit Criteria
Entry and exit criteria are sets of conditions that must be satisfied before entering or exiting a
project phase. The criteria state what is required (for example, from previous phases) to support
a phase (entry criteria) and what is required of a phase to determine completeness (exit criteria).
Entry and exit criteria are defined for each phase to assure quality deliverables from one phase to
the next.
The entry criteria for one phase usually ensure that the exit criteria from the previous phase are
completed. Some exit criteria may satisfy the entry criteria of a phase other than the next one in
line. They also include any additional set-up criteria. For instance, product test execution entry
criteria may include the requirement that all assembly test exit criteria be met. An additional
entry criterion to product test may be that the product test environment is established and all
product test preparation exit criteria be met.
The V-Model specifies that activities in one phase must be completed before moving on to the
next phase. It is critical that the exit criteria defined for the preceding phase have been met;
however, in cases where this is not possible, it is essential that this shortfall be correctly
documented and understood by the recipient phase, and that necessary action plans be devised
to resolve the identified issues.

2/14/2006 Page 4 of 4