立项评审检查表
立项评审检查表提示：由评委填写此表格，本表仅代表评委个人的意见。
3C汽车内审工厂审查检查表(精制研究)
参照优选# 1 3C 工厂检查的内审检查表 质保处 序号 标准条款号 质管QS 文件条款号 检查内容 检查记录 备注 1 1．1 质量处相关人员职责和相互关系 2 1．1 总检科职能描述是否齐全 3 1．1 管理科职能描述是否齐全 4 1．1 各类人员职责履行情况如何 5 1．2 抽查有关人员是否具备必要能力（总检、检验员） 6 2．2 是否制定了《文件和资料控制程序》、《认证标志管理规定》及《产品监督管理办法》？ 7 2．2 查阅程序文件，其内容是否覆盖了2。2 a ）~c ）规定 8 2．2 抽查质保处文件是否受控 9 2．3 查质量记录控制程序文件，是否对记录标识储存、保管、处理进行了规定，是否充分和适宜 10 2．4 抽查保存的质量记录及现场记录各三份，确认规定和实施的符合性；质量记录填写是否清晰、完整 11 3．1 是否制订了对供应商选择、评价和日常管理程序选择、评价准则和日常管理方法是否明确、适宜 12 3．1 是否按程序要求对供应商进行了选择、评定及是常 管理
参照优选# 2 内部质量体系审核检查表 质保处 SXD-Q –A 第 2 页共 4 页 序号 标准条款号 质管QS 文件条款号 检查内容 检查记录 备注 13 3．2 抽查、选择、评定的相关质量记录 14 3．2 是否制定了关键元器件和材料检测验证及定期确认检验程序，规定是否适宜 15 3．2 文件规定（合格检验规程）、抽查关键件（三份）检验记录确认其符合性和有效性 16 3．2 当由供应商进行检验时，是否对检验提出了明确的要求 17 3．2 关键件合格证明是否齐全、有效 18 5．1 是否制定了文件化例行检验和确认检验程序，规定是否适宜 19 5．2 是否按程序要求进行了例行检验和确认检验，现场抽查认证产品按规定要求进行例行检验和确认检验 20 5．3 抽查总检入库记录（3份）、认证产品确认检验记录是否符合规定要求 21 6 查阅有关检验和试验设备相关规定，确认其能否保证检验和试验设备满足检验试验能力要求 22 6 现场观察（审查）检验人员是否按操作规程使用仪器设备
ISO9000现场审核检查表
中质协质量保证中心（QAC）质量管理体系现场审核检查指导清单 项目编号： 受审核方名称： 审核人员： 审核组长： 审核日期：
使用说明 1.本检查指导清单按主要活动和过程编制，为现场审核提供指导。 2.使用本清单时，审核组应结合审核计划的分工情况和组织的实际活动和过程，选用不同的清单内容。 3.在现场审核时，请审核员结合本清单的要求，按过程方法进行审核。应关注PDCA循环在过程的应用，以及每一个过程的输入和输出情况、与其他过程之间的接口和相互关系。 例如：对7.4采购过程的审核，可从以下方面考虑： 一、策划阶段： 1.采购过程所要达到的目标是什么，目标制定是否合理？（5.4.1） 2.采购工作的流程（过程）是否明确，与其他过程（部门）之间的接口关系？（4.1、7.1） 3.是否规定了相应的职责权限，职责权限分配是否合理、充分？（5.5.1） 4.与接口过程（如设计过程、生产和服务提供过程）、部门之间通过什么方式进行沟通，信息传递是否及时、全面；部门内各岗位之间的信息沟 通是否及时、顺畅？（5.5.3） 5.对各岗位人员能力有哪些要求、人员能力要求是否适当？（ 6.2） 6.是否确定了相关的过程控制文件和记录要求，包括选择、评价和重新评价供方的准则等？（4.2.3、4.2.4）
二、实施阶段： 1.是否按要求选择、评价和重新评价供方，查证相关的评价和评价所引起的任何必要措施的记录。（7.4.1） 2.对供方及采购产品控制的类型和程度是否与其对最终产品的影响程度相适应？（7.4.1） 3.采购信息（文件、实物、图样等）能否清楚地表述拟采购的产品（如产品名称、规格、型号、数量等基本信息）？（7. 4.2） 4.当存在下述情况，是否在采购信息中考虑到标准7.4.2中a/b/c条款的要求？（7.4.2） a)当进货检验的手段不完善，无法检验进货产品的质量时； b)对最终产品影响比较大，只有规定了产品、程序、过程和设备批准的要求或人员资格的要求或质量管理体系的要求，才能确保所采购产品的质量保证要求时； 5.是否存在由于规定的采购要求不充分、不适宜造成的采购产品的不充分、不适宜？（7.4.2） 6.组织是否确定并实施进货检验及其他必要的活动，以满足采购要求？（ 7.4.3） 7.当组织和顾客有现场验证要求时，组织在采购信息中对验证的安排和产品放行的方式作出规定。（7.4.3） 三、检查阶段： 1.是否确定了相应的监视和测量方法，按要求对此过程的实施进行检查？查证相关的检查记录。（8. 2.3） 2.是否对检查结果或数据进行收集、统计和分析？查证本过程目标的实现程度。（8.4、5.4.1） 四、改进阶段：
ISO13485内审检查表完整各部门
内审检查表 审核员：第 1 页共 10 页 受审部门总经理管理者代表日期 审核内容审核方法记录标准条款评价 查看体系文件判别是否符合标准规定符合 1按要求建立文件化的质量管理体系。查，符合标准规定。 质量管 2质量管理体系覆盖的产品范围。4.1检查是否相符。覆盖的产品范围符合符合理体系总要求查，文件齐全符合检查是否齐全。3质量管理体系各层次的文件。
符合有没有删减部分，如有则记录4质量管理体系的删减。有删减合理 查文件目录判别各级文件是否齐全。公司应建立并保持的质量管理体系文件。1查，各级文件齐全符合抽查三份文 件是否相符 查目录，判别是否能满足生产经营的符合保存的医疗器械的法律、法规。文件 24.2.1满足生产经营的需求需求要求总则3对每一型号的医疗器械建立并保持一套技术文档抽查一套技术文档，检查是否正确、相关技术文件符合 齐全、清晰，符合生产要求。。 质量手册应包括以下内容：符合阐明企业质量管理体系 4.2.2质量检查质量手册，查有没有阐明企业质符合 1) 清楚的阐明企业质量管理体系覆盖的范围。含包范围，盖覆手册量管理体系覆盖范围，有无缺YY/T YY/T0287 专用要求内0287专用要求内容，有没有描述过程2) 应形成文件的程序或对其引用。符合容，有描述过程及其相及其相互作用。互作用。 3) 识别企业质量管理体系所需过程及过程之间符合的相互作用的表述。有质量方针总经理对其建立和改进质量管理体系的承诺。1 通过查质量记录，作出判断的证据。符合 5.1 2总经理将满足顾客要求和法律、法规要求的重要询问二个现场员工，作出判断明白满足顾客要求和法符合管理 承诺性传达给组织的成员。律、法规要求的重要性与领导层交谈，了解顾客要求和法律了解顾客要求和法律、 、法规传达情况以及顾客要求得到满法规传过情况以及顾客符合 1确保顾客的需求得到确定并予以满足。5.2 足的情况要求得到满足。 完全理解顾客和法律法以顾客为关 2应完全理解顾客和法律法规要求。抽查二份合同的执行情况。符合注焦点规的要求 1制定了质量方针,并已在相关层次中传达质量方检查有无质量方针，在办公室、生符合制定了质量方针5.3 针。产车间能否看到质量方针。 各层次人员对质量方针符合质量方针 2各层次人员对质量方针的理解程度询问二个员工。的理解1质量目标应与质量方针相一致，质量目标应是查目标与方针是否一致，查相关职查目标与方针一致 5.4 符合能部门有无自己的质量目标。可测量的，并应在相关职能和层次上展开。各职能部门对质量 目标抽查二个部门。各职能部门对质量目标的完成情况。 2策划符合的完成情况达标质量策划体现了质量管符合查质量策划文件。质量策划体现了质量管理体系的持续改进。3 理体系的持续改进符合1最高管理者应确保企业内的职责、权限得到规查组织机构图和部门职责、权限。最高管理者已规定企业内的职责、权限。定。符合 5.5职责、权限和2最高管理者应指定管理者代表并明确其职责和查管理者代表的任命书和职责、权最高管理者指定管理者 代表，明确其职责和权符合限。权限。沟通限． 内审检查表 审核员：第 2 页 共 10 页
技术评审TechnicalReviewTR
第16章技术评审 技术评审(Technical Review,TR)的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。 技术评审的过程是SPP模型的重要组成部分。本规范阐述了技术评审过程域的3个主要规程： ☆制定技术评审计划[SPP-PRO-TR-PLANNING]。 ☆正式技术评审[SPP-PROC-TR-FTR]。 ☆非正式技术评审[SPP-PROC-TRITR]。 上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。 本规范适用于国内IT企业的软件研发项目。建议拥护根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。 16.1 介绍 技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开放的最佳实践之一。 技术评审能够在任何开发阶段执行，它可以比测试更早地发现并消除工作成果中的缺陷。技术评审的主要好处有： ☆通过消除工作成果的缺陷而提高产品的质量。 ☆越早消除缺陷就越能降低开发成本。 ☆开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，在一定程度上提高了开发生产率。 可见技术评审有助于“提高质量、提高生产率、降低成本”，符合软件过程改进的根本目的。 技术评审有两种类型： ☆正式技术评审（FTR）。FTR比较严格，需要举行评审会议，参加评审会议的人员比较多。 ☆非正式技术评审（ITR）。ITR的形式比较灵活，通常在同伴之间展开，不必举行评审会议，评审人员比较少。 理论上讲，为了确保产品的质量，产品的所有工作成果都应当接受技术评审。现实中，为了节约时间，允许人们有选择地对工作成果进行技术评审。技术评审方式也视工作成果的重要性和复杂性而定。 技术评审过程域有3个主要规程：“制定技术评审计划”、“正式技术评审”和“非正式技术评审”。如图所示。 图16－1：技术评审过程域示意图 技术评审的注意事项： ☆评审人员的职责是发现工作成果中的缺陷，并帮助开发人员给出消除缺陷的办法，而不是替开发人员消除缺陷。
2019最新评审准则内部审核检查表
内审员：审核日期：表格受控编号条款号检查内容检查记录检查结论 4.1机构4.1.1 1.检验检测机构的法人登记、注册证书(营业执照)文件是否由相关行政主管部门核发，是否处于有效期内：资质认定证书所用名称、地址是否与法人登记、注册文件一致：登记、注册文件中的经营范围是否包含检验检测、检验检测或者相关表述，是否有影响其检验检测活动公正性的诸如生产、销售等经营项目。 2.非独立法人检验检测机构，其所在的法人单位是否是依法成立并能承担法律责任；该检验检测机构在其法人单位内是否有相对独立的运行机制是否能提供所在法人单位对检验检测机构独立运作和承担法律责任的法人授权文件；如果所在法人单位的法定代表人不担任检验检测机构管理层的，是否由法定代表人对检验检测机构管理层进行授权。 3.检验检测机构是否具备承担法律责任的能力，在发生检验检测结果出现错误和其他后果时，能承担起经济赔偿责任 4.1.2 1.检验检测机构的组织结构图是否清楚表明了其管理体系的职责和相互关系，非独立法人的检验检测机构是否通过组织结构图表明了与其他部门的关系，说明其独立运作。 2.检验检测机构是否配备包括人员、设施、设备、系统及支持服务等与其检验检测能力相适应的资源。 3.检验检测机构是否设置质量管理、技术管理和行政管理的部门或岗位，清楚表达了三者之间的关系。 质量管理要求是否融入技术运作中，是否能控制技术运作有效运行，行政管理是否能为技术运作提供支持和服务。管理体系文件是否覆盖了《检验检测机构资质认定能力评价检验检测机构通用要求》(RB/T214-2017)中质量管理、技术管理和行政管理的要求。 检验检测机构管理体系职责是否落实，质量管理、行政管理和技术管理之间关系是否明确，过程接口是否清晰，是否形成相互协调的系统的管理体系。
投标文件评审检查表
投标文件评审检查表 项目名称: 检查日期 序号评审内容评审方法确认备注一投标文件 1项目编号与名称□投标文件与招标文件项目编号、名称是否一致、正确、相符，标段是否清晰； 2投标人名称□投标人名称与营业执照、资质证书、银行资信证明等证明证书一致 3投标文件版式、 格式、文本格式 □投标文件版式、文本格式、字体、行数、图片是否模糊歪斜， 是否按招标文件要求格式编辑； □招标文件有版式、格式要求的部分是否采用要求版式、格式； 4投标文件目录□投标文件目录是否完整，页码是否更新 5投标文件的完整 性 □对照目录进行逐项检查 6投标内容□符合招标文件规定 7页码、页眉、页 脚、标题 □有无重页和缺页、页眉正确性； □检查页脚文字、页码连续性； □检查投标文件标题分配和组合条理性； 8报价□注意货币单位； □报价与组价文件的一致性、对应性；大小写是否一致； □只能有一个有效报价（按招标文件要去提交备选投标方案的除外）； □投标报价没有大于最高限价； □投标报价说明描述与组价文件的相适应； □若二次优惠报价或提交降价函是否按招标文件要求装订或单独递送。 □纸质版、电子版、上传应都一致，格式符合； 9商务造价（预算 书） □预算书符合招标文件“预算书”的范围、数量，符合清单/ 预算编制的要求。 □清单描述与招标文件的对应性； □计算规则和清单规则是否符合规范； □造价文件的完整性，排序是否符合汇总表； □报价表及造价文件涉及的表格文件是否按照招标文件规定 填写，编制人、审核人、投标人是否按规定签字盖章。 □是否有偏高、偏低现象，所用工、料、机单价是否合理、准 确，是否有偏离市场或招标文件明确要求的，以免产生不平衡 报价。 □所用工、料、机单价是否有偏离招标文件明确要求的规格、 型号、数量 □“投标报价汇总表”、“工程量清单”采用Excel表自动计 算，数量乘单价是否等于合价（合价按四舍五入规则取整）。 □合计项目单价保留两位小数，总价必须大小写齐全。 10资质文件检查□顺序及完整性检查、有无复印不清楚或歪斜，检查证明材料是否齐全； 11营业执照、资质、 安全生产许可 证、开户许可证、 认证证书等 □营业执照，且经营范围与招标项目一致，注册资金和资质符 合法律法规和招标文件要求； □安全生产许可证、三体系认证、计量合格证等是否齐全并满 足招标文件要求； □开户许可证信息是否正确；
java代码审查V1.0
一、概述 代码审查（Code Review）是消灭Bug最重要的方法之一，这些审查在大多数时候都特别奏效。由于代码审查本身所针对的对象，就是俯瞰整个代码在测试过程中的问题和Bug。并且，代码审查对消除一些特别细节的错误大有裨益，尤其是那些能够容易在阅读代码的时候发现的错误，这些错误往往不容易通过机器上的测试识别出来。 1.1主要工作 1、发现代码中的bug; 2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。 3、是否符合java开发规范和代码审核检查表 1.2 基本流程 1、代码编写者和代码审核者坐在一起，由代码编写者按照UC（Use Case）依次讲解自己负责的代码和相关逻辑，从表现层->持久层; 2、代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug;对这些bug记录在案。 3、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要一行一行静下心看。同时代码又要全面的看，以确保代码整体上设计优良。 4、代码审核者根据审核的结果编写“代码审核报告”，“审核报告”中记录发现的问题及修改建议，然后把“审核报告”发送给相关人员。 5、代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。 6、代码编写者 bug fix完毕之后给出反馈。 7、代码审核者把Code Review中发现的有价值的问题更新到"代码审核检查表"的文档中，对于特别值得提醒的问题可群发email给所开发人员。 1.3 责任 代码编写者，代码审核者共同对代码的质量承担责任。这样才能保证Code Review不是走过场，其中代码编写者承担主要责任，代码审核者承担次要责任。
[DOC]-检查表代码评审检查表-JAVA-其它制度表格
[DOC]-检查表代码评审检查表－JAVA-其它制度表格C++代码评审检查表 1 变量, 属性, 常数声明缺陷 (VC) , 是否按照命名规范声明变量和常数? , 变量或属性是否存在引起混乱的类似名称Are there variables or attributes with confusingly similar names? , 每一个变量和属性是否有 正确的类型? , 每一个变量和属性是否被恰当地初始化? , 所有的for-循环控制变量是否在循环头部声明? , Are there literal constants that should be named constants? 是否有literal constants需要命名为constant, , 是否存在应该是常数的便量或属性? , 是否存在应该是局部变量的属性? , 所有的属性是否有恰当访问modifiers (private, protected, public)? , 是否存在应该是非静态或vice-versa的静态属性? 2 方法定义缺陷 (FD) , 是否按照命名规范声明方法? , 每一个方法的的参数值在使用前是否作过检查? , 对于所有的方法: 在每一个返回点是否返回正确的值? , 所有的方法是否有恰当访问modifiers 班(private, protected, public)? , 是否存在应该是非静态或vice-versa的静态方法? 3 类定义缺陷 (CD)
, 每一个类是否都有正确的构造和析构函数? , 在子类中是否有应该定义在超类中的公共成员? , 类继承层次是否简单? 4 数据引用缺陷 (DR) , 对于所有的数组引用: 每一个下标值是否在定义的边界值范围内? , 对于所有的对象或数组引用: 值是否确认是非-null? 5 计算/数字 Defects (CN) , 是否存在使用混合类型数据的计算? , 在一个计算中是否存在向上溢出(overflow)或向下溢出(underflow)? , 对于使用一个以上操作符的表达式: 赋值和优先级是否正确? , 是否使用扩号以避免不明确的语句? 6 比较/Relational 缺陷 (CR) , 每一个布尔型测试: 是否检查了正确的条件? , 比较操作符是否正确? , Has each boolean expression been simplified by driving negations inward? , 每一个布尔表达式是否正确? , 比较是否会产生不恰当的，易忽略的副作用, , 是否不注意地将一个"&" 换成了"&&"或者将一个"|"换成"||"? 7 控制流程缺陷 (CF) , , 对每一个循环:是否选择了最好的循环结构? , 循环都有终止条件吗? , 如果在一个循环中存在多个退出地方, 每一个退出是否必要并且被正
评审检查表
欧盟注册水产企业检查表(草稿) 厂名：注册编号: 厂址：检查日期: 检查项目符合不符合说明一、企业安全卫生质量管理 （）（）（）1.根据欧盟94/356/EC决议建立了自我卫生检查系统 （或HACCP体系） （）（）（）2.有记录自我检查的执行及验证所有相关资料，包 括： （1）详细的综合性文件，如： 产品描述；（）（）（）标明关键点的生产工艺描述；（）（）（）各关键点，危害，风险评估和控制措施；（）（）（）各关键点的监测和检查所标明（）（）（）需受控参数的关键限值；（）（）（）失控时的纠偏措施；（）（）（）验证和复核的方法。（）（）（）（2）适当的自我检查文件管理系统和相关记录，如： 是否进行了危害分析（）（）（）是否有自我检查（或HACCP）计划（）（）（）关键点的观察或监测记录（）（）（）
验证活动的结果和记录；（）（）（）纠偏措施的书面报告和记录；（）（）（）追溯、确定生产批次的所有文件。（）（）（） 3.建立了一个多学科人员组成的（HACCP）小组， （）（）（）包括熟悉质量控制、生产、卫生、加工厂和设备的 卫生及操作、微生物等方面知识的管理人员 （）（）（）4.产品描述应包括组成、结构和物理化学特征、加工 过程、包装、贮藏和销售条件、有效期、使用说明 和任何适用的微生物和化学标准等。 5.工艺流程图应包括所有从原料到将最终产品投放 （）（）（）市场的步骤，并附列充足的技术数据，如： （1）加工区和辅助的平面布局（）（）（）（2）设备的布置和特征；（）（）（）（3）所有步骤的顺序；（）（）（）（4）操作的工艺参数尤其是时间和温度，包括耽搁；（）（）（）（5）产品的流程（包括潜在的交叉污染）；（）（）（） （）（）（）（6）清洁区和非清洁区的隔离； （）（）（）（7）清洁和消毒方法； （）（）（）（8）企业的环境卫生； （）（）（）（9）人员路线和卫生规范； （）（）（）（10）产品的贮藏和销售条件。
代码走查检查表
代码走查检查表 评审日期：年月日评审对象作者 评审人评审工作量 序号检查项评审意见 走查前准备 1 得到一份解释代码的最新的设计文档，作为代码走 查的参考 2 代码都已提交，版本统一 程序结构组织 1 所有代码的结构清晰，具有良好的结构外观和整齐 2 所有的模块（函数和外部接口）定义清晰，模块分解 清楚 3 所有的功能需求都明显的覆盖 4 整个代码体系结构组合合理 ,分层清晰，代码之间功 能划分明确 5 所有的接口模块化，尽量减少接口之间的耦合度，修 改时尽量不影响其他代码模块 6 代码体系构架对空间和速度都已经进行考虑 7 数据库操作、IO操作等是否正确关闭资源。并且必 须在try -catch-finally 的finally中关闭。 8 一个业务如果进行多次数据库更新、添加、删除是否 正确添加事务。 9 进行逻辑与、逻辑或判断时是否使用短路与、短路或。 10 多处使用相同代码时，应定义唯一方法或变量以供使 用。 11 对象是否使用工厂获取。 12 导入类时，如果仅使用包中的几个类，应导入具体类， 而不是导入整个包。 13 数组声明的时候使用 int[] index ，而不要使用 int index[]。 14 代码实现的逻辑是否与详细设计描述的逻辑一致 15 检查类中是否有无效的代码或者是无用的代码。 16 不要使用System.out.print()以及System.err输 出，需要进行日志处理 17 所有的文件名符合文件命名规范，见名知意 18 文件和模块分组清晰 19 较长的语句、表达式或参数（>80字符）要分成多行 书写，长表达式要在低优先级操作符处划分新行，操 作符放在新行之首，划分出的新行要进行适当的缩 进，使排版整齐，语句可读 20 每个程序文件都小于2000行
现场审核检查表.pdf
被审核过程：审核编号：日期： 产品：被审核工序：页码： 被审核项目：原材料验收审核员： 检查容检查记录（符合打勾，不符合详记）原材料验收规（厂家、牌号、规格、颜色……） 是否确定 验收手段、测量频次是否确定 原材料是否封存了外观标准样品 测量频次是否与质量保证状况相适应 以质量保证模式接受产品时是否定期进行了 产品审核 不合格品处理方式是否满足要求 不合格品隔离、做标识，标识的易读性、可 靠性
被审核过程：审核编号：日期： 产品：被审核工序：页码： 被审核项目：库存管理审核员： 检查容检查记录（符合打勾，不符合详记）定置管理图，定置管理（区域化分、标识） 帐、物、卡是否一致，库存是否定期核对 对环境敏感的材料（如：化学品）的存放条 件是否适宜，对存放条件是否定期监控 库存的周转和先进先出 失效期限的管理（报警、冻结） 包装信息（供应商、生产日期、数量……） 清晰易读 包装、搬运方式是否会导致质量下降(油污、 碰撞、损坏) 防火、防水、防雨措施 适宜的照明、湿度、温度、现场清洁度，是 否与产品类型相适应
被审核过程：审核编号：日期： 产品：被审核工序：页码： 被审核项目：检验与试验审核员： 检查容检查记录（符合打勾，不符合详记）——外观质量检验工艺是否确定 是否封存有标准样件 检验工位的照明度、清洁度如何 检验员是否经过培训 ——尺寸、性能的检测是否有检查规 检查规中的规定是否适宜 是否与控制计划一致，与图纸定义一致 ——检测工具是否验收，是否经过校准 校准标识是否易于识别 检具是否进行了测量系统分析 ——是否按工艺要求进行了检测 检验员是否熟练 检验员是否经过授权
2016最新版内部审核检查表格.docx
2016 版内部审核检查表 编制人： 内部审核纪录编号：
内审检查表 内审员：审核日期： 2016 年月日 条款号检查内容检查记录检查整改项及 结论说明 4评审要求 4.1 组织 4.1 依法成立并能够承担相应法律责任的法人或者其他组织 4.1.1公司或者其所在的组织应有明确的法律地位，对其出具的检测数据、结果负责，查资料查单位法人证书、组织机公司有相应的法律符合 并承担相应法律责任。构代码等证明文件地位 4.1.2公司应明确其组织结构及质量管理、技术管理和行政管理之间的关系。组织结构是否完善符合 岗位设置是否有利于检测活动中组织机构完善能够 责任范围区分，有无重叠责任不满足检测活动开展 清现象 4.1.3公司及其人员从事检测活动，应遵守国家相关法律法规的规定，遵循客观独立、公正性声明内容是否覆盖公正符合 公平公正、诚实信用原则，恪守职业道德，承担社会责任。性、独立性、利益关系、外部干有公正性声明 扰、人为因素等各种影响 4.1.4公司应建立和保持维护其公正和诚信的程序。公司及其人员应不受来自内外部有相应程序，询问相符合 的、不正当的商业、财务和其他方面的压力和影响，确保检测数据、结果的真实、查程序文件及询问相关人员关人员没有受到来 客观、准确和可追溯。自外部等的压力 4.1.5公司应建立和保持保护客户秘密和所有权的程序，该程序应包括保护电子存储符合 和传输结果信息的要求。公司及其人员应对其在检测活动中所知悉的国家秘密、商查程序文件有相应程序 业秘密和技术秘密负有保密义务，并制定和实施相应的保密措施。 4.2 具有与其从事检测活动相适应的检测技术人员和管理人员 4.2.1 公司应建立和保持人员管理程序，对人员资格确认、任用、授权和能力保持等进行规范管理。公司应与其人员建立劳动或录用关系，明确技术人员和管理人员的岗 位职责、任职要求和工作关系，使其满足岗位要求并具有所需的权力和资源，履是否建立了人员管理程序文件文有程序文件，相关记符合件中是否对录用、培训、管理等录可以证实活动符 活动的职责、范围、工作程序等合要求
《技术评审》过程规范
《技术评审》过程规范 技术评审(Technical Review,TR)的目的是尽早地发觉工作成果中的缺陷，并关心开发人员及时排除缺陷，从而有效地提升产品的质量。 技术评审的过程是SPP模型的重要组成部分。本规范阐述了技术评审过程域的3个要紧规程： ☆制定技术评审打算[SPP-PRO-TR-PLANNING]。 ☆正式技术评审[SPP-PROC-TR-FTR]。 ☆非正式技术评审[SPP-PROC-TRITR]。 上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“要紧步骤”、“输出”、“完成准则”和“度量”均已定义。 本规范适用于国内IT企业的软件研发项目。建议拥护按照自身情形（如商业目标、研发实力等）适当地修改本规范，然后推广使用。 16.1 介绍 技术评审最初是由IBM公司为了提升软件质量和提升程序员生产率而倡导的。技术评审方法差不多被业界广泛采纳并收到了专门好的成效，它被普遍认为是软件开放的最佳实践之一。 技术评审能够在任何开发时期执行，它能够比测试更早地发觉并排除工作成果中的缺陷。技术评审的要紧好处有： ☆通过排除工作成果的缺陷而提升产品的质量。 ☆越早排除缺陷就越能降低开发成本。 ☆开发人员能够及时地得到同行专家的关心和指导，无疑会加深对工作成果的明白得，更好地预防缺陷，在一定程度上提升了开发生产率。 可见技术评审有助于“提升质量、提升生产率、降低成本”，符合软件过程改进的全然目的。 技术评审有两种类型：
☆正式技术评审（FTR）。FTR比较严格，需要举行评审会议，参加评审会议的人员比较多。 ☆非正式技术评审（ITR）。ITR的形式比较灵活，通常在同伴之间展开，不必举行评审会议，评审人员比较少。 理论上讲，为了确保产品的质量，产品的所有工作成果都应当同意技术评审。现实中，为了节约时刻，承诺人们有选择地对工作成果进行技术评审。技术评审方式也视工作成果的重要性和复杂性而定。 技术评审过程域有3个要紧规程：“制定技术评审打算”、“正式技术评审”和“非正式技术评审”。如图所示。 图16－1：技术评审过程域示意图技术评审的注意事项： ☆评审人员的职责是发觉工作成果中的缺陷，并关心开发人员给出排除缺陷的方法，而不是替开发人员排除缺陷。 ☆技术评审应当“就事论事”，不要打击有失误的开发人员的工作主动性，更不准搞人身攻击（如讥讽、讽刺等）。 在会议评审期间要限制过多的争辩，以免白费他人的时刻。 技术评审过程域产生的要紧文档有： ☆整个项目的《技术评审打算》，模板见[SPP-TEMP-TP-PLAN]。 ☆《技术评审同通知》，模板见[SPP-TEMP-TR-NOTES]。 ☆《技术评审报告》，模板见[SPP-TEMP-TR-REPORT]。 ☆常用的《技术评审检查表》见[SPP-TEMP-TR-CHECKLIST]。 16.2 制定技术评审打算