你的眼里还有没有 “8.3.4 设计和开发控制” 这个条款的要求？
再问你个问题：按照新版标准，设计开发的 ...
设计开发评审：评审对象是设计开发的结果（成果及阶段性成果），目的：评审结果满足要求的能力
输入评审：评审的对象：输入 目的：评审输入的充分性、适宜性
两个评审对象不同，目的也不同。当然不是一类别的评审
有个问题我思考了很久，标准的设计和开发过程，只是指的设计开发全过程中的实施阶段活动含：如绘图、参数确定、小样研制、大样研制、架构设计、系统实现等。8.3.4的设计和开发过程控制的对象不含设计开发的策划及设计和开发输入， 8.3.2策划时确定的设计和开发阶段也仅仅是对实施过程的划分如初步设计、施工设计。这些阶段不含策划及输入。8.3.4的要求不是针对8.3.2及8.3.3的
2008版7.3.1 有“适合于每个设计和开发阶段的评审、验证和确认活动；”在这里评审、验证、确认地位是一致的，如果将策划、输入作为设计开发的一个阶段。怎么去验证、确认。总不能确认输入满足使用要求吧
2015版规定了每个设计开发阶段都要评审，不一定每个阶段都要验证、确认。如果不是这样理解阶段的划分，真要乱成一锅粥，譬如测试是个复杂的过程， 要策划检测大纲、要制备试验样件等列为一个阶段也是可以的。按8.3.4要求也是要评审的，还要评审其结果满足要求的能力，可能吗。
还有好多地方都有评审，有输入的评审、有对设计开发计划书的评审、签订设计开发项目为标的的合同过程，还要进行合同评审。设计开发验证报告上有审核、批 准说明也是进行了评审的。文件控制要求对文件要进行评审。评审很多，但不是设计开发评审。
2008版标准要求对设计开发输入进行评审，新标准这个要求没有了。这是明摆的事。 标准为什么要这样修改，是一定有它的道理的。 我们不妨在这个问题上多思考一下 rml 发表于 2017-4-25 18:14
你说的不是评审，是验证。
评审解决的不是“设计出来的是不是想要的那个东东”的问题。它解决的是“现有 ...
应该回到一剑老师的，将就点看吧 牛角尖 发表于 2017-4-25 21:27
设计开发评审：评审对象是设计开发的结果（成果及阶段性成果），目的：评审结果满足要求的能力
输入评审 ...
还是送你一张图吧，虽然这是2008版时的三者关系图，但2015版仍适用，只不过图中的 “产品” 现在应是 “产品和服务”。
看来你对 “按照新版标准，设计开发的输出在放行前还要不要批准？” 这个问题是无法回答了。
牛角尖 发表于 2017-4-25 21:27
设计开发评审：评审对象是设计开发的结果（成果及阶段性成果），目的：评审结果满足要求的能力
输入评审 ...
设计输入不清晰，不准确，甚至是南辕北辙，错误表述，会不会对结果满足要求的能力造成影响？
需求收集、确认、分解分配，本身就是一个设计开发活动的自然阶段，
当然，标准也说的很清楚没有要求每个阶段就必须要有评审、验证、确认。
但是需求阶段，会没有验证吗？例如甄别需求，检查需求的分解分配是否存在错误或遗漏，这些活动不是验证吗？
你不能一直只盯着以整个项目来看的最终的输出和最终的结果，什么是过程？任何过程和阶段都应该是有输入输出应该不否认吧？如果研发活动其中一个自然阶段是需求阶段，那么这个阶段的输入输出是什么？
有可能这个阶段没有所谓的确认，但是为什么不可以有评审和验证呢？
另外2015版也没有规定每个设计开发阶段都要评审，不知道你这个论断是从标准哪里看出来的。我估计是来自8.3.2的 组织应考虑 这一段，
不要只看到应，就认为必须有，是要你必须去考虑，而且还有一个限定是适用的设计开发评审，考虑过后，不适用，不应该有评审难道不可以吗？片面去理解标准才真是容易乱成一锅粥。
按照你举的例子，
输入的评审，通过分析收纳需求，明确了设计输入，整个设计输入有关的活动存不存在要求？刑不形成结果？所输出的需求说明书也好，包需求也好，这些结果满不满足要求？事情做的好不好?需求描述准不准确？有没有按时输出结果？ 有关的评审就不是设计开发评审了？
如果你认同设计输入有关的活动可能是一个设计开发的阶段（概念阶段、需求阶段），你自己也说了每个设计开发阶段都要评审（当然我也说了不见得），但是你又认为在8.3.2里面提到的设计开发评审和8.3.4里面提到的评审又不是一个东西。我觉得你自己的逻辑也要捋一捋，不是自相矛盾了吗？
8.3.3里面，的确没有出现评审二字，我认为这并不矛盾，本身8.3.2就说的很清楚，你要自己去考虑到底适用哪些评审，其实，你也可以认为新标准看来，甚至不仅输入的评审，所有设计开发评审都可能没有了，如果真的有各种各样统统不适用的情况出现。
只不过，现实中这么特殊的情况毕竟是少数，所以输入的评审绝大多数情况下还是会存在，因为的确“适用”
kingrobin 发表于 2017-4-26 03:16
设计输入不清晰，不准确，甚至是南辕北辙，错误表述，会不会对结果满足要求的能力造成影响？
需求收集、 ...
还是举个简单的审核设计开发输入例子吧
审核2008版时，被审核方提供了设计开发清单，列举了输入的内容如功能性能要求、法规清单等，查实其内容满足了7.3.2各项要求，另查到，对输入评审的记录（报告），评审结论：“完整、清楚、没有发现有自相矛盾的地方。”报告上有批准人及时间等信息。大体来讲审核发现就应该是“合格了”。如果没有提供评审的证据，就是不合格。不符合7.3.2“应对这些输入的充分性和适宜性进行评审。”
审2016版时 ，审核还是上例，审核员查实输入清单上的内容是否满足了8.3.3的各项要求。如果满足了就是合格，不满足就是不合格。企业没有提供输入评审记录（报告），询问企业为什么对输入不评审，企业负责人说，我们哪会不评审呢，不评审怎么去“确定必须的要求”，输入清单怎么编得出来。 查设计开发输入清单，审核、批准栏均空白。此时，开具不符合“8.6成文信息应包括：b)可追溯到授权放行人员的信息”。
这就是修改前后的如何审核的区别
对于后者那样的对横向要求（不含本条款 ）的 审核，可适用于“正面求证，负面报告”的方式，即如果合格可以不记录。不合格予以记录并出具书面报告。类似这样的横向要求很多，如：文件批准、清晰。发放、作废、还有记录的要求等，其缺陷一眼就看得出，没发现缺陷就不要在记录中一一下结论了（也是不可能的）。在审核中一些良好的习惯应该提倡和坚持如：审核时不忘记记录编、审、批的信息 牛角尖 发表于 2017-4-27 10:12
还是举个简单的审核设计开发输入例子吧
审核2008版时，被审核方提供了设计开发清单，列举了输入的内容如 ...回39楼
你以为，这样审核是那么容易的吗，仅仅“查实其内容满足了7.3.2各项要求”，是那么简单的吗，你能够做得到吗？你说的找人家要模板，确实不好，但有人提出与我交流，我会很乐意。这位老师说你太落后，是不是没用电脑记录，如果这样很不好，现在我们都是电子化了，留底的纸质资料只有30张左右。阅卷都是远程阅卷方式。 牛角尖 发表于 2017-4-27 10:12
还是举个简单的审核设计开发输入例子吧
审核2008版时，被审核方提供了设计开发清单，列举了输入的内容如 ...
你以为，这样审核是那么容易的吗，仅仅“查实其内容满足了7.3.2各项要求”，是那么简单的吗，你能够做得到吗？你说的找人家要模板，确实不好，但有人提出与我交流，我会很乐意。这位老师说你太落后，是不是没用电脑记录，如果这样很不好，现在我们都是电子化了，留底的纸质资料只有30张左右。阅卷都是远程阅卷方式。 牛角尖 发表于 2017-4-27 10:12
还是举个简单的审核设计开发输入例子吧
审核2008版时，被审核方提供了设计开发清单，列举了输入的内容如 ...
你以为，这样审核是那么容易的吗，仅仅“查实其内容满足了7.3.2各项要求”，是那么简单的吗，你能够做得到吗？你说的找人家要模板，确实不好，但有人提出与我交流，我会很乐意。这位老师说你太落后，是不是没用电脑记录，如果这样很不好，现在我们都是电子化了，留底的纸质资料只有30张左右。阅卷都是远程阅卷方式。
回39楼的 rml 发表于 2017-4-27 13:17
振振有词呵。
旧版不多说了。“清单审核”和“结论审核”也不多说了（不是没得说，是不说）。
说关于新 ...
这个错误是应该承认的， 输入清单上审核批准空白，判8.6不对，应判7.5.2c)“评审和批准，已确保适宜性和充分性”。如果是软件产品之类设计成果就是最终的产品，这类的8.3对 阶段性成果及成果的评审报告，如详细设计说明书评审报告， 审核、批准空白，是适用 “8.6成文信息应包括：b)可追溯到授权放行人员的信息”这个评审包含了验证的内容，评审通不过是不能放行到系统实现这个阶段的。如果设计开发的成果用于自身的生产 ，这时候8.3只是运行中的一个环节，其地位与8.2、8.4相当。这种情况下8.6放行的要求不适用8.3 牛角尖 发表于 2017-4-27 17:01
回39楼
你以为，这样审核是那么容易的吗，仅仅“查实其内容满足了7.3.2各项要求”，是那么简单的吗，你能 ...
既然你问了我能够做得到吗？ 我可以肯定的告诉你，做不到，因为这根本就不是我们的选项，而且也不许我们的审核员这样审核，见一次说一次。
我们年年都会和某机构的审核组联合审核某央企，我总结的最大不同就是我们的人多数时间在现场看，对方的审核员多数时间在办公室抄记录。第一次审核两个机构的审核员都是一个大房间吃饭，接待人每人发个红包，我们的人没有一个人拿，他们的人早都揣兜里了，气氛很尴尬。后面的每一次审核就没在一起再吃过饭。
举这个看似没关系的例子，只是想说，风格不一样，我能理解你为什么这么审核，和联合审核的他机构审核员聊过这个话题，其实也都是比较老资格的老同志，告诉我没办法，审核记录要面面俱到，抽样数一个不能少，时间任务地点事件统统要交代清楚，所以根本没有时间深入审核，只能看看记录来审核，电子版记录按条款做好模板，按条款顺序做检查表问问题（每当我听到他们这么问问题，我相信接受审核的人的内心是和我一样崩溃的）。 但是我不知道你是不是理解我说的为什么不能这么审核。
设计开发过程的审核，我自认我还是有些经验，至少现在机构超过50人天的审核项目基本都是我在带队，至少我试过好几次在一场审核中连续审研发过程一两个礼拜。
我基本上不怎么会去看所谓的输入清单，尤其当输入信息自然分散时，为什么要有个清单？我也不会建议我们的客户通过“清单”来证明他输入是齐备的，评审是适宜的。
以后再聊聊过程审核和价值审核的话题，太晚了 没看明白，单位针对新版要求换版，设计开发控制程序怎么编，头痛
页:
1
[2]