关于软件开发
哪位老师有软件开发的iso9001质量手册和程序文件 33类是我的专业，以我审核过的大多数软件企业来看，至少一半以上的企业的咨询顾问根本不了解软件行业的特点，生搬硬套制造业手册和文件的情况严重Jane，请问你是自己企业需要还是做顾问用？ 在百度文库上看到过一些关于软件行业的手册和程序，但正如楼上所说，可能是生搬硬套了制造业手册和文件，感觉比较肤浅，没说出什么实质性内容。 现在多数企业的手册没有实用的价值 kingrobin 发表于 2012-11-3 21:24 static/image/common/back.gif
33类是我的专业，以我审核过的大多数软件企业来看，至少一半以上的企业的咨询顾问根本不了解软件行业的特点 ...
生般硬套是现在的通病，原因不光是在咨询老师，有时企业只是为了要个证书，根本不配合咨询人员，那么怎样写出符合企业实际情况和有效的文件呢！
对于这样的问题就需要有经验和能力的审核老师去审核
其实这也是最锻炼审核人员的环境之一吧 lfradio 发表于 2012-11-4 06:53 static/image/common/back.gif
生般硬套是现在的通病，原因不光是在咨询老师，有时企业只是为了要个证书，根本不配合咨询人员，那么怎样 ...
我们总是习惯为自己找各种各样的借口
不是吗？ 既然是软件开发企业，重点就是在7.3，一般7.3也就是7.5.1，当然，如果有去客户现场实施的情况，即项目式的开发，7.5.1的内容还需要更多现场控制要求。
关于7.3.*各阶段的策划和控制，不建议按7.3.1到7.3.7安上对应的一个表格，如设计开发评审表、确认表、验证表.......
可以看一看GBT 8567-2006 ，虽然是文档编写规范，但是实际上已经归纳了该行业的一个通用特点。
下文对7.3.* 各个阶段可能对应的项目开发文档做一个归纳，未必准确，仅供参考
7.3.1 项目开发计划立项报告软件质量保证计划软件配置管理计划
7.3.2 需求说明书、可研报告、软件规格需求说明、软件接口需求说明
7.3.3 阶段性输出——概要设计说明、详细设计说明、软件设计说明、接口设计说明、数据库设计说明...... 最终输出——软件产品规格说明、软件版本说明、用户手册、操作手册、源代码、安装文件及其载体......
7.3.4项目周报、月报等各阶段评审记录，通常是会议纪要的形式
7.3.5软件测试计划、测试用例、测试报告（可能细分单元测试、结构测试、功能测试、集成测试、系统测试、回归性测试、用户体验测试等），以及软件产品登记所需的外部测试也属于7.3.5
7.3.6项目结项会议、项目总结报告、用户试用报告......
7.3.7设计变更需求/申请,企业一般会定义变更类型，复杂的变更可能依然走设计开发的完整流程，简单的变更走简易流程。涉及记录看企业是如何规定的
我经常遇到的情况是企业明明自己是大概能满足行业的一些规范要求的
咨询老师偏偏抛弃不用，来整什么验证表、评审表、确认表，填一些空洞虚无的内容上去
“同意”“OK”“批准” 理论联系实际，既符合标准要求，又能满足企业发展的需要的文件才是好的文件；但遗憾的是，通常的咨询都是给个模版，然后生搬硬套，搞得最后企业是没有办法执行。 本人是33类的见证审核员。所学专业计算机与通信，前期咨询主要为IT业，可为您提供帮助。坛里有我的拙文。可以借鉴。 kingrobin 发表于 2012-11-4 09:10 static/image/common/back.gif
我经常遇到的情况是企业明明自己是大概能满足行业的一些规范要求的
咨询老师偏偏抛弃不用，来整什么验证 ...
那是因为一类咨询人员对标准的理解问题，另一类就是审核老师喜欢那些表格。。。
现在很多企业的生产计划等都是老板按照组织管理方便原则去做，但是到了外审的时候，个别审核老师就说人家没这没那，按他的意思去补！
最后，等回访企业的时候，企业就把这些事情告诉咨询公司！现在大多数都是为了迎合那些需要各种表格的审核老师去做！要不为啥现在出现了很多不合理的删减情况发生。。。
有时候我不要去刻意责怪一些咨询人员，更多的也要在我们审核人员自身找问题！这样才对认证这个行业有推进性！否则审核说咨询，咨询反过来说审核，这样只能是双方对自己的侮辱！ lfradio 发表于 2012-11-4 14:22 static/image/common/back.gif
那是因为一类咨询人员对标准的理解问题，另一类就是审核老师喜欢那些表格。。。
现在很多企业的生产计 ...
这样的审核员，咨询老师又何必去迎合，那么说明还是为了通过评审的功利思想作怪
往往这样的审核员自己思路有问题，又没有人指出，只能在一条黑路上自以为是的越走越远！ kingrobin 发表于 2012-11-4 14:29 static/image/common/back.gif
这样的审核员，咨询老师又何必去迎合，那么说明还是为了通过评审的功利思想作怪
往往这样的审核员自己思 ...
从咱们的角度可以这样去说，但是站在那些咨询老师角度去看呢，要是不这样那他们靠什么吃饭呢！
这其实也就是为啥现在咨询质量严重下降，费用低的最主要原因之一。。。
要是大家都不去迎合这样的审核老师，那这样的审核“大户”还怎么在这队伍中混饭吃呀。。。
其实更可笑的还是您没遇到的呢，很多咨询老师不会做的，都提出删减！技术专家不懂第三方审核属于外审还是内审。。。
种种乱象，只能说明一件事，那就是我们自身出现了问题，需要服药，而不是外在的问题。。。当我们自身病都除去了，那这个病也就完全除去了。。。否则，永远都是病态的产物 kingrobin 发表于 2012-11-4 14:29 static/image/common/back.gif
这样的审核员，咨询老师又何必去迎合，那么说明还是为了通过评审的功利思想作怪
往往这样的审核员自己思 ...
提出也没用，人家根本不接受！不清楚是咱提的有问题，还是他们的理解比咱们高。。。没办法，所以只能黑下去，等啥时候遇到企业叫真的时候，这样的审核老师就知道是自身问题还是咨询老师真的如他们所说的差了。。。 lfradio 发表于 2012-11-4 14:47 static/image/common/back.gif
提出也没用，人家根本不接受！不清楚是咱提的有问题，还是他们的理解比咱们高。。。没办法，所以只能黑下 ...
不管是咨询老师还是审核老师，都一样的，都不缺和稀泥的角色
而且不和稀泥怎么办，在很多机构也是身不由己的和稀泥
较真，机构第一个不待见你，认为你没有能力去搞定局面，机构只关心企业能不能按时缴费，能及时交钱打款的企业就是好企业。
很多帖子都在把不同机构做比较，我觉得比较哪个机构最好或者最差都没意思，只看一点
审核员对于现场情况有没有决定权，有没有开主缺的权力，是评价机构的一个关键要素 rml 发表于 2012-11-5 12:29 static/image/common/back.gif
在一家某专业系统集成公司，技术部拿出了两个项目的“设计任务书”、“方案策划”、“软件设计计划”、“评 ...
Project也好，其他项目管理软件或系统也好，提供的是管理平台，还是应该有一些过程文档的，当然是指技术文档，而不是评审、验证、确认的记录
页:
[1]