软件项目过程文档评审检查表模板

软件设计评审检查表

是否所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰的描述？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析？
详细设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
正确性
是否处理所有条件（大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
该测试计划是否和更高级别的测试计划文档一致？
正确性
该测试计划的进入和退出条件是否实现？
是否所有必须的驱动程序和桩（stubs）都已被定义且可利用来测试指定的功能？
详细级别/程度
是否定义了总体设计目标？
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？

软件项目过程文档评审检查表

过程模板模板是否符合iso表单模板要求表格的表头是否使用统一的淡蓝色表格中的字体是否统一模板中文字描述是否合理。
评审耗时（小时）
是否通过 N/A,Y,N
缺陷个数
缺陷描述
版本号：2 修订号：0
第1页共1评审人
评审日期
评审规模（页）
序号
1 1.1 1.2 1.3
1.4
1.5
1.6
2 2.1 2.2 2.3 2.4
检查项
过程规范是否符合过程文件模板要求规范中的角色是否已经定义清楚活动中对应的角色是否正确活动的描述是否使用了多余的形容词和副词规范中的模板是否用蓝色标注出来规范中提到的模板是否和定义的模板一致

过程审核检查表示例

针对顾客提出的特殊设备、工装、材料均能按时交付产线使用
为了对正式投产提供保障，是否对项目交接进行了控制
查XX公司项目时，生产部门能提供新产品制作的SOP 、图纸、工装、设备等的验收记录，品质部门提供了产品的检验规范
是否只和获得批准且具备质量能力的供应商开展合作
查目前的合格供方，均对其展开了调查和评价，同时采购部门提供了供应商的评价准则，评价包括供应商质量保证PPM、供货、研发能力，但缺少汽车业务量（绝对值，以及占总业务量的百分比），业务连续性规划（如：防灾准备、应急计划）等的调查项目
目前项目计划处于第三阶段，但未对各阶段展开评价，未确认各阶段项目的落实情况。
按照XX公司客户项目的进展，更新项目计划，重新评审项目计划
工程部
10/30
项目管理机构是否可以在项目进行过程中提供可靠的变更管理
目前所有的产品结构，外观变更均通知顾客并得到批准，同时对变更后的结果进行了验证关闭。
对于涉及变更SOP的，应及时编制更改
修订供应商调查表，增加对供应商汽车业务量占比、业务连续性规划的项目调查
采购部
10/30
在供应链上是否考虑了顾客要求
通过联络函的形式告知供方有关顾客要求，并有IQC监控目前的来料状况，查双方签订的质量保证协议有明确要求顾客要求
是否与供应商就供货业绩约定了目标，并且加以落实
在质量协议上有规定供货PPM要求，每月的供方绩效评价统计每个供方的供货PPM是否达标
是否按实际的需要对进厂的货物进行了储存（仓库应根据实际存放条件，定期对库存物料进行巡查，对于相似物料应按照不同颜色标识或存放地点不同来管理，对于有存放周期限制的物料应按照先进先出原则发料，并统计长时间不用的呆滞物料和过期物料）
1、呆滞物料无台账管理：物料没有进行编制呆滞明细表、处理方式及处理期限，没有做到物尽其用、货畅其流、减少资金堆积的目的，2.报废仓无台账无具体管理措施

软件过程检查实用表.docx

