8.3的变化

牛角尖

8.3的变化

从2008版的7.3到2016版的8.3发现有以下变化

一、增加了8.3.1总则条款，组织因建立、实施和保持适当的设计和开发过程，已确保后续的产品和服务的提供。

审核该条款时，应收集组织是否建立了有关设计和开发方面的程序文件，具体查手册或程序文件是否包含了上述的内容，确定本次审核对8.3条款的抽样项目，

二、8.3.2 设计和开发策划

较之2008版7.3.1增加了“产品和服务的设计和开发所需的内部和外部资源”。

  在审核时应予以关注，收集这方面的策划的证据。

  增加了“证实已经满足设计和开发要求所需的成文信息”这里成文信息是指的每项活动产生的记录和文件，如：机械产品的方案设计产生出原理图，示意图等。软件设计的架构设计活动，应产生出设计规格说明书。系统实现阶段应产生源代码，编制出用户说明书等，设计评审应有评审报告，验证应有测试报告等

三、 8.3.3设计开发的输入

  这个条款不再要求对设计输入评审 。理由可能是“针对所设计和开发的具体类型的产品和服务，确定必需的要求”本身已经隐含了评审，可以说确定要求的过程，也是一个评审的过程。故不再重复要求进行设计开发输入的评审。

   审核该条款时，应对 输入的要件逐一核对是否满足标准的要求，其中最重要的是功能和性能的要求及法规要求、标准规范等。

  四、8.3.4条款合并了原来的7.3.4、7.3.5、7.3.6条款，新增加了“规定拟获得的结果”的控制要求。这里的结果，就是设计和开发的成果。如：机械设备的设计，其最终成果，可以是一套图纸，也可以包含样机。也可以包含批量生产的完整的工艺文件。  需要得到什么样的结果，都应得到规定（最终成果一般都会在合同或立项书里面确定）。

  拟获得的结果，不仅仅是最终的成果，还有阶段性成果。如软件开发的架构设计，最终的系统实现等。为了完成最终成果满足输入要求，有时会将设计划分成N个阶段，一步步地实现最终的成果。如：软件开发设计开发阶段分为概要设计、详细设计、系统实现3个阶段。其中阶段性成果有概要设计说明书，详细设计说明书。这些都要一一明确。

五、评审、验证、确认的变化

2008版的7.3.1“b) 适合于每个设计和开发阶段的评审、验证和确认活动；”、7.3.4“在适宜的阶段对设计和开发进行系统的评审”改成了  8.3.4“所需的过程阶段，包括适用的设计和开发评审”。“所需的设计开发验证及确认活动” 。即以前评审、验证、确认活动安排在适宜的阶段进行。即这些活动有可能进行，有可能不进行。其中评审活动是要么不评审，只要评审了就应该是系统的评审。现在验证及确认的要求基本不变。评审改为每个阶段必须评审，但评审的方式及程度可以多样，可以系统地评审、也可以局部评审，根据是否适用而定。

审核时要把握阶段的划分，很多人将活动误为阶段，如将测试、确认划为阶段，评审就无法进行。

六、8.3.5设计和开发的输出改变不大。其中有个a)满足输入要求。审核时查看验证的结论如何。验证通过，可以说满足了输入要求。验证不通过成果就不能输出。

七、设计和开发更改

   2008版“应对设计和开发的更改进行适当评审、验证和确认，并在实施前得到批准”。每个更改都要进行评审、验证和确认。这种更改只能是最终输出成果的更改。如：施工中的设计更改。软件的打补丁等。2016版明确的更改包含设计开发期间及后续所做的更改。

    在审核中仍然可以将设计开发期间的更改放在8.3.4一并审核。成果移交后的更改在7.3.6表述。这样审核方便些。

学为考试

楼主在第一个问题中提出：“审核该条款时，应收集组织是否建立了有关设计和开发方面的程序文件，具体查手册或程序文件是否包含了上述的内容。”标准要求建立手册和程序文件了吗？
第三个问题，说得对：“ 这个条款不再要求对设计输入评审”。

fziso

按条款要求（有时甚至恐怖到每一句话）逐一对照，往往容易造成：死板硬套、照本宣科。例如：比如一件衣服去缝纫店修补，这里面就涉及到一个简单的设计：缝纫店要依据衣服的破损程度，作出设计一套怎么缝纫、怎么的方案出来、并且要求在极短的时间内付诸实施（客人很急），怎么可能形成一套繁琐的设计（策划、输入、输出、评审、验证、确认、更改）资料？ 但是：新版本用词是“文件化信息（成文信息）“，所谓“文件化信息（成文信息）“可以理解为”具有类似或等同文件性质的信息“，这么短的时间完成的这项简单设计，虽然无法输出书面化的设计（策划、输入、输出、评审、验证、确认、更改）资料，但照样可以输出设计（策划、输入、输出、评审、验证、确认、更改）的”文件化信息“

