评审检查表veryimportant.docx
- 文档编号:13683901
- 上传时间:2023-06-16
- 格式:DOCX
- 页数:24
- 大小:24.05KB
评审检查表veryimportant.docx
《评审检查表veryimportant.docx》由会员分享,可在线阅读,更多相关《评审检查表veryimportant.docx(24页珍藏版)》请在冰点文库上搜索。
评审检查表veryimportant
评审检查表
文档修改情况记录
版本
修改状态
修改日期
修改摘要
修改人
5.项目计划检查表
项目计划检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
✓合格✗不合格TBD待完成NA不适用
检查情况
检查项:
项;有效检查项:
项;通过项:
项;通过率:
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
完整性
5
文档有独立的版本说明部分
6
文档列出了项目的验收标准
7
文档列出了项目组成员和项目相关人员、角色、职责
8
文档选定了项目生命周期模型
9
文档选定了项目里程碑
10
对项目进行了估计(规模、工作量、进度、关键计算机资源、成本)
11
进行了WBS工作分解
12
文档作了项目的风险估计及风险管理计划
13
文档分析了项目所需的知识技能及培训计划
14
编写了配置管理计划
15
编写测试计划
16
编写质量保证计划
17
使用project项目管理工具编写项目进度计划
符合性检查
18
风险管理计划的风险是否排序,对前三个是否进行了分析,缓解计划是否合理
19
培训计划中的培训内容是否是项目组需要的、可行的
20
配置管理计划中的配置库机构划分是否合理,是否对开发过程中的工作产品进行了配置项的设置
21
质量保证计划是否检查了列表,和开发计划的进度是否一致
22
项目进度计划的工作任务是否包括了生命周期的所有工作(如:
是否覆盖了所有需求的设计和开发)
23
项目进度计划的资源和时间分配是否合理,里程碑的划分和交付物是否明确
承诺性
24
计划中列出的相关人员是否都了解自己的角色和职责,并在承诺记录上签字
6.需求规格说明书检查表
需求规格说明书检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
✓合格✗不合格TBD待完成NA不适用
检查情况
检查项:
项;有效检查项:
项;通过项:
项;通过率:
序号
主要检查项
检查结果
说明
标准化
7.
有规定的文档标识
8.
引用的文档现行有效
9.
文档编写的内容、格式符合相关标准、规定的要求
10.
文档签署完整
11.
设计陈述中的命名、术语和缩写是否上下文一致
完整性和正确性
12.
文档有独立的版本说明部分
13.
没有丢失任何需求或必要信息,重点在于用户任务
14.
是否包括了所有的原始需求(指系统或软件需求,通常限制在开发或验证上)
15.
是否列出了系统所必须的依赖、假设以及约束
16.
数据精度、时间特性和适应性是否已经明确
17.
运行需求是否明确(运行平台、接口需求、用户界面等),符合初始需求
18.
对质量的要求是否明确、合理(正确性、健壮性、安全性等)
19.
是否分析了潜在的需求
20.
是否标识并解决了需求中的潜在问题
21.
需求说明书是否已包括了主要的质量属性,例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性。
一致性
22.
是否存在冲突或重复的需求项
23.
开发计划、产品和活动与需求是否保持一致
24.
是否可以根据软件需求规范中的信息制定出详细的测试集,并且每项需求是否可以测试
25.
需求与相关文档之间是否描述一致
清晰性
26.
是否对关键术语和缩略语进行定义和描述
27.
需求是否清晰无歧义
28.
系统的目标是否已定义
29.
是否有对整套系统进行功能概述
30.
是否已详细说明了软件环境(共存的软件)和硬件环境(特定的配置)
31.
每项需求是否描述了状态、输入、输出与处理方法
可靠性
32.
是否定义了可度量的质量目标等质量特性?
33.
所有不期望事件及其响应都得到了描述?
34.
是否考虑了特殊的初始状态(例如断电与异常终止等)
35.
是否描述了错误检查及恢复需求?
可维护性
36.
是否需求之间是弱耦合的(例如:
改变某项需求不会对子系统产生意想不到的影响)
37.
需求是否会将设计的复杂度降到最低
38.
功能性需求中是否考虑到可维护性的要求
39.
是否考虑到重用已有的设计,是否对设计及集成的效果进行了描述
可追踪性
40.
是否所有函数、结构、限制等都可以被追踪到需求,反之也可以
41.
是否所有的需求都可以分配到适当的函数
42.
是否所有的设计目标和执行都得到了实现
43.概要设计说明书检查表
概要设计说明书检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
✓合格✗不合格TBD待完成NA不适用
检查情况
检查项:
项;有效检查项:
项;通过项:
项;通过率:
序号
主要检查项
检查结果
说明
标准化
44.
有规定的文档标识
45.
引用的文档现行有效
46.
文档编写的内容、格式符合相关标准、规定的要求
47.
文档签署完整
完整性
48.
文档有独立的版本说明部分
49.
是否在需求文档中定义的需求都在概要设计中得到了解决
50.
是否所有的以前的TBD(待确定条目)都已经被解决了
51.
是否所有的TBD的影响都已经被评估了
52.
是否仍存在可能不可行的设计部分
53.
是否在设计过程中考虑到需求中TBD的预期变化
54.
有文档的文字目录页
55.
有总体设计部分
56.
有功能设计
57.
有接口设计
58.
有性能设计
追溯性
59.
设计是否可以追踪到需求
60.
需求是否可追溯到设计
符合性
61.
是否每个设计都是可测试的或以别的方式可以确定的
62.
设计范围、边界是否清晰,文档中是否清晰阐明了系统的各项特性及预期的结果
63.
逻辑性、算法和处理过程是否正确
64.
文档是否符合客户的需要
65.
设计是否考虑到未来的扩充性
66.
设计的系统是否易于维护
67.详细设计说明书检查表
详细设计说明书检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
✓合格✗不合格TBD待完成NA不适用
检查情况
检查项:
项;有效检查项:
项;通过项:
项;通过率:
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
5
设计陈述中的命名、属于和缩写是否上下文一致
完整性
5
文档有独立的版本说明部分
6
每个设计是否都有相应的标识
7
每个设计的输入/输出是否进行了描述
8
关键的用户接口是否进行了描述
9
用户接口是否模块化,并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术,避免使用怪异的、不易理解的方式和方法
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
需求是否可追溯到设计
68.编码检查表
通过结合编码检查表和代码检查单,可以比较清楚地确定代码问题的位置。
5.1代码检查表
代码检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
✓合格✗不合格TBD待完成NA不适用
检查情况
检查项:
项;有效检查项:
项;通过项:
项;通过率:
序号
主要检查项
检查结果
说明
规范性
1
编码是否符合项目或组织的编码标准
2
头文件包含是否完整
3
参数在程序开始时是否被初始化
4
参数在程序循环时是否被初始化
5
在函数或过程调用的时候参数是否被初始化
6
函数调用的格式和参数是否正确
7
变量的声明和拼写是否一致
8
变量声明的范围是否恰当
9
是否所有的指针都被初始化为NULL
10
程序中申请的内存使用后是否释放
11
是否每个==、‖等都验证了正确性
12
是否打开的文件都及时关闭了
符合性
13
源代码单元是否已经完成
14
源代码单元是否已经经过了调试
15
源代码单元是否实现了设计的全部功能
5.2代码检查内容
重要性
激活
级别
检查项
命名
重要
20
命名规则是否与所采用的规范保持一致
重要
20
是否遵循了最小长度最多信息原则
重要
50
has/can/is前缀的函数是否返回布尔型
注释
重要
10
注释是否清晰且必要
重要
Y
10
复杂的分支流程是否已经被注释
10
距离较远的}是否已经被注释
10
非通用变量是否全部被注释
重要
Y
50
函数是否已经有文档注释(功能、输入、返回及其他可选)
10
特殊用法是否被注释
声明、空白、缩进
20
每行是否只声明了一个变更(特别是那些可能出错的类型)
重要
40
变更是否已经在定义的同时初始化
重要
40
类属性是否都执行了初始化
20
代码段落是否被合适地以空行分隔
Y
20
是否合理地使用了空格使程序更清晰
20
代码行长度是否在要求之内
20
折行是否恰当
语句/功能分布/规模
20
包含复合语句的{}是否成对出现并符合规范
20
是否给单个的循环、条件语句也加了{}
20
If/if-else/if-elseif-else/do-while/switch-case语句的格式是否符合规范
40
单个变量是否只做单个用途
重要
20
单行是否只有单个功能(不要使用“;”进行多行合并)
重要
40
单个函数是否执行了单个功能并与其命名相符
Y
20
操作符++和—的应用是否符合规范
规模
重要
20
单个函数是否不超过规定行数
重要
缩进层数是否不超过规定
可靠性(总则/变量和语句)
重要
是否已经消除了所有警告
重要
Y
40
常数变量是否声明为final
重要
80
对象使用前是否进行了检查
重要
80
局部对象变量使用后是否被复位为NULL
重要
70
对数组的访问是否是安全的(合法的index取值为[0,MAX_SIZE-1])
重要
20
是否确认没有同名变量局部重复定义问题
20
程序中是否只使用了简单的表达式
重要
Y
20
是否已经用()使操作符优先级明确化
重要
Y
20
所有判断是否都使用了(变量==)的形式
80
是否消除了流程悬挂
重要
80
是否每个if-else语句都有最后一个else以确保处理了全集
重要
80
是否每个switch-case语句都有最后一个default以确保处理了全集
80
for循环是否都使用了包含下限不包含上限的形式(k=0;k 重要 40 XML标记书写是否完整,字符串的拼写是否正确 40 对于流操作代码的异常捕获是否有finally操作以关闭流对象 20 退出代码段时是否对临时对象做了释放处理 重要 40 对浮点数值的相等判断是否是恰当的(严禁使用==直接判断) 可靠性(函数) 重要 Y 60 入口对象是否都被进行了判断不为空 重要 Y 60 入口数据的合法范围是否都被进行了判断(尤其是数组) 重要 Y 20 是否对有异常抛出的方法都执行了try…catch保护 重要 Y 80 是否函数的所有分支都有返回值 重要 50 int的返回值是否合理(负值为失败,非负值为成功) 20 对于反复进行的int返回值判断是否定义了函数来处理 60 关键代码是否做了捕获异常处理 重要 60 是否确保函数返回CORBA对象的任何一个属性都不能为null 重要 60 是否对方法返回值对象做了null检查,该返回值定义时是否被初始化 重要 60 是否对同步对象的遍历访问做了代码同步 重要 80 是否确认在对Map对象使用迭代遍历过程中没有做增减元素操作 重要 60 线程处理函数循环内部是否有异常捕获处理,防止线程抛出异常而退出 20 原子操作代码异常中断,使用的相关外部变量是否恢复先前状态 重要 函数对错误的处理是否恰当 可维护性 重要 实现代码中是否消除了直接常量(用于计数起点的简单常数例外) 20 是否消除了导致结构模糊的连续赋值(如a=(b=d+c)) 20 是否每个return前都要有日志记录 20 是否有冗余判断语句(如: if(b)returnture;elsereturnfalse;) 20 是否把方法中的重复代码抽象成私有函数 备注: 1)激活: 本列标注Y的为激活的项目,表明这些项目必须被明确地自查(其他问题处于“顺便被检查”的状态),在运行编码检查的时候,前期几乎所有项都要在激活状态;后期稳定后,保持8~10个(或遵从当前规范)激活的检查项。 为了醒目,可以像此表这样将当前的激活项用亮黄色表示。 2)级别: 使用IBM10级法,分别是 10 文档 注释,消息 20 语法 拼写,标点符号,打字,指令格式 30 联编打包 变更管理,库,版本控制 40 复制 说明,重名,作用域,限制 50 接口 过程调用和引用,输入/输出,用户格式 60 检查 出错信息,不合适的检查 70 数据 结构,内容 80 函数 逻辑,指针,循环,递归,计算,函数缺陷 90 系统 配置,计时 100 环境 设计,编译,测试,其他支持系统问题 其中10~40是编码错误,50~100是设计错误。 3)检查项: 所有检查项均为一般疑问句,当发现回答为“否”时,即存在一个缺陷。 69.测试用例检查表 测试用例检查表 项目编号 工作产品 检查日期 检查人员 检查结果标记 ✓合格✗不合格TBD待完成NA不适用 检查情况 检查项: 项;有效检查项: 项;通过项: 项;通过率: 序号 主要检查项 检查结果 说明 完整性 1 测试用例是否覆盖了测试计划的测试需求中描述的所有测试类型和功能点 2 每个测试用例是否清楚地填写了测试特性、步骤、预期结果 3 用例设计是否包含了正面和反面的用例 4 非功能测试需求和不可测试需求是否在用例中列出并说明 5 不同业务流程用例是否覆盖 6 测试用例是否包含测试数据、测试数据声称办法或者输入的相关描述 7 每个测试用例前是否有标识 8 用例陈述中的命名、术语和缩写是否上下文一致 9 是否所有的指针都被初始化为NULL 追溯性 10 系统测试用例是否可追溯到产品需求 11 产品需求是否可追踪到系统测试用例 12 集成测试用例是否可追溯到概要设计 13 概要设计是否可追踪到集成测试用例 70.产品验收和发布检查表 测试用例检查表 项目编号 工作产品 检查日期 检查人员 检查结果标记 ✓合格✗不合格TBD待完成NA不适用 检查情况 检查项: 项;有效检查项: 项;通过项: 项;通过率: 序号 主要检查项 检查结果 说明 1 产品是否已经通过集成测试 2 产品是否已经完成了用户要求的全部功能或与用户达成一致 3 产品的各个部分是否都是最新版本 4 产品的名称、版本号是否正确 5 产品的各个部分是否都经过了评审 6 是否提供了用户手册 7 用户手册是否与产品的版本一致 8 是否提供了所有产品的清单 9 是否说明了使用产品应当注意的问题 10 是否表明了产品的版权 71.测试计划检查表 测试计划检查表 项目编号 工作产品 检查日期 检查人员 检查结果标记 ✓合格✗不合格TBD待完成NA不适用 检查情况 检查项: 项;有效检查项: 项;通过项: 项;通过率: 序号 主要检查项 检查结果 说明 完整性 1 该测试计划是否详细说明测试的大体方法和策略 2 该测试计划是否详细说明所有测试活动的顺序 3 该测试计划是否描述了将使用的软硬件系统环境 4 该测试计划是否描述了测试活动中断和恢复的条件/情形 5 该测试计划是否为所有测试定义了成功标准 6 该测试计划是否充分地描述了被测试的功能 7 该测试计划是否明确地描述了不被测试的功能 8 该测试计划是否充分地描述了测试基线 9 对于阶段交付,该测试计划是否有在每一阶段建立测试基线给下一阶段使用 依从性 10 该测试计划是否依从了与开发有关的所有说明书、标准和文档 一致性 11 是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序 12 该测试计划是否和更高级别的测试计划文档一致 正确性 13 该测试计划的进入和退出条件是否实现 14 是否所有必须的驱动程序和桩(stubs)都已被定义且可利用来测试指定的功能 详细级别/程度 15 测试案例是否完整覆盖了所有功能,是否覆盖了被测试功能的正常执行情况 16 测试案例集是否覆盖了足够的非法和冲突的输入 17 测试案例集是否包括了足够的默认输入值的使用 18 测试案例集是否考虑到了足够数量的程序错误路径 易测性/可行性 19 测试方法是否可行 20 是否所有被认为不可测的需求都被详细说明并说明原因 21 是否对获得测试软件、方法和工具分配了足够的时间并形成了进度计划 22 测试所要求的资源是否已经详细说明和估计 23 对于多次的构建(builds),是否已在前一构建的基础上确定所有的需求 24 测试所包含的所有人员的角色和职责是否都已详细说明 25 在已计划的测试人员之间是否存在进度冲突 可追溯性 26 测试是否有执行/演示在适当级别的文档所说明的需求? 27 测试验收标准是否可追溯到更高级别的文档?
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 评审 检查表 veryimportant