软件设计评审表-模板

合集下载

软件产品评审表

软件产品评审表
交互性要
第一反应原则;1•做什么事情有关联的针25求阿里木原则;
对性反应及语言(不用人联
想)。与当前操作是一对一
非局域化原则;
的对应关系,不拐弯抹角,
引导原则;
让用户无法理解。
互动性原则;
2.在编辑语言时想象是与阿里木机器人在进仃对话。
3.杜绝基于自己的理解摘取部分在自己思维中的信息,形成片面性局域性理解。必须是完整的提示性、指导性语言。让用户容易操作。

有条件通

结论方式
记录
一致决定口过半数表决
会议时间
评审人
评审人
评审人
评审人
日期
不予通过
:决定口评审负责人裁决决定口
评审
整改意见
界面
界面布局
界面布局的合理
布局合理,层次清晰。
5
性。
界面美观
界面的美观性。
界面美观。
5
设计
界面兀素
界面元素的一致性。
窗口、菜单、图标、按钮
等元素的一致性。
5
功能要求
技术运用
技术运用的合理
各种技术表现与具体内容
15
性;
有机结合,各种媒体使用协
内容实现的正确
调;
性。
多媒体信息的呈现可控;链
接准确、无死链。
4.事件化、情绪化、故事化、游戏化
软件性能
响应性要
页面转换的响应
页面转换快捷;
5

性;
对用户的操作及时作出交
互动过程中的响
互反馈;
应性;
稳定性要

帮助机制的完备
性;
错误处理机制完
备性;
确认退出机制的

软件设计评审表-模板

软件设计评审表-模板
9
用户接口是否模块化,并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
Байду номын сангаас16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术,避免使用怪异的、不易理解的方式和方法
设计范围、边界是否清晰,文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
评审项目
详细设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
检查项:项;有效检查项:项;通过项:项;通过率:%
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
需求是否可追溯到设计
编制: 日期: 审核: 日期: 批准: 日期:
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
5
设计陈述中的命名、属于和缩写是否上下文一致
完整性
5
文档有独立的版本说明部分

软件设计评审表-模板

软件设计评审表-模板
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
完整性
5
文档有独立的版本说明部分
6
有文档的文字目录页
7
有总体设计部分
8
有功能设计
9
有接口设计
10
有性能设计
追溯性
11
设计是否可以追踪到需求
12
需求是否可追溯到设计
符合性
13
是否每个设计都是可测试的或以别的方式可以确定的
14
9
用户接口是否模块化,并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术,避免使用怪异的、不易理解的方式和方法
设计范围、边界是否清晰,文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
评审项目
详细设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20

软件设计评审表-模板

软件设计评审表-模板
序号主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
5
设计陈述中的命名、属于和缩写是否上下文一致
完整性
5
文档有独立的版本说明部分
6
每个设计是否都有相应的标识
7
每个设计的输入/输出是否进行了描述
8
关键的用户接口是否进行了描述
9
用户接口是否模块化,并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术,避免使用怪异的、不易理解的 方式和方法
XXXXXXXXXXXX单位名称
软件设计评审表
项目名称
型号规格
软件产品
设计人
评审人员
部门
职务或职称
评审人员
部门
职务或职称
评审项目
概要设计说明书
评审日期
评审结果标记
合格不合格TBD待完成NA不适用
评审情况
检查项:项;有效检查项:项;通过项:项;通过率:%
序号」主要检查项
检查结果
说明
标准化
1
有规定的文档Байду номын сангаас识
设计范围、边界是否清晰,文档中是否清晰阐明了系统的 各项特性及预期的结果

软件设计评审报告模板

软件设计评审报告模板
类别
名字
工作单位
职务
主持 人
评审小组成员
记录员
2.
评审问题跟踪表
编号
问题描述
问题类型
严重性
提交者
提交日期
问题处理负责人
解决措施/原因说明
问题解决状态
实际关闭日期
问题关闭验证人
备注
1
2
3.
提示:由主持人或评审员填写此表格。
评审结论
[ ]工作成果合格,“无需修改”或者“需要轻微修改但不必再审核”。
[ ]工作成果基本合格,需要作少量的修改,之后通过审核即可。
附件九
文件状态:
[ ]草 稿
[ ]正式发布
[ ]正在修改
文件标识:
HDT_
当前版本:
作 者:
完成日期:
版本历史版ຫໍສະໝຸດ /状态作者参与者起止日期
备注
1.
提示:由评审主持人或评审员填写此表格。
待评审的
工作成果
工作成果名称、标识符、版本、作者、时间……
技术评审方式
(正式评审)或者(走查)
评审时间
评审地点
参加评审的人员
[ ]工作成果不合格,需要作比较大的修改,之后必须重新对其评审。
意见
负责人签字
签字: 日期:
Welcome To
Download !!!
欢迎您的下载,资料仅供参考!

软件设计评审检查表

软件设计评审检查表
测试计划检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略?
该测试计划是否详细说明所有测试活动的顺序?
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形?
该测试计划是否为所有测试定义了成功标准?
是否详细说明了参数的度量单位、取值范围、正确度和精度?
共享数据区域及其存取规定的映射是否一致?
可维护性
单元是否具有高内聚度和低耦合度(例如:对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小)?
性能
是否该单元的所有约束例(如过程时间和规模)都被详细说明?
可靠性
初始化是否使用到缺省值,缺省值是否正确?
包括了数据流、控制流和接口的单元设计是否已清晰的说明?
完整性
是否已定义和初始化所有的变量、指针和常量?
是否已描述单元的全部功能?
是否已详细说明用来实现该单元的关键算法(例如:用自然语言或PDL)?
是否已列出该单元的调用?
依从性
该文档是否遵循了该项目已文档化的标准?
是否采用了所要求的方法和工具来进行单元设计?
该测试计划是否充分地描述了被测试的功能?
该测试计划是否明确地描述了不被测试的功能?
该测试计划是否充分地描述了测试基线?
对于阶段交付,该测试计划是否有在每一阶段建立测试基线给下一阶段使用?
该测试计划是否定义了足够和正确的衰退测试?
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档?
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序?