1.过程检查要素表客户定制平台或产品研检查内容或应用开中间件维护项目检查时间检查结果参加成员发项目发项目项目√√计划过程√√计划阶段结束（可选）（可选）计划跟踪和设计阶段结束√√√√监督过程测试阶段结束软件产品审√√√√正式评审结束查过程（可选）（可选）需求分析阶段软件过程SQA人员，审计报告项目组成员软件过程SQA人员，审计报告项目组成员软件过程 SQA人员审计报告项目经理SQA人员，需求分析过软件过程√结束项目经理，程审计报告测试阶段结束系统分析员√√系统设计过设计阶段结束软件过程SQA人员，√项目经理，程测试阶段结束审计报告系统分析员√需求和设计软件过程SQA人员，√√√编码阶段结束管理过程审计报告项目经理，软件编码过软件过程SQA人员，√编码阶段结束程√审计报告项目组成员√软件测试过（可选）软件过程SQA人员，√测试阶段结束程审计报告项目组成员SQA人员，项目经理，产品验收和软件过程√√√√项目验收后测试人员，发布过程审计报告配置人员，用户代表SQA人员，配置管理过设计阶段结束软件过程√√√√项目经理，程测试阶段结束审计报告配置管理员高级经理，软件质量保软件过程√√√√验收阶段结束SQA经理，证过程审计报告项目经理2.过程打分2.1.过程打分原则：1)过程打分占整个项目得分的30％，以 30 分为满分，最低分不低于9 分。

2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。

3)SQA人员对经剪裁的软件过程的检查内容和实施情况进行剪裁。

4) 项目级的软件过程剪裁必须得到高级经理，质量管理部经理和项目SQA 人员的检查和认可；检查内容和实施情况剪裁必须得到项目经理和受审计人员的认可。

5)软件过程检查打分的依据是“ 过程检查表” 。

2.2.打分步骤：1)依据标准过程定义项目过程，得出项目过程数N 。

软件质量保证立项评审检查表

软件质量保证立项评审检查表1000字软件质量保证立项评审检查表一、需求分析1. 需求是否清晰、具体，是否与用户需求相符合？2. 是否需要补充或精化需求？是否已经广泛征求用户意见？3. 需求是否可以量化，是否可以度量，以及程度？4. 需求是否完整具备可行性、可实现性、可测试性？5. 需求是否构成了完整的规格说明书？二、设计文档1. 设计文档是否清晰、具体，是否是项目整体的完整性？2. 设计文档中的系统模块、功能模块是否划分明确，模块之间的接口定义是否清晰？3. 设计文档是否考虑了可扩展性、可维护性、可测试性等因素？4. 是否有详细的数据结构和算法描述？5. 是否有详细的接口设计和协议定义？三、编码1. 编码是否遵照设计文档，变量、函数、接口等定义是否清晰规范？2. 编码是否遵循团队约定的代码规范，是否合乎良好的编程习惯？3. 长大的复杂度是否能够在可控的范围内？4. 是否设置了有效的代码注释，方便其他程序员理解和维护？5. 代码风格是否美观，可读性是否良好？四、测试1. 测试计划是否清晰，测试用例是否完善？2. 是否考虑到各种不同的测试策略和测试方法？3. 测试是否包含细致的测试脚本和测试数据，以及详细的测试记录？4. 测试报告是否符合规范和需求，是否能够详细地描述问题和解决方案？5. 测试人员的反馈是否及时，是否遵循优先级原则及时解决问题？五、文档1. 是否有详尽的用户帮助手册和安装说明文档？2. 文档是否符合公司或部门的标准及规范，包括版式及内容等？3. 文档是否易于查找，是否提供详细的目录及索引规划？4. 文档是否准确、详细、易懂、有用，容易让用户理解？5. 是否有响应的文档版本控制及更新机制？六、验收1. 是否有详细的验收计划和验收流程？2. 验收标准是否符合用户要求，以及实际软件工程产品的需求？3. 是否有足够的验收数据，是否全面？4. 是否制定了验收的测试和评估机制？5. 是否有足够的用户支持和评估人员参与测试和评估？七、项目工程价值1. 项目工程是否符合公司或部门的目标与愿景？2. 项目工程是否有足够的经济效益或社会效益？3. 项目工程是否为公司或部门突破技术障碍或获得新技术而做出的贡献？4. 项目工程是否有行业领先水平，是否通过认证？5. 项目工程是否对公司或部门的进一步发展有推动作用？八、项目管理1. 项目经理是否有权威和汇报机制，是否有足够的资源配备？2. 项目管理是否有充足的规划和控制，是否符合公司或部门的项目管理流程和规范？3. 是否全面掌握和收集项目信息，在管理中进行有效的变更控制和风险管理？4. 是否足够注意项目的质量控制和工程的规划合理性？5. 是否通过合理的时间、人力和财务的管理，使得项目得以成功完成？以上是软件质量保证立项评审检查表。

