I had a discussion a while back with a couple of coworkers on the subject of what exactly constitutes independent verification, validation, and accreditation. Afterward I checked with some reference materials (namely [LEW92]) and discovered where I'd gone wrong. I jotted down these notes to help me get it right in future discussions.
In the context of computer software, the terms verification, validation, and accreditation have specific meanings. There are numerous books and other publications on the subject that can elaborate on these terms, but in very simple terms,
Verification is an activity that determines whether the product of each phase of the software development cycle meets the requirements made upon it in each preceding phase, as in the questions "Does the software design satisfy all elements of the requirements?" or "Does the implementation accurately reflect the design?"
Validation is an activity that answers the question, "Is the software suitable for its intended purpose?" Provided the verification activity has been properly performed, that question translates roughly to "Does the software meet its requirements when it's run?"
Accreditation is a milestone: when it is reached, the accrediting agency issues a statement that the software product is appropriate for a specified purpose within a well-defined set of circumstances. Accreditation must be done by a respected authority in the field if the software's user community is to have confidence in the software.
It is important that these activities are kept independent of the development activity and that they are conducted rigorously. This is, among other reasons, to ensure that the customer's confidence in the software can remain high.
Well, maybe they're not all myths; perhaps just points of confusion.
IV&V and VV&A are different activities because they have different abbreviations.
Nope. Both abbreviations refer to the same fundamental activities, verification and validation. Both verification and validation are best done by independent organizations, and usually these activities are followed (when successful) by accreditation. Using one abbreviation or the other normally doesn't imply that a step or an assumption has been skipped.
Running the software is verification.
Running the software and comparing its results with expectations is a key component of validation, not verification.
QA is a limited form of V&V.
Some of the goals of QA are the same as some of the goals of V&V, but they are not the same. They are complementary activities with some fundamental differences. For example:
QA is an internal process, the responsibility of the developer, and the personnel involved in that activity are part of the development organization, whereas V&V is performed by an independent organization that answers to the customer.
QA applies to the entire software project and all work products generated therein, including things that are not of interest to V&V, such as defect reports, project metrics, user documentation, and so on.
A software development organization is performing verification and/or validation when it tests its software.
Again, developer testing shares some common goals with the verification and validation activities, but it is an internal activity that lacks the crucial independence of true V&V, and it's often focused on additional attributes of the software that lie outside the scope of verification.
V&V is part of the "waterfall model" of the software development life cycle.
V&V is conducted independent of, and preferably in parallel with, the development effort. As [LEW92] says, V&V is "an added-value concept."
Compliance testing is the same as validation.
Maybe, maybe not. If a compliance test suite is comprehensive enough, it may serve to validate the software. If it isn't, then it alone doesn't meet the rigorous demands of the validation activity.
[LEW92] Lewis, Robert O. Independent Verification and Validation: A Life Cycle Engineering Process for Quality Software. New York: John Wiley & Sons, Inc., 1992.
Chuck Taylor -- (Copyright) -- (Contact)