PRINCIPLES OF SOFTWARE VALIDATION

This section contains the general principles that should be considered for validation of software.

1.      REQUIREMENTS

A documented software requirements specification provides a basis for both validation and verification. The software validation process cannot be completed without stable software requirements.

2.      DEFECT PREVENTION

Software quality assurance should focus on preventing the introduction of errors in the software development process and not try to "quality test" code software after it is written. Software testing is very limited in its ability to all the hidden defect surface defects software code.

3.     TIME AND EFFORT

A case that software is validated requires time and effort to develop. Preparing for software validation should start early, that is during the design and development planning and design input. The final conclusion is that the software must be validated spread based on aggregated from the planned effort throughout the software lifecycle evidence.

4.     SOFTWARE LIFE CYCLE

Software validation takes place within the environment of an established software lifecycle. The life cycle of software is including software engineering practices and documentation to support the software validation effort. In addition, the software life cycle contains specific verification and validation activities suitable for the intended use of the software.

5.     PLANS

The software validation process is defined and controlled with the aid of a plan. The software validation plan defines "what" is to be achieved through the software validation effort. Software validation plans specify areas such as scope, approach, resources, schedules and the nature and scope of activities, tasks and work items.

6.     PROCEDURES

The software validation process is performed by using methods. These procedures establish "how" to validate the software to perform the exercise. The procedures are specific action or series of actions that need to be taken to identify the complete individual validation activities, tasks and work items.

7.      SOFTWARE VALIDATION AFTER A CHANGE

Due to the complexity of the software, seemingly small local changes can significantly impact overall system. Even a small change in the software, will be returned to the status of software validation. When software is changed, a validation analysis has not been performed for verification of individual changes, but also to determine the magnitude and impact of these changes in the system software.

8.     VALIDATION COVERAGE

Validation coverage should be based on the complexity and risk of security software, not a fixed size or resources. Selection of validation activities, tasks and work items should be proportionate to the complexity of the design software and the risks associated with the use of software for specified intended use.

9.     INDEPENDENCE OF REVIEW

Validation activities must be carried out with the aid of the quality assurance fundamental precept of the "independence of the review." Confirmation itself is extremely difficult. If possible, an independent evaluation is always better, especially for higher risk applications. Some companies outsource to a third party independent verification and validation, but this solution is not always feasible.

10.  FLEXIBILITY AND RESPONSIBILITY

Specific application of these principles validation software can be very different from one application to another. The device manufacturer has flexibility in choosing how to apply these principles in verification, but retains ultimate responsibility for proving that the software has been verified.