软件产品评审表

合集下载

体系产品要求评审表样本

体系产品要求评审表样本
填写人:日期:
总经办(评审质量保证能力)
填写人:日期:
生产部(评审产品生产能力及交货期规定)
填写人:日期:
品技部(评审技术保证能力和产品检测能力)
填写人:日期:
供销部(评审原材料供应能力、产品交付方式、服务规定、合同合法性、完整性和明确性)
填写人:日期:
评审结论
签ห้องสมุดไป่ตู้:日期:
备注
注:“信息来源”栏填电话、传真或合同草案及其相应编号。
产品规定评审表
Q/YF.CXC03-02-B01 编号:
□初次评审 □变更(原评审表号: )
顾客名称
联系人
电话
产品名称
规格/型号
订货数量
进度规定
信息来源
合同类别
顾客对产品明示与潜在规定(技术规定、质量规定、支持服务、价格等)
填写人:日期:
我司为满足顾客规定所作出承诺
填写人:日期:
国家、行业原则及法律法规规定

互联网软件项目评审表

互联网软件项目评审表

5
6
7
界面元素
界面元素的一致 窗口、菜单、图标、按钮

等元素的一致性
10
技术运用的合理 各种技术表现与具体内容
技术运用
性; 内容实现的正确
有机结合,各种媒体使用 协调;多媒体信息呈现可208 功能要求

控;连接准确、无死链。
1.软件的易用性,不让用
第一反应原则; 户无法理解
交互性要求 引导原则;
2.必须有完整的提示、指
主审人 评审人
评审人 评审人
15
A
B
16
17
18
19
20
21 评审会议记录
22
23
C
D
E
F
G
24 25 26
记录人签名 27
评委表决记录 无条件通过 28
结论方式记录 一致决定 29 30 31 32 评审整改意见 33 34 35
日期
有条件通 过
过半数表决决定 评审负责人
不予通 过
裁决决定
A 1
B
C
D
E
F
G
项目评审表
项目名称 2
评审项目 3
评审细项
策划人
评审指标 (评审要点)
指标说明 (评审要点说明)
最高分 值
分值
相对完整的完成软件需求
产品内容 产品内容 内容的完整性 功能;有明确的使用者定
10
位 4
5
界面布局
界面布局的合理 性
布局合理,层次清晰
5
界面
界面美观 界面美观设计 界面美观
25
互动性原则
导性语言,让用户容易操
9

软件设计评审表-模板

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

(整理)SE-Checklist-TR1ChecklistTR1评审表-030000.

(整理)SE-Checklist-TR1ChecklistTR1评审表-030000.
工程设计是指RAS-DFX方面,由系统工程师负责.有可能在产品开发团队中成立产品工程设计小组对此负责.
RAS:可靠性\可获得性\可服务性.
A
关联:
Sub-TR:产品包需求
交付件:NA
活动:NA
Link:
Sub-TR:Offering Requirements
Deliverables:Usability And Benchmark Requirements
此项建议由开发代表/测试人员给出评审意见
It's recommended thatRDPDT/EEis responsible for this checklist item
A
关联:
Sub-TR:产品包需求-可测试性需求
交付件:NA
活动:NA
Link:
Sub-TR:Offering Requirements -Testability Requirements
软件是否具备行为跟踪、控制支撑功能,是否具备系统日志、测试能力安装与配置功能,是否提供标准外部测试接口,是否符合《软件可测试性工程技术规范》之STES01标准?
Does the software support the functions such as behave tracing, action control, system log, testability configuration and etc? Can it supply external test interface? Does it meet the requirement of STES01 in Software testability engineering technical specification?

软件设计评审表-模板

软件设计评审表-模板
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

软件设计评审表模板

软件设计评审表模板

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

4.2 软件项目产品质量评审表

4.2 软件项目产品质量评审表
系统能根据查询结果生成报表输出
查询结果少了统计信息
在报表增加相关统计信息
产品的性能指标
数据库查询时系统的响应时间不大于20秒
显示性指标
产品上线以后,产品出现Bug的频度为每周不能多于4个
试用一周时发现了10个Bug
☆☆☆☆☆
增加测试力度,必须保证上线前的Bug出现频度。
4.2软件项目产品质量评审表
项目名称
项目经理
产品功能性指标
指标
实际情况
重要性(五分制)
评审结果
人员、区域管理
满足实际业务要求
通过
权限管理
只对部门进行了管理,没有对区域权限进行管理
增加对区域权限进行管理
产品是带图标的图形用户界面
只是下拉菜单的界面,不生动
停止其它模块的开发,赶快修改现有模块界面
产品的输出界面和报表

