程序代码评审记录表
合集下载
评审简表、评审表填写说明
《评审简表》填写说明1、《简表》采用“河南省职称管理信息系统”中“个人申报版”录入、修改、上报、打印。
“个人申报版”软件、升级程序、更新代码及使用说明可到“河南职称网”下载。
请申报人员仔细阅读软件说明，并通过升级程序和“更新代码”更新软件。
选择评委会时，应选择河南教师中级专业技术职务任职资格评审委员会。
另，河南省教育厅代码：19018。
2、操作程序：点击河南省职称网—点击软件下载—安装—打开系统—高中级评审简表（或进入其他评价方式——初评、初聘、直接认定）——点击高校教师（或其他）---正高、副高、中级——省直---选择评委会（申报我校具有副教授评审权的10个学科的人员应选择河南教师高级专业技术职务任职资格评审委员会，其他申报高级职称人员应选择河南省高等学校教师评委会、申报中级职称人员应选择河南评委会）——确定---录入全部信息（不得空栏，字体尽量大、排版美观）---保存---返回---上报申报信息---保存（生成“txt文本”）。
由系统生成的和经审核后的纸质《评审简表》内容一致的“txt 文本”（以申报人员姓名命名）发送至szk@。
3、若不能直接打印《评审简表》，可通过PDF虚拟打印机在本机打印保存PDF文件后，到连接A3打印机的电脑打印。
4、《简表》右上方“填表人签名”一栏中不需签名。
5、《简表》中“第一学历”应为第一次参加工作前的学历。
6、《简表》中“其他专业技术职务”一栏，如果申报人员在上次申报之后，本次申报之前曾经参加过专业技术职务任职资格转评，则申报人员务必填写本栏内容，以确保《简表》能体现出本次申报符合相应的任职年限要求。
7、《简表》中“工作学习简历”请按照时间顺序连续填写，不得有间断并确保真实准确。
8、《简表》中“教学完成情况”一栏，填写时按××-××学年填写，为近5年。
9、《简表》中论文、著作、科研等部分内容填写时标明序号“1.2.3…”，论文排序从第一篇送审论文即开始编号为“1”，依次顺延。
软硬件评审记录
评审结论说明
主要遗留问题
序号
问题描述
严重等级
提出人
责任人
关闭或处理说明
评审结论
拟制
审核
注：问题级别分严重问题A、重要问题B、次要问题C和提示问题D四种：
1.严重问题A：指产品特性严重不符合法律法规要求，可能会造成财产或人身伤害的不合理项，或则产品丧失基本功能，无法使用的项目。
2.重要问题B：指产品特性不满足预期的要求，产品部分功能丧失，如数据偏低、网卡不兼容等。
3.次要问题C：产品特性不满足预期要求，但不影响基本功能的使用，会降低客户满意度的项目。如产品外观、包装方式等。
4.提示问题D：未构成A\B\C类问题，但有发展成问题的趋势。
评审记录
项目名称
产品型号
评审ห้องสมุดไป่ตู้型
□评审会议■电子流
评审时间
评审主题
□硬件系统设计评审□原理图评审□BOM评审□PCB设计评审□代码提交审核□软件设计评审□软件需求规格书□测试用例评审□测试报告评审□ID评审□产测流程设计评审□包装设计评审□装备软件评审□其他
评审专家
部门
角色
姓名
部门
角色
姓名
序号
评审材料/内容
主要遗留问题
序号
问题描述
严重等级
提出人
责任人
关闭或处理说明
评审结论
拟制
审核
注：问题级别分严重问题A、重要问题B、次要问题C和提示问题D四种：
1.严重问题A：指产品特性严重不符合法律法规要求，可能会造成财产或人身伤害的不合理项，或则产品丧失基本功能，无法使用的项目。
2.重要问题B：指产品特性不满足预期的要求，产品部分功能丧失，如数据偏低、网卡不兼容等。
3.次要问题C：产品特性不满足预期要求，但不影响基本功能的使用，会降低客户满意度的项目。如产品外观、包装方式等。
4.提示问题D：未构成A\B\C类问题，但有发展成问题的趋势。
评审记录
项目名称
产品型号
评审ห้องสมุดไป่ตู้型
□评审会议■电子流
评审时间
评审主题
□硬件系统设计评审□原理图评审□BOM评审□PCB设计评审□代码提交审核□软件设计评审□软件需求规格书□测试用例评审□测试报告评审□ID评审□产测流程设计评审□包装设计评审□装备软件评审□其他
评审专家
部门
角色
姓名
部门
角色
姓名
序号
评审材料/内容
软件设计评审检查表
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线?
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试?
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
是否将需求分别陈述,因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
需求规格说明书检查表
概要设计检查表
Y： 是 TBD:不确定 N： 不是 NA：不适用
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了?
包括了数据流、控制流和接口的单元设计是否已清晰的说明?
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
测试计划进程表开发阶段测试阶开发组集成测试承测试组系统测试业主联合测试软件需求分析完成确认测试计划完成系统测试计划软件概要完成软件集开始设计确开始设计软件设计评审检查表设计成测试计划认测试用例编写确认测试说明系统测试用例编写系统测试说明软件详细设计完成软件单元测试计划开始设计集成测试用例编写集成测试说明软件编码编写软件单元测试说明执行软件单元测试编写软件单元测试报告软件测试完成集成测试说明执行集成测试进行测试分析编写软件集成测试报告完成软件确认测试说明执行软件确认测试进行测试分析编写确认测试报告完成系统测试说明执行系统测试进行测试分析编写系统测试报告
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线?
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试?
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
是否将需求分别陈述,因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
需求规格说明书检查表
概要设计检查表
Y： 是 TBD:不确定 N： 不是 NA：不适用
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了?
包括了数据流、控制流和接口的单元设计是否已清晰的说明?
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
测试计划进程表开发阶段测试阶开发组集成测试承测试组系统测试业主联合测试软件需求分析完成确认测试计划完成系统测试计划软件概要完成软件集开始设计确开始设计软件设计评审检查表设计成测试计划认测试用例编写确认测试说明系统测试用例编写系统测试说明软件详细设计完成软件单元测试计划开始设计集成测试用例编写集成测试说明软件编码编写软件单元测试说明执行软件单元测试编写软件单元测试报告软件测试完成集成测试说明执行集成测试进行测试分析编写软件集成测试报告完成软件确认测试说明执行软件确认测试进行测试分析编写确认测试报告完成系统测试说明执行系统测试进行测试分析编写系统测试报告
CMMI3认证全套资料-代码评审记录
Num. of Open 0 0 0
实到情况（Y/N) 预评审准备时间（h)
填写 自动
0
0
结论（Y/N)
解决情况(Y/N) 1
评审问题统计表
0
0
0
疑问
0
0
轻微
Total Num. Num. of Open Problems
0
0
严重
Total Num. Num. of Open Problems
问题等级 疑问 轻微 严重
Total Num. 0 0 0
代码评审记 录
记录人：
评审时间
评审日期： 评审开始时间： 评审结束时间： 评审时长（hs）：
评审模块
文件/模块名 Module A Module B
0.0
版本 20101010.0 20100908.0
评审人员
应到人
预评审发现问题/疑问收集
参考检查单
检查内容 代码的编写格式是否一致？ 定义的程序名是否有意义？ 命名中若使用特殊约定或缩写，是否有注释 说明？ 代码编译后是否未产生Warning? 数据类型和数据声明是合理正确的吗？ 所有定义的子程序都使用了吗？ 是否防止引用已经释放的内存空间？ 对于退出过程/函数后仍然需要存在的内存， 是否确保该内存使用完毕后及时释放该内 存？ 注释是否清晰正确？ 是否符合特定语言的代码要求？（见“特定 语言代码要求”页）
(如需增加检查项，在此行前插入）
0 描述说明
评审问题跟踪
问题ID 1
问题描述
问题等级
(如需增加检查项， 在此行前插入）
评审结论及确认
以下签字代表评审人员同意以上文档，对文档内容进行承诺 评审情况分析：（对评审发现问题以及评审问题统计数据进行分析）
ISCCCQOT0440 软件安全开发服务资质认证审核记录表
审核记录
符
合
不 符 合
需 观 察
42.
测试阶段- 集成测试
E2.5.2 a）仅二级/一级要求：明确集成测 试策略，制定集成测试计划。
抽查项目，查验集成测试的测试策略、 测试计划。
43.
E2.5.2 b）仅二级/一级要求：依据概要设 计方案和测试计划进行集成测试设计， 并执行集成测试，形成测试记录。
抽查项目，查验集成测试设计、测试 记录。
查验需求阶段控制程序文件；抽查项 目，查验需求阶段项目文档，内容应 覆盖审核条款的要求。
需求阶段项目文档包括可行性报告、 招标文件、需求分析报告等。
17.
E1.2 b）结合软件项目需求、安全需求， 与客户充分沟通，达成共识并形成记录。
抽查项目，查验与客户沟通的记录。
18.
19.
E2.2 a）仅二级/一级要求：准确识别和 综合分析软件项目在可用性、完整性、 真实性、机密性、不可否认性、可控性 和可靠性等方面的安全需求。
52.
E2.6.1仅二级/一级要求：试运行结束 后，制定系统试运行报告，并提交客户。
抽查项目，查验系统试运行报告，内 容应覆盖审核条款的要求。
53.
E3.6.1 a）仅一级要求：提供三个月以上 的试运行记录和报告。
抽查项目，查验系统试运行记录和报 告。
54.
E3.6.1 b）仅一级要求：综合软件系统试 运行状态，建立软件系统运行策略和安 全指南。
44.
E3.5.2仅一级要求：对集成测试结果进 行分析，形成分析报告。
抽查项目，查验集成测试分析报告。
45.
46.
47.
测试阶段・ 系统测试
E2.5.3a）仅二级/一级要求：制定包括系 统安全性测试在内的测试计划，并执行 系统测试，形成测试记录。
符
合
不 符 合
需 观 察
42.
测试阶段- 集成测试
E2.5.2 a）仅二级/一级要求：明确集成测 试策略，制定集成测试计划。
抽查项目，查验集成测试的测试策略、 测试计划。
43.
E2.5.2 b）仅二级/一级要求：依据概要设 计方案和测试计划进行集成测试设计， 并执行集成测试，形成测试记录。
抽查项目，查验集成测试设计、测试 记录。
查验需求阶段控制程序文件；抽查项 目，查验需求阶段项目文档，内容应 覆盖审核条款的要求。
需求阶段项目文档包括可行性报告、 招标文件、需求分析报告等。
17.
E1.2 b）结合软件项目需求、安全需求， 与客户充分沟通，达成共识并形成记录。
抽查项目，查验与客户沟通的记录。
18.
19.
E2.2 a）仅二级/一级要求：准确识别和 综合分析软件项目在可用性、完整性、 真实性、机密性、不可否认性、可控性 和可靠性等方面的安全需求。
52.
E2.6.1仅二级/一级要求：试运行结束 后，制定系统试运行报告，并提交客户。
抽查项目，查验系统试运行报告，内 容应覆盖审核条款的要求。
53.
E3.6.1 a）仅一级要求：提供三个月以上 的试运行记录和报告。
抽查项目，查验系统试运行记录和报 告。
54.
E3.6.1 b）仅一级要求：综合软件系统试 运行状态，建立软件系统运行策略和安 全指南。
44.
E3.5.2仅一级要求：对集成测试结果进 行分析，形成分析报告。
抽查项目，查验集成测试分析报告。
45.
46.
47.
测试阶段・ 系统测试
E2.5.3a）仅二级/一级要求：制定包括系 统安全性测试在内的测试计划，并执行 系统测试，形成测试记录。
评审报告模版
是否明确了项目范围和约束？
是否别了项目风险？
是否评估了项目风险值及控制措施？
是否确定了所有项目涉众（干系人）？
是否确定了项目各项资源需求？
是否确定了项目各项里程碑？
是否确定了项目开发模式，？
是否明确了项目进度计划完成时间？
是否明确了项目系统测试计划完成时间？
是否明确了项目风险控制计划完成时间？
是否明确了项目质量保证计划完成时间？
用例简述是否明确执行此用例的不同用户和用户通过此用例要达到的最终结事件流是否明确描述了系统所有主要的包括应有的分支动作并指明了触发条件且每个动作都是由应有的具体角色发送或接收的
XX评审报告
1
提示：由开发部项目经理填写此表格。
项目名称
评审类型
[走查/审查/复审]
时间
地点
参加
人员名单
姓名
工作单位（部门）、职务、职称
附录A
主要检查项
评价
实现代码是否完整正确地实现了设计方案？
代码实现方式是否合理、高效？
代码资源消耗、性能、执行效率、日志输出是否符合要求？
是否有重复实现公司已有代码或开源代码的地方？
代码编写是否符合编码格式规范？
代码编写是否符合系统日志规范？
代码编写是否符合安全编码规范？
提交版本时是否填写详细的备注信息？
是否明确了项目配置管理计划完成时间？
附录D
主要检查项
评价
分析包的结构是否与系统用例包结构一致？
是否分析定义出必要的边界类、控制类和实体类，通过其类图和协作图来表现相关系统用例的实现？
必要的类方法和属性是否已经定义？
每个分析类是否在其文本框中描述了真正的类名及其作用，
每个类方法是否描述了真正的方法名或实现类名，以及这些方法或实现类的作用和实现要求？
是否别了项目风险？
是否评估了项目风险值及控制措施？
是否确定了所有项目涉众（干系人）？
是否确定了项目各项资源需求？
是否确定了项目各项里程碑？
是否确定了项目开发模式，？
是否明确了项目进度计划完成时间？
是否明确了项目系统测试计划完成时间？
是否明确了项目风险控制计划完成时间？
是否明确了项目质量保证计划完成时间？
用例简述是否明确执行此用例的不同用户和用户通过此用例要达到的最终结事件流是否明确描述了系统所有主要的包括应有的分支动作并指明了触发条件且每个动作都是由应有的具体角色发送或接收的
XX评审报告
1
提示：由开发部项目经理填写此表格。
项目名称
评审类型
[走查/审查/复审]
时间
地点
参加
人员名单
姓名
工作单位（部门）、职务、职称
附录A
主要检查项
评价
实现代码是否完整正确地实现了设计方案？
代码实现方式是否合理、高效？
代码资源消耗、性能、执行效率、日志输出是否符合要求？
是否有重复实现公司已有代码或开源代码的地方？
代码编写是否符合编码格式规范？
代码编写是否符合系统日志规范？
代码编写是否符合安全编码规范？
提交版本时是否填写详细的备注信息？
是否明确了项目配置管理计划完成时间？
附录D
主要检查项
评价
分析包的结构是否与系统用例包结构一致？
是否分析定义出必要的边界类、控制类和实体类，通过其类图和协作图来表现相关系统用例的实现？
必要的类方法和属性是否已经定义？
每个分析类是否在其文本框中描述了真正的类名及其作用，
每个类方法是否描述了真正的方法名或实现类名，以及这些方法或实现类的作用和实现要求？
代码评审标准与结果
6
注释对于理解代码是否有帮助
7
代码中的注释是否充分
8
代码中的注释是否过多
布局/封装缺陷
1
代码布局风格和缩排标准是否前后一致并体现其逻辑结构
2
代码中是否存在已被注释且不再使用的代码
3
复杂程序是否合理地分解成多个子程序
4
每个方法的代码量是否都不超过60行
5
方法或类之间是否具有低耦合性
6
方法或类之间是否具有高内聚性
2
比较运算符是否正确
3
布尔表达式是否通过内部否定操作进行了简化
4
每个布尔表达式是否都正确
5
比较操作是否存在不引人注意的副作用
6
是否存在“&&”替换为“&”或“||”替换为“|”的情况
7
代码中是否避免了对浮点型数值的相等比较操作
流程控制缺陷
1
每个循环是否选用了最佳循环结构
2
所有的循环结束条件是否明显
3
6
注释对于理解代码是否有帮助
7
代码中的注释是否充分
8
代码中的注释是否过多
布局/封装缺陷
1
代码布局风格和缩排标准是否前后一致并体现其逻辑结构
2
代码中是否存在已被注释且不再使用的代码
3
复杂程序是否合理地分解成多个子程序
4
每个方法的代码量是否都不超过60行
5
方法或类之间是否具有低耦合性
6
方法或类之间是否具有高内聚性
7
是否存在重复代码且它的功能可以通过调用其他方法实现
8
方法参数数量是否控制在5个以内
性能/算法缺陷
1
是否存在更好的数据结构和算法可以采用
注释对于理解代码是否有帮助
7
代码中的注释是否充分
8
代码中的注释是否过多
布局/封装缺陷
1
代码布局风格和缩排标准是否前后一致并体现其逻辑结构
2
代码中是否存在已被注释且不再使用的代码
3
复杂程序是否合理地分解成多个子程序
4
每个方法的代码量是否都不超过60行
5
方法或类之间是否具有低耦合性
6
方法或类之间是否具有高内聚性
2
比较运算符是否正确
3
布尔表达式是否通过内部否定操作进行了简化
4
每个布尔表达式是否都正确
5
比较操作是否存在不引人注意的副作用
6
是否存在“&&”替换为“&”或“||”替换为“|”的情况
7
代码中是否避免了对浮点型数值的相等比较操作
流程控制缺陷
1
每个循环是否选用了最佳循环结构
2
所有的循环结束条件是否明显
3
6
注释对于理解代码是否有帮助
7
代码中的注释是否充分
8
代码中的注释是否过多
布局/封装缺陷
1
代码布局风格和缩排标准是否前后一致并体现其逻辑结构
2
代码中是否存在已被注释且不再使用的代码
3
复杂程序是否合理地分解成多个子程序
4
每个方法的代码量是否都不超过60行
5
方法或类之间是否具有低耦合性
6
方法或类之间是否具有高内聚性
7
是否存在重复代码且它的功能可以通过调用其他方法实现
8
方法参数数量是否控制在5个以内
性能/算法缺陷
1
是否存在更好的数据结构和算法可以采用
软件质量保证配置管理计划评审检查表
√： 检查通过
х： 检查不通过需修改
其他标记：请注明原因
配置管理计划
目标
（）
适用范围
（）
职责与权限
（）
配置项标识
（）
配置管理工具
（）
配置项组织结构
（）
备份制度
（）
版本发放
（）
变更控制
（）监督Βιβλιοθήκη 监控（）评审结论评审结论是否明确
（）
评审遗留问题是否落实
（）
评审报告
评审报告是否成文
（）
评审报告是否发给参加评审的人员
（）
项目SQA人员签名：
请在（）内标注相关检查结果
质量策划
（）
需求文档
（）
设计文档
（）
测试计划用户手册
（）
会议记录
（）
调研报告
（）
培训记录
（）
每日/周工作记录
（）
评审报告
（）
源代码
（）
开发工具与版本
（）
配置管理工具的定义
（）
配置项组织结构
（）
备份制度是否明确
（）
版本发放
版本发放原则（谁做，如何做）
（）
版本标识原则
（）
变更控制
明确的提交流程
（）
明确的修改流程
（）
对配置项（包括源码）修改时填写注释
（）
源代码阶段性设置Lable
（）
监督与控制机制是否明确
（）
评审的组织
以上资料是否提前2天发给参加评审的人员
（）
是否指定评审会议主持人
（）
评审的参与人
配置管理计划中涉及的SCCB成员
х： 检查不通过需修改
其他标记：请注明原因
配置管理计划
目标
（）
适用范围
（）
职责与权限
（）
配置项标识
（）
配置管理工具
（）
配置项组织结构
（）
备份制度
（）
版本发放
（）
变更控制
（）监督Βιβλιοθήκη 监控（）评审结论评审结论是否明确
（）
评审遗留问题是否落实
（）
评审报告
评审报告是否成文
（）
评审报告是否发给参加评审的人员
（）
项目SQA人员签名：
请在（）内标注相关检查结果
质量策划
（）
需求文档
（）
设计文档
（）
测试计划用户手册
（）
会议记录
（）
调研报告
（）
培训记录
（）
每日/周工作记录
（）
评审报告
（）
源代码
（）
开发工具与版本
（）
配置管理工具的定义
（）
配置项组织结构
（）
备份制度是否明确
（）
版本发放
版本发放原则（谁做，如何做）
（）
版本标识原则
（）
变更控制
明确的提交流程
（）
明确的修改流程
（）
对配置项（包括源码）修改时填写注释
（）
源代码阶段性设置Lable
（）
监督与控制机制是否明确
（）
评审的组织
以上资料是否提前2天发给参加评审的人员
（）
是否指定评审会议主持人
（）
评审的参与人
配置管理计划中涉及的SCCB成员
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2
3
1)有”*”标志的内容必须填写。
2).缺陷类型可能是下面的类型之一:逻辑、标准、多余的代码、用户界面、可跟踪性、一致性、可移植性、设计疑点、性能。
3).缺陷严重性可以是：危急的、主要的、次要的、表面的；
正式评审花费的总时间（会议时间）＝人时
正式评审发现的缺陷总数（∑每人发现的缺陷数量）＝个
评审结论
1.1
项目代码评审表
评审代码文件清单
文件名称
版本号
作者
文档规模
(页数或者代码行数)
地点
评审日期
评审组长
评审方式
□正式评审□走查
评审成员
评审准备
准备阶段花费的总时间（∑每人花费的时间）＝人时
准备阶段发现的缺陷总数（∑每人发现的缺陷数量）＝个
评审过程记录
序号
描述*
提出人
缺陷类型
缺陷严重性
拟定修改日期*
1
□不做修改可通过；□经过修改可通过；□不通过再评审；
评审小组组长（签字、日期）
评审小组成员（签字、日期）
文档作者（签字、日期）
其他参会成员（签字、日期）
3
1)有”*”标志的内容必须填写。
2).缺陷类型可能是下面的类型之一:逻辑、标准、多余的代码、用户界面、可跟踪性、一致性、可移植性、设计疑点、性能。
3).缺陷严重性可以是：危急的、主要的、次要的、表面的；
正式评审花费的总时间（会议时间）＝人时
正式评审发现的缺陷总数（∑每人发现的缺陷数量）＝个
评审结论
1.1
项目代码评审表
评审代码文件清单
文件名称
版本号
作者
文档规模
(页数或者代码行数)
地点
评审日期
评审组长
评审方式
□正式评审□走查
评审成员
评审准备
准备阶段花费的总时间（∑每人花费的时间）＝人时
准备阶段发现的缺陷总数（∑每人发现的缺陷数量）＝个
评审过程记录
序号
描述*
提出人
缺陷类型
缺陷严重性
拟定修改日期*
1
□不做修改可通过；□经过修改可通过；□不通过再评审；
评审小组组长（签字、日期）
评审小组成员（签字、日期）
文档作者（签字、日期）
其他参会成员（签字、日期）