评审报告.docx
- 文档编号:23310848
- 上传时间:2023-05-16
- 格式:DOCX
- 页数:19
- 大小:21.89KB
评审报告.docx
《评审报告.docx》由会员分享,可在线阅读,更多相关《评审报告.docx(19页珍藏版)》请在冰豆网上搜索。
评审报告
评审报告
1.评审的组织
提示:
由项目经理填写此表格。
项目名称
评审类型
[走查/审查/复审]
时间
地点
参加
人员名单
姓名
工作单位(部门)、职务、职称
记录员
2.评审内容
提示:
由项目经理填写此表格。
序号
内容
1
功能说明
1、
2、
2
功能说明
1、
2、
…
3.评审结果
评审内容(序号):
走查人员(代码走查时填写):
评审结果
问题描述
问题类型
(变更/缺陷/风险/待定)
评审意见/建议
总体意见
或建议
附录A需求规格说明评审检查表
主要检查项
评价
一完备性
1所有必要的属性、假定和约束是否有完整描述
2是否所有的需求和约束都被分配了优先级
3是否明确定义了确定需求优先级的标准
4需求的状态是否描述正确
5是否描述了软件安装需求(打包,用户培训等)
6是否描述了开发环境与运行环境、如果用户要求是否明确了开发语言
二一致性
1所有的需求之间描述是否一致
2需求与相关文档之间是否描述一致
3需求描述是否与真实操作环境一致(例如.事件序列,数据率,带宽等)
4需求文档是否与业务需求一致
三数据用法
1所有的数据的类型、单位、精确度、约定、取值范围和边界条件等是否被确定
2是否所有数据及其组成被明确描述
3是否描述了全局数据与逻辑数据之间的映射
4是否描述了数据储存方法
5是否提供了储存与共享数据的功能与方法
6是否描述了对存储数据的完整性要求
7是否描述了对被储存数据的操作频率与类型
8是否描述了共享数据的访问方式(例如:
随机、有序等)
四文档/清晰性
1系统的目标是否得到定义
3对术语的描述是否与用户和最终客户一致
3需求是否清晰无歧义
4是否有对程序实现的功能的概括描述
5是否对操作的方法、状态等进行了描述
6是否明确描述了软硬件环境
7是否明确描述了影响执行的假定
8每项需求是否描述了状态、输入、输出与处理方法
五功能性
1功能需求描述是否充分满足了客户与最终用户的需求
2每项功能性需求的输入是否是充分与必须的
3每项功能性需求是否清晰的描述了输入(包括共享数据)是如何变换为输出的(包括共享数据)
4是否功能性需求的所有状态都得到了定义
六接口
1是否所有的外部和内部的接口都是充份的和必需的
2是否每项功能性需求的输出都可以明确为另一个功能性需求的输入或外部接口
3是否描述了所有与系统相关的软硬件系统的接口与人机交互接口
4是否所有的显示界面的内容、格式与约定都得到了清晰描述
5是否所有的数据元素都得到了充分描述
6是否清晰充分地描述了功能性需求之间的数据流
7是否所有的接口数据得到了清晰充分描述
七细节
1是否所有标明“ToBeDetermineds”(TBDs)的问题都得到解决
2是否所有的接口都描述充分足以开展设计工作
3是否所有功能性需求描述充分足以开展设计工作
4是否所有性能需求描述充分足以开展设计工作
5是否每项功能性需求的输入和输出、准确性,精确度,范围,类型,比率,单位,频率都被描述
八可维护性
1是否需求之间是弱耦合的(例如:
改变某项需求不会对子系统产生意想不到的影响)
2需求是否会将设计的复杂度降到最低
3功能性需求中是否考虑到可维护性的要求
4是否考虑到重用已有的设计,是否对设计及集成的效果进行了描述
5在功能性需求是否考虑了可移动性
6继承的和预定义的工具情怀设计是否得到了描述
九性能
1是否所有的性能需求都可分配到具体的功能需求
2是否描述了对资源及其限制的性能需求
十可靠性
1是否定义了可度量的质量目标等质量特性
2是否可靠性需求可以分配到功能性需求
3是否有效性需求可以分配到功能性需求
4是否描述了安全性需求并可分配到功能性需求
5所有不期望事件及其响应都得到了描述
6是否考虑了特殊的初始状态(例如断电与异常终止等)
7功能需求之间的序列被陈述,并且这些序列是必须的
8是否描述了错误检查及恢复需求
十一标准
1文档格式是否符合项目定义的标准
十二可测试性
1是否所有程序可以被测试、证明、分析或检查以确定是否符合需求
3需求的每个状态是否是离散的、明确的可测试的
3是否所有的程序都定义了验收准则
4是否定义了明确的通过/不通过标准
5是否为每项需求描述了测试方法(测试,示范,分析或检验)
十三环境
1是否依照需求开发的产品可以在最终用户操作环境运行
十四可追踪性
1是否所有函数、结构、限制等都可以被追踪到需求,反之亦然
2是否所有的需求都可以分配到适当的函数
3是否所有的设计目标和执行都得到了实现
附录B概要设计评审检查表
主要检查项
评价
一完备性
1是否在需求文档中定义的需求都在概要设计中得到了解决
2是否在设计过程中考虑到需求中TBD的预期变化
3是否评估了TBD会产生的影响
4是否对可能不可行的概要设计准备了风险计划
5是否有设计模型并文档化
6是否定义了折衷方案并给出选择依据,并给出不选择其他方案的理由
二一致性
1在设计中是否考虑了真实操作环境(硬件、软件与支持软件)
三正确性
1从进度、成本与技术能力等方面考虑,设计是否可行
2是否有错误、缺失或不完备的逻辑
四数据用法
1是否所有相关的数据元素、参数与对象都得到了定义
2是否提供了管理、储存与共享数据的功能与方法
3是否所有需要的数据都得到了定义了吗,同时没有定义不必要的数据
五文档/清晰性
1在体系结构设计中,是否清晰描述了数据流、控制流与接口
2在设计说明书中是否描述了所有的假设、约束、决定与依赖
3是否定义了目标
4在合适时,是否有设计是否多样的、一致的
六功能性
1对每个子模块是否都做了简要描述并概略描述了采用的算法
2选择的设计或算法是否满足需求
七接口
1所有接口的描述是否与需求文档一致
2在软件各个功能模块之间的数据流是否得到了明确描述
3是否对所有的元件之间的接口都进行了定义
4是否接口的定义正确、合理
5是否所有的外部接口定义可以追索到需求
八细节
1是否每个子模块的规模都得到估计(KLOC,FPA)并且是合理的
2是否考虑了所有可能的状态和用例
3是否描述足够详细以至于可以开始详细设计阶段
九可维护性
1设计是否高内聚、低耦合的
2设计是模块化的吗
3设计是否采用了继承,是否描述了选择的工具
十性能
1在适当量,是否建立了性能模型并文档化
2是否主要的性能参数明确(例如实时要求,内存、处理速度、I/O等)
3是否识别并分析了执行的关键路径
十一可靠性
1设计是否满足了系统的完整性需求
十二标准
1文档格式是否符合项目定义的标准
十三可测试性
1是否设计可以被测试、证明、分析或检查以确定是否符合需求
2设计是否可以以增量和方式进行集成以进行测试
十四可追踪性
1是否所有的设计可以追踪到需求、业务需求
2设计时是否考虑以后文追踪需求
3采用的以前的设计文档是否可得到
4复用以前的设计的风险是否识别并分析
附录C.详细设计评审检查表
主要检查项
评价
一清晰性、完整性清晰性
1是否清晰的描述了单元设计信息,包括数据流程、控制流程、接口
2文档结构是否清晰、组织是否合理
3文档结构是否便于维护和修改
4设计是否易于理解
5每个单元模块是否都有相应的标识
6是否对单元模块的目的和功能进行了描述
7每个单元模块的输入/输出是否进行了描述
8是否说明了用于实现该单元模块的算法
9是否提供了一致的错误处理机制
10系统结构是否合理、清晰
11各子系统、模块之间的关系是否描述得清楚
12系统的设计是否考虑了系统的可扩展性
13设计是否考虑了重用性
14重用构件是否进行了标识
15是否说明了重用模块的获得方式和相关的文档
16系统的设计是否考虑了系统的易移植性
17设计是否使用标准的技术,避免使用怪异的、不易理解的方式和方法
18是否列出了所有的调用
19对变量、指针和常量进行了定义和初始化吗
20设计能实现特定的需求和目标吗
21是否对程序的注释进行了设计
22是否对程序的限制和约束进行了说明
23所有设计是否是可测试的
二一致性、正确性
24文档是否符合项目标准
25是否用要求的方法或工具进行设计的
26数据元素的名称在整个单元中保持一致吗
27所有的设计接口相互间是一致的吗
28是否存在逻辑上的问题
29是否对各种情况都进行了处理(如大于、等于、小于0,switch/case情况)
30是否为开发和维护代码提供了充分的基础
31所有的设计单元都可追溯回需求吗
三接口
32参数的数量、类型和顺序是否匹配
33是否正确的定义了输入输出数据
34是否清晰的描述了传递参数的顺序
35是否识别了传递参数的机制
四可维护性、可靠性
36设计单元是否具有高内聚度低耦合度(即该单元的变化不会对本单元造成不可预料的影响,对其他单元的影响达到最小)
37设计的复杂度已经最小了吗
38是否具有清晰性、可读性、可修改性,满足维护需求
39是否设定了正确的初始化缺省值
40是否对输入、输出、接口和结果进行了错误检查
41是否对错误情况给出了有意义的信息提示
42是否考虑了意外情况
43是否符合相关的法律法规
附录D.项目策划评审检查表
主要检查项
评价
是否已经确定了业务需求
是否已经确定了系统构架方案
是否明确了项目范围和约束
是否识别了项目风险
是否评估了项目风险值及控制措施
是否确定了所有项目涉众(干系人)
是否确定了项目各项资源需求
是否确定了项目各项里程碑
是否确定了项目开发模式,
是否明确了项目进度计划完成时间
是否明确了项目系统测试计划完成时间
是否明确了项目风险控制计划完成时间
是否明确了项目质量保证计划完成时间
是否明确了项目配置管理计划完成时间
附录E.分析设计评审检查表
主要检查项
评价
分析包的结构是否与系统用例包结构一致
是否分析定义出必要的边界类、控制类和实体类,通过其类图和协作图来表现相关系统用例的实现
必要的类方法和属性是否已经定义
每个分析类是否在其文本框中描述了真正的类名及其作用,
每个类方法是否描述了真正的方法名或实现类名,以及这些方法或实现类的作用和实现要求
必要的类之间关系是否用类图表示,且关系正确
协作图中各对象间的交互是否正确表示,且实现了系统用例的事件流
类图中各类关系、协作图中各对象间的交互是否足以描述了系统构架方案的实现
协作图文本框中是否具体说明了此系统用例功能的实现
是否已确定界面框架规范
是否已确定界面显示风格
是否确定了
数据模型图中的依赖关系是否正确
数据模型图中的依赖关系是否涵盖所有必要的表间关系
数据模型是否包含所有使用的表,且表和字段均有说明
数据模型各表应有的主键、索引是否已建立
是否已经确立实现系统构架方案的程序框架,并制定了开发指南
附录F.代码评审检查表
主要检查项
评价
实现代码是否完整正确地实现了设计方案
代码实现方式是否合理、高效
代码资源消耗、性能、执行效率、日志输出是否符合要求
是否有重复实现公司已有代码或开源代码的地方
代码编写是否符合编码格式规范
代码编写是否符合系统日志规范
代码编写是否符合安全编码规范
提交版本时是否填写详细的备注信息
项目源代码注释是否完整注释和代码是否相符
配置文件的备注是否详细完整
代码中是否存在各方都不明确或不理解的地方
人机界面是否符合UI规范
项目中有否采用新技术这些新技术对项目的影响如何对于今后的项目采用这些技术有何建议
项目过程中有哪些好的经验
项目过程中有哪些不足之处今后如何改进
附录G测试用例评审检查表
主要检查项
评价
一清晰性
1用户操作指南是否清楚,便于测试步骤的执行
2用户操作指南是否一步一步按必需的执行顺序来说明
3安装和测试的步骤是否准确,无歧义,并且作为独立的项目
4当执行测试的重要部分时,是否有“进度”信息提示用户
5成功/失败的标准是否定义清楚并且无歧义
二完整性
1每个需求是否都分配了测试用例
2每个设计项是否都分配了测试用例
3每行代码是否都至少在一个测试用例中覆盖了
4所有定义的和使用的数据流是否都至少在一个测试用例中覆盖了
5是否针对以前出现过的那些常见错误提供专门的测试用例
6所有的简单边界条件是否都做过测试(例如最大最小值)
7复杂的边界条件是否做过测试(例如不同的输入数据组合后可能产生最大最小值)
8有没有检查输入数据合法性的测试用例
9提供的测试用例对语句覆盖率作过考虑吗
10被测功能是否有正确描述
11被测功能是否最新版本
12此测试步骤的目的描述是否完整、准确
13是否会对此功能相关的每个需求都用此测试步骤进行测试
14每个测试步骤的预期响应是否在用户操作指南中有描述
15测试步骤是否会列出测试的先后次序
16测试步骤是否会指出正确评价测试结果的重要性
17是否说明了在程序停机或显示错误时,步骤是否可以继续进行
18在被测功能中,是否有足够数量的控制路径被测试
19测试步骤是否能判定成功还是失败
20在被测功能中,是否有足够数量的逻辑条件表达式被测试
21测试用例是否说明了程序对非法和冲突的输入数据的响应
三一致性
1是否对测试步骤的所有依赖性都进行了识别
四准确性
1运行步骤后得到的实际结果是否和预期的相一致
2被测代码和测试仪器与软件之间的接口是否正确
五性能
1如果性能标准和测试步骤的任何一步相关,是否有明确的说明
六可靠性
1测试设备是否已经确认和校准
2测试软件是否经过确认
3所有输入数据是否都被验证
4是否收集和记录了足够的测试数据以支持软件可靠性的评估
七易测性
1测试步骤是否识别了所有测试所必需的设备、软件和人员
2测试步骤是否能在开发组提供最少支持的情况下进行
3测试步骤是否和测试设备的能力相一致
4测试用例是否具有较强的可读性和可操作性
八兼容性
1对数据的兼容性是否做过测试
2对不同的硬件配置是否做过测试
3在不同版本的操作系统上是否做过测试
九可追踪性
1测试步骤是否列出操作必需的所有规格、步骤、手册或操作手册
2需求和验收测试组合间的追溯性是否被体现
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 评审 报告
![提示](https://static.bdocx.com/images/bang_tan.gif)