关于设计输出的记录及逻辑问题
8.3.5 末句 组织应保留有关设计和开发输出的成文信息 就是保留图纸、配方等，还是对这些设计成果的一些管理记录？应该是前者吧。另外，新版调整了顺序，8.3.4控制之后才是8.3.5输出，感觉逻辑上有点不通，为何在设计评审、验证、确认之后再提设计输出？没有图纸、配方这些设计输出如何开展这三步活动？
第一问题：“8.3.5 末句 组织应保留有关设计和开发输出的成文信息 就是保留图纸、配方等，还是对这些设计成果的一些管理记录？应该是前者吧。”应该是前者，标准中没有对设计成果管理提出要求，不太可能要求保持对设计成果管理的记录。
第二个问题：“...新版调整了顺序，8.3.4控制之后才是8.3.5输出，感觉逻辑上有点不通，为何在设计评审、验证、确认之后再提设计输出？没有图纸、配方这些设计输出如何开展这三步活动？”， 先有评审、验证、确认通过后再有成果的输出，逻辑上没有问题。输出的成果一定是最终的成果，评审、验证、确认对象也可能是阶段性成果。输出不应该包含阶段性成果。如软件开发，输出可以包含源代码、用户说明书、培训方案等，作为阶段性成果的“概要设计说明书”及“详细设计说明书”不应该是输出。类比一下硬件生产。检验（适用时包含验收）合格后出厂。半成品可以检验但不能出厂。 牛角尖 发表于 2017-4-21 21:10
第一问题：“8.3.5 末句 组织应保留有关设计和开发输出的成文信息 就是保留图纸、配方等，还是对这些设 ...
不要自然认为标准条款是一个绝对固化的时间先后的逻辑顺序。
就如同设计输入在设计评审、验证、确认的前面，不代表，设计输入只发生在项目初期阶段，实际一个研发项目，设计需求可能不断在调整。
设计评审在项目立项策划阶段就没有了吗？
设计输出在后面，难道设计输出不需要去验证、评审和确认了吗？
回到第一个问题，设计成果有关的管理记录指的是什么？如果指向包括例如图纸审核记录、图纸发布发行记录，那么这个成文信息既是设计输出有关的成文信息，也可能是设计评审/验证有关的成文信息。 如果2015版标准在8.3.5设计和开发输出一节仍保留 “输出放行前应得到批准” 的控制要求，就不应有设计成果管理记录是不是设计输出的疑问了。 回复了一堆，现在还没通过审核，已经没有再码字的热情。
一句话，标准的条款顺序不代表绝对的时间先后逻辑顺序。 kingrobin 发表于 2017-4-21 22:56
不要自然认为标准条款是一个绝对固化的时间先后的逻辑顺序。
就如同设计输入在设计评审、验证、确认的前 ...
不要自然认为标准条款是一个绝对固化的时间先后的逻辑顺序。 --标准条款当然不能这样去理解，但实际运作中还是有相对顺序的。
就如同设计输入在设计评审、验证、确认的前面，不代表，设计输入只发生在项目初期阶段，实际一个研发项目，设计需求可能不断在调整。--这个很赞成
设计评审在项目立项策划阶段就没有了吗？-原来的7.3.4及现在的8.3.4的设计开发评审在策划阶段真还没有，08版的输入评审的要求在7.3.2 是对“评审输入的充分性和适宜性进行评审” 。“要求应完整、清楚，并且不能自相矛盾。”7.3.4的评审是对设计结果评审“a) 评价设计和开发的结果满足要求的能力； b) 识别任何问题并提出必要的措施。 ”两个评审说的不是一回事。2016版有了变化，输入已经不要求评审了，设计开发的评审基本没变，只是在评审时机上有所不同。2008版7.3.4“在适宜的阶段对设计和开发进行系统的评审”，且在7.3.1要求“适合于每个设计和开发阶段的评审、验证和确认活动；”可以理解为，有些阶段要评审，有些阶段可能不需要评审。2016版8.3.4“实施评审活动，以评价设计开发的结果满足要求的能力”，且在8.3.2要求“所需的过程阶段，包括适用的设计开发评审”可以理解为在所有的设计开发阶段都要评审。（这里的设计开发阶段就只能是设计开发的实施过程，即可产生成果或阶段性成果的阶段）
进行设计输出在后面，难道设计输出不需要去验证、评审和确认了吗？-验证、评审、确认了才能输出，如果验证、评审、确认没通过，设计开发就没完成（没完成怎么输出？），或采取措施改进，再次验证（、评审、确认） 通过后才能输出，或宣告设计开发失败。
回到第一个问题，设计成果有关的管理记录指的是什么？如果指向包括例如图纸审核记录、图纸发布发行记录，那么这个成文信息既是设计输出有关的成文信息，也可能是设计评审/验证有关的成文信息。--设计和开发控制的成文信息已在8.3.4有要求。8.3.5应是特指构成成果载体的输出成文信息。 牛角尖 发表于 2017-4-22 22:24
不要自然认为标准条款是一个绝对固化的时间先后的逻辑顺序。 --标准条款当然不能这样去理解，但实际运作 ...
2016版有了变化，输入已经不要求评审了，设计开发的评审基本没变，只是在评审时机上有所不同。
新版标准对设计和开发输入进行评审的要求不是没有了，而是隐含了。理由如下：
8.3.2 设计和开发策划
在确定设计和开发的各个阶段控制时，组织应考虑： b）所需的过程阶段，包括适用的设计和开发评审；
8.3.3 设计和开发输入
针对设计和开发的目的，输入应是充分和适宜的，且应完整、清楚。
8.3.4 设计和开发控制
组织应对设计和开发过程进行控制，以确保：b）实施评审活动，以评价设计和开发的结果满足要求的能力；
什么是评审，评审就是对客体实现所规定目标的适宜性、充分性或有效性的确定。因此，为了确保满足设计和开发的目的，对设计和开发输入的充分性和适宜性，组织仍应合理策划并实施评审。
一剑封喉 发表于 2017-4-23 11:28
新版标准对设计和开发输入进行评审的要求不是没有了，而是隐含了。理由如下：
8.3.2 设计和开发策划
...
8.3.3 设计和开发输入
针对设计和开发的目的，输入应是充分和适宜的，且应完整、清楚。这个要求是针对输入的要求，不是针对输入评审的要求。新标准既然取消了输入评审的要求，审核是就不能再要求组织提供输入评审的证据，含是否列入设计开发计划、输入评审记录（报告等）。审核时审核员应查实输入是否满足了7.3.3的要求。并形成审核发现。
关于设计开发的阶段的划分，的确是个纠结的事，有的按PDCA划分，有的把一些重要的活动列为阶段，如项目总结阶段，用户意见收集阶段，测试阶段（在软件行业这是个重要的过程，耗时且耗精力， 企业在策划时有时会将其列成一个阶段）。按照“b）所需的过程阶段，包括适用的设计和开发评审”对这些阶段都要进行评审。实际上是行不通的。我们所理解的设计开发阶段只能是设计开发的实施过程中分的阶段，即产生设计开发成果（结果）或阶段性成果的这些阶段。审核中不必介意企业怎么去划分阶段，只要是包含上述的阶段就行。如：软件开发的设计开发计划书的对过程的安排（未细化、未含用户说明的编制等）为：需求分析、概要设计、详细设计、编码、设计开发评审、测试、确认。这样的策划不合格。
如果改为：需求分析、概要设计、概要设计评审、详细设计、详细设计评审、编码、代码走查及评审、 测试（含评审）、确认。这样的策划可认为合格。这里面清楚地将设计开发分成了3个阶段：概要设计、详细设计、系统实现（编码）及各阶段的评审，也明确了验证及确认的安排 牛角尖 发表于 2017-4-23 12:36
8.3.3 设计和开发输入
针对设计和开发的目的，输入应是充分和适宜的，且应完整、清楚。这个要求是针对输 ...
看来你是那种拿本标准走天下的审核员。
审核时除了标准，你看不看企业体系成文规定？
具体到对设计和开发的审核，你看不看企业对具体产品和服务的设计和开发各阶段各过程所策划的评审、验证、确认安排？是否验证这些评审、验证、确认活动有否按策划安排实施？
企业如何满足“针对设计和开发的目的，输入应是充分和适宜的，且应完整、清楚”要求？如何满足“组织应保留有关设计和开发输入的成文信息”要求？应收集哪些有关设计和开发输入的成文信息审核证据以证实企业符合要求？
既然你坚持新标准取消了对输入评审的要求，那就坚持你的观点吧。我无意强迫你接受我的观点，但是建议你在读标准时多思考，多问自己几个为什么。例如，旧版标准有“8.3.4 设计和开发控制”这个条款要求吗？新版标准为什么要增加这个条款？
牛角尖 发表于 2017-4-22 22:24
不要自然认为标准条款是一个绝对固化的时间先后的逻辑顺序。 --标准条款当然不能这样去理解，但实际运作 ...
设计开发评审所针对的结果满足要求的能力，难道就只有最终设计输出的结果吗？怎么理解设计开发的阶段，不同阶段又分别有什么样的结果？
所以认为输入的评审和设计结果的评审不是一回事，我并不认同。
没有通过验证、评审、确认，就没有输出了吗？输出是自然存在的，是不是你想要的输出并不是输出是否存在的前提。 kingrobin 发表于 2017-4-23 17:26
设计开发评审所针对的结果满足要求的能力，难道就只有最终设计输出的结果吗？怎么理解设计开发的阶段，不 ...
关于对输入的评审和对设计开发结果的评审这在08版的7.3.2、7.3.4与16版的8.3.4都有明确的表述，再看两遍就知道是不是一回事，我的帖子都说得很清楚了。关于设计阶段的划分我也说得很清楚，设计成果与阶段性成果也表述了。有一点，输出的肯定是最终的成果， 这相当于通过了出厂检验的产品一样。没有通过出厂检验可以视同生产还没有完成。
我赞同一剑老师的一个观点，新标准（虽然）取消了输入评审的要求 但隐含了输入评审。这个在审核中深有体会，如作为输入证据的“需求说明书”，对所有的设计开发需求逐一进行了表述 。虽然没有评审记录、评审报告之类的文字，说明书也没有刻意的去评审，但这种说明书隐含了输入评审。在审核2016版时发现有些仍然对输入进行了评审，有些输入载体隐含了输入评审，有些没有对输入进行评审，我们做到心中有数就行。针对标准要求，少做的不行，多做的不管。但有一点，不能开具“没有提供对输入进行评审的证据”这样的不符合。因为没有依据。 牛角尖 发表于 2017-4-23 19:43
关于对输入的评审和对设计开发结果的评审这在08版的7.3.2、7.3.4与16版的8.3.4都有明确的表述，再看两遍 ...
你说：但有一点，不能开具“没有提供对输入进行评审的证据”这样的不符合。因为没有依据。
那你认为新版标准 8.3.4b）是针对什么的评审要求？为什么？
8.3.4 设计和开发控制
组织应对设计和开发过程进行控制，以确保：b）实施评审活动，以评价设计和开发的结果满足要求的能力。
“确定设计开发有哪些必需的输入要求” 这个过程要不要控制？对输入的充分性和适宜性要不要评审？要不要评价这个过程的结果（设计和开发输入确定过程所确定的结果）满足要求的能力？
顺便再问你个问题：按照新版标准，设计开发的输出在放行前还要不要批准？
一剑封喉 发表于 2017-4-23 20:22
那你认为新版标准 8.3.4b）是针对什么的评审要求？为什么？
8.3.4 设计和开发控制
组织应对设计和开 ...
8.3.4b)的评审的对象是设计和开发的结果，这个评审怎么可以作为输入评审呢，怎么“以评价设计和开发的结果满足要求的能力。”，输入实际上是在确定要求。怎么成了满足要求呢，故这两个评审不是一回事。输入评审要求在新版中取消了 。8.3.4的a)规定拟获得的结果与8.3.3有关，输入涉及的要求是针对最终的设计成果的，8.3.4a)要求拟获得的结果不仅仅是最终拟获得的结果，也包括各个拟获得的阶段性结果，譬如，某化工产品分为小样研制及大样研制，都要有配方及其它的工艺文件都要满足输入的要求等。a)条款里也没有提出对输入进行评审的要求。
输入就是在确定要求，确定要求不就是控制吗？在确定要求时一般都隐含了评审。也可能是这个原因，新标准取消了输入评审的要求。 新标准将输出的位置调整到确认之后，而2008版是有了输出才做评审、验证、批准，这样调整，用意何在？是之前2008版的做法不合理？还是新版察觉到了，进行更正、完善？或者本身就是一种倒退？
有人认为是确认后才正式形成输出。那之前的输出只就是草案，经过控制三步骤就是正式的。这个理解对吧？ 牛角尖 发表于 2017-4-23 21:47
8.3.4b)的评审的对象是设计和开发的结果，这个评审怎么可以作为输入评审呢，怎么“以评价设计和开发的结 ...
8.3.4 设计和开发控制
组织应对设计和开发过程进行控制，以确保：b）实施评审活动，以评价设计和开发的结果满足要求的能力。
按照你的理解，“设计和开发的结果” 应该就是设计开发的输出了。那标准为什么不直接写成“实施评审活动，以评价设计和开发的输出满足要求的能力”？
其实，这里要求评审的是按照组织在策划阶段确定的评审安排，对设计和开发各阶段过程的结果进行评审。 emeipengxu 发表于 2017-4-23 21:57
新标准将输出的位置调整到确认之后，而2008版是有了输出才做评审、验证、批准，这样调整，用意何在？是之前 ...
同意，我也是这样认为的 以前的也没错到那里去，同样可以这样理解，但容易造成误会，现在这样更合理些 rml 发表于 2017-4-24 07:32
还是语文和逻辑的问题。
这个问题其实不是问题。2015不过是用”成文信息“取代了”信息及其载体“这个广 ...
顺便也讨论下这样个问题吧。 软件开发企业，将测试报告、测试用例（一般作为测试计划的一部分）作为输出，审核时遇到这个情况是不会在成太大的问题，反正无论8.3.4或8.3.5 总是要求提供的。但他们是设计开发的输出吗，这个问题我还没琢磨好，先提出来讨论，尤其希望看到RMl老师的见解。 牛角尖 发表于 2017-4-23 22:06
同意，我也是这样认为的
这个要修正一下，最终成果验证合格后应该就可以作为设计开发的输出了，确认有点有时候在交付后才能完成，8.3.5a)也规定“满足输入的要求”。验证合格可以认为满足了输入的要求 rml 发表于 2017-4-24 11:29
“测试报告”首先是作为测试结果的记录连同必要的措施的记录一并都属于8.3.4f。必要时可能作为8.3.5输出 ...
感谢回复，第一个问题，很赞同
关于第二个问题：
我见到一些应用软件的测试用例，就像打坦克游戏一样，达到效果要求坦克遇到墙要停下来，实际操作一下坦克遇到墙不能动弹，这一项测试，合格，如果穿过去了，则不合格，称为BUG.前不久见到一个测试用例，提供给甲方，用于验收时测试。那是个表格形式的， 有 测试内容、测试方式、达到什么要求栏目，最后还留有一栏空白栏“测试结果（通过打钩，通不过打叉）”左看看，又看看都像是个测试大纲。如果是测试大纲，就相当于7.3.5“c)包括或引用监视和测量的要求....”.这就是输出了。但这种测试用例大多是只用于内部测试。并不会提供给客户。客户也看不懂这个。软件生产不同于硬件，设计好了，下一步是投产，需要一个测试大纲或标准检验产品是否合格。软件产品设计好了产品就出来了，没有后续的生产及检验，不需要测试大纲、产品标准之类的。到底测试用例是不是输出，我还没想清楚。 牛角尖 发表于 2017-4-23 19:43
关于对输入的评审和对设计开发结果的评审这在08版的7.3.2、7.3.4与16版的8.3.4都有明确的表述，再看两遍 ...
设计开发输入难道就不是某个阶段的结果？
以ICT行业推崇的IPD并行开发模式来说，第一个阶段叫概念阶段，这个阶段的重要输出结果是什么？产品包需求。
产品包需求是什么东西？用ISO 8.3来说，不就是设计输入。
设计输入本身也有一个演进的过程，客户原始需求-系统需求-架构需求-特性需求，不同阶段都有不同输出，每一个阶段又是下一个阶段的输入。
什么是结果满足要求的能力？为什么不说输出满足要求的能力？
非要说不是一回事也没法勉强。 牛角尖 发表于 2017-4-24 12:45
感谢回复，第一个问题，很赞同
关于第二个问题：
我见到一些应用软件的测试用例，就像打坦克游戏一 ...
你可以认为测试用例是一个策划阶段的输出，也可以把测试用例看作是整个设计项目的输出，但这要看情况，尤其是当这个项目的所开发的测试用例会被收入用例库得到后续项目的沿用的话，同时也是一种经验的总结，是知识的积累。
某些项目的测试活动，只是调用用例库通用用例，不存在在这个项目里面对测试用例再开发，这种用例本身，应该看作就是一个工具，跟测试仪器没有区别。执行用例的结果，是设计验证的结果。测试报告，反映了产品的具体指标和性能，承载了输出信息。 kingrobin 发表于 2017-4-25 00:55
设计开发输入难道就不是某个阶段的结果？
以ICT行业推崇的IPD并行开发模式来说，第一个阶段叫概念阶段 ...
输入当然可以评审，只是标准不提这个要求，但这个评审的依据和目的与那个评审的依据可是不同的，那个评审的依据是包含输入确定的要求的，通俗的讲就是设计出来的是不是想要的那个东东，还有那些需要改进的。这个依据和目的和输入评审一样吗，依据都不同，怎么会是一回事？ 牛角尖 发表于 2017-4-25 12:03
输入当然可以评审，只是标准不提这个要求，但这个评审的依据和目的与那个评审的依据可是不同的，那个评审 ...
你的眼里还有没有 “8.3.4 设计和开发控制” 这个条款的要求？
再问你个问题：按照新版标准，设计开发的输出在放行前还要不要批准？
页:
[1]
2