Wednesday, January 30, 2013

Sample SVVP


Sample SVVP


The various aspects of SVVP are described in the following paragraphs.

1.       Style.  The SVVP should be plain and concise. The document should be clear, consistent and modifiable. Authors should assume familiarity with the purpose of the software, and not repeat information that is explained in other documents.

2.       Responsibility.  The developer is normally responsible for the production of the SVVP. The user may take responsibility for producing the Acceptance Test Specification (SVVP/AT), especially when the software is to be embedded in a larger system. It is however recommended that user member should be part of team responsible for preparing SVVP.

3.       Medium. It is usually assumed that the SVVP is a paper document. The SVVP could be distributed electronically to participants with the necessary equipment.

4.       Service Information. The SR, AD, DD, UT, IT, ST and AT sections of the SVVP are produced at different times in a software project. Each section should be kept separately under configuration control and contain the following service information.

(a)       Abstract
(b)       Table of Contents
(c)        Document Status Sheet
(d)       Document Change records made since last issue

5.       Content of SVVP/SR, SVVP/AD & SVVP/DD sections. These sections define the review and tracing activities in the SR, AD and DD phases of the lifecycle. While the project management plan(PMP) may summarise these activities, the SVVP should provide the detailed information. For example the PMP may schedule an AD/R, but this section of the SVVP defines the activities for the whole AD phase review process. These sections of the SVVP should avoid repeating material from the standards and guidelines and instead define how the procedures will be applied.


(a)       Purpose
(b)       Reference Documents
(c)        Definitions
(d)       Verification overview


6.       Content of SVVP/SR, SVVP/AD & SVVP/DD sections. These sections define the review and tracing activities in the SR, AD and DD phases of the lifecycle. While the project management plan(PMP) may summarise these activities, the SVVP should provide the detailed information. For example the PMP may schedule an AD/R, but this section of the SVVP defines the activities for the whole AD phase review process. These sections of the SVVP should avoid repeating material from the standards and guidelines and instead define how the procedures will be applied.

(a)       Purpose
(b)       Reference Documents
(c)        Definitions
(d)       Verification overview
(i)         Organisation
(ii)        Master schedule
(iii)       Resources summary
(iv)       Responsibilities
(v)        Tools, techniques and methods
(e)       Verification Administrative Procedures
(i)         Anomaly reporting and resolution
(ii)        Task iteration policy
(iii)       Deviation policy
(iv)       Control procedures
(v)        Standards, practices and conventions
(f)        Verification Activities
(i)         Tracing
(ii)        Formal proofs
(iii)       Reviews
(g)       Software Verification Reporting.

7.       The description of the contents in detail is given at Enclosure 7. Additional material should be inserted in additional appendices. If there is no material for a section then the phrase 'Not Applicable' should be inserted and the section numbering preserved.

8.       Content of SVVP/UT, SVVP/IT, SVVP/ST & SVVP/AT sections. The SVVP contains four sections dedicated to each test development phase. These sections are called:

(a)       Unit Test Specification (SVVP/UT);
(b)       Integration Test Specification (SVVP/IT);
(c)        System Test Specification (SVVP/ST);
(d)       Acceptance Test Specification (SVVP/AT).

9.       This directive recommends the following table of contents for each test section of the SVVP. The description of the contents in detail is given at Enclosure 8.

(a)       Test Plan.
(i)         Introduction
(ii)        Test items
(iii)       Features to be tested
(iv)       Features not to be tested
(v)        Approach
(vi)       Item pass/fail criteria
(vii)      Suspension criteria and resumption requirements
(viii)     Test deliverables
(ix)       Testing tasks
(x)        Environmental needs
(xi)       Responsibilities
(xii)      Staffing and training needs
(xiii)     Schedule
(xiv)     Risks and contingencies
(xv)      Approvals.

(b)       Test Designs (for each test design...).

(i)         Test design identifier.
(ii)        Features to be tested.
(iii)       Approach refinements.
(iv)       Test case identification.
(v)        Feature pass/fail criteria.

(c)        Test Case Specifications (for each test case...).

(i)         Test case identifier
(ii)        Test items
(iii)       Input specifications
(iv)       Output specifications
(v)        Environmental needs
(vi)       Special procedural requirements
(vii)      Inter-case dependencies.

(d)       Test Procedures (for each test case...).