软件设计与开发评审检查表

是否在内存访问的时候执行了边界检查（例如: 数组、数据结构、指针等）来保证只是改变了目的存储位置？
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出故意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否可以对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到本来拟定的权衡因素?
所继承设计的已知风险是否已拟定和分析？
具体设计检查表
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
检查项
Y/TBD/N/NA
清楚性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
对的性
是否解决所有条件（大于、等于、小于零、switch/case）？是否存在解决“case not found”的条件？
是否对的地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
备注
检查项
Y/TBD/N/NA
清楚性
系统的目的是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清楚, 不模糊？
是否有对整套系统进行功能概述？
是否已具体说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？

软件评审检查表

在体系结构设计中，是否清晰描述了数据流、控制流与接口？在体系结构设计中，是否清晰描述了数据流、控制流与接口？在设计说明书中是否描述了所有的假设、约束、决定与依赖？在设计说明书中是否描述了所有的假设、约束、决定与依赖？是否定义了目标？是否定义了目标？在合适时，是否有设计是多样的、一致的？在合适时，是否有设计是多样的、一致的？功能性对每个子模块是否都做了简要描述并概略描述了采用的算法？对每个子模块是否都做了简要描述并概略描述了采用的算法？选择的设计或算法是否满足需求？选择的设计或算法是否满足需求？接口所有接口的描述是否与需求文档一致？所有接口的描述是否与需求文档一致？在软件各个功能模块之间的数据流是否得到了明确描述？在软件各个功能模块之间的数据流是否得到了明确描述？是否对所有的元件之间的接口都进行了定义？是否对所有的元件之间的接口都进行了定义？是否接口的定义正确、合理？是否接口的定义正确、合理？是否所有的外部接口定义可以追索到需求？是否所有的外部接口定义可以追索到需求？细节 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]免[ ] ] ] ] ] ] ]

软件评审检查表-计分

15
交互性要求
简易位，一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
15
软件性能
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
部署后是否可以正常使用.
5
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
2
界面美观设计
界面的美观性.
界面美观.
3
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
5
功能要求
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
100分
评审结论：
5ห้องสมุดไป่ตู้
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.
5
安全性要求
访问安全性，使用安全
性
用户身份管理和访问控制
数据安全性
10
软件文档
文档资料
完整性
规范性
软件过程文件目录
20
分数
软件产品评审表
评审时间：
评审人员：评审组长（），评审成员（）

项目计划评审检查表模板

项目计划评审检查表
序号计划与合同是否符合？ 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 是否定义了合理的沟通计划？ 30 该项工作的计划与实际成本是否合理？ 31 该项工作的计划与实际进度是否合理？ 32 项目管理小组成员职责分工是否明确，并得到确认？建议: 检查项
评审人员不适用优秀

软件设计与开发评审检查表

该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析？
详细设计检查表
Y: 是 TBD: 不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化？
依从性
是否遵守了项目的文档编写标准？
一致性
数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致？
该设计是否反映了实际操作环境（硬件、软件、支持软件）？
可行性
从进度、预算和技术角度上看该设计是否可行？
是否存在错误的、缺少的或不完整的逻辑？
数据使用
所有复合数据元素、参数以及对象的概念是否都已文档化？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
依从性
该文档是否遵守了该项目的文档编写标准？
一致性
需求说明是否存在直接相互矛盾的条目？
本需求说明书是否与相关需求素材一致？
可行性
所描述的所有功能是否必要并充分地满足了客户/系统目标？
需求说明书的描述的详细程度是否足以进行详细的设计？
已知的限制（局限）是否已经详细说明？
是否已确定每个需求的优先级别？
可管理性
一致性

