详细设计说明书检查表
详细设计说明书评审检查表
# 检查项 是/否/不适用 否 不适用 清晰性、完整性 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 设计的复杂度已经最小了吗？
Peoplesoft项目开发过程规范标准
Peoplesoft 项目开发过程规1.1目的系统设计编码的目的在于开发、设计和实现关于需求的解决方案。
本过程规定了项目开发设计工作应遵循的步骤和原则，保证《需求规格说明书》中的各项要求在设计时都能够得到满足；对项目的编码实现进行质量控制，保证编码实现活动按计划顺利完成并与设计相一致。
1.2适用围适用于公司所有产品研发类、产品开发类、维护开发类项目。
1.3参考文件《决策分析控制程序》《评审过程实施细则》《变更控制程序》《软件测试控制程序》1.4定义无1.5职责1.6 入口1.6.1 入口准则《需求规格说明书》通过评审1.6.2 输入《需求规格说明书》1.7流程图1.8主要活动系统设计编码过程包括系统设计、系统实现。
系统设计是指设计软件系统的体系结构、 数据库、模块等，在需求和代码之间建立桥梁，一般分概要设计和详细设计两个阶段； 系统实现是指开发工程师按照系统设计去编码开发， 并鼓励进行单元测试、 代码走查；在设计编码过程中同时进行用户文档的编制。
2. 5.8.1设计原则设计工作应正确、完整地反映《需求规格说明书》的各项要求，充分考虑其功能、性能、 安全、出错处理及其它需求。
保证设计的易理解性、可追踪性、可测试性、接口的开放性和制作用户文档图1.设计编码过程示意图图2 :软件设计编码过程示意图兼容性，考虑健壮性（易修改、可扩充、可移植）、重用性。
考虑选用合适的编程语言和开发工具，制定编码规和系统约定等。
对于PS开发，需要在实现难度，代码维护，系统集成方面考虑，在对需求处理时需要定义好任务的技术边界，比如该方案哪部分由java处理，哪部分由peoplesoft处理，是否需要引入第三方组件等。
3. 582设计方法设计时要使用有效的方法进行软件设计。
软件设计方法一般采用面向结构设计方法、面向对象设计方法或其他方法。
4. 583多方案选择系统设计过程进行多方案选择时，按照《决策分析控制程序》进行系统架构选择和关键技术方案的确定。
产品设计输入内审检查表模板
顾客合同的要求16顾Fra bibliotek的特殊特性要求
17
顾客的标识要求
18
顾客的可追溯性要求
19
顾客的包装要求
20
信息使用方面的要求
以往设计项目的信息
21
分析竞争对手得到的信息
22
供方反馈的信息
23
内部反馈的信息
24
外部客户反馈的信息
25
质量目标方面的要求
产品质量目标
26
产品寿命目标
27
产品可靠性目标
11
对输入要求风险的评估，以及对组织缓解/管理风险（包括来自可行性分析的风险）的能力的评估
12
产品要求符合性的目标，包括防护、可靠性、耐久性、可服务性、健康、安全、环境、开发时程安排和成本等方面
13
顾客确定的目的国（如有提供）的适用法律法规要求
14
嵌入式软件要求
15
产品设计输入的内容要求（详细内容）
产品设计输入内审检查表模板（8.3.3.1）
编号
检查内容
1
产品设计输入控制要求
应对作为合同评审结果的产品设计输入要求进行识别
2
形成文件
3
进行评审。说明：评审的目的是确保设计和开发输入充分、适宜；并且完整、清楚，不会自相矛盾
4
组织应有一个过程，将从以前的设计项目、竞争产品分析（标杆）、供应商反馈、 内部输入、使用现场数据和其它相关资源中获取的信息，推广应用于当前和未来相似性质的项目
5
产品设计输入内容包括
产品规范，包括但不限于特殊特性；包括功能和性能要求
6
适用的法律、法规要求。说明：可能有强制性认证要求、环保和安全方面的法律要求
结构设计检查表checklist
钣金件一般情况下，对于一条边的一部分弯折，为了避免撕裂和畸变，应设计止 裂槽或切口。切口宽度一般大于板厚t，切口深度一般大于1.5t。 钣金弯折件的弯折区应避开零件突变的位置，弯折线离突变形区的距离L应大于 两倍的弯折半径r，即L≥2r。 铆装螺母中心到弯折边内侧的距离L应大于铆装螺母外圆柱半径R与弯折内角半径 r之和，即L>R+r。 压铸件凡是在壁与壁的连接处（模具分型面部位除外）都应设计圆角，不仅有利 于压铸成型，避免应力及产生裂纹，并可以延长模具寿命，当压铸件需要电镀或 涂覆时，圆角可以防止镀（涂）料沉积，获得均匀镀（涂）层。压铸件圆角一般 取：1/2壁厚≤R≤壁厚 锌铝合金压铸件最小的铸造斜度一般取：外表面1°；内表面1.5°；型芯孔（单 边）2°
13
其它
评审时间
相关 批准人 文档 状态 名称
评审记录 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免
□ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免
□ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免 □ 是 □ 否 □ 免
编号 器件编码 001 002 003 004 005 006 A06/A07 A06/A07 A06/A07 A06/A07 A06/A07 A06/A07
软件开发文档英文缩写
各类软件开发文档的英文缩写－适合用于文档编码文档名称英文简写工作任务说明书SOWProcess Handbook (项目过程手册)PHBEstimation Sheet (估计记录)ESTProject Plan (项目计划)PPLSoftware Management Plan( 配置管理计划)CMPSoftware Quality Assurance Plan （软件质量保证计划）QAPSoftware Risk Management Plan （软件风险管理计划）RMPTest Strategy（测试策略）TSTWork Breakdown Structure （工作分解结构）WBSBusiness Requirement Specification(业务需求说明书) BRSSoftware Requirement Specification(软件需求说明书) SRSSystem Testing plan (系统测试计划)STPSystem Testing Cases （系统测试用例）STCHigh Level Design(概要设计说明书)HLDIntegration Testing plan (集成测试计划)ITPIntegration Testing Cases （集成测试用例）ITCLow Level Design (详细设计说明书)LLDUnit Testing Plan ( 单元测试计划)UTPUnit Testing Cases （单元测试用例）UTCUnit Testing Report （单元测试报告）UTRIntegration Testing Report （集成测试报告）ITRSystem Testing Report （系统测试报告）STRRequirements Traceability Matrix (需求跟踪矩阵) RTMConfiguration Status Accounting （配置状态发布）CSAChange Request Form （变更申请表）CRFWeekly Status Report （项目周报）WSRQuality Weekly Status Report （质量工作周报）QSRQuality Audit Report(质量检查报告)QARQuality Check List(质量检查表)QCLPhase Assessment Report （阶段评估报告）PARClosure Report （项目总结报告）CLRReview Finding Form (评审发现表)RFFMinutes of Meeting （会议纪要）MOMMetrics Sheet （度量表）MTXConsistanceCheckForm（一致性检查表）CCFBaseline Audit Form（基线审计表）BAFProgram Trace Form（问题跟踪表）PTF。
软件测试英语术语 缩写
软件测试常用英语词汇静态测试：Non-Execution-Based Testing或Static testing 代码走查：Walkthrough代码审查：Code Inspection技术评审：Review动态测试：Execution-Based Testing白盒测试：White-Box Testing黑盒测试：Black-Box Testing灰盒测试：Gray-Box Testing软件质量保证SQA：Software Quality Assurance软件开发生命周期：Software Development Life Cycle冒烟测试：Smoke Test回归测试：Regression Test功能测试：Function Testing性能测试：Performance Testing压力测试：Stress Testing负载测试：Volume Testing易用性测试：Usability Testing安装测试：Installation Testing界面测试：UI Testing配置测试：Configuration Testing文档测试：Documentation Testing兼容性测试：Compatibility Testing安全性测试：Security Testing恢复测试：Recovery Testing单元测试：Unit Test集成测试：Integration Test系统测试：System Test验收测试：Acceptance Test测试计划应包括：测试对象：The Test Objectives测试范围： The Test Scope测试策略： The Test Strategy测试方法： The Test Approach,测试过程： The test procedures,测试环境： The Test Environment,测试完成标准：The test Completion criteria测试用例：The Test Cases测试进度表：The Test Schedules风险：Risks接口：Interface最终用户：The End User正式的测试环境：Formal Test Environment确认需求：Verifying The Requirements有分歧的需求：Ambiguous Requirements运行和维护：Operation and Maintenance.可复用性：Reusability可靠性： Reliability/Availability电机电子工程师协会IEEE：The Institute of Electrical and Electronics Engineers) 正确性：Correctness实用性：Utility健壮性：Robustness可靠性：Reliability软件需求规格说明书：SRS （software requirement specification ）概要设计：HLD （high level design ）详细设计：LLD （low level design ）统一开发流程：RUP （rational unified process ）集成产品开发：IPD （integrated product development ）能力成熟模型：CMM （capability maturity model ）能力成熟模型集成：CMMI （capability maturity model integration ）戴明环：PDCA （plan do check act ）软件工程过程组：SEPG （software engineering process group ）集成测试：IT （integration testing ）系统测试：ST （system testing ）关键过程域：KPA （key process area ）同行评审：PR （peer review ）用户验收测试：UAT （user acceptance testing ）验证和确认：V&V （verification & validation ）控制变更委员会：CCB （change control board ）图形用户界面：GUI （graphic user interface ）配置管理员：CMO （configuration management officer ）平均失效间隔时间：（MTBF mean time between failures ）平均修复时间：MTTR （mean time to restoration ）平均失效时间：MTTF （mean time to failure ）工作任务书：SOW （statement of work ）α测试：alpha testingβ测试：beta testing适应性：Adaptability可用性：Availability功能规格说明书：Functional Specification软件开发中常见英文缩写和各类软件开发文档的英文缩写：英文简写文档名称MRD market requirement document （市场需求文档）PRD product requirement document （产品需求文档）SOW 工作任务说明书PHB Process Handbook (项目过程手册)EST Estimation Sheet (估计记录)PPL Project Plan (项目计划)CMP Software Management Plan( 配置管理计划)QAP Software Quality Assurance Plan （软件质量保证计划）RMP Software Risk Management Plan （软件风险管理计划）TST Test Strategy（测试策略）WBS Work Breakdown Structure （工作分解结构）BRS Business Requirement Specification(业务需求说明书)SRS Software Requirement Specification(软件需求说明书)STP System Testing plan (系统测试计划)STC System Testing Cases （系统测试用例）HLD High Level Design (概要设计说明书)ITP Integration Testing plan (集成测试计划)ITC Integration Testing Cases （集成测试用例）LLD Low Level Design (详细设计说明书)UTP Unit Testing Plan ( 单元测试计划)UTC Unit Testing Cases （单元测试用例）UTR Unit Testing Report （单元测试报告）ITR Integration Testing Report （集成测试报告）STR System Testing Report （系统测试报告）RTM Requirements Traceability Matrix (需求跟踪矩阵)CSA Configuration Status Accounting （配置状态发布）CRF Change Request Form （变更申请表）WSR Weekly Status Report （项目周报）QSR Quality Weekly Status Report （质量工作周报）QAR Quality Audit Report(质量检查报告)QCL Quality Check List(质量检查表)PAR Phase Assessment Report （阶段评估报告）CLR Closure Report （项目总结报告）RFF Review Finding Form (评审发现表)MOM Minutes of Meeting （会议纪要）MTX Metrics Sheet （度量表）CCF ConsistanceCheckForm（一致性检查表）BAF Baseline Audit Form（基线审计表）PTF Program Trace Form（问题跟踪表）领测国际科技（北京）有限公司领测软件测试网 /软件测试中英文对照术语表A• Abstract test case (High level test case) ：概要测试用例• Acceptance：验收• Acceptance criteria：验收标准• Acceptance testing：验收测试• Accessibility testing：易用性测试• Accuracy：精确性• Actual outcome (actual result) ：实际输出/实际结果• Ad hoc review (informal review) ：非正式评审• Ad hoc testing：随机测试• Adaptability：自适应性• Agile testing：敏捷测试• Algorithm test (branch testing) ：分支测试• Alpha testing：alpha 测试• Analyzability：易分析性• Analyzer：分析员• Anomaly：异常• Arc testing：分支测试• Attractiveness：吸引力• Audit：审计• Audit trail：审计跟踪• Automated testware：自动测试组件• Availability：可用性B• Back-to-back testing：对比测试• Baseline：基线• Basic block：基本块• Basis test set：基本测试集• Bebugging：错误撒播• Behavior：行为• Benchmark test：基准测试• Bespoke software：定制的软件• Best practice：最佳实践• Beta testing：Beta 测试领测国际科技（北京）有限公司领测软件测试网 /• Big-bang testing：集成测试• Black-box technique：黑盒技术• Black-box testing：黑盒测试• Black-box test design technique：黑盒测试设计技术• Blocked test case：被阻塞的测试用例• Bottom-up testing：自底向上测试• Boundary value：边界值• Boundary value analysis：边界值分析• Boundary value coverage：边界值覆盖率• Boundary value testing：边界值测试• Branch：分支• Branch condition：分支条件• Branch condition combination coverage：分支条件组合覆盖率• Branch condition combination testing：分支条件组合测试• Branch condition coverage：分支条件覆盖率• Branch coverage：分支覆盖率• Branch testing：分支测试• Bug：缺陷• Business process-based testing：基于商业流程的测试C• Capability Maturity Model (CMM) ：能力成熟度模型• Capability Maturity Model Integration (CMMI) ：集成能力成熟度模型• Capture/playback tool：捕获/回放工具• Capture/replay tool：捕获/重放工具• CASE (Computer Aided Software Engineering) ：电脑辅助软件工程• CAST (Computer Aided Software Testing) ：电脑辅助软件测试• Cause-effect graph：因果图• Cause-effect graphing：因果图技术• Cause-effect analysis：因果分析• Cause-effect decision table：因果判定表• Certification：认证• Changeability：可变性• Change control：变更控制• Change control board：变更控制委员会• Checker：检查人员• Chow's coverage metrics (N-switch coverage) ：N 切换覆盖率• Classification tree method：分类树方法• Code analyzer：代码分析器• Code coverage：代码覆盖率领测国际科技（北京）有限公司领测软件测试网 /• Code-based testing：基于代码的测试• Co-existence：共存性• Commercial off-the-shelf software：商用离岸软件• Comparator：比较器• Compatibility testing：兼容性测试• Compiler：编译器• Complete testing：完全测试/穷尽测试• Completion criteria：完成标准• Complexity：复杂性• Compliance：一致性• Compliance testing：一致性测试• Component：组件• Component integration testing：组件集成测试• Component specification：组件规格说明• Component testing：组件测试• Compound condition：组合条件• Concrete test case (low level test case) ：详细测试用例• Concurrency testing：并发测试• Condition：条件表达式• Condition combination coverage：条件组合覆盖率• Condition coverage：条件覆盖率• Condition determination coverage：条件判定覆盖率• Condition determination testing：条件判定测试• Condition testing：条件测试• Condition outcome：条件结果• Confidence test (smoke test) ：信心测试（冒烟测试）• Configuration：配置• Configuration auditing：配置审核• Configuration control：配置控制• Configuration control board (CCB) ：配置控制委员会• Configuration identification：配置标识• Configuration item：配置项• Configuration management：配置管理• Configuration testing：配置测试• Confirmation testing：确认测试• Conformance testing：一致性测试• Consistency：一致性• Control flow：控制流• Control flow graph：控制流图• Control flow path：控制流路径• Conversion testing：转换测试• COTS (Commercial Off-The-Shelf software) ：商业离岸软件• Coverage：覆盖率• Coverage analysis：覆盖率分析领测国际科技（北京）有限公司领测软件测试网 /• Coverage item：覆盖项• Coverage tool：覆盖率工具• Custom software：定制软件• Cyclomatic complexity：圈复杂度• Cyclomatic number：圈数D• Daily build：每日构建• Data definition：数据定义• Data driven testing：数据驱动测试• Data flow：数据流• Data flow analysis：数据流分析• Data flow coverage：数据流覆盖率• Data flow test：数据流测试• Data integrity testing：数据完整性测试• Database integrity testing：数据库完整性测试• Dead code：无效代码• Debugger：调试器• Debugging：调试• Debugging tool：调试工具• Decision：判定• Decision condition coverage：判定条件覆盖率• Decision condition testing：判定条件测试• Decision coverage：判定覆盖率• Decision table：判定表• Decision table testing：判定表测试• Decision testing：判定测试技术• Decision outcome：判定结果• Defect：缺陷• Defect density：缺陷密度• Defect Detection Percentage (DDP) ：缺陷发现率• Defect management：缺陷管理• Defect management tool：缺陷管理工具• Defect masking：缺陷屏蔽• Defect report：缺陷报告• Defect tracking tool：缺陷跟踪工具• Definition-use pair：定义-使用对• Deliverable：交付物• Design-based testing：基于设计的测试• Desk checking：桌面检查领测国际科技（北京）有限公司领测软件测试网 /• Development testing：开发测试• Deviation：偏差• Deviation report：偏差报告• Dirty testing：负面测试• Documentation testing：文档测试• Domain：域• Driver：驱动程序• Dynamic analysis：动态分析• Dynamic analysis tool：动态分析工具• Dynamic comparison：动态比较• Dynamic testing：动态测试E• Efficiency：效率• Efficiency testing：效率测试• Elementary comparison testing：基本组合测试• Emulator：仿真器、仿真程序• Entry criteria：入口标准• Entry point：入口点• Equivalence class：等价类• Equivalence partition：等价区间• Equivalence partition coverage：等价区间覆盖率• Equivalence partitioning：等价划分技术• Error：错误• Error guessing：错误猜测技术• Error seeding：错误撒播• Error tolerance：错误容限• Evaluation：评估• Exception handling：异常处理• Executable statement：可执行的语句• Exercised：可执行的• Exhaustive testing：穷尽测试• Exit criteria：出口标准• Exit point：出口点• Expected outcome：预期结果• Expected result：预期结果• Exploratory testing：探测测试领测国际科技（北京）有限公司领测软件测试网 /F• Fail：失败• Failure：失败• Failure mode：失败模式• Failure Mode and Effect Analysis (FMEA) ：失败模式和影响分析• Failure rate：失败频率• Fault：缺陷• Fault density：缺陷密度• Fault Detection Percentage (FDP) ：缺陷发现率• Fault masking：缺陷屏蔽• Fault tolerance：缺陷容限• Fault tree analysis：缺陷树分析• Feature：特征• Field testing：现场测试• Finite state machine：有限状态机• Finite state testing：有限状态测试• Formal review：正式评审• Frozen test basis：测试基线• Function Point Analysis (FPA) ：功能点分析• Functional integration：功能集成• Functional requirement：功能需求• Functional test design technique：功能测试设计技术• Functional testing：功能测试• Functionality：功能性• Functionality testing：功能性测试G• glass box testing：白盒测试H• Heuristic evaluation：启发式评估• High level test case：概要测试用例• Horizontal traceability：水平跟踪领测国际科技（北京）有限公司领测软件测试网 /I• Impact analysis：影响分析• Incremental development model：增量开发模型• Incremental testing：增量测试• Incident：事件• Incident management：事件管理• Incident management tool：事件管理工具• Incident report：事件报告• Independence：独立• Infeasible path：不可行路径• Informal review：非正式评审• Input：输入• Input domain：输入范围• Input value：输入值• Inspection：审查• Inspection leader：审查组织者• Inspector：审查人员• Installability：可安装性• Installability testing：可安装性测试• Installation guide：安装指南• Installation wizard：安装向导• Instrumentation：插装• Instrumenter：插装工具• Intake test：入口测试• Integration：集成• Integration testing：集成测试• Integration testing in the large：大范围集成测试• Integration testing in the small：小范围集成测试• Interface testing：接口测试• Interoperability：互通性• Interoperability testing：互通性测试• Invalid testing：无效性测试• Isolation testing：隔离测试• Item transmittal report：版本发布报告• Iterative development model：迭代开发模型K• Key performance indicator：关键绩效指标领测国际科技（北京）有限公司领测软件测试网 /• Keyword driven testing：关键字驱动测试L• Learnability：易学性• Level test plan：等级测试计划• Link testing：组件集成测试• Load testing：负载测试• Logic-coverage testing：逻辑覆盖测试• Logic-driven testing：逻辑驱动测试• Logical test case：逻辑测试用例• Low level test case：详细测试用例M• Maintenance：维护• Maintenance testing：维护测试• Maintainability：可维护性• Maintainability testing：可维护性测试• Management review：管理评审• Master test plan：综合测试计划• Maturity：成熟度• Measure：度量• Measurement：度量• Measurement scale：度量粒度• Memory leak：内存泄漏• Metric：度量• Migration testing：移植测试• Milestone：里程碑• Mistake：错误• Moderator：仲裁员• Modified condition decision coverage：改进的条件判定覆盖率• Modified condition decision testing：改进的条件判定测试• Modified multiple condition coverage：改进的多重条件判定覆盖率• Modified multiple condition testing：改进的多重条件判定测试• Module：模块• Module testing：模块测试• Monitor：监视器• Multiple condition：多重条件• Multiple condition coverage：多重条件覆盖率领测国际科技（北京）有限公司领测软件测试网 /• Multiple condition testing：多重条件测试• Mutation analysis：变化分析• Mutation testing：变化测试N• N-switch coverage：N 切换覆盖率• N-switch testing：N 切换测试• Negative testing：负面测试• Non-conformity：不一致• Non-functional requirement：非功能需求• Non-functional testing：非功能测试• Non-functional test design techniques：非功能测试设计技术O• Off-the-shelf software：离岸软件• Operability：可操作性• Operational environment：操作环境• Operational profile testing：运行剖面测试• Operational testing：操作测试• Oracle：标准• Outcome：输出/结果• Output：输出• Output domain：输出范围• Output value：输出值P• Pair programming：结队编程• Pair testing：结队测试• Partition testing：分割测试• Pass：通过• Pass/fail criteria：通过/失败标准• Path：路径• Path coverage：路径覆盖• Path sensitizing：路径敏感性• Path testing：路径测试领测国际科技（北京）有限公司领测软件测试网 / • Peer review：同行评审• Performance：性能• Performance indicator：绩效指标• Performance testing：性能测试• Performance testing tool：性能测试工具• Phase test plan：阶段测试计划• Portability：可移植性• Portability testing：移植性测试• Postcondition：结果条件• Post-execution comparison：运行后比较• Precondition：初始条件• Predicted outcome：预期结果• Pretest：预测试• Priority：优先级• Probe effect：检测成本• Problem：问题• Problem management：问题管理• Problem report：问题报告• Process：流程• Process cycle test：处理周期测试• Product risk：产品风险• Project：项目• Project risk：项目风险• Program instrumenter：编程工具• Program testing：程序测试• Project test plan：项目测试计划• Pseudo-random：伪随机Q• Quality：质量• Quality assurance：质量保证• Quality attribute：质量属性• Quality characteristic：质量特征• Quality management：质量管理领测国际科技（北京）有限公司领测软件测试网 /R• Random testing：随机测试• Recorder：记录员• Record/playback tool：记录/回放工具• Recoverability：可复原性• Recoverability testing：可复原性测试• Recovery testing：可复原性测试• Regression testing：回归测试• Regulation testing：一致性测试• Release note：版本说明• Reliability：可靠性• Reliability testing：可靠性测试• Replaceability：可替换性• Requirement：需求• Requirements-based testing：基于需求的测试• Requirements management tool：需求管理工具• Requirements phase：需求阶段• Resource utilization：资源利用• Resource utilization testing：资源利用测试• Result：结果• Resumption criteria：继续测试标准• Re-testing：再测试• Review：评审• Reviewer：评审人员• Review tool：评审工具• Risk：风险• Risk analysis：风险分析• Risk-based testing：基于风险的测试• Risk control：风险控制• Risk identification：风险识别• Risk management：风险管理• Risk mitigation：风险消减• Robustness：健壮性• Robustness testing：健壮性测试• Root cause：根本原因S• Safety：安全领测国际科技（北京）有限公司领测软件测试网 /• Safety testing：安全性测试• Sanity test：健全测试• Scalability：可测量性• Scalability testing：可测量性测试• Scenario testing：情景测试• Scribe：记录员• Scripting language：脚本语言• Security：安全性• Security testing：安全性测试• Serviceability testing：可维护性测试• Severity：严重性• Simulation：仿真• Simulator：仿真程序、仿真器• Site acceptance testing：定点验收测试• Smoke test：冒烟测试• Software：软件• Software feature：软件功能• Software quality：软件质量• Software quality characteristic：软件质量特征• Software test incident：软件测试事件• Software test incident report：软件测试事件报告• Software Usability Measurement Inventory (SUMI) ：软件可用性调查问卷• Source statement：源语句• Specification：规格说明• Specification-based testing：基于规格说明的测试• Specification-based test design technique：基于规格说明的测试设计技术• Specified input：特定输入• Stability：稳定性• Standard software：标准软件• Standards testing：标准测试• State diagram：状态图• State table：状态表• State transition：状态迁移• State transition testing：状态迁移测试• Statement：语句• Statement coverage：语句覆盖• Statement testing：语句测试• Static analysis：静态分析• Static analysis tool：静态分析工具• Static analyzer：静态分析工具• Static code analysis：静态代码分析• Static code analyzer：静态代码分析工具• Static testing：静态测试• Statistical testing：统计测试领测国际科技（北京）有限公司领测软件测试网 /• Status accounting：状态统计• Storage：资源利用• Storage testing：资源利用测试• Stress testing：压力测试• Structure-based techniques：基于结构的技术• Structural coverage：结构覆盖• Structural test design technique：结构测试设计技术• Structural testing：基于结构的测试• Structured walkthrough：面向结构的走查• Stub: 桩• Subpath: 子路径• Suitability: 符合性• Suspension criteria: 暂停标准• Syntax testing: 语法测试• System:系统• System integration testing：系统集成测试• System testing：系统测试T• Technical review：技术评审• Test：测试• Test approach：测试方法• Test automation：测试自动化• Test basis：测试基础• Test bed：测试环境• Test case：测试用例• Test case design technique：测试用例设计技术• Test case specification：测试用例规格说明• Test case suite：测试用例套• Test charter：测试宪章• Test closure：测试结束• Test comparator：测试比较工具• Test comparison：测试比较• Test completion criteria：测试比较标准• Test condition：测试条件• Test control：测试控制• Test coverage：测试覆盖率• Test cycle：测试周期• Test data：测试数据• Test data preparation tool：测试数据准备工具领测国际科技（北京）有限公司领测软件测试网 /• Test design：测试设计• Test design specification：测试设计规格说明• Test design technique：测试设计技术• Test design tool: 测试设计工具• Test driver: 测试驱动程序• Test driven development: 测试驱动开发• Test environment: 测试环境• Test evaluation report: 测试评估报告• Test execution: 测试执行• Test execution automation: 测试执行自动化• Test execution phase: 测试执行阶段• Test execution schedule: 测试执行进度表• Test execution technique: 测试执行技术• Test execution tool: 测试执行工具• Test fail: 测试失败• Test generator: 测试生成工具• Test leader:测试负责人• Test harness：测试组件• Test incident：测试事件• Test incident report：测试事件报告• Test infrastructure：测试基础组织• Test input：测试输入• Test item：测试项• Test item transmittal report：测试项移交报告• Test level：测试等级• Test log：测试日志• Test logging：测试记录• Test manager：测试经理• Test management：测试管理• Test management tool：测试管理工具• Test Maturity Model (TMM) ：测试成熟度模型• Test monitoring：测试跟踪• Test object：测试对象• Test objective：测试目的• Test oracle：测试标准• Test outcome：测试结果• Test pass：测试通过• Test performance indicator：测试绩效指标• Test phase：测试阶段• Test plan：测试计划• Test planning：测试计划• Test policy：测试方针• Test Point Analysis (TPA) ：测试点分析• Test procedure：测试过程领测国际科技（北京）有限公司领测软件测试网 /• Test procedure specification：测试过程规格说明• Test process：测试流程• Test Process Improvement (TPI) ：测试流程改进• Test record：测试记录• Test recording：测试记录• Test reproduceability：测试可重现性• Test report：测试报告• Test requirement：测试需求• Test run：测试运行• Test run log：测试运行日志• Test result：测试结果• Test scenario：测试场景• Test script：测试脚本• Test set：测试集• Test situation：测试条件• Test specification：测试规格说明• Test specification technique：测试规格说明技术• Test stage：测试阶段• Test strategy：测试策略• Test suite：测试套• Test summary report：测试总结报告• Test target：测试目标• Test tool：测试工具• Test type：测试类型• Testability：可测试性• Testability review：可测试性评审• Testable requirements：需求可测试性• Tester：测试人员• Testing：测试• Testware：测试组件• Thread testing：组件集成测试• Time behavior：性能• Top-down testing：自顶向下的测试• Traceability：可跟踪性U• Understandability：易懂性• Unit：单元• unit testing：单元测试• Unreachable code：执行不到的代码领测国际科技（北京）有限公司领测软件测试网 /• Usability：易用性• Usability testing：易用性测试• Use case：用户用例• Use case testing：用户用例测试• User acceptance testing：用户验收测试• User scenario testing：用户场景测试• User test：用户测试V• V -model：V 模式• Validation：确认• Variable：变量• Verification：验证• Vertical traceability：垂直可跟踪性• Version control：版本控制• Volume testing：容量测试W• Walkthrough：走查• White-box test design technique：白盒测试设计技术• White-box testing：白盒测试• Wide Band Delphi：Delphi 估计方法。
概要设计说明书检查表
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更
▢是▢否
是否所有的TBD的影响都已经被评估了
▢是▢否
是否仍存在可能不可行的设计部分
▢是▢否
是否已记录设计时的权衡考虑该文件是否包括了权衡选择的标准和不选择其它方案的原因
▢是▢否
依从性
依从性该文档是否遵守了该项目的文档编写标准
▢是▢否
一致性
▢是▢否
是否所有的界面都提供了所要求的信息
▢是▢否
是否已说明内部各界面之间的关系
▢是▢否
界面的数量和复杂程度是否已减少到最小
▢是▢否
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
▢是▢否
可维护性
该设计是否是模块化的
▢是▢否
这些模块具有高内聚度和低耦合度
▢是▢否
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明
▢是▢否
性能
主要性能参数是否已复（例如：输入输出检查）
▢是▢否
是否已考虑非正常情况
▢是▢否
是否所有的错误情况都被完整和准确地说明
▢是▢否
该设计是否满足该系统进行集成时所遵守的约定
▢是▢否
易测性
是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的
▢是▢否
是否已描述最低级别数据元素是否已详细说明取值范围
▢是▢否
功能性
是否对每一下级模块进行了概要算法说明
▢是▢否
所选择的设计和算法能否满足所有的需求
▢是▢否
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
▢是▢否
是否已描述界面的功能特性
化工设备安全设计诊断检查表
3.11
设计温度高于或等于350℃，且口径大于DN200；设计温度低于或等于-46℃，且口径大于DN50的管道、与直接对大气排放的安全阀或释放阀连接的管道、装有金属波纹膨胀节的管道、火炬排放系统管道等应进行应力分析计算。
与工艺气管线相连的低压氮气或中压氮气等公用工程管线上应设置手阀+止逆阀，防止工艺气串至公用工程系统；
阀门应采用密封性能好的旋塞阀和球阀；
易燃易爆、极度和高度危害介质管道不得采用非金属管道；
危险介质是否设置双阀；
可燃气体排放是否设置阻火器和止回阀；
易燃易爆物料储存是否设置氮封保护；甲、乙A类可燃液体或有毒（中度危害）的采样应采用循环密闭采样系统。
《关于危险化学品企业贯彻落实<国务院关于进一步加强企业安全生产工作的通知>的实施意见》(安监总管三〔2010〕186号)
2.6
工艺技术应来源可靠，有合规的技术转让合同或安全可靠性论证。
《危险化学品生产企业安全生产许可证实施办法》（国家安全生产监督管理总局令第41号）
2.7
基础设计、详细设计阶段应进行危险与可操作性（HAZOP）分析。
2.14
储罐、工艺流程中的介质与原设计发生改变时，应履行工艺变更手续。
《关于加强化工过程安全管理的指导意见》（安监总管三〔2013〕89号）
2.15
应有避免生产过程中产生的粉尘形成爆炸性混合物或堵塞设备和管道的措施。
3.管道专业设计核查表
3.1
管廊的高度应满足装置内消防道路的设置要求。
详细设计说明书检查表
是否所有的设计决定都能追溯到权衡考虑
▢是▢否
单元需求是否都能上溯到更高级别的文档更高级别文档的需求是否已经在单元中体现
▢是▢否
承建单位（盖章）：
负责人：
日期：
建设单位（盖章）：
项目经理：
日期：
监理机构（盖章）：
监理工程师：
日期：
是所有的逻辑都能被测试
▢是▢否
是否已描述测试程序、测试数据集和测试结果
▢是▢否
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的。
▢是▢否
该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）
▢是▢否
可追溯性
是否设计的每一部分都能追溯到其它项目文档的需求，也能追溯到更高级别文档的需求
可维护性
这些模块具有高内聚度和低耦合度
▢是▢否
性能
是否该单元的所有约束例如过程时间和规模都被详细说明
▢是▢否
可靠性
初始化是否使用到缺省值，缺省值是否正确
▢是▢否
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置
▢是▢否
是否执行输入、输出、接口和结果的错误检查
▢是▢否
是否对所有错误情况都发出有意义的信息
▢是▢否
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配
▢是▢否
是否考虑到意外事件
▢是▢否
易测性
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的。
▢是▢否
该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）
▢是▢否
▢是▢否
接口
教案检查表(模板)
教案检查表（模板）教案编写者：[姓名]日期：[日期]教案概述：本教案检查表旨在为教师提供一个教案编写和检查的标准模板，以确保教案的质量和完整性。
通过使用此检查表，教师可以系统地评估和管理自己的教案，从而提高教学效果和学生的学习成果。
教案检查表：一、教案基本信息1.1 课程名称：[课程名称]1.2 课程代码：[课程代码]1.3 授课教师：[姓名]1.4 授课日期：[日期]1.5 授课对象：[年级/专业]二、教学目标2.1 知识目标：[具体知识目标1][具体知识目标2][具体知识目标3]2.2 技能目标：[具体技能目标1][具体技能目标2][具体技能目标3]2.3 情感目标：[具体情感目标1][具体情感目标2][具体情感目标3]三、教学内容3.1 教材：[教材名称]3.2 教学资源：[教学资源名称] 3.3 教学方法：[教学方法名称] 3.4 教学步骤：[具体教学步骤1] [具体教学步骤2][具体教学步骤3]四、教学评估4.1 评估方式：[评估方式名称] 4.2 评估指标：[评估指标1] [评估指标2][评估指标3]4.3 评估工具：[评估工具名称]4.4 评估时间：[评估时间]五、教学反思5.1 教学效果：[教学效果评价] 5.2 学生反馈：[学生反馈意见]5.3 改进措施：[改进教学的措施][其他备注信息]教案检查表使用说明：1. 在编写教案时，请根据实际情况填写教案基本信息。
2. 根据课程目标和教学内容，明确教学目标，并具体列出知识、技能和情感目标。
3. 详细规划教学内容，包括教材、教学资源、教学方法和教学步骤。
4. 制定教学评估方案，包括评估方式、评估指标、评估工具和评估时间。
5. 在教学结束后，进行教学反思，评估教学效果，收集学生反馈，并提出改进措施。
通过使用此教案检查表，教师可以确保教案内容的完整性、逻辑性和可操作性，从而提高教学质量，促进学生的全面发展。
六、教学资源准备6.1 教材准备：[教材名称]6.2 辅助材料：[辅助材料名称]6.3 技术准备：[所需技术名称]6.4 教具准备：[教具名称]七、课堂管理7.1 课堂规则：[课堂规则描述]7.2 学生分组：[分组方式及分组人数]7.3 纪律维护：[纪律维护策略]7.4 学生参与：[提高学生参与度的策略]八、教学活动设计8.1 导入：[导入活动描述]8.2 主体教学：[教学活动主体部分描述]8.3 互动环节：[学生互动活动描述]8.4 总结：[课堂总结活动描述]九、作业与练习9.1 作业布置：[作业内容与要求]9.2 作业反馈：[作业批改与反馈方式]9.3 练习设计：[练习内容与目标]9.4 练习反馈：[练习批改与反馈方式]十、课后反思与评估10.1 教学反思：[对本节课教学的思考与评估]10.2 学生反馈：[收集学生对课堂的反馈]10.3 改进措施：[针对教学效果不足提出的改进方法]10.4 下次教学计划：[下一节课的教学计划和目标]教案检查表使用说明（续）：6. 在教学资源准备部分，详细列出所需的教学资源、技术、教具等，确保课堂顺利进行。
软件评审检查表
在体系结构设计中，是否清晰描述了数据流、控制流与接口？ 在体系结构设计中，是否清晰描述了数据流、控制流与接口？ 在设计说明书中是否描述了所有的假设、约束、决定与依赖？ 在设计说明书中是否描述了所有的假设、 约束、 决定与依赖？ 是否定义了目标？ 是否定义了目标？ 在合适时，是否有设计是多样的、一致的？ 在合适时，是否有设计是多样的、一致的？ 功能性 对每个子模块是否都做了简要描述并概略描述了采用的算法？ 对每个子模块是否都做了简要描述并概略描述了采用的算法？ 选择的设计或算法是否满足需求？ 选择的设计或算法是否满足需求？ 接口 所有接口的描述是否与需求文档一致？ 所有接口的描述是否与需求文档一致？ 在软件各个功能模块之间的数据流是否得到了明确描述？ 在软件各个功能模块之间的数据流是否得到了明确描述？ 是否对所有的元件之间的接口都进行了定义？ 是否对所有的元件之间的接口都进行了定义？ 是否接口的定义正确、 合理？ 是否接口的定义正确、 合理？ 是否所有的外部接口定义可以追索到需求？ 是否所有的外部接口定义可以追索到需求？ 细节 KLOC，FPA） 是 否 每 个 子 模 块 的 规 模 都 得 到 估 计 （ KLOC ， FPA ） 并 且是 合理 1 的？ 是否考虑了所有可能的状态和用例？ 2 是否考虑了所有可能的状态和用例？ 是否描述足够详细以至于可以开始详细设计阶段？ 3 是否描述足够详细以至于可以开始详细设计阶段？ 九 可维护性 设计是否高内聚、低耦合的？ 1 设计是否高内聚、低耦合的？ 2 设计是模块化的吗？ 设计是模块化的吗？ 设计是否采用了继承，是否描述了选择的工具？ 3 设计是否采用了继承，是否描述了选择的工具？
是[1]否[ ]免[ ] 是[ ]否[1]免[ ] 是[1]否[ ]免[ ] 是[1]否[ ]免[ ] 是[ ]否[ ]免[ ] 是[ ]否[1]免[ ] 是[ ]否[ ]免[1] 是[ ]否[ ]免[ ] 是[ ]否[ ]免[1] 是[ ]否[1]免[ ] 是[ ]否[1]免[ ] 是[ ]否[1]免[ ] 是[ ]否[1]免[ ] 是[ ]否[ ]免[ ] 是[ ]否[1]免[ 是[ ]否[1]免[ 是[ ]否[1]免[ 是[ ]否[ ]免[ 是[ ]否[1]免[ 是[1]否[ ]免[ 是[ ]否[1]免[ ] ] ] ] ] ] ]
项目设计评审检查表
设计评审检查单
项目名称 评审人
项目经理 评审日期
合格 不合格 未检查 不适用
共计
结论
统计结果
0
0
0
0
0
序号 概要设计
检查内容
1 设计方案是否满足产品需求与用户需求的功能、性能及安全性等所有要求？
2 设计方案的架构设计是否简单而清晰？ 3 是否尽可能避免了模块（或子系统）间的相关性？
4 是否对处理流程、总体结构与模块、功能与模块的关系进行了清楚的描述？
5 是否对数据结构了清晰描述？对内部模块间接口进行了清楚 描述？
7 如果有移植的需求，那么设计中是否对移植性作了充分的考虑？ 8 如果采用数据库技术，数据库设计是否与其了他设计内容一致？ 9 是否详细考虑了编码时的代码复用问题？ 10 设计方案是否考虑了软件的扩展性与维护性？ 11 是否规定了设计与编码时的命名规则？ 12 是否进行了出错信息与出错处理的设计？ 详细设计 13 界面设计是否布置合理、版面美观、内容协调？
14 如果采用面向对象的设计方法，是否对对象模型进行了清楚表述？
检查情况
15 如果采用面向结构化的设计方法，是否对模块结构关系进行了清楚表述？
16 每个对象（或模块）的数据结构、处理逻辑都进行了必要的描述？
17
对重要的用户使用场景是否用动态模型（表述系统如何响应特定事件）进行描 述？
评审人意见 补充信息
产品技术评审-TR3检查表
产品技术评审-TR3检查表
目录
1目的 (4)
2适用范围 (4)
3定义 (4)
4TR3检查表 (4)
1 目的
编写本说明书的主要目的，也可指出与本本说明书相对应活动应达到的目的。
2 适用范围
列出有哪些角色、部门、岗位、人员在什么情况下使用本说明书。
也可鉴别并简单地列出该说明书不适用的领域。
3 定义
列出本文档中所使用的术语和缩略语。
可引用已有的数据字典，如没有则需要在此列出。
例如：参见《数据字典.doc》
术语——列出在本流程中用到的关键词和专用词，并给出其含义；
缩略语——应列出在本流程中用到的所有缩略语，并给出中英文全称；另外在正文中缩略语首次出现处也要给出其中英文全称。
4 TR3检查表。
软件项目初验文档清单
1、中标通知书
2、项目合同
3、项目经理任命书
4、项目开工申请表
5、项目实施方案
6、项目质量保证计划
7、项目实施进度计划
8、软件需求规格说明书（含需求规格审核表）
9、概要设计说明书（含概要设计说明书审核表）
10、详细设计说明书（含审核表）
11、数据库详细设计说明书
12、测试计划方案审核表
13、测试方案
14、测试用例
15、测试报告
16、项目初步验收申请表
17、项目初步验收方案
18、项目施工日志
19、功能对照检查表
20、自检报告
21、项目初验总结报告
22、三方会议纪要
23、项目初验报告书（项目备忘录）
24、项目付款申请表
共24个文件，应该能满足大部分软件初验标准。
当然还要看甲方以及监理方对项目监管的要求，适当增/减文档。
软件开发度量及考核方法
软件开发度量及考核方法一、引言如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。
虽然目前很多公司有这方面的绩效考核，但是由于软件开发行业的特殊性，大多数公司没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。
所以根据以前经验和相关的资料编写了适用于本部门的度量和考核方法。
该考核方法是技术支持部软件开发人员和测试人员的试行版本。
二、目的对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。
三、考核实施办法1、定义1.1、软件项包括1）、技术文档："软件工程产品集"所确定的配置项。
主要包括：用户需求文档、需求分析文档、概要设计文档、详细设计文档、开发计划、测试文档、用户手册、总结报告等。
2）、计算机程序。
1.2、度量数据的来源1）、项目计划：过程度量中及时度考核数据的主要依据。
2）、测试文档：计算机程序质量考核数据主要依据。
3）、软件维护记录：主要是指软件产品投入用户使用后产生的软件维护记录。
2、质量度量2.1 度量指标主要根据各类软件项检查表的检查指标来确定。
例如，详细设计说明书检查表有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。
（1）软件项的质量等级的确定根据度量综合指标进行。
2）度量综合指标计算公式为：Total = ∑QiMi。
3）其中i=1,2,...n代表指标数量；4）Q代表度量的指标；5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。
度量指标权重系数表序号 1 2 3 4 5 …指标指标1 指标2 指标3 指标4 指标5 … 加权平均分权重权数1 权数2 权数3 权数4 权数5 … 1.06）质量评价：一般地，根据度量综合指标值，有以下评分标准。
同行评审指南V1.0
文件编号：同行评审指南本V1.0文档修订记录目录1编制目的 (1)2适用范围 (1)3过程指南 (1)3.1软件工作交付物同行评审类型的选择 (1)3.2正规检视指南 (2)3.2.1同行评审组织者的选择 (2)3.2.2正规检视计划 (2)3.2.3介绍会议 (5)3.2.4预评审 (5)3.2.5评审会议 (5)3.2.6缺陷的修改与验证 (7)3.3走查流程 (7)3.3.1计划 (7)3.3.2准备 (8)3.3.3评审会议 (8)3.3.4缺陷的修改与跟踪 (8)4附录 (9)4.1附录1：表格索引 (9)1编制目的本文档的编制目的是为同行评审过程提供指导，以提高同行评审的效率，及早地发现被评审的软件工作交付物中的错误与缺陷，提高软件交付物质量。
2适用范围本指南适用于XXX银行信息科技部软件开发系统的同行评审活动。
3过程指南开始执行该过程的必须具备的前提条件：如执行该过程的角色应具备的能力和资源、约束条件已满足等。
3.1 软件工作交付物同行评审类型的选择项目技术经理在计划同行评审类型时可以根据表1 进行选择。
表1.同行评审类型选择建议在需求与设计过程中，在正式的正规检视之前，可以安排走查，对过程可以不具体要求，但是必须完成《同行评审总结报告》中的缺陷汇总表。
为了保证同行评审的效率，项目技术经理在制定项目计划时应注意以下事项：➢在估计工作量时应考虑评审的工作量。
➢提供同行评审所需的资源，项目组成员的任务安排中要包括同行评审。
3.2 正规检视指南3.2.1同行评审组织者的选择项目技术经理在确定了要进行正规检视的软件工作交付物同时要选择同行评审组织者，同行评审组织者要符合以下要求：➢是所要评审的软件工作交付物方面的专家。
➢接受过同行评审组织者培训，参加过两次以上正规检视类型同行评审。
3.2.2正规检视计划作者在软件工作交付物完成后，根据评审计划提交软件工作交付物。
评审组织者要验证正规检视的入口准则与输入物。
软件设计评审检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
产品详细设计评审检查表-模板
××产品详细设计评审检查表
【内容】
●评审人员根据此表认真审核《产品详细设计规格说明书》。
●如果是合同项目，可能还需要用户审核，视具体情况而定。
【裁剪原则】
此部分内容不允许裁剪。
评委名称
评委日期YYYY-MM-DD
评审结论 合格 不合格 TBD 待完成 NA 不适用详细设计检查表结论
基本检查详细设计是否覆盖了所有的总体设计条目？
详细设计和总体设计之间是否存在冲突？每一个模块的关键算法、关键数据结构是否清楚？
各模块之间的接口是否清晰？
设计是否是可实现的？
设计是否有遗漏和缺陷？
可读性检查设计说明是否通俗易懂？
设计中，关键部分是否使用图表加以说明？是否提供软件设计图（类图，序列图，状态图…）
是否提供数据结构设计图(数据库设计，XML结构设计，文件格式设计)
是否提供样例代码，说明如何使用？
可用性检查设计中的命名是否与
现有系统冲突
是否存在不合理的设计结构（例如包耦合：不应交叉耦合，下层中的包不应依赖于上层中的包，依赖关系不得跳层，包不应依赖于子系统，仅应依赖于其它包或接口）
设计是否与某些现有规范存在冲突？（编码规范，设计规范，J2EE 规范….）
设计实现的复杂程度设计实现的瓶颈
依赖型检查是否使用或依赖于第三方的产品？
第三方产品是否可以由不同的提供商替换？
设计中涉及到关键技术是否成熟？
其他问题。
产品结构设计检查表
软件设计检测表
项目名称： 送检人：
序号 编号
1
1 外观结构
检查项目说明
检查结果 是 否 NA
2 1.1 外观方案是否具有独创性，是否已经充分考虑知识产权方面风险？
3 1.2 外观尺寸与重量是否满足需求？
4 1.3 外观方案是否满足需求?
5 1.4
备注 （不符合项需要说明）
12 2.2 各结构件壁厚是否合理？
13 2.3 加强筋的厚度与数量是否合理？
14 2.4 螺丝选用是否合理？
15 2.5 安装固定柱是否合理？
16 2.6 各结构件的装配性能是否合理？
17 2.7 产品结构是否方便维护
18 2.8 结构工艺是否设计合理？
19 3 外接口结构设计部分
20 3.1 接口标识是否规范？ 21 3.2 接口布局方式是否合理？ 22 3.4 接口方式是否具通用性？ 23 3.5 接口方式是否具通用性？
6 1.5 外观方案的符号、丝印内容等是否符合行业规范？
7 1.6 外观设计方案选用的材料，表面处理是否考虑了现有的制造工艺和制作成本？
8 1.7 产品外观上是否有名牌粘纸、条码等黏贴位置？ 9 1.8 产品结构是否已经考虑电子器件的发热与散热？ 10 2 其他内部设计
11 2.1 结构设计是否留有升级和扩展空间？
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
35
是否设计的每一部分都能追溯到其他项目文档的需求，也能追溯到更高文档的需求？
36
是否所有的设计决定都能追溯到权衡考虑？
37
单元需求是否都能上溯到更高级别的文档？更高级别文档的需求是否已经在单元中体现？
填表说明：Y—是，TBD—不确定，N—否，NA—不适用
监理工程师：日期：
12
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
13
是否所有声否所有该单元的数据结构都被详细说明？
15
是否所有修改共享数据（或文件）的程序都考虑到了其他程序对该共享数据（或文件）的存取权限？
16
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
17
接口参数在数量、类型和顺序上是否匹配？
18
是否所有的输入和输出都被正确定义和检查？
19
是否传递参数序列都被清晰描述？
20
是否所有参数和控制标志由已描述的单元传递或返回？
21
是否详细说明了参数的度量单位、取值范围、正确度和精度？
22
共享数据区域及其存取规定的映射是否一致？
可维护性
23
单元是否具有高内聚度和低耦合度（如对该单元的更改不会在该单元有任何无法预料的影响并对其他单元的影响很小）？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
30
是否考虑到意外事件？
易测性
31
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
32
该设计是否包含检查点来帮助测试（如有条件的编译代码和数据声明测试）？
33
是否所有的逻辑都能被测试？
34
是否已描述测试程序、测试数据集和测试结果？
性能
24
是否该单元的所有约束（如过程时间和规模）都被详细说明？
可靠性
25
初始化是否使用到默认值，默认值是否正确？
26
是否在内存访问的时候执行了边界检查（如数组、数据结构、指针等）来确保只是改变了目标存储位置？
27
是否执行输入、输出、接口和结果的错误检查？
28
是否对所有错误情况都发出有意义的信息？
29
详细设计说明书检查表
序号
检查项
Y/TBD/N/NA
清晰性
1
所有单元或过程的目的是否都已文档化？
2
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
3
是否已定义和初始化所有的变量、指针和常量？
4
是否已描述单元的全部功能？
5
是否已详细说明用来实现该单元的关键算法（如用自然语言或PDL）？
6
是否已列出该单元的调用？
依从性
7
该文档是否遵循了该项目已文档化的标准？
8
是否采用了所要求的方法和工具来进行单元设计？
一致性
9
数据元素的命名和使用在整个单元和单元接口之间是否一致？
10
所有接口的设计是否互相一致并且和更高级别文档一致？
正确性
11
是否处理所有条件（>0，=0，<0，switch/case）？是否存在处理“case not found”的条件？