(i)         Test procedure identifier
(ii)        Purpose
(iii)       Special requirements
(iv)       Procedure steps.

(e)       Test Reports (for each execution of a test procedure ...).

(i)         Test report identifier
(ii)        Description
(iii)       Activity and event entries.

10.       Plan Evolution.

(a)       UR phase.

(i)         By the end of the UR review, the SR phase section of the SVVP must be produced. The SVVP/SR must define how to trace user requirements to software requirements so that each software requirement can be justified. It should describe how the SRD is to be evaluated by defining the review procedures. The SVVP/SR may include specifications of the tests to be done with prototypes.

(ii)        The initiator(s) of the user requirements should lay down the principles upon which the acceptance tests should be based. The developer must construct an acceptance test plan in the UR phase and document it in the SVVP (SVV11). This plan should define the scope, approach, resources and schedule of acceptance testing activities.

(b)       SR phase.

(i)         During the SR phase, the AD phase section of the SVVP must be produced (SVVP/AD). The SVVP/AD must define how to trace software requirements to components, so that each software component can be justified. It should describe how the ADD is to be evaluated by defining the review procedures. The SVVP/AD may include specifications of the tests to be done with prototypes.

(ii)        During the SR Phase, the developer analyses the user requirements and may insert 'acceptance testing requirements' in the SRD. These requirements constrain the design of the acceptance tests. This must be recognised in the statement of the purpose and scope of the acceptance tests.

(iii)       The planning of the system tests should proceed in parallel with the definition of the software requirements. The developer may identify 'verification requirements' for the software. These are additional constraints on the unit, integration and system testing activities. These requirements are also stated in the SRD.

(iv)       The developer must construct a system test plan in the SR phase and document it in the SVVP. This plan should define the scope, approach, resources and schedule of system testing activities.

(c)        AD phase.

(i)         During the AD phase, the DD phase section of the SVVP must be produced (SVVP/DD). The SVVP/AD must describe how the DDD and code are to be evaluated by defining the review and traceability procedures.

(ii)        The developer must construct an integration test plan in the AD phase and document it in the SVVP. This plan should describe the scope, approach, resources and schedule of intended integration tests. Note that the items to be integrated are the software components described in the ADD.

(d)       DD phase.

(i)         In the DD phase, the SVVP sections on testing are developed as the detailed design and implementation information become available.

(ii)        The developer must construct a unit test plan in the DD phase and document it in the SVVP. This plan should describe the scope, approach, resources and schedule of the intended unit tests.

(iii)       The test items are the software components described in the DDD. The unit, integration, system and acceptance test designs must be described in the SVVP. These should specify the details of the test approach for a software feature, or combination of software features, and identify the associated test cases and test procedures.

(iv)       The unit integration, system and acceptance test cases must be described in the SVVP. These should specify the inputs, predicted results and execution conditions for a test case.

(v)        The unit, integration, system and acceptance test procedures must be described in the SVVP. These should provide a step-by-step description of how to carry out each test case.

(vi)       The unit, integration, system and acceptance test reports must be contained in the SVVP.

11.       Planning of extensive and careful verification and validation is as important activity as planning for development of software application. Evolution, documentation and adoption of sound SVVP is very essential to ensure reliable and efficient end software product.


12.       It is very important to prepare a sound plan for software verification and validation well in time. The preparation of plan shall commence with the very first stage of software development cycle (URD phase). All software verification and validation activities must be documented in the Software Verification and Validation Plan (SVVP). The SVVP is recommended to be divided into seven sections that contain the verification plans for the SR, AD and DD phases and complete test specifications for the unit, integration, system and acceptance testing. Following figure  summarises when each software verification and validation sub-plan is generated and documented in the preparation of master SVVP.


13.       Each row of the figure  corresponds to a section of the SVVP and each column entry corresponds to a subsection. For example, the entry 'ST Plan' in the SVVP/ST row means that the System Test Plan is drawn up in the SR phase and placed in the SVVP section 'System Tests', subsection 'Test Plan'.

14.       Following figure shows the relationships between the sections and subsections of the SVVP. Sections are shown in boxes. Relationships between sections are shown by lines labeled with the verb in the relationship (e.g. 'contains'). The one-to-one relationships are shown by a plain line and one-to-many relationships are shown by the crow's feet.



No comments:

Post a Comment