Friday, May 22, 2009

Verifcation and Validation

Verification and Validation

Being technically (or technologically) inclined, I have always had a quest for certain definitions which have hitherto remained confounding to me. Being forced into a way of thinking, (if not, a way of life) by birth, it impossible for me not adopt an attitude of generalization (we may call it spiritual) while contemplating on a particular issue.

The two words that troubled me in my professional career as an engineer were the words, “verification” and “validation”. Many sources and many definitions (including a NASA version) not being satisfactory, I contemplated on these two words seeking a more general definition which I wish to share in this blog.

But before going to the definition itself, I thought I might recount the extant definitions doing the rounds in the industry -

Verification – (The act of) Building the product right.
Validation – (The act of) Building the right product.
Verification is a quality process that is used to evaluate whether or not a product, service, or system complies with regulations, specifications, or conditions imposed at the start of a development phase. Verification can be in development, scale-up, or production. This is often an internal process. (from the wikipedia as on 23 May 2009)
Validation is the process of establishing evidence that provides a high degree of assurance that a product, service, or system accomplishes its intended requirements. This often involves acceptance of fitness for purpose with end users and other product stakeholders. (from the wikipedia as on 23 May 2009)
Software Verification and Validation (V&V) is the process ofensuring that software being developed or changed willsatisfy functional and other requirements (validation) andeach step in the process of building the software yields theright products (verification). The differences betweenverification and validation are unimportant except to thetheorist; practitioners use the term V&V to refer to all ofthe activities that are aimed at making sure the softwarewill function as required.
After reading these definitions, I would almost always come out feeling satisfied, but the moment these definitions were not in front of me I couldn’t remember which was which! Being a theorist, (refer to the NASA definition), the difference was important to me.
My definition is as under –
Verification – A test (of hypothesis) against Ideality.
Validation – A test (of hypothesis) against (perceived) Reality.
The moot point to the theorist, then, is the definition of the words “Ideality” and “Reality”, as obviously these words help us differentiate between verification and validation.
Ideality - A notion (product of human mind or minds) that is declared to be acceptable by a consensus through a process of debate.
Reality – That which is.
Given these definitions, the need to inset the word “perceived” within brackets is stated next. This is so because a definition should applicable to the non-theorist also for whom according to the NASA definition “the difference does not matter”. When you talk of “perceived reality” (that is, when you read the definition by removing the brackets) you are in a sense talking of hypothesis testing of “a notion against a notion”, both in case of verification and in case of validation. Ideality is already a notion by definition and perceived reality is a notion unless we accept that perception is reality! Thus to the non-theorist, this difference vanishes or as NASA says this difference(s) are unimportant.
To the theorist, the word “perceived” needs to be dropped and then there is a very clear difference between verification and validation and allows this difference to be used across domains, not merely software, but as diverse as accounting, finance, law, sociology and even philosophy, as means to discriminate between Truth and Untruth.
After all, that is what a quest for “definition” is about anyway, isn’t it?

No comments:

Post a Comment