软件过程检查表格模板

精心整理
1.过程检查要素表
2.过程打分
2.1.过程打分原则：
1)过程打分占整个项目得分的30％，以30分为满分，最低分不低于9分。

2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了
使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。

3)SQA人员对经剪裁的软件过程的检查内容和实施情况进行剪裁。

4)项目级的软件过程剪裁必须得到高级经理，质量管理部经理和项目SQA人员的检查和认可；检查内容
和实施情况剪裁必须得到项目经理和受审计人员的认可。

5)软件过程检查打分的依据是“过程检查表”。

2.2.打分步骤：
1)依据标准过程定义项目过程，得出项目过程数N。

2)每个项目过程的得分M＝30/N。

3)采用“过程检查表”，对各个过程进行检查和打分。

4)定义“过程检查表”中的实际检查内容项个数为X，每项标准得分10分，因此每个“过程检查表”的
5)/该
6)
7)
8)
9)
分计算。

2.3.
第一次
第二次
C=5.3＋5.6＋5.3＋5.7＋5.6＝27.5
3.过程检查表
3.1.计划过程检查表
3.5.系统设计过程检查表
3.6.需求和设计管理过程检查表
3.7.软件编码过程检查表
-来源网络。

软件设计评审检查表

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

软件需求分析评审检查单

软件需求分析评审检查单
软件评审记录
工程代号项目名称
评审日期
年月日
评审性质
序
评审项目
合格不合格不适用
号
1. 文档文档齐全
2. 规范文档编制规范
需求分析方法 3.
工具使用正确
4.
软件功能需求
5.
需求性能要求
6.
ቤተ መጻሕፍቲ ባይዱ
内容接口要求
7.
完整、数据要求
8. 软件正确环境要求
9. 需求软件实时性需求
计划
22.
验证计划安排明确、合理可行
23.
确认计划安排明确、合理可行
24. 软件质量保证计划明确、完整
25. 软件测试的范围和内容明确
26. 配置测试结果评价准则明确、可行
项测测试的组织、人员、进度安排
27. 试计合理、明确
划
评审 □ 复审 □ 备注
10. 规格需求正确性要求
11. 说明合理、完备性要求
12.
可行一致性要求
13.
无二义性要求
14.
可验证性要求
15.
可追踪性要求
16.
可靠性要求明确
17.
数据安全和保密要求明确
18.
阶段划分明确
19.
计划安排明确、合理、可行
软件
20.
软件配置管理要求明确
开发
21.
安全计划安排明确、合理可行

软件过程检查表

1.过程检查要素表2.过程打分2.1.过程打分原则：1)过程打分占整个项目得分的30％，以30分为满分，最低分不低于9分。

2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。

3)SQA人员对经剪裁的软件过程的检查内容和实施情况进行剪裁。

4)项目级的软件过程剪裁必须得到高级经理，质量管理部经理和项目SQA人员的检查和认可；检查内容和实施情况剪裁必须得到项目经理和受审计人员的认可。

5)软件过程检查打分的依据是“过程检查表”。

2.2.打分步骤：1)依据标准过程定义项目过程，得出项目过程数N。

2)每个项目过程的得分M＝30 / N。

3)采用“过程检查表”，对各个过程进行检查和打分。

4)定义“过程检查表”中的实际检查内容项个数为X，每项标准得分10分，因此每个“过程检查表”的最高得分A = 10X。

5)实际检查时，对“实施情况”一栏中每个条款进行打勾“✓”,因此实际每项得分Bj=（打勾条款数/ 该项实际检查总条款数）×10。

6)每个过程的实际得分Bi=∑1x Bj。

7)每个过程的换算得分B=Bi /A ×M。

8)若某个过程发生多次z，则该过程得分B=(∑1zB)/z 。

