软件评审检查表-问题记录
软件项目需求评审检查表-模板
7充
功能项（能够统计各地区、行别的资金流量流向）有
8 遗漏
功能项（根据机构代码、行别、清算行、地区代码等 条件查询收费信息；根据机构代码、行别、清算行、 地区代码等条件查询提出提入业务量）未在需求说明
9 书中体现，需要补充；
3306951832.xls 第2页 共2页
评审准备表
项目经理 角 色 评审检查者
QA工程师 评审日期
序号
1 跨区代理问题
2020/9/23 缺陷记录
作者
记录人
缺陷总数 缺陷级别 提出人
一般
14 备注
多表实现。其中控制类型只允许条件是否可略去需和
2 用户确认
3
4 进行修改
补充市区操作员和各县区操作员可查询的账户信息范
5围 6 大额交易查询检测功能：用户界面项遗漏行别等字段
12 有遗漏
功能项（已存在的银行类别可以修改，如将农信社改
13 为农合行或农商行）不需要实现批量改
批量导入、导出功能。提供按机构代码、清算行行号 、账号位数批量删除账户信息功能。提供账户批量迁 移功能）原系统中导入Excel、批量删除功能还未实
14 现，需要补充 15
一般 一般 严重 严重
建议
上海畅星智能系统有限公司
提供账户批量迁移功能原系统中导入excel批量删除功能还未实现需要补充功能项一台前置机支持多个清算账户未在需求说明书中体现需要补充功能项交易明细查询可以设置查询金额的范围有遗漏上海畅星智能系统有限公司第2页共5页a1299073341编号项目是否不适用说明1需求划分是否合理是2业务规则是否均有说明
软件开发部内审检查表
软件开发部内审检查表内部审核检查表JL-HWKS-24 受审核部门软件开发部审核日期2017年9月15日审核员茆秋琪ISO9001管理体系要求条款检查内容和方法检查记录6.2质量目标与应对措施组织是否设定了质量目标？目标的内容是否符合方针的要求？目标的内容是否包括产品要求及满足产品要求的所需的内容？目标的内容是否体现了持续改进的精神？组织均已设定了质量目标。
目标的内容均已符合方针的要求。
目标的内容均已包括产品要求及满足产品要求的所需的内容。
目标的内容均已体现了持续改进的精神。
9.3管理评审询问管理评审会议是如何筹备的；查评审计划和评审记录：a评审计划和.会议通知，b.评审输入的发言文件，c.签到表，d.会议记录，e. 评审决定（输出），f. 会议决定落实的文件。
已查管理评审的相关记录，基本筹备符合ISO标准要求。
9.1.3 分析和评价如何证实质量管理体系的适宜性和有效性，并评价在何处可以持续改进质量管理体系的有效性，公司建立和保持《分析与改进管理程序》，以确定、收集和分析适当的数据和信息？证实质量管理体系的适宜性和有效性，并评价在何处可以持续改进质量管理体系的有效性，公司建立和保持《分析与改进管理程序》，以确定、收集和分析适当的数据和信息。
8.5.2产品标识对产品是否进行了标识，产品的检验状态标识是否符合规定的要求？在记录中对标示和可追溯性进行了规定。
7.1.3基础设施是否为公司的设备设施提供管理？配备了满足公司软件开发，开发的产品能够满足客户的需求，符合相关产品标准7.1.4过程运行环境是否为公司办的环境提供检查？为公司软件开发的工作环境提供检查，见相关制度7.1.5监视和测量的资源是否编制了《监视和测量控制程序》？对于计量器具的管理是否建立台账并且年度检测？编制了《监视和测量控制程序》对于计量器具的管理建立台账并且年度检测8.7不合格控制的输出公司采用那些对不合格控制的方法a)本公司采用内部审核、过程审核、工作质量的检查活动，对质量管理体系的各个过程及其派出进行有效性评价；通过对原材料检测、成品检测过程过程实现服务提供过程进行分析8.5开发和服务的控制本公司是否对开发和服务提供过程进行策划，并使其在受控条件下进行。
软件项目过程文档评审检查表
评审耗时 （小时）
是否通过 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
检查项
过程规范 是否符合过程文件模板要求 规范中的角色是否已经定义清楚 活动中对应的角色是否正确 活动的描述是否使用了多余的形容词和 副词 规范中的模板是否用蓝色标注出来 规范中提到的模板是否和定义的模板一 致
软件质量问题跟踪记录表模板
确定解决问题措施
确定解决问题措施
第一次检杳日期
质量人员检杳的日期
第一次跟踪缺陷的实际检杳日期
第二次解决人
对存在的问题进行修正人
检杳后对问题确定修改人
第二次预计解决日期
确定解决问题的日期
确定解决问题的日期
第二次解决措施
确定解决问题措施
确定解决问题措施
第一次检杳日期
质量人员检杳的日期
第三次跟踪缺陷的实际检查日期
2、一般：活动已经进行/工作产品已经存在，但其中部分内容不符合要求；
3、严重：活动完全没有进行或工作产品完全没有；检杳点前应该执行的过 程没有执行，比如已经到测试阶段，但测试用例评审没有进行;后补或伪造；能引发客户投诉或产生重大质量问题；
问题描述
简要描述问题
检杳后填与，对不合格项简要说明问题
第一次解决人
提升后结果
上报提升后的结果描述
对上报缺陷的审核，对结果描述。上报的原则参照过程与产品质量保证规范
质量人员
执行检查的人员
检杳后填与，质量人员姓名
检验项编号
检验项在质量检查表中的编号
根据过程任务名称从质量检杳表中复制并且不能修改
检验项
用来衡量检查对象的标准
检杳类型
有审核，监察
从检杳表中复制并且不能修改，检杳后必须选择审核，或者监察
负责人
该项检验项的主要负责人或作者
检杳前填写，项目或活动成员的姓名
缺陷严重性
该缺陷的严重性
分为三个等级。
1、轻微：对质量、进度、成本等项目因素产生轻微影响；
第
次 解 决
措 施
第
次 检 查 日 期
第二次缺陷关闭状态
测试计划评审检查表
5 是否明确测试环境（软件、硬件环境）？
6 是否对选定的测试工具的相关信息进行了详细描述并且经过确认？
7 测试各阶段的人员和进度安排是否合理？ 是否确定了测试阶段存在的主要风险，制定了详细的控制措施，并已经取得部
8 门或公司领导层的支持？
9 是否明确了配置库的层次结构？
10 《配置库结构层次ຫໍສະໝຸດ 》中确定的层次结构是否完整、实用？
11 是否明确了测试过程中基准配置项变更与完善控制的界定准则？
说明：（责任人对确定为“否”的检查项给出必要说明）
第 1 页/共 1 页
测试计划评审检查表
表格编号：项目编号-阶段/文档类别代号-两位顺序号
项目名称：
序 号
检查项
结 果
1 是否明确测试目的、预期达到的目标以及本次测试的范围？
2 是否完整、清晰地列出本计划中的专用词汇，并沿用了先前过程中定义词汇？
3 是否根据确定的测试类型与测试范围明确测试所需的手段、方法？
4
是否根据软件产品或项目的实际特点，对"A"、"B"、"C"、"D"四类问题的分级 原则进行了明确、详细地描述？
软件过程检查表
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。
软件评审检查表
在体系结构设计中，是否清晰描述了数据流、控制流与接口？ 在体系结构设计中，是否清晰描述了数据流、控制流与接口？ 在设计说明书中是否描述了所有的假设、约束、决定与依赖？ 在设计说明书中是否描述了所有的假设、 约束、 决定与依赖？ 是否定义了目标？ 是否定义了目标？ 在合适时，是否有设计是多样的、一致的？ 在合适时，是否有设计是多样的、一致的？ 功能性 对每个子模块是否都做了简要描述并概略描述了采用的算法？ 对每个子模块是否都做了简要描述并概略描述了采用的算法？ 选择的设计或算法是否满足需求？ 选择的设计或算法是否满足需求？ 接口 所有接口的描述是否与需求文档一致？ 所有接口的描述是否与需求文档一致？ 在软件各个功能模块之间的数据流是否得到了明确描述？ 在软件各个功能模块之间的数据流是否得到了明确描述？ 是否对所有的元件之间的接口都进行了定义？ 是否对所有的元件之间的接口都进行了定义？ 是否接口的定义正确、 合理？ 是否接口的定义正确、 合理？ 是否所有的外部接口定义可以追索到需求？ 是否所有的外部接口定义可以追索到需求？ 细节 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
软件性能
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
部署后是否可以正常使用.
5
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
2
界面美观设计
界面的美观性.
界面美观.
3
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
5
功能要求
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合 ，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
100分
评审结论：
5ห้องสมุดไป่ตู้
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.
5
安全性要求
访问安全性，使用安全
性
用户身份管理和访问控制
数据安全性
10
软件文档
文档资料
完整性
规范性
软件过程文件目录
20
分数
软件产品评审表
评审时间：
评审人员：评审组长（），评审成员（）
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合 ，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
交互性要求
简易位，一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
软件性能
软件定位
使用者的明确性.
明确的使用者定位.明确的目标
软件部署
部署
软件的发布与安装部署
部署后是否可以正常使用.
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
界面美观设计
界面的美观性.
界面美观.
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
软件产品评审
评审时间：2019-5-17
评审人员：评审组长（），评审成员（）
产品介绍主讲：程飞
项目名称
智能交通集成管理平台
开发小组
研发中心（智能交通）
开发人员
组长：成员：
评审项目
评审细顶评审指标(评要点)指标说明(评审要点说明}
问题列表
产品内容
产品内容
内容完整性
即相对完整的完成软件愿景,说明书上的功能.
安全性要求
访问安全性，使用安全性
用户身份管理和访问控制
数据安全性
软件文档
文档资料
完整性
规范性
软件过程文件目录
评审结论：通过
有条件的通过
不通过（需再次评审）
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.