Version: |
CS 4500, University of Utah
|
The Verification and Validation Plan (V&V Plan or VVP) sections given in this outline are guidelines to the contents of your V&V Plan. Include at least these sections. Your team may have good reasons for wanting to deviate from this proposed outline. In this case, you must motivate any deviations to the instructor. If a section is not applicable in your case, do not delete it; instead, give the topic heading and write "Not applicable."
This outline contains links to the appropriate sections.
The following outline is a reasonable organization for the Verification and Validation Plan.
Full description of the main objectives of the V&V Plan.
This summarizes the project and product in order to resituate the reader in your project's goals and objectives.
Provide only the ones that are going to be helpful in understanding this document. Do not simply repeat terms that were useful in earlier projects documents; ensure that each team you use will be useful in the context of the VVP. Be sure to alphabetize!
At a minimum, the reference list for the VVP should include your team's SRS and SDS documents. If this is an enhancement project, it is likely you need to list the previous team's VVP document. Use proper and complete reference notation. Give links to documents as appropriate.
A short description of how the rest of the V&V Plan is organized and what can be found in the rest of the document. This is not simply a table of contents. Motivate and briefly describe the various parts.
This section updates the planning for reviews, walkthroughs, inspections, and audits that was started in the team's project plan. The section should address both the procedures that the team has followed and the schedule of reviews, walkthroughs, inspections, and audits. The project has general guidelines about reviews and audits that will help as you update this section.
This section describes the test planning for individual software components. Note that this section and the next will describe expected behaviors. When testing is done, any time the actual output of a test case does not match the expected output, the team will create an incident report within the defect tracker.
This section describes the testing for the software product as a whole.
In this section, the team will discuss their procedures for defect tracking. This includes a brief discussion of the tool, the team's procedures for reviewing defect reports on a regular basis, and the team's process for assigning responsibility for a defect to specific individuals. This section should also discuss the severity codes that will be assigned.
This section is used to show (and discover) the specific connections between the SRS and the SDS. It is here that the unique identification for requirements and design sections becomes very important. See the VVP-info document for a detailed discussion of the traceability presentation.
The test-requirements cross-reference matrix shows how every requirement listed in the SRS will be tested. See the VVP-info document for a more detailed discussion of the test requirements cross-reference matrix.
Acceptance test can be planned very early, since the test cases should be based on the description of the product in the SRS document. This section describes the general procedure.
This section will list the exact criteria that will be used to determine acceptance of the product by, or on behalf of, the client. To the fullest extent possible, these criteria should be described in such a way that they can be objectively verified.
The process for installing the product will be described in this section. The installation may be a transfer process, it may involve creating a disk or CD for the client, or it may simply be a matter of providing the client with the URL.
This section can be used to describe additional V&V activities a team plans, such as review procedures.