The differences between D&D Review, D&D Verification and D&D Validation?

I

issmart

I want to know the among both of them in term of time, target to be checked, timing and typical method to be used in checking. In term of ISO9001 7.4,7.5 and 7.6, there is no clear explanation on these three terms. Can anyone answer me?
 
C

chergh - 2008

Review is essentially looking at the results of a "milestone", "gate" or whatever your company calls these. It is looking at progress, evaluating results, ensuring things are going as planned. You would also look at problems, look at the need for corrective action etc. It is essentially as the title suggests a project review.

Verification is confirming that your product meets the specified requirements. If you specify that your widget should be 2x2 cm you would do a verification test to ensure this.

Validation is confirming that your product meets the requirements for its intended use. If your widget is to be used to plug a 3x3 cm hole it would be unsuitable for that use.

Not sure how clear I have been but hope it helps.
 
I

isonagaraj

Re: What is the difference between D&D Review, D&D Verification and D&D Validation?

I am not agree with the explanation for "Design verification".


Design verification is not product verification. It is for verifying your Design input Vs Design output.

example : If widget should assembled on 23x32 cm. You have to verify your Design output ( Drawing /Report) whether dimension is made correctly or not.

Product verification - Iso 9000 clause - 8.2.4 & 7.4.3

Design Verfication - ISO 9000 clause - 7.3.4
 
F

fuzzy

Re: What is the difference between D&D Review, D&D Verification and D&D Validation?

Review is essentially looking at the results of a "milestone", "gate" or whatever your company calls these. It is looking at progress, evaluating results, ensuring things are going as planned. You would also look at problems, look at the need for corrective action etc. It is essentially as the title suggests a project review.

Verification is confirming that your product meets the specified requirements. If you specify that your widget should be 2x2 cm you would do a verification test to ensure this.

Validation is confirming that your product meets the requirements for its intended use. If your widget is to be used to plug a 3x3 cm hole it would be unsuitable for that use.

Not sure how clear I have been but hope it helps.

I would also differ with you Chergh, :mg: on your definition for design review. While there is language on "appropriate stages" the primary focus is on the suitability of the design in meeting design requirements not on the project. Design review is intended to be a cross-functional look at the completeness of the design in meeting the intent of the product or service contracted. While this may be covered within a typical Stage-gate review, I would not consider them the same. ISO does not require a "project review"...it says design review for a reason.:yes: :2cents:
 
P

potdar

Re: What is the difference between D&D Review, D&D Verification and D&D Validation?

I will try to explain these terms in the physical sense (and move to a bit complex physical product than widgets).

A design is done to obtain preset design outputs.

A review is a cross-check on the paper to ensure that all design outputs envisaged have been delivered. This is done before a protoype is built to try and ensure lowest probabilities of prototype failure.

Verification is simulated prototype testing in laboratory conditions. Say a new automobile is designed. Before it is allowed on the roads, it is put on the test tracks within the manufacturer's facilities and put through all sorts of rigorous testing conditions that it is likely to be subjected to in its working life (the defined design output).

Having passed the verification stage, the prototype is then put through the validation stage. Now it gets permission from the authorities to come out on the roads and you see shrouded vehicles moving around on the roads. They will be put through peak hour traffic in the metros, cramped parking areas, expressways, dirt tracks, deserts, marshlands, mountainous roads at high altitudes.... the real life operations test. In other words, design validation.

What is described above stands for mass production products. For one off designs prototype testing is not feasible. Here the verification and validation stages are considered accetable if done by using virtual simulations on computers / comparison with established results of peer products etc. They can even be combined into one.
 
Last edited by a moderator:

Colin

Quite Involved in Discussions
Re: What is the difference between D&D Review, D&D Verification and D&D Validation?

Potdar, I am with you on the design review stage, I would just add that it is normal to have people from various parts of the organisation involved e.g. purchasing, so they can comment on things such as 'lead times' and costs of materials. The aim being to prevent potential problems.

I am also with you on verification, usually involving tests on prototypes, alternative calculations etc.

I would look at validation differently though. I believe that validation can only be done on the 'finished product. e.g. if the automobile was verified on prototypes, we can only do the validation on the product that actually comes off the line. Or, if it is software we have designed, validation can only be done when it is installed on the user's own system. Additionally, if you then sell that software to someone else, you would have to re-validate it on their system.

I also agree that sometimes verification and validation may have to be done at the same time.
 
P

potdar

Re: What is the difference between D&D Review, D&D Verification and D&D Validation?

I would look at validation differently though. I believe that validation can only be done on the 'finished product. e.g. if the automobile was verified on prototypes, we can only do the validation on the product that actually comes off the line. Or, if it is software we have designed, validation can only be done when it is installed on the user's own system. Additionally, if you then sell that software to someone else, you would have to re-validate it on their system.

We are saying the same thing in different words. Validation is always done on a design 'as you intend to sell it'. The word 'prototype' is used only to distinguish between design verification and product verification. Product verification is understood to mean different things by different people.

Coming back, no authorities will ever permit sale of a product whose design is not verified (ref our original auto example). So, no point in going in for 'mass production' of the finished product 'as we intend to sell it' before the validation process is completed. Only the numbers necessary for the test are manufactured. These are the prototypes.

Your example of a software system is halfway between a mass production system and a one off product as discussed in my earlier post. Here it is feasible to test it in real life working condition before commissioning, but by installing on the client's system platform itself. So, the testing is done. Once again, no client is going to permit comissioning of this system till the validation trials are declared successful. Till such time, he will continue a parallel run of his existing system.
 
Top Bottom