P01评审记录-计划-软件计划评审模板

P01评审记录-计划-软件计划评审模板
1、环境要求
方式:□会签 ■会议(■选中/□未选,可多选)
时间: 20XX年9月26日 场所: 公司会议室 其他:投影仪
2、评审范围
XXXAPP《立项报告》《项目开发计划》、《配置管理计划》《质量保证计划》进行评审。
3、评审要求
1、时间安排是否合理。
2、开发任务是否合理。
3、人员安排是否合理。
4、配合人员
软 件 产 品 设 计 评 审 表
表:Q/YD-D-2.0-01编号:WDGeneral Office-01
项目名称
XXXAPP
项目编号
WDGeneral Office
评审类型
■策划 □设计输入(需求分析)□设计输出(设计说明书)(■选中/□未选)
申请人
XX20XX年9月25日
项 目 组 申请概要说明
5.决议通过《项目开发计划》《配置管理计划》《质量保证计划》,并批准执行。
(后附共0页)




不存在明显的问题。
左俊鑫20XX年9月26日
(后附共 0 页)




《立项报告》《项目开发计划》、《配置管理计划》《质量保证计划》的时间、开发任务和人员安排合理,予以批准执行。
决议:通过 □解决以上问题后通过□解决以上问题后于 年 月 日再次评审
评审组长(签字):XXX20XX年9月26日




不存在问题,故没有措施跟踪。
评审组长(签字):XXX20XX年9月26日
注:本表附页可使用任何格式。
评审组长:XXX评审组成员:XXX
其 他:无
5、附件名称
XXXAPP《立项报告》

软件设计评审检查表

软件设计评审检查表
完整性
是否已定义和初始化所有的变量、指针和常量?
是否已描述单元的全部功能?
是否已详细说明用来实现该单元的关键算法(例如:用自然语言或PDL)?
是否已列出该单元的调用?
依从性
该文档是否遵循了该项目已文档化的标准?
是否采用了所要求的方法和工具来进行单元设计?
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致?
可维护性
单元是否具有高内聚度和低耦合度(例如:对该单元的更改不会在该单元有任 何无法预料的影响并对其它单元的影响很小)?
性能
是否该单元的所有约束例(如过程时间和规模)都被详细说明?
可靠性
初始化是否使用到缺省值,缺省值是否正确?
是否在内存访问的时候执行了边界检查(例如:数组、数据结构、指针等)来 确保只是改变了目标存储位置?
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义?
是否对关键术语和缩略语进行定义和描述?
所使用的术语是否和用户/客户使用的一致?
需求的描述是否清晰,不含糊?
是否有对整套系统进行功能概述?
是否已详细说明了软件环境(共存的软件)和硬件环境(特定的配置)?
如果有会影响实施的假设情况,是否已经声明?
完成软件确认测 试说明、执行软件 确认测试、进行测 试分析、编写确认 测试报告
完成系统测试 说明、执行系 统测试、进行 测试分析、编 写系统测试报 告
是否将需求分别陈述,因此它们是独立的并且是可检查的?
是否所有需求都可以回溯到相应的需求素材,反之亦然?
是否已详细说明需求变更的过程?
Y:是TBD:不确定N:不是NA:不适用
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
评审情况
!
检查项:项;有效检查项:项;通过项:项;通过率:%
序号
主要检查项
检查结果
说明
{
标准化
1
有规定的文档标识
,
2
引用的文档现行有效
3
.
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整

5
设计陈述中的命名、属于和缩写是否上下文一致

完整性
5
文档有独立的版本说明部分

6
每个设计是否都有相应的标识
是否每个设计都是可测试的或以别的方式可以确定的
#
14
设计范围、边界是否清晰,文档中是否清晰阐明了系统的各项特性及预期的结果
15

逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
~
17
设计是否考虑到未来的扩充性
~
18
设计的系统是否易于维护

评审项目
详细设计说明书
/
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
'
7
每个设计的输入/输出是否进行了描述
8
$
关键的用户接口是否进行了描述
9
用户接口是否模块化,并且修改时不影响其他程序

10
是否提供了一致的错误处理机制

11
各子系统、模块之间的关系是否描述得清楚
,
12
系统的设计是否考虑了系统的可扩展性
13
[
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
说明
标准化
1
有规定的文档标识
2
!
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
<
4
文档签署完整
*
完整性
5
文档有独立的版本说明部分
:
6
有文档的文字目录页
~
7
有总体设计部分
8
(
有功能设计
9
有接口设计
%
10
有性能设计
`
追溯性
11
设计是否可以追踪到需求

12
需求是否可追溯到设计
.
符合性
13
XXXXXXXXXXXX单位名称
软件设计评审表
项目名称

型号规格
软件产品
设计人
>
评审人员
部门
职务或职称
评审人员
·;
{


评审项目
概要设计说明书
评审日期

评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
检查项:项;有效检查项:项;通过项:项;通过率:%
@
序号
主要检查项
检查结果
16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术,避免使用怪异的、不易理解的方式和方法
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
需求是否可追溯到设计
编制: 日期: 审核: 日期: 批准: 日期:
相关文档
最新文档