软件质量保障-软件架构评审表Design Review Checklist

软件质量保障-软件架构评审表Design Review Checklist

Design Review ChecklistArchitecture DesignGeneral:Does the architecture convey a clear vision ofthe system that can be used for furtherdevelopment?Is the architecture structured to support likelychanges?Does the architecture describe the system at ahigh level of detail? (No interface orimplementation details.)Does the architecture cleanly decompose thesystem?Is the architecture independent of theinfrastructure used to develop the system?Has maintainability been considered?No duplicate functionality in the architecture?Complete:Are software requirements reflected in thesoftware architecture?Is effective modularity achieved? Are modulesfunctionally independent?Does each module/class have anunderstandable name?Is each association well named?Is each association’s and aggregation’scardinality correct?Correct:Does each association reflect a relationshipthat exists over the lives of the relatedmodules/classes?Does the architecture have loose coupling andgood cohesion?1Detailed DesignGeneral:Does the design support moving to the next phase ofdevelopment?Does design contain proper level of detail?Does the design have conceptual integrity? (Qualitywhere the individual pieces all contribute to making alarger whole. Design consistency.)Will the design be easy to port to anotherenvironment?Have reusable components been identified?Is effective modularity achieved? Are modulesfunctionally independent?Complete:Is the class design consistent with architecturaldesign? (i.e., each class traceable to architecturalcomponent and no classes span architecturalcomponents)Does each class have an understandable name?Does each class define attributes, methods,relationships, and cardinality?Is each association well named?Is each association’s and aggregation’s cardinalitycorrect?2Correct:Does each class have a clearly defined purpose? Caneach class be described in a single sentence?Is a consistent naming scheme used for all classes?Are all attributes private?Are all method signatures specified including returntypes and parameters?Do all subclasses implement the "is-a-kind-of"relationship properly?Is there no duplicate functionality between classes inthe design?In inheritance structures, are all attributes and methodspushed as high in the inheritance structure as isproper?Are all polymorphic methods within related subclassesidentically named?Does each association reflect a relationship that existsover the lives of the related objects?Has error handling been specified?Is design detail amenable to implementation language?No hidden implementation details shown?Does design display high cohesion and low coupling?Consistent:Are each 0..* and 1..* relationships implemented withcontainers/collectors?Are each association’s cardinalities consistent(instantaneous vs. over-time)?Are the views provided by different modelingnotations consistent?Is a consistent naming convention used and followed?3。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
运行环境是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性。
布局合理,层次清晰。
2
界面美观设计
界面的美观性。
界面美观。
3
界面元素
界面元素的一致性。
窗口、菜单、图标、按钮等元素的一致性。
5
功能要求
技术运用
技术运用的合理性;
内容实现的正确性。
各种技术表现与具体内容有机结合,各种媒体使用协调;
多媒体信息的呈现可控;链接准确、无死链。
5
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出机Leabharlann 的完备性。每个操作都有联机帮助或提示;
联机帮助易读、易懂处理用户可能出现的任何错误操作;
避免出现数据未保留而退出。
5
安全性要求
访问安全性;使用安全性。
用户身份管理和访问控制;数据安全性。
10
软件文档
文档资料
文档资料的完整性;
文档资料的规范性。
软件
项目名称
开发小组
成员
组长
评审项目
评审细项
评审指标
(评审要点)
指标说明
(评审要点说明)
最高
分值
分值
产品内容
产品内容
内容的完整性。
即相对完整的完成软件愿景说明书上的功能。
5
软件定位
使用者的明确性。
即有明确的使用者定位。
5
软件部署
部署
软件的发布与部署。
部署后是否可以正常使用。
5
运行环境
运行环境的适用性。
15
交互性要求
简易性;一致性;反馈性;容错性;图形化。
人机交互简单、形象
输入、输出方面的一致性;
对用户的操作及时作出反馈;
对可能出现的错误进行检测、报告和处理。
15
软件性能
响应性要求
页面转换的响应性;
载入时间的短时间要求;
短时启动时间要求;
负载量(客户)指标明确化。
页面转换快捷;媒体装入时间简短;有确定的负载量性能指标。
有愿景说明书、开发计划说明书、需求规格说明书、架构设计说明书、详细设计说明书、测试报告等开发文档;
有开发过程管理文档;
有用户手册;
文档编写符合标准和要求。
20
总计
100
相关文档
最新文档