研发部管理制度汇编(网)(共33页).doc

精选优质文档-倾情为你奉上版/次：A/ 0研发部管理制度汇编编 制：审 核：批 准：分发号：北京XX开发公司2012年5月专心-专注-专业目 录第一章 项目管理制度1、 目的：为规范项目研发、加强项目管理，公司根据企业实际情况和研发产品的特点，特制订项目管理制度，望研发部门遵照执行。2、 范围：适用于对本企业研发部项目研发的管理。3、 职责：3.1 研发部工程师负责对相应模块进行设计开发。3.2 研发部技术主管负责对公司研发过程技术方向监控与技术支持。3.3 研发部行政主管负责对公司研发人员行政方向监控与人事工作。4、 程序：4.1 项目流程概述项目流程项目研发须经过立项、设计、实现和测试等几个阶段。 项目立项项目评审项目设计制作项目实现项目实际测试项目调整项目交付项目生成交付物归档管理4.2 立项1) 针对研发项目，首先要起草项目立项报告。2) 针对已经签定销售合同的项目发生的研发，作为合同项目研发，不再单独立项。3) 项目只有立项后才允许进行进度研发。4) 项目立项后应获得一个唯一的研发编号，费用报销、研发领料领用等，都使用此编号作为物 流控制和财务核算的依据。5) 项目计划报告必须具有项目名称、立项目的、编制、审核、项目周期、预计达到参数指标以及该项目特设指标或者关键技术等相关内容。4.3 设计1) 立项后，项目进入设计阶段。2) 设计阶段由设计承担人完成技术设计报告和测试计划报告，以作成项目计划报告。3) 技术设计报告应说明项目名称、研发系统或设备的需求、总体功能、模块划分等。4) 测试计划报告应说明项目名称、产品功能、测试项目、测试条件、测试方法、测试工期和时间计划等内容。5) 项目负责人应邀请研发部门和公司其他部门相关人员，对设计报告和测试计划报告进行评审。6) 针对没有通过设计评审的项目，须进行重新设计，再组织有关评审。4.4 实现1) 设计评审通过后，进入项目实现阶段。2) 研发人员必须在实现过程中书写相关文档，文档必须有电子形式。软件实现文档应包括软件功能性说明文档和源代码说明文档。硬件实现文档包括电器原理图及结构示意图。3) 项目负责人有责任按照项目计划报告，跟踪监督项目的进展情况，按时敦促验收阶段性成果。4) 研发产品由研发人员自行调试，调试过程中必须撰写调试记录。调试记录应该说明项目名称，编号，调试记录版本号，调试时间，软硬件版本号，调试中发现的主要问题，调试环境，解决方法等有关内容。5) 研发产品确认运行稳定后，由项目负责人组织内部验收。研发文档应视为研发实现阶段工作量的一部分，不具备研发文档将视为工作没有结束，不组织内部验收。6) 软件功能性说明文档应说明项目名称，编号，软件名称和编号，软件功能，软件功能模块划分，主要功能实现过程，软件主要实现算法。7) 源代码说明文档项目编号，软件名称，软件功能等。源代码说明文档可以包含在源代码文件中，以注释形式存在。4.5 测试1) 研发产品经内部验收后，进入测试阶段。2) 测试阶段开始后，研发实现人员将研发的产品，以及研发调试记录移交给测试人员。测试人员按照产品的测试计划报告、研发调试记录，设计测试过程，填写产品测试报告。3) 产品测试报告应该说明项目名称，编号，测试报告版本号，需测试功能，指标，测试方法，测试环境，测试条目，测试结果，结论等。4) 如果研发产品不能通过测试，测试人员应把产品测试报告提交给产品实现人员。产品实现人员修改软硬件后重新进行调试，相应更新研发调试记录内容和版本号，确认产品合格后提交 测试人员再次检测。如此反复，直到产品通过测试为止。5) 测试人员确认产品达到要求，在产品测试报告的结论栏内签字表示同意，交项目负责人。4.6 产品发布1) 项目负责人拿到产品测试通过的报告后，填写或者委托他人填写产品发布公告和产品发布计划，交公司技术负责人或者授权产品发布人核准，签字发布。项目负责人与签字发布产品的不得为同一人。发布公告和产品发布计划需送市场部、生产部和公司有关领导。2) 项目负责人必须在产品发布后一周内，将所有研发文档整理存档。3) 产品发布计划应说明项目名称、编号、产品名称、型号、版本号、产品说明书的完成时间和计划。产品说明书的完成时间一般应在产品完成后5个工作日内完成。4.7 生产1) 产品发布后，进入正式生产阶段。2) 生产阶段须具备总装图、电器原理图和性能参数要求。3) 装配图应说明产品名称、型号结构件的固定位置、装配顺序、电气连接图、走线固定位置等。4) 生产测试要求文档需要说明针对的产品名称，型号、测试环境和测试方法。4.8 项目调整1) 设计更改l 由于市场或技术原因，需要对项目重新进行设计时，更改人员需填写设计更改申请单，按照立项程序进行审批。需经公司技术负责人签字同意，报公司总经理批准生效。l 对已经发布的产品进行更改，被认为是一个新的研发项目，按照标准程序执行。l 对尚未发布的产品进行更改，需要更新该项目所有此前产生过的技术文档，已经进行过的评审必须重新进行。2) 项目取消l 出于市场或其他方面的考虑，需要取消某个项目的研发，必须由发起人或者委托人填写项目取消申请表，申请表必须说明项目名称，编号，取消原因。l 研发项目的取消需经公司技术负责人签字同意，报公司总经理批准生效。l 项目取消后，研发助理负责将项目取消通知发送给公司领导层和研发、销售、生产、财务等 相关部门。3) 项目暂停l 出于市场或资源饱和原因，需要暂停某个项目的研发，必须由发起人或者委托人填写项目暂停申请表。l 申请表必须说明项目名称，编号，取消原因。研发项目的暂停需经公司技术负责人签字同意，报公司总经理批准生效。l 项目暂停后，研发助理负责将项目暂停通知发送给公司领导层和研发、销售、生产、财务等相关部门。5、 质量记录：第二章 研发部绩效管理制度1、 目的：通过考核评定实行相应的绩效处罚，并不断的发现管理的工作不足之处，调整全公司的工作方向和管理目标。原则：以奖为主，以罚为辅，重奖轻罚，奖罚分明。2、 范围：适用于对本企业研发部人员绩效方面的管理。3、 职责：3.1 研发部行政主管负责制定研发部人员绩效考核指标的修改和建立。3.2 研发部员工应遵循此制度条款配合公司绩效考核工作。3.3 办公室应配合研发部做好绩效考核相应工作并对考核结果进行整理归档。4、 程序：4.1 宗旨考核制度贯彻于研发工作全过程中，利用绩效和奖金相结合的报酬机制，鼓励积极，鞭策落后，提高产品开发效率和合格率，减少失误，降低开发成本，增加公司产品的市场竞争力，同时调动每位研发人员的工作积极性，努力提高工作水平，统一员工的工作努力方向，推动公司的持续快速发展。4.2 基本原则1) 结果考核与行为考核相结合2) 考核者必须依据员工实际表现和工作事实进行评价。3) 公司成立技术开发评审小组，小组成员由总经理任命。4) 考核必须公开考核流程、公开考核指标，坚持公正、公平、公开的原则，考核结果由考核双方共同签字确认。5) 考核执行人必须充公了解员工在考核期内的工作内容、工作过程和工作效果。在双方平等沟通的基础上展开考核工作。4.3 细则1) 按照各人负责的工作类别不同，考核类别分为“优秀、良好、合格、不合格”。2) 电路设计：视产品复杂性及任务的完成情况，以绩效考核表为准。3) 结构设计：视产品复杂性及任务的完成情况，以绩效考核表为准。4) 硬件设计：视产品复杂性及任务的完成情况，以绩效考核表为准。5) 软件设计：视产品复杂性及任务的完成情况，以绩效考核表为准。6) 文秘及后勤：及时、准确、妥善的将设计师的文件归档、分发、收取，对需要打样的产品落实追踪到位，准时是考核的主要条件。4.4 考核对象1) 试用期及实习期员工不参与此项考核2) 已转正的员工则根据工作情况，分为非技术类及技术类进行考核。3) 部门经理级人员（含部门副经理）不参加此项考核，由公司统一进行部门经理综合考核评定。4.5 考核周期与时间1) 实行半年度考核；每半年考核一次。其中每年的6月份考核上半年的业绩，每年12月份考核下半年的业绩。2) 考核正式开始前十日部门开始进行考核，两个工作日提交办公室汇总呈评审小组最后得分，三个工作日评审小组出具考核结果，由办公室下达考核结果给部门经理，五个工作日内完成绩效面谈。4.6 实施1) 考核的依据：设计计划书中的进度规定和设计要求。2) 考核方法：综合评分，按照公司绩效考核表中内容进行考核。3) 评分标准：分为自评和上级领导评价，根据分值加权求得最终分数对应相应等级。4) 每次考核完成汇总员工评分并分出等级，并根据公司相应规定进行鼓励与批评谈话。5) 公司设置独立员工工资体系外的考核资金，每季度得分超过100%的员工，每增加1%奖励基本工资的10%，最高不超过其基本工资的200%。有特殊贡献的员工，公司予以奖励，由董事会审批。6) 绩效考核流程图：考核前期准备7)制定考核计划考核执行考核考核评价考核反馈（申诉、面谈、调查表）绩效的更新和修改资料的归档整理4.7 考核体制考核对象初评汇总部门复评最终核定技术人员研发部门办公室评审小组副总经理部门职员研发部门办公室/副总经理1) 由员工填写本季度主要工作项目及业绩，给考核者相应参考数据。2) 部门评定：由员工直属上级对员工个人本季度各考核项目做出综合评分。3) 评审小组对其考核的结果做复评。4) 副总经理进行最终评定。4.8 绩效沟通与改进1) 每考核完成一次部门经理至少需和员工进行一次绩效面谈，共同确定绩效计划，讲解员工优势和需要改进的绩效，共同分析与实际结果存在差距的原因，达到组织绩效与个人绩效目标一致。2) 各部门可根据工作需要增加面谈次数。3) 面谈方式为：以正式的、一对一、面对面的方式进行。4) 每次考核完成要进行绩效考核情况调查，分发调查表进行无记名调查，针对提出的问题进行改进。4.9 考核申诉考核申诉是为了使考核制度完善化和在考核过程中真正做到公开、公正、合理而设定的特殊程序。1) 参加考核的任何员工对评估结果拥有申诉的权利，部属与直接主管接到考核内容和结果后，如有异议，可先向直接主管提出申诉，由直接主管进行协调；如直接主管协调后仍有异议，可向办公室提出申诉，由办公室进行调查协调。2) 考核申诉的追诉时限至考核当月结束为止。4.10 评估资料的保管1) 各部门部门经理指定专人对员工所有的评估资料进行集中保管，考核表必须以电子文档形式及书面形式各保留一份，电子文档由部门及办公室各留存一份，书面文档由办公室作为人事档案留存。2) 季度评估表作为员工的人事档案由行政部统一保管。3) 除管理人员因工作需要可查看员工的评估资料外，其他员工不得随意翻看、查阅。4) 任何接触到考核资料的人员都有保密的义务，不得散布、传播。4.11 附则1) 本制度由公司管理部门负责修订而成，解释权归办公室。2) 整体考核进程由办公室负责推动，各相关部门协助完成。3) 本制度是公司绩效考核的重要制度，每一位员工均可对其不完善之处向办公室直接提出相关建议，被采纳的建议将在制度中及时修订。4) 本制度执行后，与本制度有抵触的规定或条款以本制度为准。5、 质量记录：绩效考核培训资料、绩效考核计划、绩效考核表、绩效考核调查表第三章 SQA工作流程1、 目的：为加强项目监控体质管理，监督研发过程，对项目研发进度进行全程质量监控。2、 范围：适用于研发部项目过程的监控管理。3、 职责：3.1 SQA项目小组成员按分工监控项目过程并及时上报质量情况。3.2 项目组长成员应配合SQA的检查和监督。4、 程序：4.1 目标：Ø 遵循软件质量保证计划进行软件质量保证活动Ø 客观地验证软件开发过程和软件产品是否遵守可用的标准、规程和要求Ø 确保将软件质量保证的活动和结果通知受影响的项目组和人员Ø 高层管理者关注在软件项目中不能解决的偏差事件和不合格项4.2 SQA活动的策略当SQA刚切入项目组时，SQA首先就要掌握项目组的一些基本情况，主要包括项目经理的能力,项目的规模，项目工期，客户对进度、质量的要求，项目组成员情况，项目组织架构情况。其中最关键的是要看项目经理的能力情况。）PM能力欠佳，则SQA的工作就是全程跟踪项目，审计是重中之重。）项目经理的能力强，则SQA的主要工作可以划分为两部分，一部分是对一些重点的过程和产品进行审计，另一部分是优化我们的过程，流程，对我们的发现的一些问题或缺陷进行分析，改进我们的过程。4.3 具体活动：1) SQA参与制定计划SQA参与制定计划包括SDP和阶段计划，在SDP活动中，SQA主要是参与到软件过程的剪裁、复审估算、参与评估风险等。然后，SQA参与复审SDP，其目的，除了熟悉项目的计划外，还需要复审看是否SDP与纳入项目的客户的需求一致，计划能否满足客户的需求的，在SDP修正中，涉及到上述内容的，也需要SQA参与。然后，SQA也会参与阶段计划的制定，主要是复审阶段计划是否满足阶段的目标。2) SQA参与复审纳入项目的需求此时SQA主要是作为复审者的角色，复审纳入的需求描述是否清晰、一致、需求的可行性等。3) SQA制定SQA审计计划在制定计划的同时，SQA也需要制定SQA审计计划，在制定SDP的时候，SQA制高层的审计计划，主要是计划有那些内容需要SQA审计的。然后，在制定阶段计划的时候，SQA需要制定具体的审计计划，包括每次审计的时间，审计的对象等。4) SQA参与进度复审或里程碑复审活动SQA在参与进度复审或里程碑复审活动中，主要是一方面了解项目的进度，另一方面，复审项目在进度复审中采取的一些修正行动的时候，是否满足客户的需求，是否可行等，而在里程碑复审中，则复审项目当前的状态是否满足里程碑的标准(Criteria of Milestone)，是否达到里程碑的目标。5) SQA审计另外，SQA的主要活动是按照制定的SQA审计计划对项目进行审计，审计的内容包括过程审计和工作产品审计。过程审计主要是审计项目开展的软件活动是否和计划、与OSSP一致，工作产品审计主要是审计工作产品是否满足标准和约束条件。6) SQA阶段总结由于公司很多项目都是采用迭代模式的开发，项目开发周期较长，所以有必要在项目某个阶段结束的时候，对SQA在这个阶段的活动进行一个总结，主要是对一些经验教训进行分析，找出这些问题背后的原因，提出一些可行性的解决方案，目的是为了提高质量保证的水平。7) 跟踪问题处理SQA应跟踪问题处理过程，直到问题解决。跟踪的问题包括日常发现的产品问题、过程问题、项目风险、评审发现的问题、测试发现的问题等。如果不能和项目组就解决方案达成一致，可向公司高层反映。8) 度量和报告SQA应善于根据过程规范和经验发现项目运行中的问题，并做到紧急问题、重要问题随时汇报，其它问题周期性汇报。SQA需要随时收集数据并保障数据的有效性、真实性。定期汇总数据、统计分析并产生度量报告。SQA应协助项目组和SEPG针对不良趋势和问题采取纠正或预防措施。9) 质量推进质量推进主要包括提高全员的质量意识和推进、解释过程的执行两个方面。这项工作需要在日常工作中一点一点地、坚持不懈地实施,这样做的目的是为了营造公司的一种质量文化氛围,理解和支持SQA的工作。10) 过程制定如果项目或组织需要制定过程规范，SQA应组织相关人员来完成过程制定工作。一般情况下，过程制定应由遵守和执行该过程的人员负责。所有制定的过程都必须经过评审，并由SQA检查执行情况。11) 过程改进过程改进是一项长期的任务。SQA应注意随时发现、听取过程执行中问题和改进工作的方法，并进行阶段性的总结（比如质量报告等），以不断改进过程，提高过程能力。12) 学习和研究SQA要不断学习和研究，尽量保持与领域最新的知识、方法同步，找出提高产品质量和工作效率的方法与过程。学习的内容主要包括管理领域和开发领域。管理领域包括质量管理（TQM、ISO9000、CMM、RUP、MSF、XP等）、软件度量（PSM、GQM、SPC、SixSigma）、项目管理、配置管理等。开发领域包括需求工程、设计、编码、测试等各阶段的开发和管理方法。13) 质量培训项目或组织需要时，SQA需要向相关人员进行质量管理方面的培训或咨询4.4 SQA审计工作指南：SQA工作的很重要一项就是审计，SQA审计工作的目标是验证项目组实际执行是否与项目计划相符合，执行的步骤是否与公司规定相符合，及时发现项目存在的问题，并提交问题报告，跟踪直至问题得到解决。4.4.1 SQA审计工作的各个阶段：可以将SQA审计划分为各个阶段：1) 审计任务计划阶段：审计任务的计划是SQA计划中的一部分，应该根据每个项目的特点进行不同的考虑，以安排审计任务。主要的依据有几点：根据项目的风险安排审计任务的重点，根据项目计划的进度安排组织审计任务的时间，根据审计对象的不同考虑审计方法；2) 审计任务执行阶段：审计任务应该按照SQA计划来执行，并根据审计对象的不同采取对应的审计方法；因为实际的审计的执行需要兼顾项目的实际情况（包括人员、进度），因此要做好SQA审计状态的记录，及时跟踪审计任务的执行情况，出现审计任务与SQA计划的出入时，应该进行计划变更；3) 审计问题的提出阶段：在审计中发现问题时，应该首先与项目相关的工作人员沟通，明确问题，同时记录SQA问题清单，并知会项目PM；问题应该得到项目组的认同，问题说明应该清晰，当问题不能够明确时（不能认同、确定），需要报请SEPG或者高层经理确认。发现的问题一般应该得到及时的处理，当问题不能及时解决时，应该提交SQA的问题报告，问题报告中需要明确问题的责任人，以及计划解决时间；4) 审计问题跟踪阶段：对SQA提交的问题，需要对其状态进行跟踪，保证问题能够得到解决，对于解决时间超出计划时间的问题，应该在每周的报告中提交给高层经理。4.4.2 SQA审计方法：审计方法根据审计对象的不同，可以分为：项目活动审计，和项目产品审计。1) 项目活动审计是根据项目计划，到达对应的项目活动执行时，SQA人员切入到项目中，通过与项目组沟通，了解项目活动的执行情况。具体的了解方式可以有多种，如：与项目组直接的沟通、通过活动的记录文档了解活动的进展、直接参与项目组的活动等；方法的选择取决于活动的类型以及项目的具体情况，采用什么方式以达到了解项目活动实际情况为目标。2) 项目产品审计，主要是对项目的工作产品进行审计，项目的工作产品是否合格包括两个方面：1、满足客户以及公司对产品的要求，一般要求符合工作产品的模板、标准，其中客户的要求一般都会明确在项目纳入的需求和相关的计划中；2、项目产品的合格也是由流程来保证的，产品的开发过程应该按照计划得到了必要的复审和评审。审计产品的时机一般是在产品提交后进行，但是SQA也应该根据工作产品的特点，注意安排产品制定、开发当中的审计，以期及早发现问题。4.5 报告机制1) 周报：把一周来SQA活动发现的问题进行汇总并加以简要的分析，发送高层、项目组有关负责人、质量部负责人、SEPG2) 上报项目经理：对一些比较紧急的问题应立即报告给PM，如果能达到一致的情况下,要求落实问题的解决,3) 上报高层：如果发现了问题，不能与pm达到一致的话，上报高层4.6 参与的其它活动Ø 了解项目成员每天的工作情况Ø 促进项目关系人员之间的沟通Ø 参与风险的识别，跟踪管理Ø 量化工作4.7 SQA工作流程图参与项目制定项目计划划准备检查表预约审计开展SQA活动编制审计报告是否有不符合性问题是否月底SQA工作提交配置管理人员是否项目结束END通知单完成的工作追踪不符合性问题编写SQA月状态报告制作修改SQA计划YesYesYesYesNoNoNo5、 质量记录：SQA计划、审计报告、状态报告第四章 项目评审制度1、 目的：主要是尽早发现潜在的问题，尽早纠正缺陷，控制项目整体进程。2、 范围：适用于研发部项目评审工作。3、 职责：3.1 项目组长协助评审人员进行项目评审工作，并提交评审计划。3.2 评审人员针对项目进行系统评审并撰写评审报告。3.3 评审人员应对评审完成发现的问题进行后续跟踪处理。4、 程序：4.1 评审角色构成因素评审人员的选择是评审效果的关键，需要考虑以下因素： Ø 项目重要性：项目重要性是决定角色构成的最重要的因素，先要根据项目的重要性而定。这与需要投入的成本有关，对于重要的项目一般会更多地投入资源，提高评审级别。 Ø 项目复杂度：项目的复杂度也是决定角色构成的因素之一，根据温伯格的公式，项目管理的复杂度相当于功能规模的平方数。笔者认为还应该考虑技术复杂度、技术新鲜度和文档复杂度等因素。项目组成员的能力成分和水平。Ø 项目组成员的能力成分和水平：评审角色构成还应当根据项目团队成员本身的各项技术水平，特别是分析和设计的技术水平如何，行业领域知识是否丰富来进行搭配。除了团队内部自己进行评审之外，评审团队最好是一些独立于项目团队之外的成员构成。 应当注意的原则是人数要少而精，一个人可以兼多个角色，但要覆盖各项人员需求。需要说明的是，不具备评审能力的不应参加，可以通过旁听来提高水平。 4.2 基本角色职责Ø 评审组长：制定评审计划、确定或制定各项评审准则、必要时组织评审人员进行培训、组织必要的资源、进行评审分工、确保正式评审准备充分、分发待评审文档、必要时召开并主持评审会议、向有关领导报告评审结果，并且跟踪评审错误的改正。 Ø 评审人员：必要时参加与评审有关的培训、按评审计划阅读待评审材料、保证对待评审材料的理解、与待评审材料作者讨论，并且指出和记录问题。 Ø 文档作者：按评审计划准备并按时提交待评审材料、必要时对材料进行解释、必要时参加评审会议，并且在确定需要改进时按时完成修改。 Ø 记录人员：评审会议中记录评审人员提出的问题及相关讨论。 Ø 项目经理：制定保证评审和改正的项目进度计划，还要确保评审准备时间、评审会议时间及错误的改正时间。而且评审安排及结果与所有项目成员沟通，必要时参加评审会议、阅读评审报告、分析缺陷原因，并且改进项目质量。 4.3 文档评审的层次Ø 过程规范：是否符合过程规范、是否按照计划提交、是否按时经过评审、是否准时发布（注意提交时间与发布时间的区别），以及评审的流程是否规范。适合的评审人员：QA。 Ø 文档规范：文档成果符合企业或业界已经制定的文档模板规范。企业，甚至行业应当制定统一的文档规范，形成一个文档约定和规则，以统一文档内容与风格。适合的评审人员：QA。 Ø 文档语法：文档成果正确使用通用的方法与术语并符合软件工程相关的技术标准，这里所说的语法包括自然语言的语法和建模语言的语法。适合的评审人员要求：精通软件工程、分析与设计方法、建模工具和相关标准。 Ø 文档语义：文档成果表达清晰、无歧义，可以反映系统目标。所有质量合格的文档 （包括模型）都代表它期望代表的语义，而且应该在代表这些语义时具有一致性。文字与图表应当互相补充说明，以更加清晰。让别人看得懂，看完后知道下一步该 怎么做。 适合的评审人员：行业业务专家、高级程序员和测试工程师。 Ø 文档逻辑：主要体现需求与设计正确性、一致性，无遗漏、多余或错误。前后左右 考虑周全，不同文档之间、文档与行业标准之间、同一文档各成分之间不互相矛盾，清晰说明相关部分之间的关系，特别是要符合相关行业的业务标准规范。 适合的评审人员：行业业务专家、产品经理和测试工程师。 Ø 文档美学：文档成果能否表述得更好一些，文字、图表是否能更加均衡和完整。 需要追求平衡的美，每个组成部分应该大小适中，可解读并可变更。平衡有多个方 面，如排版次序更加合理、文字、图形更加精炼并更易理解等。适合的评审人员：系统分析与设计专家，以及建模工具专家。 Ø 结果优化：通过检查判断文档成果（如项目计划、需求规格及设计方案）是否还有改进的空间，以便更加方便地进行项目管理、降低成本、加快进度、提高质量并减少风险，尽可能达到最佳方案。任何一项设计都可以有许多不同的方案，通过“方案优化”选定一种最好的方案。 适合的评审人员：系统分析与设计专家、项目经理和产品经理。 4.4 文档评审流程 4.4.1 评审流程概览和流程图确定评审组长。 制定并发布评审计划。准备评审。 举行评审会议。 改正、跟踪和回归评审。 分析、总结和报告。 归档。 4.4.2 确定评审组长由品质保证人员与项目经理、部门经理论协商，确定项目的评审级别及评审人员角色构成要求，初步确定评审组长人选。品质保证人员与评审组长沟通，最终确定评审组长。评审组长充分了解项目相关情况，为制定评审计划做好准备。 4.4.3 评审计划 评审组长制定评审计划（根据项目计划和质量计划） 。 评审组长确定评审对象和评审时间。 评审组长确定评审级别和策略（形式的组合）。 评审组长确定评审流程裁减和提交物。 评审组长确定入口条件并通过准则。 评审组长确定回归评审准则。 评审组长制定评审检查表（CheckList）。 评审组长确定评审角色构成。 评审组长根据评审角色构成确定评审人员并成立评审小组。 相关人员（评审人员和项目团队双方）确认评审计划。评审组长发布评审计划。 4.4.4 评审准备 正式评审前准备：文档作者向相关人员发布文档。 评审人员阅读了解文档，争取发现大部分问题。 文档作者解决大部分发现的问题。 评审组长确定会议地点、环境、设备和所有材料。 评审组长确定人员职责和会议议程。 评审组长确定评审开始条件成熟。 评审组长通知相关人员到会。 4.4.5 评审会议 主持人（评审组长）宣布会议议程、人员职责和会场纪律。 文档作者介绍工作成果，对评审人员的疑问进行必要的解释。 评审人员对不解之处提出疑问，指出问题或缺陷并说明根据。 文档作者与评审人员讨论缺陷的真实性，分清缺陷性问题和建议性问题，讨论确定是否需要按照评审人员的要求进行改进。一般不涉及为节省时间改进方案或错误的纠正方案。 4.4.6 评审记录 正式评审应当记录有共识的问题或缺陷，也要记录有争议待解决的问题。使评审工 作文档化，便于跟踪最终解决。 总体记录：包括项目名称、系统名称版本号、 日期时间、 主文档名称、附文档名称、 文档版本号、作者、评审类型（首次、回归、部分和阶段） 、评审人员和评审结论。 缺陷记录：包括缺陷编号、提出者、章节页码、缺陷描述、缺陷类型（严重、一 般和建议）和承诺改正时间。 验证记录：全部打勾的 CheckList，说明 CheckList 所列的工作都已经做完，所列的内容都已经评审完，确保工作的完整性。 4.4.7 评审结论评审结论包括如下内容： 是否需要修改？这是就成果的整体而言，结论可以是无需、少量、较大或是一个量化的数字。 项目组确定是否接受修改要求？这是针对具体的一条意见或建议。有些问题可能是 误会，消除了就不是问题；有些建议性的问题，项目组考虑进度可不接受修改要求。 如不接受修改要求，项目组给出不修改的理由。 如何处理？是否需要进行回归评审？ 总体结论：合格或不合格。 确定的修改责任人和跟踪责任人。 确定的回归评审时间。 是否都认同评审结论？如果需要做得更正式一些，可以要求相关人员签字表示同意评审结论，签字 。4.4.8 跟踪与总结评审中发现的问题的后续跟踪是改正错误并消除缺陷的有效措施， 应当有专门的负责人进行后续跟踪确认错误都已改正，根据结论必要时回归评审。 评审组长分析评审数据并总结经验。 评审组长发布评审记录与数据分析报告。 管理人员应当防止评审数据被不恰当地使用，如果使用评审数据来对个人进行绩效 评价，将会给以后的评审工作造成障碍，使评审各方不能放开进行评审。 评审组长进行工作总结，工作总结很有必要，有利于对项目或过程的改进。 评审组长提交各类评审报告，有关领导批准发布通过的文档。 4.4.9 材料归档评审材料归档是项目配置管理工作的一部分。新建项目，记载配置管理工具中为此项目 建立一个目录，并建立下列子目录。 待评阅态：文件放入此目录后会自动通过邮件通知需要评阅的人员，全体评阅人员评阅完毕，也会自动通过邮件把意见通知文档作者并实现到期自动提醒功能。 待评审态：文件放入此目录后会自动通过邮件通知需要评审的人员，全体评阅人员评审完毕，也会自动通过邮件把批准或拒绝的意见通知文档作者并实现到期自动提醒功能。 受控态：评审批准后自动转入受控态并发布自动邮件。 签出态：为了修改而版本升级，当文件签出时放入签出态。修改后的文档可能签入到待评阅态、待评审态或直接到受控态，但文档版本已经升级。 产品态：项目结束后受控态的文档自动归到产品态。5、 质量记录：评审计划、评审报告第五章 项目交付物管理制度1、 目的：为规范本公司研发部技术文件的管理，确保文件编制的正确性、完整性，特制订本制度。2、 范围：适用于公司研发部门项目完成后的交付物的管理。3、 职责：3.1 项目组长及成员应对所研发项目的交付物列清单逐一交付。3.2 办公室为研发部技术文件设立档案保管，借阅情况统一进行统计。4、 程序：4.1 技术文件的编制、审核、批准 1) 技术文件包括：a) 产品设计图纸；b) 作业指导书；c) 设计相关书籍、光盘等；d) 技术档案和技术资料；e) 未打印出图的尚在计算机里的图纸资料；f) 发放到各部门的技术文件；g) 实物样品等研发部相关文件。2) 技术文件的技术要求和数据等必须符合国家相关标准和规定要求。3) 技术文件由技术开发部等相对应部门编制，研发部应对技术文件的准确性、合理性负责。4) 研发部部长负责技术文件的审核。5) 总经理负责技术文件的批准。6) 技术文件的编制必须严格保密。7) 技术文件应保证标题栏中的编号、名称、日期、审核、批准等栏中签署齐全，签署不齐全的技术文件无效。4.2 技术文件的管理与应用1) 技术文件的发放：a. 技术文件在发放至生产车间之前，必须加盖“受控文件”章，到研发部处登记，填写【技术文件领返记录表】，签字领出。b. 技术文件的发放按生产计划进行，定期发放的生产用文件由研发部统一下发和更换。研发部门必须保证下发的工艺的完整性和有效性，同时保证下发到车间主任、生产指导、检验等部门的工艺应一致。2) 技术文件的保管和使用：a. 研发部的技术文件应长期并分类保存，管理要科学系统，能有效控制，确保各相关部门都能得到有效的版本，防止作废的技术文件误用。作废的技术文件必须经常研发部部门鉴定且研发部部长批准后销毁。b. 本公司的技术文件，由研发部管理。确保所保管的技术文件不受潮、不霉烂、不受损、不丢失。c. 纸质技术文件或光盘技术文件等收存到资料柜内保管，资料柜钥匙由研发部部长负责保管。本单位有关人员可以查、借阅。借阅技术文件应凭技术开发部部长批准的【借阅申请单】向研发部借阅。用完及时归还，并保证文件的完整性。d. 技术文件是公司进行生产和各项管理工作共同的技术依据，必须加强管理，各种技术文件的登记、保管、复制、收发、注销、归档和保密工作，保证技术文件的完整，准确清晰、统一等。e. 签字领出技术文件人应负责将领出的文件收回，交研发部部长存档。f. 每种技术文件，研发部应完成技术资料整理，并做备份、存档。g. 本厂所使用的研发部技术文件一律由研发部统一保管，统一建档并逐一登记。3) 技术文件的更改a. 产品投入生产时，技术科应及时提供相应的工艺作业指导书并确保无误。生产部如发现操作时，有不妥当的方面及时与技术科主管沟通解决。b. 下发后的技术文件如需更改，研发部需要下发文件更改申请单，各相关部门必须据通知单要求做相应更改。涉及安全性能的图纸更改后，须由研发部组织重新审核并备案。更换的技术文件要有标记，并要有记录。c. 技术文件修改前，负责修改部门要提出修改理由及具体内容，交研发部部长审批。d. 修改后的技术文件必须重新履行会审、会签及批准手续，填发文件更改申请单。4) 技术文件的保密a、 任何部门、个人不得擅自打印、复制公司技术文件，不得以电子文档等形式在网上传递或者用移动硬盘、U盘、软盘等拷贝出。因工作需要必须打印或复制时，经办人提出书面申请书，开发部部长签字批准后方可通过打印、复制、拷贝。b、 为了保证技术资料的保密性，除按正常程序办理外，任何人不得私自向外人转让和借出技术资料，一经发现要按公司所签署的保密协议给予严肃处理。c、 员工用于工作的计算机未经主管批准不得随意拆开，计算机硬盘中的资料属公司机密，硬盘不准任何人私自带出公司。若计算机出现故障，需研发部部长指定专业人送修，并保证硬盘中资料保密性。d、 技术科及其他使用、保管技术资料的部门或个人，应注意保密，严禁将技术资料带出公司，或提供给其他公司。5) 技术文件的销毁a、 由于新技术的日新月异，越积越多的技术文件会占据不必要的资源，故有的技术文件需要销毁和清除，对回收的技术文件由技术部门统一管理。b、 需要销毁的研发部技术文件，研发部部长会同有关技术人员一起仔细校对核实，然后将销毁理由与销毁文件清单上报研发部部长，由研发部部长签署“同意”后，方可销毁。c、 普通技术文件须保存3年以上，重要技术文件须保存5年以上，以方便以后的产品技术改造。因各种原因，导致某种产品不再生产，或产品改型，使原有技术资料报废，由研发部收回，加盖“报废”章，并专项保管。5、 质量记录：交付物清单第六章 项目验收流程1、 目的：为规范公司项目验收工作流程。2、 范围：适用于公司验收项目管理。3、 职责：3.1