详细设计评审表
专家评审意见表
评审地点
贺兰
评审形式
会议
总评意见
通过(√)、不通过()(括号内划√)
评审意见:
一、该项目工艺简单,危险化学品涉及品种少,设计专篇内容较全面,结核《银川市危险化学品建设项目安全评价及标准》中规定的内容编制,同意通过专家评审。
二、存在问题:
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. 维护保养计划:______________建议改进:_______________评审结论:______________________评审人员签名:______________________ 日期:______________________ (以上为评审表格草稿,具体内容根据实际情况进行调整)。
软件设计评审表-模板
引用的文档现行有效
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
施工组织设计评分标准索引表
3.施工中每日安全早会,每周安全周会实施情况(0.1分)
第X章第XX节PXX
4.施工过程中特种作业许可证办理是否符合基本要求(0.1分)
第X章第XX节PXX
5.对于专项施工方案的提交以及工作危险分析是否具备(0.1分)
第X章第XX节PXX
6.施工用电组织计划是否完善(0.1分)
第X章第XX节PXX
第X章第XX节PXX
资源配备计划(1分)
施工设备、材料和人力是否能保证施工顺畅,是否有备用计划(0-1分)
第X章第XX节PXX
5.脚手架专项方案(0-1分)
第X章第XX节PXX
6.冬雨季施工方案(0-1分)
第X章第XX节PXX
7.与其他分包商的协调配合方案(0-1分)
第X章第XX节PXX
8.应急方案及其他施工必须的方案(0-1分)
第X章第XX节PXX
质量管理体系与措施(2分)
1.项目管理团队,项目管理10年以上相关经验(可以以大学/大专毕业那年开始计算工作经历年限,须在投标文件中附毕业证),其他直接管理人员五年以上,人员配备齐全,使各作业面能在分包商的有效管理之下(0-0.25分)
第X章第XX节PXX
2.承包商对废弃物管理和处理措施是否符合当地政府及业主需求?
第X章第XX节PXX
3.承包商是否对施工车辆有效控制和管理?
第X章第XX节PXX
工程进度计划与措施(2分)
进度计划的控制手段及保证措施-组织、技术、经济、合同各方面的具体措施是否体现。进度计划是否有进度落后的赶工方案。冬雨季专项施工方案。施工进度计划满足业主的工期和节点要求(2分)
7.PPE采购和使用是否符合基本要求(0.1分)
第X章第XX节PXX
产品开发TR5评审要素表
防护测试是否通过?
热测试是否通过? 需求实现
必须通过。TR3是基于样机的测试,即使测试中出现 问题,但问题能够定位,在样机上整改能通过测试, 并且对于整改措施,专业实验室工程师与产品线沟通 达成共识,确认对策措施能够落实到产品中,也认为 该产品已经达到A级要求。 判定的依据为专业实验室 的实验报告。如未通过,请将不合格部分在备注中列 出。
识,确认对策措施能够落实到产品中,也认为该产品
交付件2:计划模板中“EMC测试”《EMC测试报告
已经达到A级要求。 判定的依据为专业实验室的实验
》
报告。EMC要求由《系统需求规格》定义。如未通
过,请将不合格部分在备注中列出。 同时,需要根
据后续活动需要考虑是否进行CE、FCC、3C测试认证
。
是否完成国际认证测试?
必须通过。 TR3是基于样机的测试,即使测试中出现
问题,但问题能够定位,在样机上整改能通过测试,
并且对于整改措施,专业实验室工程师与产品线沟通
达成共识,确认对策措施能够落实到产品中,也认为
该产品已经达到A级要求。 判定的依据为专业实验室
的实验报告。如未通过,请将不合格部分在备注中列
出。
1/2
说明
备注 建议:拟制一篇系统测试报告,详细描述系统设计 规格实现情况、遗留问题等。 建议:拟制一篇系统集成测试报告,详细描述系统 设计规格实现情况、遗留问题等。 计划模板中“环境测试”《环境测试报告》
热测试是否通过? 需求实现
必须通过。 TR3是基于样机的测试,即使测试中出现 问题,但问题能够定位,在样机上整改能通过测试, 并且对于整改措施,专业实验室工程师与产品线沟通 达成共识,确认对策措施能够落实到产品中,也认为 该产品已经达到A级要求。 判定的依据为专业实验室 的实验报告。如未通过,请将不合格部分在备注中列 出。
MakeX 创新设计奖评审表说明书
1.MakeX (1)2 (4)3 (11)4 (16)5 (19)6 (23)7 (26)1 (27)2 (30)3MakeX (32)4 (36)5- (37)●●●●●●●●●●●●●●MakeX 创新设计奖评审表□智慧交通□智造大师□雷霆营救战队编号:战队姓名:维度具体指标评分区间单项得分创新外观设计(20分)外观造型独特性,与众不同10 8 6 4 2 外观设计艺术性与观赏性10 8 6 4 2创新性结构突破(30分)战车整体结构紧凑精巧、行动灵活,传感器应用丰富10 8 6 4 2 结构设计具备独特性,与众不同10 8 6 4 2 功能实现方式取得创新性突破10 8 6 4 2工程笔记论述(10分)工程笔记中关于外形或结构设计的内容详细,论述清楚10 8 6 4 2总得分评审补充说明:评审签名:日期:MakeX 工程笔记奖评审表□智慧交通□智造大师□雷霆营救战队编号:战队姓名:维度具体指标评分区间单项得分内容完善度(45分)封面完整显示战队信息 5 4 3 2 1 目录清晰,内容结构完整,重点突出10 8 6 4 2 章节内容详细,阐述条理清晰10 8 6 4 2 有丰富的文字或图片内容记录学习过程10 8 6 4 2 详实的手稿素材展现战车迭代和完善的过程,论述了问题及解决方案10 8 6 4 2制作美观(20分)笔记制作精良,美观度及观赏性高10 8 6 4 2 充满创意的封面展示和内容排版设计10 8 6 4 2总得分评审补充说明:评审签名:日期:MakeX 技术分享奖评审表战队编号:战队名称:维度具体指标评分区间单项得分线上分享(15分)在MakeX官方平台分享高质量的技术型文章,且内容具有技术性参考价值10 8 6 4 2 内容获得较多良好反馈,具有实际的文章阅读量,点赞数等数据支撑,与其他会员进行积极互动,促进社区技术交流5 4 3 2 1线下分享(15分)积极主动组织或参与各类活动,如分享会,工作坊等10 8 6 4 2 分享获得良好反馈,有实际数据支撑,在分享过程中与他人进行积极互动,促进社区技术交流5 4 3 2 1比赛表现(10分)参赛过程中乐于协助其他战队,主动帮助和解决其他战队遇到的技术问题,以自身力量积极带动其他战队10 8 6 4 2申请材料质量(10分)提交文档内容详细完整,逻辑清晰,表述清楚 5 4 3 2 1 视频制作精良,充分展现战队风采 5 4 3 2 1总得分评审补充说明:评审签名:日期:MakeX 宣传大使奖评审表战队编号:战队名称:维度具体指标评分区间单项得分线上传播(20分)在各网络平台分享、推广MakeX赛事10 8 6 4 2 宣传活动卓有成效并有数据支撑, 积极促进社区交流,形成社区影响力10 8 6 4 2线下宣传(20分)积极主动组织或参与各类线下活动10 8 6 4 2 宣传活动卓有成效并有数据支撑, 积极促进社区交流,形成社区影响力10 8 6 4 2现场表现(10分)比赛现场主动与他人交流、认识新战队,通过多种形式展示了战队文化10 8 6 4 2申请材料质量(10分)提交文档内容详细完整,逻辑清晰,表述清楚5 4 3 2 1 视频制作精良,所有战队成员展示完整,充分展现战队特点5 4 3 2 1总得分评审补充说明:评审签名:日期:MakeX 精神奖评审表战队编号:战队名称:维度具体指标评分区间单项得分技术水平(20分)战队技术能力突出,战绩优异,以自身力量积极带动其他战队,起到模范作用10 8 6 4 2 具备科学钻研精神,不断推陈出新,取得技术和创新突破10 8 6 4 2团队文化(30分)优异的团队运营模式,合理分工、目标规划清晰10 8 6 4 2 注重知识和技能的传承,不断沉淀,注重新队员的培养,老、新队员默契合作10 8 6 4 2 积极营造和宣传团队文化,多形式展现战队风采,宣导赛事精神10 8 6 4 2比赛表现(10分)参赛过程中乐于协助其他战队,主动帮助和解决其他战队遇到的技术问题10 8 6 4 2申请材料质量(10分)提交文档内容详细完整,逻辑清晰、表述清楚 5 4 3 2 1 视频制作精良,所有战队成员展示完整,充分展现战队特点5 4 3 2 1总得分评审补充说明:评审签名:日期:MakeX 优秀导师奖评审表姓名:维度具体指标评分区间单项得分教学理念(10分)传道授业解惑,以培养和引导学生为目的,引导学生树立正确的价值观10 8 6 4 2专业知识技能(20分)过硬的专业知识技能,教学方法有效,引导学生取得优异战绩10 8 6 4 2 积极主动分享行业内知识技能或带队经验10 8 6 4 2赛事精神(20分)协助构建公平公正的竞赛环境10 8 6 4 2 认同在比赛和日常教学中尊重和践行赛事精神,以多种形式切实传播赛事精神10 8 6 4 2申请材料质量(10分)提交文档内容详细完整,逻辑清晰,表述清楚 5 4 3 2 1 视频制作精良,充分展现个人风采 5 4 3 2 1总得分评审补充说明:评审签名:日期:2020 MakeX 综合奖项申请表申请人/战队姓名联系电话战队编号邮箱省份及国家比赛名称申请奖项□技术分享奖□宣传大使奖□MakeX精神奖□优秀导师奖申请人身份□参赛战队□指导老师申请材料是否已包括□申请表□视频□报告□其他_________自媒体公众账号/主页(选填)MakeX论坛账号/主页(若申请技术分享奖,此项必填)2020年参赛经历及成绩请将此表如实填写,申请方式及要求以官网公布的奖项公告为准。
新产品设计开发全套表单模板
新产品设计开发全套表单模板设计开发新产品是一个复杂而关键的过程。
为了提高工作效率、确保设计开发工作有序进行,使用一套全面而规范的表单模板是非常必要的。
本文将介绍一套适用于新产品设计开发的全套表单模板,旨在帮助你规范和优化设计开发流程。
一、产品需求调研表产品需求调研是新产品设计开发的第一步。
通过明确产品的需求和市场的背景信息,可以为后续的设计开发工作提供指导。
以下是产品需求调研表的几个关键内容:1. 产品概述:简要介绍产品的基本信息和核心卖点。
2. 目标用户:明确产品的目标用户群体和其需求特点。
3. 市场竞争分析:分析产品在市场上的竞争情况,包括竞争对手、市场份额等。
4. 需求列表:详细列出产品的各项需求,包括功能需求、外观需求等。
二、概念设计表概念设计是新产品设计开发的关键环节。
在进行具体设计之前,需要对产品进行初步的概念化设计,以确保设计方向正确。
以下是概念设计表的几个要点:1. 设计目标:明确概念设计的目标,包括产品定位、用户体验等。
2. 外观设计:描述产品的整体外观设计思路和风格。
3. 结构设计:讨论产品的结构框架、材料选择等。
4. 创新点:提出产品的创新点和差异化竞争策略。
三、详细设计表详细设计是将概念设计转化为具体的产品设计方案的过程。
以下是详细设计表的几个重要内容:1. 功能设计:详细描述产品的各项功能设计要求。
2. 参数规格:列出产品各项参数要求,如尺寸、重量、功耗等。
3. 零部件清单:列出产品所需的各个零部件,并注明供应商信息。
4. 工艺流程:描述产品的生产制造流程,包括工艺步骤、设备要求等。
四、样品评审表在产品开发的过程中,样品评审是必不可少的环节。
通过评审样品,可以发现和修正产品设计中存在的问题。
以下是样品评审表的几个关键点:1. 样品信息:记录样品的基本信息,包括样品名称、生产批次等。
2. 外观质量:评估样品的外观质量,包括表面光洁度、装配质量等。
3. 功能性能:检测样品的功能性能是否符合设计要求。
软件设计评审检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略?
该测试计划是否详细说明所有测试活动的顺序?
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形?
该测试计划是否为所有测试定义了成功标准?
是否详细说明了参数的度量单位、取值范围、正确度和精度?
共享数据区域及其存取规定的映射是否一致?
可维护性
单元是否具有高内聚度和低耦合度(例如:对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小)?
性能
是否该单元的所有约束例(如过程时间和规模)都被详细说明?
可靠性
初始化是否使用到缺省值,缺省值是否正确?
包括了数据流、控制流和接口的单元设计是否已清晰的说明?
完整性
是否已定义和初始化所有的变量、指针和常量?
是否已描述单元的全部功能?
是否已详细说明用来实现该单元的关键算法(例如:用自然语言或PDL)?
是否已列出该单元的调用?
依从性
该文档是否遵循了该项目已文档化的标准?
是否采用了所要求的方法和工具来进行单元设计?
该测试计划是否充分地描述了被测试的功能?
该测试计划是否明确地描述了不被测试的功能?
该测试计划是否充分地描述了测试基线?
对于阶段交付,该测试计划是否有在每一阶段建立测试基线给下一阶段使用?
该测试计划是否定义了足够和正确的衰退测试?
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档?
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序?
产品详细设计评审检查表-模板
××产品详细设计评审检查表
【内容】
●评审人员根据此表认真审核《产品详细设计规格说明书》。
●如果是合同项目,可能还需要用户审核,视具体情况而定。
【裁剪原则】
此部分内容不允许裁剪。
评委名称
评委日期YYYY-MM-DD
评审结论 合格 不合格 TBD 待完成 NA 不适用详细设计检查表结论
基本检查详细设计是否覆盖了所有的总体设计条目?
详细设计和总体设计之间是否存在冲突?每一个模块的关键算法、关键数据结构是否清楚?
各模块之间的接口是否清晰?
设计是否是可实现的?
设计是否有遗漏和缺陷?
可读性检查设计说明是否通俗易懂?
设计中,关键部分是否使用图表加以说明?是否提供软件设计图(类图,序列图,状态图…)
是否提供数据结构设计图(数据库设计,XML结构设计,文件格式设计)
是否提供样例代码,说明如何使用?
可用性检查设计中的命名是否与
现有系统冲突
是否存在不合理的设计结构(例如包耦合:不应交叉耦合,下层中的包不应依赖于上层中的包,依赖关系不得跳层,包不应依赖于子系统,仅应依赖于其它包或接口)
设计是否与某些现有规范存在冲突?(编码规范,设计规范,J2EE 规范….)
设计实现的复杂程度设计实现的瓶颈
依赖型检查是否使用或依赖于第三方的产品?
第三方产品是否可以由不同的提供商替换?
设计中涉及到关键技术是否成熟?
其他问题。
详细设计评审表
软件详细设计评审表
项目名称:项目负责人:
主审人:评审时间:
一评审流程
1、由公司领导、各部门相关人员、主审人、评审专家、项目负责人、软件测试人员组成一个评审小组通过阅读和讨论详细设计的内容对详细设计进行评审。
2、项目负责人提前把概要设计说明书、详细设计说明书等文档分发给评审小组成员作为评审依据小组成员在充分阅读这些材料之后进入下一步。
3、召开详细设计评审会。
在会上首先由该项目的系统分析员介绍总体设计思想包括需求概述和软件结构然后由各个模块的具体设计者分别对模块设计进行说明在此过程中小组成员可以提出问题展开讨论审查是否有错误存在。
4、在讨论结束后由项目负责人整理出一份《详细设计评审报告》。
5、若发现错误较多或发现重大错误则在改正之后再次组织详细设计评审。
二评审人员
公司高层
营销部
技术部
工程部
研发部
主审人
评审专家
项目负责人
软件测试人员
三评审内容(评审的具体结果可以参见评审会议记录)
模块评审指标评审内容评审
要求
结果
1.软件架构设计1.1合理性
系统应用架构的逻辑清晰、关系明确、层次合
理。
必须1.2先进性
系统开发技术架构先进、充分考虑系统功能可
重用、可扩展的要求。
建议1.3可维护性
设计易于理解,易于修改,易于测试和调试,
稳定性较好,方便用户未来的系统运维。
建议1.4安全性设计充分考虑系统运行的安全性,子系统间及建议
评审结果签署意见:。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件详细设计评审表
项目负责人: 评审时间:
一评审流程
1、 由公司领导、各部门相关人员、主审人、评审专家、项目负责人、软件测试人员组 成一个评审小组 通过阅读和讨论详细设计的内容
对详细设计进行评审。
2、 项目负责人提前把概要设计说明书、 详细设计说明书等文档分发给评审小组成员
作为评审依据 小组成员在充分阅读这些材料之后
进入下一步。
3、 召开详细设计评审会。
在会上 首先由该项目的系统分析员介绍总体设计思想 包
括需求概述和软件结构 然后由各个模块的具体设计者分别对模块设计进行说明 在此过
程中小组成员可以提出问题 展开讨论 审查是否有错误存在。
4、 在讨论结束后
由项目负责人整理出一份《详细设计评审报告》。
5、 若发现错误较多 或发现重大错误 则在改正之后 再次组织详细设计评审。
二评审人员
三 评审内容(评审的具体结果可以参见评审会议记录)
项目名称: 主审人:。