详细设计评审表
专家评审意见表
评审地点
贺兰
评审形式
会议
总评意见
通过（√）、不通过（）（括号内划√）
评审意见：
一、该项目工艺简单，危险化学品涉及品种少，设计专篇内容较全面，结核《银川市危险化学品建设项目安全评价及标准》中规定的内容编制，同意通过专家评审。
二、存在问题：
1、P703、P803建筑灭火器的设立数量不一致
11、建议统计安全设施的品种、型号、位置、数量、备品量、单价、总价
12、建设监理资质
13、受限空间辨识
14、八大类区域、三个影响辨识不明确
15、图纸上建议将关键位置、重点部位的位置、距离明确标出
16、重大危险源辨识不需列入碳酸、液碱
17、噪声辨识、斗式提升机机械伤害辨识
专家签名：丁文捷
2011年8月20日
2、P803泄露应急措施提出不恰当
3、P883安全设施类投资概算不准确，需要详细描述以给予验收核实
①紧急处理设施 136万元
②劳动用品和装备 80万元
③防爆设施196万元
④作业现场防护设施 105万元
4、建设项目平面布置图未按比例绘制，安全距离未有效标注，特别是储存区域
专家签名：靳毅
2011年8月20日
2、工艺生产化学过程，要列出化学工艺流程及方程式
3、P15公用工程供配电、配电室设计防火门，能外开，且配置CO2和钢粉灭火器
4、P24危化品一览表（表1—6）指导企业建立登记档案
5、P26抑制毒化学品需安全登记
6、P86安全组织机构及人员设置分三级管（公司车间班级）
7、P87安全投入一览表P88，将安全投入的名称、用途、数量、分布重新完善补充
2、特种设备及安全附件表（做独立附表）
软件产品评审表
25
软件性能
响应性要求
页面转换的响应性；
互动过程中的响应性；
页面转换快捷；
对用户的操作及时作出交互反馈；
5
稳定性要求
帮助机制的完备性；
错误处理机制完备性；
确认退出机制的完备性。
每个操作都有帮助或提示并易于理解；
保证处理用户可能出现的任何错误操作；
避免出现数据未保留而退出。
界面布局
界面布局的合理性。
布局合理，层次清晰。
5
界面美观设计
界面的美观性。
界面美观。
5
界面元素
界面元素的一致性。
窗口、菜单、图标、按钮等元素的一致性。
5
功能要求
技术运用
技术运用的合理性；
内容实现的正确性。
各种技术表现与具体内容有机结合，各种媒体使用协调；
多媒体信息的呈现可控；链接准确、无死链。
15
交互性要求
记录人
签名
日期
评委表决记录
无条件通过
有条件通过
不予通过
结论方式记录
一致决定□过半数表决决定□评审负责人裁决决定□
评审
整改意见
第一反应原则；
阿童木原则；
非局域化原则；
引导原则；
互动性原则；
1.做什么事情有关联的针对性反应及语言（不用人联想）。与当前操作是一对一的对应关系，不拐弯抹角，让用户无法理解。
2.在编辑语言时想象是与阿童木机器人在进行对话。
3.杜绝基于自己的理解摘取部分在自己思维中的信息，形成片面性局域性理解。必须是完整的提示性、指导性语言。让用户容易操作。
5
软件文档
文档资料
文档资料的完整性；
详细设计说明书评审检查表
# 检查项 是/否/不适用 否 不适用 清晰性、完整性 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 设计的复杂度已经最小了吗？
华为研发文档模板-详细设计评审意见表
详细设计评审意见表
单据编号：
项目名称
项目编号
项目经理
评审日期
参加评审人员
评审意见：
□分类、条理较清晰
□ 详细设计的内容完整
相关建议：文档内容较完整，包含了详细设计各个主要方面
□模块设计内容详细、合理性
相关建议：模块功能、模块间关系说明比较详细，合理
□程序设计内容详细、合理性，程序输入输出描述完整
相关建议：程序流程说明较清楚，输入输出比较清晰完整
□模块的输入、输出项描述清楚
相关建议：模块间交互说明比较清楚，流程图比较清晰
其他建议：无
项目评审过程：
由项目经理简要描述项目概要设计的评审过程，包括评审人员提出的问题及纠正办法，文档修改建议等，由项目经理在以下空格处填写：
评审人员
（签字）：
项目经理
（签字）
详细设计说明书
详细设计说明书1．导言（Introduction）本章对该文档的目的、功能范围、术语、相关文档、参考资料、版本更新进行说明。
1.1 目的（Purpose）本文档的目旨在推动软件工程的规范化，使设计人员遵循统一的详细设计书写规范，节省制作文档的时间，降低系统实现的风险，做到系统设计资料的规范性与全面性，以利于系统的实现、测试、维护、版本升级等。
详细设计的详细程度，应达到可以编写程序的程度。
1.2 范围（Scope）本文档用于软件设计阶段的详细设计，它的上游（依据的基线）是《概要设计说明书》，它的下游是源程序清单及单元测试计划，并为单元测试报告提供测试依据。
该范围应覆盖《概要设计说明书》中的功能点列表、性能点列表、接口列表。
软件详细设计的范围是：各子系统的公用模块实现设计、专用模块实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、其他详细设计等。
按照3层结构（B/A/S）的布局，详细设计应从下面3个方面进行。
数据库服务器上的面向数据的设计：数据字典物理设计、基本表物理设计、中间表物理设计（报表设计）、临时表物理设计、视图物理设计、存储过程物理设计、触发器物理设计。
应用服务器上的面向业务逻辑的设计：接口数据设计、中间件设计、数据通信传输设计、可视构件设计、非可视构件设计、角色授权设计、功能点设计（功能点列表设计）。
浏览器上的面向对象的设计：录入修改界面设计、浏览查询界面设计、登录注册界面设计、信息发布界面设计。
1.3 术语定义（Terms Glossary）术语定义，如表6-16所示。
表6-16 术语定义1.4 参考资料（References）[1] 《概要设计说明书》[2] 《需求分析说明书》[3] 《软件合同》[4] 命名规范[5] 程序设计规范[6] 界面设计规范1.5 相关文档（Related Documents）[1] 源程序清单[2] 单元测试计划及报告[3] 《用户使用手册》1.6 版本更新记录（V ersion Updated Rcord）版本更新记录，如表6-17所示。
软件设计评审检查表
是否所有修改共享数据 （或文件）的程序都考虑到了其它程序对该共享数据 （或 文件）的存取权限？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰的描述？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析？
详细设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
正确性
是否处理所有条件 （大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
该测试计划是否和更高级别的测试计划文档一致？
正确性
该测试计划的进入和退出条件是否实现？
是否所有必须的驱动程序和桩（stubs）都已被定义且可利用来测试指定的功 能？
详细级别/程度
是否定义了总体设计目标？
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？
软件设计评审表-模板
用户接口是否模块化，并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
Байду номын сангаас16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法
设计范围、边界是否清晰，文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
评审项目
详细设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
检查项：项；有效检查项：项；通过项：项；通过率：%
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
需求是否可追溯到设计
编制： 日期： 审核： 日期： 批准： 日期：
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
5
设计陈述中的命名、属于和缩写是否上下文一致
完整性
5
文档有独立的版本说明部分
工程施工标准化评审表格
工程施工标准化评审表格项目名称：_______________________ 项目编号：______________________评审日期：_______________________ 评审人员：______________________评审内容及要求：1. 项目可行性研究及初步设计是否合理，现场勘察数据是否准确、全面？2. 施工方案、施工图纸是否符合规范要求，是否安全、可行？3. 施工组织设计是否科学合理，施工进度计划是否可行？4. 施工人员素质及技术水平是否符合要求，是否有施工经验？5. 施工现场安全管理措施是否到位，是否符合相关标准要求？6. 施工过程中的质量控制措施是否完善，是否符合技术标准？7. 材料采购及使用是否符合要求，是否具备合格证明？8. 施工过程中是否存在违规操作行为，是否存在质量安全隐患？9. 施工结束后是否进行验收，是否符合规范要求？10. 施工后的维护保养计划是否合理，是否考虑到长期使用的需求？评审结果及建议改进：1. 项目可行性研究及初步设计方案：______________建议改进：_______________2. 施工方案及施工图纸：______________建议改进：_______________3. 施工组织设计及进度计划：______________建议改进：_______________4. 施工人员素质及技术水平：______________建议改进：_______________5. 施工现场安全管理措施：______________建议改进：_______________6. 施工质量控制措施：______________建议改进：_______________7. 材料采购及使用：______________建议改进：_______________8. 违规操作及质量安全隐患：______________建议改进：_______________9. 施工验收：______________建议改进：_______________10. 维护保养计划：______________建议改进：_______________评审结论：______________________评审人员签名：______________________ 日期：______________________ （以上为评审表格草稿，具体内容根据实际情况进行调整）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件详细设计评审表
项目名称：项目负责人：
主审人：评审时间：
一评审流程
1、由公司领导、各部门相关人员、主审人、评审专家、项目负责人、软件测试人员组成一个评审小组通
过阅读和讨论详细设计的内容对详细设计进行评审。
2、项目负责人提前把概要设计说明书、详细设计说明书等文档分发给评审小组成员作为评审依据小组
成员在充分阅读这些材料之后进入下一步。
3、召开详细设计评审会。
在会上首先由该项目的系统分析员介绍总体设计思想包括需求概述和软件结构然后由各个模块的具体设计者分别对模块设计进行说明在此过程中小组成员可以提出问题展开讨论
审查是否有错误存在。
4、在讨论结束后由项目负责人整理出一份《详细设计评审报告》。
5、若发现错误较多或发现重大错误则在改正之后再次组织详细设计评审。
二评审人员
公司高层
营销部
技术部
工程部
研发部
主审人
评审专家
项目负责人
软件测试人员
三评审内容（评审的具体结果可以参见评审会议记录）
模块评审指标评审内容评审
要求
结果
1.软件架构设计
1.1合理性系统应用架构的逻辑清晰、关系明确、层次合理。
必须1.2先进性
系统开发技术架构先进、充分考虑系统功能可重用、可扩
展的要求。
建议1.3可维护性
设计易于理解，易于修改，易于测试和调试，稳定性较好，
方便用户未来的系统运维。
建议1.4安全性
设计充分考虑系统运行的安全性，子系统间及程序与数据
库调用的权限管理方式设计可行、合理。
建议1.5安装部署要
求
系统架构设计充分考虑计算机支撑平台的实际情况，明确
软件配置项部署方式及要求。
建议
2.软件功能设计2.1可追溯性
系统功能设计能覆盖了所有已确定的软件需求项，软件单
元每一成分都能可追溯到相应需求。
没有明显遗漏。
必须2.2设计粒度
系统功能单元数据结构被详细说明，达到句法级的粒度，
对功能单元运行的异常情况，有相应的处理方式和记录。
建议2.3正确性功能单元的数据结构正确，程序变量命名规范、前后一致，建议
评审结果签署意见：。