|
This thread is carried over and continued in the Current Elsmar Cove Forums 
|
|
|
This thread is carried over and continued in the Current Elsmar Cove Forums
|
The New Elsmar Cove Forums
|
 The New Elsmar Cove Forums
 ISO 9001/4:2000
 7.3 Design and Development
|
 UBBFriend: Email This Page to Someone! |
next newest topic | next oldest topic |
| Author | Topic: 7.3 Design and Development |
|
Andy Bassett Forum Contributor Posts: 274 |
posted 20 September 2000 09:09 AM
   
I actually value most of the changes in the new ISO 9000:2000, i think it makes it a much more user friendly beast. However Design and or Development still has me confused. Can you help me out, can we take an unusual example ie the design of a NASCAR Racecar, and specify what each section could be. This is my understanding; 7.3.1 Design and/or development planning 7.3.2 Design and/or development inputs. 7.3.3 Design and/or developement outputs. 7.3.4 Design and/or development review 7.3.5 Design and/or developement verification. 7.3.6 Design and/or development validation 7.3.7 Control of Design and/or development changes. Any help greatfully accepted. ------------------ [This message has been edited by Andy Bassett (edited 20 September 2000).] IP: Logged |
|
Sherri O Lurker (<10 Posts) Posts: 6 |
posted 20 September 2000 10:57 AM
Andy, this may help. My company build racks that hold car parts (just for brief background). Here is how we respond to those items: 7.3.2 Inputs: Input is infomration received in order to begin. This can be written/verbal instructions from an engineer, parts, math data, etc. 7.3.3 Outputs: Ours are in the form of prints, disk, prototype racks, etc. 7.3.4 Review: FMC requires us to document reviews. We have concept(preliminary ideas/sketches), protoype(design only and sometimes includes an actual proto rack) and final design. The reviews are with the designer and the engineer and may include, estimating, production, and QC. 7.3.5 Verification: From our business we can verify a design by building a prototype for approval. 7.3.6 Validation: Our company cannot do validation for our products in house. Besides 95% of our customers who have us do design do the validation testing(which by the way for a rack usually means SHAKE / IMPACT tests)for us and copy us on the results(sometimes). 7.3.7 Changes: You're rights, you need to develop a way to track changes and how you relay these changes to the operations involved. We use a Design Revision Form with a distribution list on the bottom. I hope this helps, I'm new to this site and don't want to make a fool of myself. IP: Logged |
|
isodog Forum Contributor Posts: 51 |
posted 20 September 2000 10:31 PM
hope this helps. Verification checks whether the design meets the original specifications (design input). Validation checks whether the new product works (does what it's supposed to). Both are important, but different ways of looking at a new product. Dave ------------------ IP: Logged |
|
Andy Basse unregistered |
posted 21 September 2000 02:05 AM
Thanks for the help so far, sometines i need real examples to fully understand how the standard can be interpreted in real-life, your example was a very good one. Sherri O dont worry if you make a fool of yourself, you are in good company. BTW How do you verify the prototype if you arent actually testing it? Do you say 'Yes this looks lie what the engineer wanted'. Who and how do you sing it off? Does somebody approve the BoM. Regards IP: Logged |
|
Fordisoman unregistered |
posted 21 September 2000 08:06 AM
Andy, Verification can begin before the prototype is built and tested. Verification should begin in the design stage using analyses, alternate calculations, simulation, modelling, whatever tools are available to the engineer. IP: Logged |
|
Sherri O Lurker (<10 Posts) Posts: 6 |
posted 21 September 2000 08:35 AM
To verify our prototype against the design, we do dimensional checks and also part checks. We can load the prototype with parts to make sure they fit properly. The customer's engineer will usually come to ur plant and sign off on the protoype/design if approved and/or make changes to restart the process. Yes i agree verification can begin before a prototype, but for most of our builds, racks are similar in design/function. We use past builds, TGR/TGW etc. IP: Logged |
|
Rick Goodson Forum Wizard Posts: 102 |
posted 21 September 2000 11:55 AM
Andy, Re Verification and Validation The input to your example would be the NASCR regs, but also would include and the owner/engineer/driver input. One of those inputs might have to do with the speed the vehicle needs to be capable of. That speed requirement is translated into an engine design in terms of displacement, horse power, torque, etc. When the engine is designed and built we 'verify' that it is the displacement specified, does supply the specified torque, produces x amount of horsepower. This is design verification. We then take it to the track to determine if it can meet the speed requirement, which is the 'end user' requirement. Does it perform. This is design validation. Now, in theory, we should do the validation under use conditions, which would imply running it in a race. In fact, the validation probably is performed in a more 'sterile' condition with just that vehicle on the track. Hope that helps. IP: Logged |
|
Andy Bassett Forum Contributor Posts: 274 |
posted 22 September 2000 02:37 AM
Thanks everyone, im just mulling over the responses to decide how best to translate them into a present problem. I now have a better understanding of how different companies are interpreting design verification and design validation. My only problem at the moment is exactly how to insert the design verification into the sample NASCAR environment REALISTICALLY, ie without burdening somebody with the need to sign something that he doesnt really understand why he is doing it. This type of environment is in someways an ISO nightmare, as development is not done in nice clean packets that can be completed and then signed off, rather development is a permanent activity taking place in the office, at the track and during the night. Regards ------------------ IP: Logged |
|
Alan Cotterell Forum Contributor Posts: 120 |
posted 23 September 2000 05:38 PM
I think you are looking at ISO9000 to guide you in how you manage the design and development activity. Probably what you should look at is your 'project management' and 'configuration management' of the product. The NASCAR rules could be seen as 'constraints' in a project management sense and 'inputs' in an ISO9000 sense. Design verification is in my opinion essentially a paper based activity, validation is performance testing. Controlling the 'data pack' involves verification and is known as 'configuration management'. It involves use of an 'engineering change control system'. I think ISO9000 circumscribes a team activity in this application, and I suggest you follow the old axiom 'say what you do, do what you say, be able to prove it' , rather than trying to design using ISO9000 as a guide. The following Australian Standards might be useful - AS3905.12 Guide to ISO9001 for architectural and engineering design practices. AS3905.16 Project Management. AS3907 Configuration Management. All available from http://www.standards.com.au IP: Logged |
|
Marc Smith Cheech Wizard Posts: 4119 |
posted 23 September 2000 05:53 PM
> ...7.3.1 Design and/or development planning OK so we need a procedure > for how design is going to be done. A general flow. will do. Include review points. > 7.3.2 Design and/or development inputs. Could the NASCAR regulations Yes. > 7.3.3 Design and/or developement outputs. Could this simply be the Yes. > 7.3.4 Design and/or development review Could this simply be the weekly Yes - you can - make sure you document the meetings and be ready to explain what you reviewed. > 7.3.5 Design and/or developement verification. What could this be? Can Verification is review of the 'paper proposal(s)'. Your early stage computations. > 7.3.6 Design and/or development validation What could this be? In this Yes. Run on track. 'Prove' design output. > 7.3.7 Control of Design and/or development changes. This should be Yes - an engineering change system. IP: Logged |
|
Andy Bassett Forum Contributor Posts: 274 |
posted 27 September 2000 05:47 AM
quote: OK, maybe slowly but surely i am getting a little closer. What would be a review of the 'Paper proposal', the drawings have already been signed off in 7.3.3 Design/Development Outputs. What would you suggest could or should physically happen here. Regards ------------------ [This message has been edited by Marc Smith (edited 27 September 2000).] IP: Logged |
|
Marc Smith Cheech Wizard Posts: 4119 |
posted 27 September 2000 06:23 AM
> What would be a review of the 'Paper proposal', the drawings have > already been signed off in 7.3.3 Design/Development Outputs. The > complete design cannot be signed off until 7.3.6 Design Validation. The review for the sign-off of the 7.3.3 outputs is your verification. Take a read through https://elsmar.com/pdf_files/APQP_Q.pdf - look at page 8. Also check the matrix on page 10. See if this helps. Sherry O states: 7.3.5 Verification: From our business we can verify a design by building a prototype for approval. A prototype is not necessary for verification. FordISOMan states: Verification can begin before the prototype is built and tested. Verification should begin in the design stage using analyses, alternate calculations, simulation, modelling, whatever tools are available to the engineer. Yup - this is it. Andy sez: My only problem at the moment is exactly how to insert the design verification into the sample NASCAR environment REALISTICALLY, ie without burdening somebody with the need to sign something that he doesnt really understand why he is doing it. Not a problem. You match inputs against outputs and the responsible engineer signs off that requiremetns are met. INPUT: Must be able to accellerate from 0 to 130 mph within 8.46 seconds. Car must weigh less than ZZZZ kg. Engine can be no larger than ZZZZ cc. OUTPUT: XXXX cc engine, X:Y compression ratio, rear axle ratio of x:y, car weight of XXXX kg, XXXX transmission, XXXXX fuel will (theoretically) meet the INPUT REQUIREMENTS. [This message has been edited by Marc Smith (edited 27 September 2000).] IP: Logged |
|
Alan Cotterell Forum Contributor Posts: 120 |
posted 28 September 2000 12:40 PM
I suggest there is a need for a 'Project Management Procedure' in your quality manual. In business some activities are project based and need a Gantt chart, scope statements etc, some are based in continuous production and need prototyping and SPC. You might be interested in ISO's activities in relation to managing project risks (including quality) See: http://www.riskreports.com/protected/archive/rmr0900.html (Also Australian Standard AS3905.16 - Project Management - quality system guidelines) IP: Logged |
|
Alan Cotterell Forum Contributor Posts: 120 |
posted 28 September 2000 12:55 PM
I suggest there is a need for a 'Project Management Procedure' in your quality manual. In business some activities are project based and need a Gantt chart, scope statements etc, some are based in continuous production and need prototyping and SPC. You might be interested in ISO's activities in relation to managing project risks (including quality) See: http://www.riskreports.com/protected/archive/rmr0900.html (Also Australian Standard AS3905.16 - Project Management - quality system guidelines) IP: Logged |
|
Andy Bassett Forum Contributor Posts: 274 |
posted 29 September 2000 02:52 AM
Funny enough we had a 'Consulting Day' with our future certification body yesterday, and one point i wanted to clear was what they wish to see as evidence of Design Verification and Evidence of Design Validation. Interestingly confusion seems to reign from all sides. Our final agreement was, using our NASCAR example, a Track Test Report is evidence of Design Verification, and a signed off Parts List is evidence of Design Validation. All a bit weak if you ask me, i can imagine a lot of disinterested signing going on (Especially 3 days before the audit), but i suppose the problem is not helped by the complexity of this environment. PS Alan - For the second time in 12 months i took a little time to try to understand the concept of Risk Management by reading the link you provided. I am afraid you will have to write me off as uneducatable, i dont understand what it is and what it can do. If you have anyhwere a practical, real life example of what it is and how it works, ill have another go. Regards ------------------ [This message has been edited by Andy Bassett (edited 29 September 2000).] IP: Logged |
|
FordISO Man unregistered |
posted 29 September 2000 09:25 AM
Alan, Based on what you just reported I don't believe your certification body understands verification or validation very well. They are way off on validation which should be a demonstration in the customer's environment that the product meets the customer's needs. And has been discussed above, verification should begin during the "paper design stage". IP: Logged |
|
FordISO Man unregistered |
posted 29 September 2000 09:31 AM
Sorry Alan, my last post should have been addressed to Andy and apparently I can't edit it now. IP: Logged |
|
Marc Smith Cheech Wizard Posts: 4119 |
posted 29 September 2000 01:15 PM
quote: If you register you can edit your posts. IP: Logged |
|
Marc Smith Cheech Wizard Posts: 4119 |
posted 29 September 2000 01:42 PM
quote:I didn't read the document, but that validation takes place at the customers facility is not always true. It depends upon who your customer is and what the product is. In some cases there are multiple validations. Many companies do validation studies in-house. T&E suppliers typoically validate in-house and at a customer's facility in 'run-offs'. Tire manufacturers validate in-house on mechanical testers and on test tracks. Some consider accellerated life testing as their validation. But - in all cases, real or simulated, validation is supposed to 'prove' the design under predicted or actual use conditions. [This message has been edited by Marc Smith (edited 29 September 2000).] IP: Logged |
|
Alan Cotterell Forum Contributor Posts: 120 |
posted 02 October 2000 11:50 AM
I hope you don't mind me answering Andy here. The following is the submission I made to the New South Wales Standing Committee on Law and Justice (Inquiry Into Workplace Safety). It give an idea what Operational Risk is about. ---------------------- Editor's note: Allan, this was pretty long. Please provide a link to it on your site. Thanks! [This message has been edited by Marc Smith (edited 02 October 2000).] IP: Logged |
|
Andy Bassett Forum Contributor Posts: 274 |
posted 05 October 2000 03:06 AM
quote: Im not sure about the 'in the customers environment', but i suppose i could argue that signing off of a Parts List by a 'qualified Engineer' is evidence of design validation. Ford ISO man - Im open to other suggestions of what could physically constitute Design Validation in this fictitional NASCAR environment. Regards ------------------ IP: Logged |
|
Alan Cotterell Forum Contributor Posts: 120 |
posted 06 October 2000 07:20 AM
I think a file containing test results and a final report on the product performance would be more suitable evidence of design validation . The report should probably compare the test results with the design input data (customer requirements). Checking of calculations and drawings by qualified engineers is, in my opinion 'design verification'. Validation involves performance testing. IP: Logged |
|
FordISOMan unregistered |
posted 10 October 2000 10:33 AM
Andy, To help clarify the difference between verification and validation, let's review the ISO spec. Verification-ensuring that the design stage output meets the design stage input. Validation- ensuring that the PRODUCT meets the defined USER's Needs. Therefore,, according to ISO, validation can't be reviewing the 'signed off parts list' which is only a "paper" review not a PRODUCT review. Validation requires performance testing the Product just as Alan states in the previous post. The key difference in validation testing is that the test is based on the manner in which the Customer will actually USE THE PRODUCT in service, not just on the stated requirements. (Verification testing which should already been accomplished proved that the PRODUCT met the STATED REQUIREMENTS.) So validation is an Operational Performance test of the Product in the way the customer will really employ it. Validation is necessary because it is extremely difficult to state all the requirements in sufficient detail to guarantee that the Product will be successful. For your NASCAR example,validation would be performed at a race track and the measures would be such things as: acceleration, top speed, lap time, braking, handling characteristics, durability, gas mileage in race conditions, and driver ergonomics. Hope this helps. IP: Logged |
|
Andy Bassett Forum Contributor Posts: 274 |
posted 11 October 2000 07:53 AM
Hello Ford ISO Man I think maybe i am confusing the issue with this obtuse (but real-life) example. When designing a race vehicle it is fairly unusal to set design parameters, you are always aiming for maximum, it is very difficult to produce a set-of figures and say ' yes 200mph, thats what we are looking for', the best i can hope for is for the relevant Test Engineer to say something like 'thats the best we can do with this car in this condition on this test day-I will now sign the stźcklist and release the car'. Regards ------------------ IP: Logged |
|
John C Forum Contributor Posts: 134 |
posted 19 October 2000 12:54 PM
Andy, Verification comes from the Latin word for truth and validation from the word meaning strength. So, it's easy. Each time you verify that the design is true to some earlier intention, then it's verification and each time you test to see if it performs like you expected, it's validation. Now these things are not just two stages, they happen, as you say yourself, continuously, as the design is developed and the performance is tested by day and by night through the prototype stages and then before and after, and even during every race. So it's very difficult to say where one or other starts or finishes. Somewhere above, someone pointed out that you should not let standard requirements dictate your design program, but approach it the other way around. You know about the design process, could patch one together, no problem, from experience, popluate the place with designers and the resources they need. I'd say that, when planning such a process, it would have to be a general description of what is going to happen; concept, bringing the general features together, checking them out theoretically, building and testing something and then continuing development from there. Then, probably record it as you go along, leaving a useful record. More than this they can't expect. [This message has been edited by John C (edited 19 October 2000).] IP: Logged |
All times are Eastern Standard Time (USA) | next newest topic | next oldest topic |
  |
Hop to: |
Your Input Into These Forums Is Appreciated! Thanks!
Main Site Search 
