2005版ISO9000标准之3.4.4给出”设计和开发”的定义为：“将要求转换为产品\过程或体系的规定的特性或规范的一组过程”，特别指出：术语“设计”和“开发”有时是同义的，有时用于规定整个设计和开发过程的不同阶段。设计和开发可分为两类，一种是产品的设计和开发，一种是过程的设计和开发。
标准7.3条款的要求主要对前者，过程的设计开发是指工艺的规划和设计，也是可以参照本条款进行控制的。
对于产品“设计和开发”的控制要求在实施的过程中，往往不能完全达到标准的要求，存在这样那样的不符合。出现不符合有实施上的不严谨或怕麻烦，但也有一部分属于对标准的理解。 以下我们按个子条款分开讨论：
1、7.3.1“设计和开发的策划”是指在与顾客有关的过程之后，或经过可行性论证并立项，设计开发的对象已确立，对设计开发过程本身的策划。
策划主要应确定：设计开发过程的阶段划分，每阶段应开展的诸如验证、评审、确认等质量活动的时机以及设计开发职责权限的授予。
策划的结果应是动态的，随着设计开发工作的开展，所形成的计划可以更新。
另外是要关注设计开发的接口。这个“接口”包括组织的、人员之间的、技术方面和外部相关的，必须要策划清楚。
对接口的管理，一方面要书面明确各自的职责，一方面还要保持有效的沟通，并形成可供追溯的记录，如《设计信息联络单》，这往往被忽视而仅以口头方式进行。
审核员在审核7.3.1时要重点把握设计开发策划进行没有?
1)、有没有经过策划形成诸如“产品开发项目任务书”或“产品设计开发计划”之类文件?
2)设计开发是否明确划分出设计的各个阶段?并明确了对阶段的评审要求?
3)对每个设计阶段的设计目标、设计成果体现、验证、确认的对象、内容要求、责任部门、相关部门、资源配置是否有明确规定?
审核员应有能力判断设计策划的充分性与适宜性，是否能作为组织产品设计开发过程控制的依据?是否 对设计开发策划走过场的结果，
2
设计开发输入时设计设计单位针对需设计项目的前期准备。
收集顾客对产品的功能、性能要求(通常是从合同、订单、与顾客沟通和市场调查研究结果信息获得);
产品应遵循的法律法规要求;
产品应依据的规范、标准要求;
本组织以往类似的设计可参考资料、数据、信息;
设计和开发所必需的其他要求(如地区、民族习俗、其他约定)
经常发现的是，组织对设计开发输入不充分，缺这少哪。导致设计开发的依据不足。对后续设计开发过程造成隐患!
另外，按标准要求“应对这些输入的充分性和适宜性进行评审。要求应完整、清楚， 并且不能自相矛盾”。
审核发现需对组织没有策划和保持应对这些输入的充分性和适宜性进行评审的记录。即使有评审也走过程。评审记录中罗列了设计输入，在评审结论中简单的表达出：“符合”。
对这种现象，应引起审核员的关注!
3、7.3.3 设计开发输出
不同的组织、不同的产品设计，其设计开发输出是迥然不同的。
审核员应有能力判断组织所设计产品的输出是否充分?
是否包含了标准7.3.3a)-d)条要求?
设计开发输出的方式是否符合于对照设计和开发的输入进行验证?
输出是否在放行前得到批准?
另外，某些行业设计开发输出与设计开发记录的记录有时不可分。比如在IT行业，计算机软件开发和系统集成设计的输出文档，不少又是设计开发的记录。
标准除7.3.3设计开发输出未明确提出保持记录外，从7.3.1.7.3.2.7.3.4.7.3.5.7.3.6.7.3.7均明确提出保持记录要求。
设计开发文件记录的整理建档
每个设计开发项目应形成的文件记录，一般地说，应有：
① 项目建议书(可行性报告)
② 项目任务书
③ 项目设计开发计划
④ 设计开发输入资料或文件
⑤ 设计开发输出资料或文件
⑥ 设计开发评审记录
⑦ 设计开发验证记录
⑧ 设计开发确认记录
⑨ 产品鉴定试验报告
⑩ 设计开发更改资料或记录
上述这些资料和记录格式的设置，应考虑必须提供的信息，例如，评审或确认记录中与会人员提出的问题，应在记录表的相关栏目里看到设计开发人员的对策及实施及验证的结果。所有资料和记录都必须按规定的权限签署，特别是文件的更改，应有按规定程序的控制记录。
4
关键是要抓住4要点：
1、评审是否有策划安排(7.3.1)?是否按照策划的设计阶段开展评审/并符合策划安排?
2、评审是否评价了设计开发的结果符合要求的能力?
3、评审是否发现了并记录了问题，同时提出了必要的措施?
4、这些措施的实施结果应在7.3.5.7.3.6.7.3.7中加以验证、确认或更改。
审核员应有能力判断设计开发评审的充分性和适宜性、有效性。经常在审核中发现，一些组织的设计开发评审也形同虚设。走过场，玩概念，评审不评审都一样。忽悠审核员，忽悠认证机构的情况严重。其最终使产品的设计开发结果不满足顾客需要。投入大量开发成本，最后一事无成!
5
①是否按7.3.1策划安排进行?
②是否达到设计开发确认的目的：为确保产品能够满足规定的使用要求或已知的预期用途要求?
③确认的时机：“只要可行，应在产品交付实施之前完成”。通常对机电硬件产品的设计开发验证可以在实验室完成。但也有它例。
审核员有必要注意的是“只要可行”这个条件。如不可行，审核员应允许组织的设
计开发确认在组织与顾客约定的时间完成。比较典型的仍然是计算机软件、系统集成或安防工程、化工设计等，设计开发的结果在设计单位是无法“验证”或“确认”的。
“验证”或“确认”只有等到设计成果已按要求组装完成后在进行。
④验证和确认结果及任何必要措施的记录要予以保持。
⑤验证和确认中任何不满足要求的结果，应在7.3.7中追溯查验其更改、评审、再验证、确认的情况。
6
审核员应把握的重点有：
1、 是否识别了设计开发更改?
2、 对设计开发的更改是否进行了评审?评审结果是否经批准并在实施前完成?评审内容是否包括了更改对产品组成部分和交付的影响?典型的是，设计部件的变更、工程分项目、分项工程的变更是否对其他部件、组件和整个工程有影响?是否会影响客户认可，影响交付(适当时应将变更通告客户)。
3、 更改评审的记录是否保持并可追溯?
4、 对设计开发的更改是否进行了重新验证、确认?结果是否经批准并在实施前完成?
7
1)、是7.3.1设计和开发策划的“注”：“设计开发的评审、验证和确认具有不同目的，根据产品和组织的具体情况，可单独会议组合方式进行并记录”。
这一个“注”实际上是给不同组织的设计开发的评审、验证和确认阶段过程可以合并进行开了一个口子。典型的应用是计算机系统集成的设计开发阶段中的这三个过程往往是合并的，并与系统集成工程实现，与系统分部工程和系统的联调联测不可分。过程的监视测量结果往往就是产品的“评审、验证和确认”结果。在后续阶段的“评审”有可能是顾客和组织的评审。
审核员应注意这个“口”，应有能力判断，哪一类组织的“评审、验证和确认”可能是合并或同步的，哪些不允许合并或同步。
设计开发评审、验证、确认是产品设计和开发各阶段所必需的质量活动，只不过根据产品的复杂程度不同，技术含量不同，顾客要求不同，组织规模及文化背景不同等等因素，需在策划时对上述三项质量活动的作出不同安排。
以设计开发评审为例，一般的说，对比较简单的产品，至少安排两次评审：方案评审和设计确认前的最终评审。而对于大型复杂产品，则要分级、分阶段进行，在设计开发策划时就应予以确定。
2)、是在7.3.3设计开发输出a)-d)要求中，增加的“注”清楚地提出对b)要求作出这样的补充：“生产和服务提供的信息可包括产品防护的细节”。
这一条要求往往被审核组织或审核员所忽略。笔者在审核多家设计开发单位，在设计开发的各阶段，没有产品的防护设计;在审核7.5.5时，也不能提供针对特定产品的防护文件要求。
审核员应注意将7.3的审核应与标准其他条款的审核相衔接。如5.4.1.7.1.6.3.7.2.7.4.2.7.5.7.6.8.3.8.2.4.8.5都多少与7.3设计开发相关。从产品实现的全过程分析。产品设计开发过程是组织全过程中的处于龙头地位的一个过程。对该过程策划、实施和控制的有效性直接影响产品满足顾客要求和法规要求，影响组织质量方针和目标的实现。审核员必须把握此点，通过对7.3的审核评价组织满足顾客要求和法规要求的能力!
