评审报告模版.docVIP

XX评审报告 1. 评审的组织 提示：由开发部项目经理填写此表格。 项目名称 评审类型 [走查/审查/复审] 时间 地点 参加 人员名单 姓名 工作单位（部门）、职务、职称 记录员 2．评审内容 提示：由开发部项目经理填写此表格。 序号 内容 1 功能说明 项目策划书/CQ编号 SRS/use case模型路径 分析设计模型路径 测试用例 源文件路径 (含数据库) 1、 2、 2 功能说明 项目策划书/CQ编号 SRS/use case模型路径 分析设计模型路径 测试用例 源文件路径 (含数据库) 1、 2、 … 3. 评审结果 评审内容(序号)： 走查人员(代码走查时填写)： 评审结果 问题描述 问题类型 (变更/缺陷/风险/待定) 评审意见/建议 总体意见 或建议 提示：评审后，1）代码缺陷由项目测试负责人录入TD的相应项目中；项目策划、SRS、分析设计及测试用例缺陷有项目SQA录入TD的QA项目中；2）评审引起的需求和设计变更则由项目经理提交变更申请（CQ）；3）评审发现的风险或待定问题，由项目经理在PWA的该项目计划中录入链接风险，SQA监督和跟踪。 附录A. 代码评审检查表 主要检查项 评价 实现代码是否完整正确地实现了设计方案？ 代码实现方式是否合理、高效？ 代码资源消耗、性能、执行效率、日志输出是否符合要求？ 是否有重复实现公司已有代码或开源代码的地方？ 代码编写是否符合编码格式规范？ 代码编写是否符合系统日志规范？ 代码编写是否符合安全编码规范？ 提交版本时是否填写详细的备注信息？ 项目源代码注释是否完整？注释和代码是否相符？ 配置文件的备注是否详细完整？ 代码中是否存在各方都不明确或不理解的地方? 人机界面是否符合UI规范？ 项目中有否采用新技术？这些新技术对项目的影响如何？对于今后的项目采用这些技术有何建议？ 项目过程中有哪些好的经验？ 项目过程中有哪些不足之处？今后如何改进？ 附录B. 需求规格说明评审检查表 主要检查项 评价 包及用例的划分是否有利于产品组件的选择部署？ 每个用例包是否使用unit-control保存至与用例包同名的子目录下？ 每个用例包是否都包含了，并且合理正确运用以驱动为原则的单向关联，包含、扩展及继承关系的用例框图？ 用例简述是否明确执行此用例的不同用户，和用户通过此用例要达到的最终结果？ 事件流是否明确描述了系统所有主要的，包括应有的分支动作，并指明了触发条件，且每个动作都是由应有的具体角色发送或接收的？ 当用例仅在另一个用例执行完毕后，或某个应用接口执行或驱动成功之后才能执行时，是否已在前置条件中明确说明？ 所有系统需求是否都至少映射到一个UseCase？ 所有角色和用例是否都被使用？是否存在重复？ 用例描述是否存在歧义或不一致性？ SRS是否明确了维护需求，如监视所需的日志或应用、系统管理员功能、可扩展能力？ SRS是否明确了安全需求，如访问和密码控制规定？ SRS是否明确了必要的性能需求，如某些功能所需的响应时间？ SRS是否明确了必要的稳定性需求，如系统在某些功能大量负载下保持有效的运行状态？ SRS是否尽可能完整地实现了用户需求？ 是否存在不可测试的需求？ 附录C. 项目策划评审检查表 主要检查项 评价 是否已经确定了业务需求？ 是否已经确定了系统构架方案？ 是否明确了项目范围和约束？ 是否识别了项目风险？ 是否评估了项目风险值及控制措施？ 是否确定了所有项目涉众（干系人）？ 是否确定了项目各项资源需求？ 是否确定了项目各项里程碑？ 是否确定了项目开发模式，？ 是否明确了项目进度计划完成时间？ 是否明确了项目系统测试计划完成时间？ 是否明确了项目风险控制计划完成时间？ 是否明确了项目质量保证计划完成时间？ 是否明确了项目配置管理计划完成时间？ 附录D. 分析设计评审检查表 主要检查项 评价 分析包的结构是否与系统用例包结构一致？ 是否分析定义出必要的边界类、控制类和实体类，通过其类图和协作图来表现相关系统用例的实现？ 必要的类方法和属性是否已经定义？ 每个分析类是否在其文本框中描述了真正的类名及其作用， 每个类方法是否描述了真正的方法名或实现类名，以及这些方法或实现类的作用和实现要求？ 必要的类之间关系是否用类图表示，且关系正确？ 协作图中各对象间的交互是否正确表示，且实现了系统用例的事件流？ 类图中各类关系、协作图中各对象间的交互是否足以描述了系统构架方案的实现？ 协作图文本框中是否具体说明了此系统用例功能的实现？ 是否已确定界面框架规范？ 是否已确定界面显示风格？ 是否确定了 数据模型图中的依赖关系是否正确？ 数据模型图中的依赖关系是否涵盖所有必要的表间关系？ 数据模型是否包含所有使用的表，且表和字段均有说明？ 数据模型各表应有的主键、索引是否已建