牛角尖

rml 发表于 2017-5-26 14:02
9 p) W" P! U; N4 A一、同“沙发”问——“组织应建立、实施和保持适当的设计和开发过程”等于“组织应建立有关设计和开发方 ...

3 i. q1 W7 d5 c9 L* x2 p旧版审核时，应将6.2、6.3、6.4通用要求应用于此，加以关注。产生同样的效果。新版则应在策划输出中明确体现。这是唯一的不同。
1
" M3 K- P0 x0 |四、这段是要求策划应考虑记录的要求。旧版不是没有而是在各子过程要求。新版也在子过程有要求，同时增加的只是策划应“考虑”。
五、既然由策划考虑，不宜先入为主固化形式。;
B  F# z. d* Y" W! J2 m% a
' T0 S5 \# g" @/ j0 ^----既然标准增加了这2个要求，运行时就要满足这2个要求。审核时就要查实策划有无这样的安排。以前审核时见过几个设计开发计划书，就专门有关于资源需求的栏目。计划书在完成期限栏的后面设置了一栏文件要求，当时觉得不错，没想到2016版增加了这2个要求。
" l, I3 [+ j( O9 H5 U
六、“不再要求对设计输入评审”是个错觉。本条第二、三段要求“针对设计和开发的目的，输入应是充分和适宜的，且应完整、清楚。||相互矛盾的设计和开发输入应得到解决”，实际上隐含了“评审”。无论采用何种形式，确定输入的适宜性、充分性或有效性（完整、清楚、不矛盾不可以归结为这三性中的任何一性吗？），就是定义的术语“评审”。只是标准“高明”地采用了暗示、隐含的手法。难道组织不需要确定这两段要求是否满足？( P$ p# G( Y1 e. Y2 p- c  k# u9 u
七、“确定必需的要求”不等于评审。否则，本条二、三段要求就没有必要了。如果“可以说确定要求的过程，也是一个评审的过程。故不再重复要求进行设计开发输入的评审”，不止本条二、三段没有必要，类似的产品和服务要求的确定（8.2.2）也就是一个评审过程，还有必要要求8.2.3产品和服务要求的评审吗？9 F- U" |0 n9 k$ e9 h. l1 A
八、本条对各“要件”的要求是“应考虑”。它与“应确定”有什么不同？为什么不要求“确定”而要求“考虑”？别把考虑当确定了。更不要轻言孰轻孰重。万一某项设计和开发无法输入法规要求，它还是“最重要”的吗？3 ~# d6 e, ?/ t1 y& H. C" {
  q$ Z: Y+ n$ N( S6 [; l建议：把握好基础术语和通用词汇和多维思考。仍然是不要先入为主，凭借想象和经验
9 I( r* r  C. h7 L& A" V+ it0 需求评审要求
' O; Y8 E% w7 f  U
* s7 t2 C/ X% I) L标准对需求评审的要求没有了，这是不争的事实，以后标准修改可能会恢复。但那是以后的事，但现在。最高指示理解了要执行，不理解也要执行。
& v6 r  u$ M: A. b3 j# u/ \, Z
* G6 @# X! b3 t' M3 \+ v& P7 U$ ~/ L九、作为最终成果规定的“拟获得的结果”可以与输入的要求不一致吗？--没有谁说不一致
$ Z8 ~1 w$ p; ~* C2 D6 T十、策划要求确定所需阶段。阶段是什么？是不是应以其输出来划分？作为阶段性成果规定的“拟获得的成果”能否与阶段输出不一致？所以，2015是个外行搞的，根本不懂设计和开发的客观逻辑。--  这是个老问题了，最好举一个划分阶段的例子。我已在文中表明我是如何划分阶段的。不过有一点，设计开发的阶段绝对不能包含“（8.2.2/8.2.3）含合同评审的那个阶段 ”及管理评审阶段。

$ Y3 n+ m6 c& b十六、旧版“‘应对设计和开发的更改进行适当评审、验证和确认，并在实施前得到批准’。每个更改都要进行评审、验证和确认”是理解错误— 2000版7.3.7“在适当时，应对设计和开发的更改进行评审、验证和确认，并在实施前得到批准。”即可能进行，也可能不进行
! a* D2 c9 e% j" [/ u$ V0 `" i2008版7.3.7“应对设计和开发的更改进行适当评审、验证和确认，并在实施前得到批准。”应就是一定要进行评审，只是评审的程度，方式等不同，2008版对设计开发的评审是要求系统地评审，更改就没有要求进行系统地评审而是适当的评审

9 {! S  \  d& {7 D# b8 o暂时到这里，得闲还会讨论

胡逸之

关于8.3我也有个疑问，某公司08版手册里删减了7.3，理由是其产品完全按国家标准生产，不存在设计和开发，但现在这个国家标准废止了，改为执行一个通用国家标准，那么现在8.3能否说不适用呢？