OA-项目阶段评审表-4-编码评审报告
APQP第二阶段小结项目阶段评审报告
标注
项目编号： 实际日期：
■是 ■是 ■是 ■是 ■是 ■是 ■是 ■是 ■是
□否 □否 □否 □否 □否 □否 □否 □否 □否
□ 附注 □ 附注 □ 附注 □ 附注 □ 附注 □ 附注 □ 附注 □ 附注 □ 附注
项目小组
■ 同意转入下一阶段 评论： 该阶段的各项评定符合要求,同意进行下一阶段
□ 拒绝进入下一阶段
第二阶段小结（项目阶段评审报告）
项目负责人： 批准：
项目名称： 计划日期：
- 机器设备是否能满足客户的需求？ - 检验设备是否能满足客户的需求？ - 供应商是否明确需要提交的相关资料？ - 是否有通知供应商送样？ - 是否有通知制作样品？ - 模具是否已验收 OK? - 样品的各项参数是否有制定？ - 样品的尺寸外观是否有确认？ - 样品的性能是否有测试？
项目小组组长： 项目小组：
批准：
项 目 小 组 决 定（最终决定）
项目作调整 在转入调整阶段谦需作深入研究 转责人：
分发人：
项目管理：阶段性评审报告模板案例
待解决问题分析：
工艺参数设定
资源配置需求：
现有设备设施能够满足NFc方向盘骨架的生产
评审结论：
NFc方向盘开发小组第一阶段任务已按计划完成。
项目小组成员认可：
编制：
审核：
批准：
项目管理：阶段性评审报告模板案例
第一阶段评审报告
项目名称
零件号/版本号
文件编号
客户名称
工作内容完成情况：
本阶段，通过市场调研、可行性（质量、经济、制造）分析，总经理组织会议对NFc方向盘进行立项，并成立了多方论证小组，明确了各小组成员的职责，开发并确定了产品的特殊特性，确定了产品流程及生产该产品所需的设备、工装和设施的要求，最后小组对该产品进行了可行性评审。
XXX(项目编号)TR4评审报告-PPT模板
售后服务及 技术支持准备
售后服务及技术支持的相应资料及指导书已交付，人员已得到培训。
TR4主要工作及完成情况——试产验证：
项目状态汇报
包括： 1、试产情况概述： 包括试产准备情况、试产起始时间、试产完成情况等。
2、试产质量指标达成情况 包括直通率、物料上线不良率等。参照《TR4验收评估报告》中的内容编写。
3、试产问题分析报告（记录试产问题的质量问题跟踪表需插入到此页） ： 1）可以按问题总数、类型、严重度、 原因的类型（硬件、软件等）、问题状态等
序号
遗留问题
1
项目遗留问题及风险说明
问题遗留原因 对后续工作的影响
应对措施
负责人
预计完成 时间
遗留问题最好直接列入此页中，若问题太多，也可插入文件
项目遗留问题及风险说明
项目风险：
序 号
风险描述
风险应对措施
风险分类
负责 人
1
APA功能的测试及调试延期到9月20日提供（延期一 与长安沟通延期风险并跟进 进度风险
BUG类型、BUG原因类型（硬件、软件、结构设计、结构类供应 商、实验方法等）、处理状态等进行分析；
2）未关闭的问题需要直接写在PPT中，要列出计划解决时间（ 质量问题跟踪表需要插入此页汇总）；
3、实验过程总结： 经验、教训
说明：对委外进行软硬件设计的项目，需从我司摸底实验、委 外单位摸底实验两个角度分别按以上思路进行分析
SOP阶段质量状况
代码评审标准与结果
注释对于理解代码是否有帮助
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
是否存在更好的数据结构和算法可以采用
测试计划评审检查表
5 是否明确测试环境（软件、硬件环境）？
6 是否对选定的测试工具的相关信息进行了详细描述并且经过确认？
7 测试各阶段的人员和进度安排是否合理？ 是否确定了测试阶段存在的主要风险，制定了详细的控制措施，并已经取得部
8 门或公司领导层的支持？
9 是否明确了配置库的层次结构？
10 《配置库结构层次ຫໍສະໝຸດ 》中确定的层次结构是否完整、实用？
11 是否明确了测试过程中基准配置项变更与完善控制的界定准则？
说明：（责任人对确定为“否”的检查项给出必要说明）
第 1 页/共 1 页
测试计划评审检查表
表格编号：项目编号-阶段/文档类别代号-两位顺序号
项目名称：
序 号
检查项
结 果
1 是否明确测试目的、预期达到的目标以及本次测试的范围？
2 是否完整、清晰地列出本计划中的专用词汇，并沿用了先前过程中定义词汇？
3 是否根据确定的测试类型与测试范围明确测试所需的手段、方法？
4
是否根据软件产品或项目的实际特点，对"A"、"B"、"C"、"D"四类问题的分级 原则进行了明确、详细地描述？
代码评审表模板
代码评审表模板代码码码码清;Code Checklist,版本,1.0码品/码目码名,称宅急送码品/码目名,称公共版本,号 1.0被码码人码字, 码码容,内___ ______码码人码字 ,___________ 码码日期, _ ____码明,码码清被码码码名模码名称码品名称码码码常码是否程序是否明地注码了其码码功能确注码格式是否正确程序码元是否承码一码码担码码程序是否合理地分解码子程序程序中接口定码是否明晰异常码理是否符合码范包名、码名命名是否符合码范方法名命名是否符合码范码量/常量是否相码系列码量是否码一集中明～自定码据码型码量是否码行了必要而充分的描述声数码量是否按相码码范码行了命名;有意码的命名、据码型的分等,数区码量是否按其命名含码承了码一的使用目的～必要码是否定码了码外码量担清晰码量引用是否正码码确常量是否使用getter/setter方法码码是否码用良好定码的枚码码型替代了码码的字符码码或布码码量使用UFBoolean是否使用UFBoolean构数构造函码行造码理可码String码是否未使用StringBuffer是否码先使用Java码准码提供的容器;ArrayList、HashSet、HashMap、LinkList,码理码序来码、集合、码码码合堆码码列构数码码的使用码景是否正数确码于public尽慎量码使用不同作用域码量名量不要相同称尽算法是否数构据码是否合理、精码算法是否可以立码码～是否据码和其他算法隔独与数离是否量避免了嵌套的用尽运码码码码是否码行了必要而充分的注码控制是否代码码行路是否径清晰Switch码句是否有缺省分支控制码码码码度是否合理～是否码行了必要而充分的注码每循码是否码码行了码一而明的功能个体确与数将数达常比码需要常放在比码表式的前面布局是否代码是否良好格式化能码其码码码并体构码码是否程序是否可码、可码展健并壮具码码码码是否已可能的“码藏”体尽是否码先使用接口而不是抽象码或具码体方法是否在参数5个内以方法用慎public修码符码于不需要子码重码的码量使用来尽final码象作用域是否码大效率是否尽内量不要在循码出码码程码用每码码码作码程码用次是否小于个数3次码程码用据码码是否有不必要的冗余据数数SQL是否Sql码句小写引用字符使用码引号码禁使用select * 形式的码句～必码指出具字段体码禁使用insert into table values;,～,～,,～必码指出具要码码的字段体避免码含的码型码码;不同据码型字段相加,数子码码前后必码加上括号避免在where使用’1=1’,’1=2’码码表方式作码部分件达条禁止使用码码禁止使用XX in () or XX in ()(in中的元素不码超码个数500)禁止使用or超码500个禁止使用not in～建码使用not exist禁止在一条sql码句中使用3码以上的嵌套如果有多表码接码～码码有主之分～量一表取从尽从个数Where子句码码件～索引列或码码码码最多的件码码放在前面条条字符串码接必码使用“||”Case when码句中只能出码=、>=、<=以及is null运算符左码接法必码码”写outer”码码字Sql中函是否在指定范码数内Join与on必码码格匹配码码码清码码描述码码修改日期修改日期码码人码字。
品质保证体系流程图
N
样件
Y
确认
实验确认 N
Y
工程图样确 认
设计 变更
N Y
实施变更
确认产品和过程特殊特性
确认新设备、工装
确认量具和试验设备
①检测报告
②试验报告 ③工装设备清单 ④产品/过程特殊特性 清单 ⑤量检具试验装备清 单
①《产品设计开发策划管理 程序》 ②《产品和过程更改程序》 ③《事态升级管理办法》 ④《FMEA管理办法》
顾客
N 顾客
Y
品质体系保证图
总经理
财务控制部 技术开发部 生产管理部 质量保证部
供方
①外来文件评审记 录 序》 ②纠正预防措施计 划表 ③略：按文件输出
输出文件
①《产品设计开发策划管理 程序》
②编《制生：产过程控制程序》
③《采购管理程序》 ④《工装管理程序》
⑤审《核设：备管理程序》
⑥《人力资源管理程序》 ⑦《检验测量设备控制程序
供方
②产品/过程特殊特 ①《产品设计开发策划管 技
性清单
理程序》
术
③DFMEA ④样件控制计划
②《FMEA管理办法》
开
③编《制产：品安全与责性与责 发
⑤产品设计草图 任管理办法》
部
⑥产品标准 ⑦设计评审记录
审核：
批准：
输出文件
关联文件
主责 部门
二 、
产 品 设 计 和 开 发
2/7
文件编号:J
版 本 号:
批量 生产 /顾 客反 馈
②产品图纸 ③检查基准书 ④作业指导书 ⑤控制计划 ⑥包装作业指导书 ⑦各工序作业、检
查记录
顾客不良反馈
合格品发运 售后/服务
新产品开发阶段性评审报告(DR4)
时间：
地点：
产品类别 评审内容 对应者
工程部 市场部 技术中心 项目管理部 工程部 质量管理部 质量管理部 质量管理部 产品验证检测 中心 质量管理部 工程部 采购物流中心 质量管理部 采购物流中心 质量管理部 制造中心 制造中心 制造中心 制造中心 制造中心 质量管理部 质量管理部 质量管理部 项目组 技术中心 工程部 技术中心 技术中心 工程部
相关文件
阶段性评审报告(DR3) 样机确认表 零件确认书 试产通知书 控制计划 控制计划检查清单 测量系统分析表 初始过程能力调查研 究表 PPAP资料 试验报告 检验/试验报告 PFMEA 过程FMEA检查清单 新品转量产交接表 IQC来料检验报告 供应商PPAP资料 PSW 作业指导书管理台帐 设备有效性记录表 培训记录签到表 新品试产前工作检讨 及实施 设计品质目标书/初期 流动管理计划书 新品试产问题点总结 报告书 产品质量策划总结和 认定报告 包含上述文件 产品履历表 技术资料 零件图纸 经验教训履历表 经验教训活用检查表
24
25 26
第1页，共2页
27 28
项目管理部是否对《生产准备进度情况计划、报告书》中的 目标实施完成情况进行跟踪？ 是否识别出项目风险，并制定相关应对措施及进行跟踪、管 理？
项目管理部 项目管理部
《生产准备进度情况 计划、报告书》 项目风险跟踪表
Hale Waihona Puke 3、评审结果： □ 本次DR4评审通过,批准进入量产阶段。 □ 本次DR4评审有条件通过,批准进入量产阶段。 □ 本次DR4评审不通过，按下记课题进行改善： （1）、改善课题事项： NO. 1 2 3 （2）、下次DR4日程： 4、会签
新产品开发阶段性评审报告（DR4）
项目阶段性评审报告
（）项目阶段性评审报告
TXjl-CX/ Rev:A/0
项目名称项目阶段
项目编号评审时间
评审方式会议评审
姓名部门职务或职称姓名部门职务或职称评
审
人
员
1 2 3 4 5
评审内容评审建议本阶段工作达成状况；
本阶段形成的资料的完好性；
下阶段输入要求能否知足
本阶段项目估算花费的控制状况
其余
本阶段遗留的问题/ 存在的风险 / 应付举措：1.遗留的问题 / 存在的风险：
1 ）
2）
3）
2.应付举措：
1）
2）
3）
3：获取的经验和教训
1）
2）
3）
评审结论：
项目经理建议：
项目管理团队建议（一定对能否能够进入下阶段进行同意）：
署名：
注：流程：项目研发团队提出申请→项目管理团队组织→项目评审委员会评审→项目经理审查→项目管理团队负责人同意→项目研发团队保留作为归档资料归档。
研发项目结项评审表
研发项目结项评审表文件编码：CSDP定制软件项目开发平台项目管理计划变更履历目录1文档介绍 (3)1.1 文档目的 (3)1.2 文档范围 (3)1.3 读者对象 (3)1.4 参考文献 (3)1.5 术语与缩写解释 (3)2项目介绍 (4)2.1 项目说明 (4)2.2 项目目标和内容 (4)2.3 项目环境资源要求说明 (5)2.3.1 项目开发环境要求 (5)2.3.2 项目测试环境要求 (5)2.4 注意事项 (5)3项目过程定义 (7)3.1 项目类型 (7)3.2 项目过程定义 (7)4项目主要里程碑 (9)5人力资源计划 (10)5.1 项目组织结构 (10)5.2 项目人员情况 (11)6培训计划 (12)6.1 项目需要的技能一览表 (12)7项目跟踪管理计划 (13)8成本预算 (13)9提交的工作产品清单 (14)10方法与工具 (15)11附属计划 (16)12附录干系人介入规约 (17)1文档介绍1.1文档目的介绍“定制软件项目开发平台”（以下简称“开发平台”项目）的基本情况，制定项目的主要里程碑和总体项目计划，并定义和裁减本项目的管理过程和环节。
通过本项目管理计划，指导民政平台项目研发和过程监管，让项目组成员了解项目总体安排，保证项目各项工作有序进行。
1.2文档范围开发平台项目管理计划的主要内容包括：项目介绍、项目过程定义、项目主要里程碑、人力资源计划、项目跟踪管理计划、提交的工作产品清单、开发方法与工具等。
1.3读者对象项目组成员（包括项目经理、开发人员、测试人员、配置管理人员等）、项目监管部、项目干系人、公司领导等。
1.4参考文献1.5术语与缩写解释2.1项目说明开发平台是通用的电子政务登记、审批类软件项目开发平台，提高应用软件的开发效率，逐步将业务实现由研发向实施转移，使定制类项目研发更注重产品平台的功能，实施更注重业务的配置实现，从而实现定制类项目产品化，业务配置化，分工精细化。
IT信息化部门项目管理规范
通过规范IT&信息化部门的项目管理，确保公司重点IT&信息化项目顺利推进和落实，从而有效地支持公司IT&信息化年度目标的实现；规范化IT&信息化部门项目管理流程，项目管理模板，提高项目的成功率。
建立合用于项目绩效评价机制和项目团队成员的绩效评价；提高项目经理和项目团队成员职业化素质及技能。
加强项目管理知识沉淀，为后续项目借鉴。
公司所有周期超过1 个月，涉及面广，协调量大，有较大项目风险的IT&信息化工作。
按照年初制定的集团IT&信息化年度目标，把目标分解到各季度、根据季度目标落实需要推进的关键IT&信息化项目。
因公司战略需要而发起的重大项目。
管理部主持项目管理部部门工作，结合公司的战略，组织和协调各方制订集团IT&信息化年度目标，监控集团所有重大集团IT&信息化项目推进。
为集团IT&信息化项目指派称职的项目经理，参与对项目关键阶段和重大变更进行评审。
制订项目经理的任职资格标准等。
1.1 确定项目范围，结合benchmark 及项目需求，制定明确的项目目标及评价标准，选择合适的项目团队成员，进行项目规划并制定项目推进计划，识别项目关键风险并制定风险应对策略。
1.2 明确项目团队成员职责及交付要求，对项目团队成员的表现进行评价。
1.3 组织项目启动(kickoff)，负责项目组的日常管理，协调资源，按计划及时完成项目立项、过程监控、结果评价等过程，并对项目等进行复盘；1.4 负责组织项目阶段评审，保证项目有效完成和关闭。
1.1 积极参预工作计划的制定和实施，明确负责的任务目标；1.2 按时完成项目经理分派的任务，保证交付质量；1.3 积极参加项目会议、培训和研讨，及时反映项目推进中浮现问题，并提出改进建议；1.4 协助项目经理协调资源，保证项目进度。
1.5 协助项目经理总结项目管理经验及教训。
负责项目立项评审，保证项目目标、范围、计划制定合理，项目团队成员选择得当，项目目标可实现。
项目产品样件阶段评审报告
4、可检验性5、安全性6、可维护性
7、法律法规8、移动结构合理性
存在冋题及改进措施：
样件的功能和重量达到了用户要求，可以进行用户确认了。
评审结论：
样件的功能能够达到技术协议要求
对改进措施的跟踪验证结果：
验证人：日期：
备注：
1、评审会议记录应予以保留
2、可另加页叙述
**********自动化有限公司
设计开发样件阶段评审报告
HT-JL-7.3-08
项目名称
******口
产口品
项目编号
TSM.00
设计开发阶段
样件
负责人
评审人员
部门
职务或职称
评审人员
部门
职务或职称
技术部
项目经理
生产部
车间主任
技术部
部长
质量部
质量工程师
技术部
副部长
技术部
结构工程师
评审内容：“□”内打“2”表示评审通过，“？”表示有建议或疑问，“X”表示不同意
编ห้องสมุดไป่ตู้:
审核:
批准:
日期:
04-项目管理-09-项目编号+项目名称项目管理计划
文件编码密级文档版本拟制人日期项目编号和项目名称项目管理计划郑重声明：XX软件股份有限公司版权所有。
本文档中任何部分未经限公司书面授权，不得将材料泄露给第三方，不得以任何手段、任何形式进行复制与传播。
变更履历版本日期变更位置变更理由/变更内容变更人备注目录1文档介绍 (4)1.1文档目的 (4)1.2文档范围 (4)1.3读者对象 (4)1.4参考文献................................1.5术语与缩写解释 (4)2项目介绍 (4)2.1项目说明 (4)2.2项目目标和内容 (4)2.3客户与最终用户介绍 (4)2.4项目环境资源要求说明 (5)2.4.1项目开发环境要求 (5)2.4.2项目测试环境要求 (5)2.4.3项目运行环境要求 (5)2.5注意事项 (6)3项目过程定义 (6)3.1项目类型 (6)3.2项目过程定义 (6)4项目主要里程碑 (12)5人力资源计划 (13)5.1项目组织结构 (13)5.2项目人员情况 (14)5.3客户或协助人员配备建议 (14)6干系人介入计划 (14)6.1项目干系人一览表 (14)6.2项目干系人介入计划 (15)7培训计划 (16)7.1项目需要的技能一览表 (16)7.2项目培训计划表 (17)8项目评审计划 (19)9度量数据收集与分析计划 (19)10项目跟踪管理计划 (20)11成本预算................................错误!未定义书签。
12提交的工作产品清单 (20)13方法与工具 (20)14附属计划 (21)15附录干系人介入规约 (21)文档介绍文档目的说明编写项目管理计划的目的。
文档范围说明文档所包含的范围。
读者对象说明本文档预期的读者。
参考文献提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：[标识符] 作者，文献名称，出版单位（或归属单位），日期例如：[AAA] 作者，《立项建议书》，组织名称，日期[SPP-PROCPP] SEPG，项目规划规范，组织名称，日期术语与缩写解释缩写/术语解释SPP软件项目计划，Software Project PlanningPP项目计划，Project Planning…项目介绍项目说明1.用简练的语言说明本项目“是什么”，“说明用途”。
代码审查报告范文
代码审查报告范文一、引言代码审查是软件开发过程中非常重要的环节，通过对代码的评审可以发现潜在的问题并及时纠正，合理分配编程任务和提高团队的合作效率。
本文对项目代码进行了详细的审查，旨在提供准确的评估和建议。
二、审查对象本次代码审查的对象是项目中的其中一模块（以下简称“待审模块”）。
该模块由开发工程师张三编写完成。
三、代码审查结果基于对待审模块的全面审查，本次审查结果如下：1.代码结构和可读性：待审模块的代码结构清晰，模块划分合理，函数命名规范，注释规范。
部分代码行长度超过了标准限制，建议进行适当调整以提高可读性。
2.效率和性能：待审模块的算法设计合理，关键代码运行效率较高。
但在一些循环中，存在重复计算的情况，建议通过合理的缓存机制来减少计算量，提高性能。
3.安全性：待审模块没有发现明显的安全漏洞和错误，已经对用户输入进行了合适的验证和处理。
但仍需要注意对敏感信息的保护和防御措施的加强。
4.错误处理和异常处理：待审模块未对所有可能的错误和异常进行适当的处理，部分场景下可能导致程序崩溃或者不可预期的结果。
建议增加错误处理和异常处理的代码逻辑，保证程序的健壮性。
5.可扩展性和复用性：待审模块的代码结构较为臃肿，缺乏模块化和封装性，导致部分函数功能重复，不利于对模块进行扩展和复用。
建议优化代码结构，增加代码的可扩展性和复用性。
6.单元测试：待审模块的单元测试覆盖率较低，需要完善单元测试用例，覆盖更多的分支。
同时，建议引入自动化测试框架，提高测试效率和质量。
四、总结和建议通过对待审模块的代码审查，我们得出以下总结和建议：1.代码结构和可读性：优化部分过长的代码行，增加适当的空行和缩进，提高代码可读性。
2.效率和性能：优化重复计算的部分，引入缓存机制，减少计算量，提高性能。
3.安全性：继续加强对敏感信息的保护，并注意常见的安全漏洞和攻击手段，防范信息泄露和篡改。
4.错误处理和异常处理：增加对可能出现的错误和异常情况的处理，保证程序的稳定性和可靠性。
阶段评审报告范文
阶段评审报告范文一、评审背景和目的随着项目的稳步推进，我们迎来了重要的阶段评审。
本次评审不仅是对前一阶段工作的全面检视，更是对未来工作的有力指导。
其目的在于确保项目始终沿着既定的轨道前进，及时纠正偏差，优化资源配置，为最终的成功奠定坚实基础。
二、评审内容本次阶段评审涵盖了项目计划、项目进度、项目质量、团队沟通和风险管理等方面。
我们不仅关注各项任务的完成情况，还对团队协作、沟通机制以及潜在风险进行了深入剖析。
三、评审方法和过程为保证评审的准确性和公正性，我们采取了多元化的评估手段。
除了召开项目团队成员参加的评审会议外，还进行了详尽的文档审核与实地考察。
每个环节都力求深入、细致，旨在发现潜在问题并提出针对性建议。
四、评审结果和发现的问题经过细致的评审，我们发现了一些不容忽视的问题。
项目进度方面，部分任务未能按计划完成，存在一定的滞后现象。
在任务质量方面，部分交付物未达到预期标准，需进一步优化和完善。
团队沟通方面，信息流通不畅的情况时有发生，影响了工作效率。
此外，风险管理方面仍有待加强，需要构建更加完善的预警与应对机制。
五、改进措施和建议为解决上述问题，我们提出以下改进措施和建议：首先，对项目计划进行动态调整，优化资源配置，确保关键任务按时完成；其次，加强质量管控，建立多级质量审核机制，确保交付物质量达标；再次，完善团队沟通机制，促进信息流通，提升团队协作效率；最后，强化风险管理，制定风险应对预案，降低项目风险。
六、总结本次阶段评审虽然揭示出不少问题，但也为我们指明了改进方向。
只要我们正视问题、积极改进，相信项目必定能够取得更加优异的成果。
我们将继续保持严谨的工作态度和高效的执行力，以确保项目圆满完成。
产品评审流程汇总表
方式、对库存物料的影 审时，发出会议 +NPI+CPQA+MSQE+PM+PMC
响，对已生产的产品之影 邀请
+Sourcing等人员
响等
评审会或评 估报告
一致同意
天线评估流程
评审报告
会议记录
会议
一致同意
会议
一致同意
会议
唯一决策
会议
唯一决策
会议
一致同意 暂无
有固定内 容,无点检 会议纪要 表
有固定内 容,无点检 会议纪要 表
原型项目阶 段关闭评审 11 （ES,PR,PP, MP）(含阶段 项目部 技术评审)
lisa
13
客户特殊需 求评审
14
订单项目评 审
15
订单项目关 闭评审
用户体验输
16
出评审（软 件，铃声，
效果，UI）
18
产品技术规 格评审
ES关闭评审：项目级
PR准入评审：项目级
PP准入评审：公司级；评委：市场，研发,物流，质量
34
新物料、新 工艺、新技 术测试标准 评审
客户与 产品质 量部
Eric
讨论原型或预研项目有关 新物料，新工艺，新技术 的测试标准和测试方法
项目立项后新物 料，新工艺，新 技术确认后一周 内
项目质量+测试+SQE+研 发工程师
35 金机会签
生产与 工厂质 量部
1、按BOM、客户需求表、 工厂评审在包装
相关ID设计师。
（此项评审是否
28
项目供应商 选择评审
确定项目供应商
局限于定制件\ 采管工程师+采购工程师 结构件）ID及3D +设计师+项目经理+SQA 图纸评估比价后 工程师
编码评审表模板
编码评审表模板
项目名称：项目负责人：
主审人：评审时间：
一：评审流程
1、由主审人、评审专家、项目负责人、若干程序员和软件测试人员组成一个评审小组，通过阅读
和讨论程序，对程序进行静态分析。
2、项目负责人提前把设计说明书、控制流程图、程序文本及有关要求、规范等文档分发给评审小
组成员，作为评审依据，小组成员在充分阅读这些材料之后，进入下一步。
3、召开程序编码审查会。
在会上，首先由程序员讲解其程序的逻辑，在此过程中，小组
成员可以提出问题，展开讨论，审查错误是否存在。
4、在讨论结束后，由项目负责人整理出一份《编码评审报告》，交给相关程序员。
5、若发现错误较多，或发现重大错误，则在改正之后，再次组织编码评审。
二：评审人员
三：编码错误清单
主审人的总结意见和签字：。
TR4评审报告模板
TR4评审报告1TR4产品质量评估 (4)1.1评审要素检查情况 (4)1.1.1评审要素符合情况 (4)1.1.2评审要素不符合项改进计划 (4)1.2规格实现情况（含规格变更情况） (5)1.3重大遗留问题评估 (6)1.4风险分析 (6)2TR4评审结论 (6)3过程规范和质量目标达成情况的评估 (8)3.1PQA过程评估 (8)3.2本次TR的度量指标 (8)3.3TR4质量目标完成情况 (8)4PDT核心组成员会签记录 (8)5公司质量部签发纪录 (9)注：通过插入目录方式自动生成，推荐保留二级目录。
TR4评审报告1TR4产品质量评估1.1评审要素检查情况1.1.1评审要素符合情况IPD-TR评审要素应该在PDCP之前被裁减，以反映不同产品的需求。
IPD-TR自检阶段或IPD-TR评审阶段才决定免评审的评审要素，将被视为“异常免评审要素”。
PDCP 之前被裁减的评审要素，则被视为“正常免评审要素”。
若评审分项为免，则在“评审要素总数”一栏填N/A1.1.2评审要素不符合项改进计划不符合项指分项评审要素表中不符合的要素，对于1个需要解决的不符合项，可能对应1个或多个改进活动。
这些改进活动是指落实到WBS3/4级计划或更细致的项目计划中的具体活动。
有些不符合项目不需要制定改进计划，只需要风险规避计划即可。
这需要根据产品现状进行判断。
1.2规格实现情况（含规格变更情况）先用文字概要说明Build规格的实现情况，多少规格已经实现，多少规格尚未实现。
对于未实现的主要规格，要在下面的表格中逐一列举并说明未实现的原因以及解决措施或对策。
进行本次TR之前会整理规格清单，对于发生规格变更的规格，要在第二张表格中逐一列举并说明发生变更的原因。
此处的规格变更是指相对于上一个IPD-TR点所变更的规格。
1.3重大遗留问题评估重大遗留问题就是产品测试和检视、评审中发现的尚未解决的重大问题。
问题级别一栏填写：致命、严重。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
OA系统 1.0
详细设计评审报告
文件控制文档编号分册名称总页数☑受控☐不受控
O A-1703 版本号 1.0
O A项目开发-详细设计评审报告第1册/共1册6页正文
审批
4页附录无
编制江华谭璨生效日期2014/4/10
湖南楚晟科技有限公司
修改变更记录：
更改条款及内容更改人
江华审批人
谭璨
更改日期
1.0 2014/4/10
声明：
在软件开发过程中的适当阶段对软件阶段产品进行评审，是确保软件产品最终质量的重要方法。
阶段评审可以对某个开发阶段的阶段产品进行评审，也可以对某几个开发阶段的阶段产品进行综合评审。
在每次阶段评审中，必须履行正式手续，填写必要的评审表格，以利于项目管理工作，利于产品验收时的质量检查工作。
项目阶段评审表由三张子表组成，表 1是对评审中指标问题记录
RPL(review problem log)；表2是评审总结报告RSR(review summary report)；表3是评审小组成员登记与签字表。
表 1评审问题记录（RPL ）
3
登记号
2014/4/10 RPL
评审问题记录 评审日期 评审性质评审√复审□
1 项目名 编号 O A 系统项目 问题摘要
项目编号 问题类型
是否解决 是 是 是 是 是 是 是 是
1 2 3 4 5 6 7 8 9 是否所设计的架构，包括数据流、控制流和接口，被清楚地表达了清晰性 清晰性
是否所有的假设、约束、策略及依赖都被记录在本文档了
数据元素、流程和对象的命名和使用在整套系统和外部接口之间是一致性 一致性 是否依照实际操作环境（硬件、软件和支持软件）进行详细设计 可行性 是否出现了错误的、缺少的或不完整的详细设计逻辑 编码规范 代码设计是否符合规范、是否符合概要设计要求 数据使用 是否已描述最低级别数据元素，是否已详细说明取值范围 算法设计
对所有算法设计、说明是否具体、明确 程序接口实现是
程序接口设计是否明确、具体
操作界面的设计是否采用了人性化的设置（例如：词汇、使用信息程序接口实现是
和进入系统的提示是否人性化） 10 程序输入输出是
11 12 13 14 程序所有输入输出是否描述具体清晰
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明可维护性 是
重要模块说明是 是否对主要逻辑模块进行了特殊的说明和解释 该设计能够提供错误检测和恢复吗？
可靠性
是 是
是否能够对该系统进行测试、演示、分析或检查来说明它是满足需易测性 求的
15 易测性 是 是
16 17 该系统是否能用增量型的方式来集成和测试 可追溯性
是否各部分的设计都能追溯到需求说明书的需求
表2 评审总结报告（RSR ）
登记号
3 RSR
评审总结报告
评审日期
201/4/10
评审性质评审□复审□
项目名 O A 系统项目
项目编号
1
评审主题 O A 系统详细设计评审报告、及阶段总结
组长
陈寨云
部门
开发部
评审小组 成员
成员 马跃、彭斌。
根据评审材料《OA 系统项目_详细设计说明书》（以下简称《详细设计》）以及系统开发已经
完成的模型，对 OA 系统项目的详细设计工作进行评审，对《详细设计》进行全面分析，这包括对
以下方面的分析：清晰性，完整性、一致性、可用性、数据的使用、算法实现、重要模块实现、程
序接口实现、程序的输入输出、程序可维护性、可靠性、易测性以及可追溯性等，通过对这些方面 的分析，得出有效结论为 O A 系统下一阶段提供可行的依据。
评审
任务
《OA 系统概要设计说明书》
评审
《OA 系统详细设计说明书》
材料
《OA 系统数据库详细设计说明书》及相关规范文档。
不需修改
通过
评审 稍作修改
通过，不需修改
结论
不通作重要修改 过 要重新评审
《OA 系统项目_详细设计说明书》细化和实现《OA 系统概要说明书》所定义的软件设计，
评论给出了OA 系统功能、算法和重要模块的实现细节。
设计内容范围在其控制范围内，技术路线可行，
文档格式内容规范，可作为OA 系统开发的依据，指导项目编码开发实现，评审小组同意通过评审。
表3评审成员登记与签字表
OA系统项目各阶段评审工作登记表
姓名职务评审日期
2014/3/10
2014/3/10
2014/3/10 备注
陈寨云马跃彭斌主评审员评审员评审员。