9)项目的过程得分C=∑1NB 。

10)为确保项目组的基本得分不低于9分，因此各过程打分不得低于9/N分，低于此分，以9/N分计算。

2.3.例子：某项目计划进行5个阶段的审计：计划过程，需求过程，设计过程，测试过程，计划跟踪和监督过程，其中计划跟踪和监督过程执行两次，其他各一次则每阶段得分M=30/5=6;第一次计划跟踪和监督过程检查项共15项，实际由于变更未发生检查了13项, 标准分为A=13×10＝130，实际检查得分Bi=123则该阶段得分B1=123/130 * 6=5.67第二次计划跟踪和监督过程，实际检查了15项，标准分为15×10＝150；实际检查得分140。

软件需求规格说明书评审检查表

22 是否所有的需求都是名副其实的需求而不是设计或实现方案？
23 是否确定了对时间要求很高的功能并且定义了它们的时间标准？
24 是否已经明确地阐述了国际化问题？
25
21
22
23
24
25
结果统计
是：
0个
否：
0个
不适用：
0个
未检查：
0个
说明
检查结果
使用说明：本检查表在项目中各种评审、审计工作实施前编制，用于列出问题、记录
软件需求规格说明书模板需求开发过程序问题号组织和完好性全部对其他需求的内部交织引用能否正确
软件需求规格说明书评审
检查表
编制人员：项目名称：检查依据：《软件需求规格说明书模板》、《需求开发过程》
编制日期：项目经理：花费工作量：
序号
问题
组织和完整性
1 所有对其它需求的内部交叉引用是否正确？
2 所有需求的编写在细节上是否都一致或者合适？
正确性
10 是否有需求与其它需求相冲突或重复？
11 是否简明、简洁、无二义性地表达了每个需求？
12 是否每个需求都能通过测试、演示、审查得以验证或分析？
13 是否每个需求都在项目的范围内？
14 是否每个需求都没有内容上和语法上的错误？
15 在现有的资源限制内，是否能实现所有的需求？
16 是否任一个特定的错误信息都具有唯一性和明确的意义？
质量属性
17 是否合理地确定了性能目标？
18 是否合理地确定了安全与保密方面的考虑？
19 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？

项目总结评审检查表

11 对项目生产率的评价是否准确、客观，具有借鉴价值？
12 对项目使用技术的评价是否准确、客观，具有借鉴价值？
13 对项目评审效率的评价是否准确、客观，具有借鉴价值？
14 对项目最终产品质量的评价是否准确、客观，具有借鉴价值？
15 对项目中的软件复用情况的评价是否准确、客观，具有借鉴价值？
16 是否对测试中发现的设计方面问题进行了详细的总结？
5 是否详细、准确地描述了项目的开发软、硬件环境以及最终提交的软件成果？
6 是否清晰描述了最终提交产品完成的系统特性？
7 产品的功能特性与最终版本的《软件需求规格说明书》中的描述是否一致？
8 是否完整、准确的填写了软件的实际复用情况？
9 是否准确填写了项目日常管理以及工作产品评审中所耗费的工作量？
10 是否准确填写了项目的进度、规模及工作量的数据？
项目总结评审检查表
表格编号：项目编号-阶段/文档类别代结果
1 是否准确描述了项目的主要参与人员在项目中的角色与各自完成的任务？
2 是否对角色、人员的变更进行了准确记录？
3 是否准确填写了项目的开始、结束时间？
4 项目计划是否及时进行更新，以保证准确地记录项目真实的开发进度？
17 是否根据测试的结果对项目的系统设计文档进行了完善？
18 是否对项目的经验教训进行了充分的总结？
19 是否完整的记录下了项目进行过程中出现的全部问题，并进行了有效的分析？
20 对项目的整体风险管理是否作出了完整、有效的总结？
说明：（责任人对确定为“否”的检查项给出必要说明）
第 1 页/共 1 页