软件过程检查表.docx
- 文档编号:11302769
- 上传时间:2023-02-26
- 格式:DOCX
- 页数:46
- 大小:28.73KB
软件过程检查表.docx
《软件过程检查表.docx》由会员分享,可在线阅读,更多相关《软件过程检查表.docx(46页珍藏版)》请在冰豆网上搜索。
软件过程检查表
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。
2)每个项目过程的得分M=30/N。
3)采用“过程检查表”,对各个过程进行检查和打分。
4)定义“过程检查表”中的实际检查内容项个数为X,每项标准得分10分,因此每个“过程检查表”的最高得分A=10X。
5)实际检查时,对“实施情况”一栏中每个条款进行打勾“”,因此实际每项得分Bj=(打勾条款数/该项实际检查总条款数)×10。
6)每个过程的实际得分Bi=∑1xBj。
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。
则该阶段得分B2=140/150*6=5.6
则计划跟踪和监督过程得分B=(5.67+5.6)/2=5.6
计划过程得分=5.3;需求过程得分=5.6;设计过程得分=5.3;测试过程得分=5.7
C=5.3+5.6+5.3+5.7+5.6=27.5
3.过程检查表
3.1.计划过程检查表
检查内容
实施情况
评价
(10分制)
是否有项目开发计划?
□项目开发计划书
□评审问题清单(可选)
□评审通知和确认表(可选)
□项目评审表
□项目评审问题追踪表
□评审人员签字
□批准人确认/签字
□评审时间
□验证人签字
□SQA人员验证
□否(说明原因):
文档格式是否正确?
□是
□文件编号
□配置项编号
□项目版本号
□审核人
□审核时间
□批准人
□批准时间
□符合模板
□否(说明原因):
项目计划文档是否按计划完成?
□是
□按计划完成:
□提前完成并评审
□按计划完成并评审
□按计划完成,评审延迟。
□未按计划完成,延迟天
□采取纠正措施
□否(说明原因):
项目计划是否以确定的需求为依据?
□是
□否(说明原因):
是否有对项目计划的承诺?
□是
□项目组成员和相关人员参与计划过程,并和项目经理就计划达成一致意见
□计划被SQA,SCM和其他相关组检查并达成一致意见
□计划被负责项目的负责人检查并达成一致意见
□项目计划在提交给用户以前在组织内部得到批准
□形成项目责任矩阵表
□若有外部用户,与外部用户就项目计划达成一致意见
□和用户协商的计划变更在最后提交给用户时得到项目内部组的批准
□已承诺项目计划被基线化(如进行配置控制)
□否(说明原因):
关键因素是否被识别和定义?
□是
□项目的进度
□任务预期开始和结束
□工作产品被识别
□项目的工作量
□里程碑开始和实现日期
□预算的费用
□计划的关键计算机资源
□项目组成员任务分配
□为软件开发确定的生命周期模型
□工作产品的验收标准被定义
□其他因素
□否(说明原因):
是否明确指定估算策略对项目的规模进行估计?
□是
□按已定义的方法执行估计过程:
□是否采用历史数据
□无历史数据
□规模估计的量度:
□功能点□需求数□代码行□其他
□规模估计结果文档化
□规模估计结果经过评审
□否(说明原因):
是否为员工的培训需要制定计划?
□是
□培训方式:
□正式培训/□非正式培训
□识别需参加培训人员
□计划参加培训时间
□识别须培训的内容
□否(说明原因):
是否为项目内和项目间的沟通制定计划?
□是
□定义内部沟通方式
□定义内部沟通时间和频率
□识别外部沟通方
□定义外部沟通方式
□定义外部沟通时间和频率
□否(说明原因):
是否确定项目的度量目标?
□是
□定义项目度量目标
□定义需收集的数据和频率
□定义数据收集方式和负责人
□定义度量分析结果
□定义度量分析报告方式
□否(说明原因):
是否识别和分析风险?
□风险管理计划
□风险项清单
□风险发生的应急对策
□风险优先级
□确定各类风险的责任人
□制定风险管理进度
□否(说明原因):
是否选择合适的生命周期模型?
□是
□选择已定义的生命周期模型
□形成新的生命周期模型
□经过批准
□未经过批准
□否(说明原因):
是否进行成本估计?
□是
□否(说明原因):
项目计划是否进行进度细化?
□是
□按生命周期模型划分里程碑
□形成项目的WBS,包括管理,技术和支持活动
□WBS活动有预留时间
□每个WBS活动分配责任人,开始和完成时间
□基于过去类似项目的经验
□小组和个人参与制定和检查WBS
□WBS任务被定义到可以进行进度估算的级别:
□每小时□每天□每2-3天
□每周□其他
□否(说明原因):
配置人员是否管理项目的配置情况?
□是
□管理计划基线
□计划基线分发给相关人员
□否(说明原因):
SQA是否定期检查项目的活动?
□是
□软件过程审计报告(频率)
□软件问题管理
□跟踪和关闭问题
□没有问题
□审计报告分发给相关人员
□否(说明原因):
3.2.软件产品审查过程检查表
检查内容
实施情况
评价
(10分制)
工作产品在决定评审前是否经过审核人的检查和审核?
□是
□否(说明原因):
是否采用工作产品检查单进行评审?
□是
□工作产品检查单
□否(说明原因):
软件评审和检查通知是否有记录?
每一个参与者是否分配了角色?
□是
□评审通知和确认表
□否(说明原因):
评审重点是否放在缺陷检查,而不是纠错上
□是
□否(说明原因):
评审结果是否形成文档
□是
□项目评审表
□项目评审问题追踪表
□否(说明原因):
评审者是否在评审会议前做了充分的准备?
评审准备数据和次数是否被收集?
□是
□评审问题清单
□评审准备工作量
□发现问题描述详细
□标识缺陷严重程度
□标识缺陷类型
□预审结论
□否(说明原因):
评审准备数据和频率是否被收集,以便可以充分应用与将来的准备和评审?
□是
度量表格:
□评审人数
□评审前准备工作量
□评审工作量
□评审次数
□否(说明原因):
评审会议是否经常有调整?
□是
□否(说明原因):
仲裁者是否接到过执行评审的培训?
□是
□否(说明原因):
评审会议时间是否按计划完成?
□是
□否(说明原因):
在每个评审中的发现的问题是否被SQA追踪或验证人检查
□是
□验证人签字
□问题完成情况描述
□按时完成修改和验证
□SQA人员验证过程完整性
□否(说明原因):
3.3.计划跟踪和监督过程检查表
检查内容
实施情况
评价
(10分制)
开发工作是否按计划开始?
□是
不按计划开始原因说明:
□否(说明原因):
项目跟踪是否以形成基线的计划为基础?
□是
□项目开始跟踪以首次计划为基准
□计划变更后跟踪以变更后的计划为基准
□否(说明原因):
计划变更是否执行变更管理过程?
是否对计划的变更进行记录和追踪?
□是
□计划变更最新版本
□变更次数
□变更控制表
□变更问题编号
□变更来源
□变更提出者
□申请时间
□修改人
□变更批准人
(□项目经理□变更控制委员会)
□评审方式
□评审
(□项目评审表□评审问题追踪表)
□签字
□变更状态追踪
□对变更请求产生影响进行评估
□项目版本状态
□修改描述
□修订页变更说明
□修改开发计划和进度
□修改相关文档
□修改人签字
□批准人签字
□验证变更结果与修改说明一致
□验证人签字
□验证日期
□SQA人员验证
□SQA人员检查日期
□变更结果通知变更执行人和受变更影响人员
□否(说明原因):
□没有变更
如果变更不执行,是否有相关的的原因说明?
□是
□变更控制表
□变更不批准原因说明
□变更请求状态为“拒绝”
□否(说明原因):
关键因素是否被监控?
□是
□监控项目的进度
□任务预期开始和结束
□项目规模
□里程碑开始和实现日期
□预算的费用
□计划的关键计算机资源
□项目组成员任务分配
□工作产品完成情况
□项目的工作量
□其他因素
□否(说明原因):
是否跟踪项目规模?
□是
□跟踪定义的项目计划规模
□跟踪项目实际规模
□实际规模和计划规模比较分析
□事件驱动调整项目规模
□按已定义的规模估计方法调整规模
□调整后的规模结果文档化并经过评审
□记录实际的项目规模
□否(说明原因):
是否跟踪项目工作量?
□是
□跟踪计划的项目工作量
□跟踪项目实际工作量
□实际工作量和计划工作量比较分析
□按规程调整工作量
□调整后工作量数据文档化并经过评审
□否(说明原因):
是否跟踪项目进度?
□是
□跟踪计划的里程碑开始结束时间
□跟踪计划任务开始完成时间
□跟踪项目成员任务分配情况
□比较和分析实际,计划的进度差异
□根据实际情况调整项目进度,并经过评审
□否(说明原因):
项目组成员是否每周提交工作情况汇报表,报告度量和分析结果?
□是
□项目组成员每周报告分配的任务状态
□所有报告的已完成的任务被检查
□项目组成员每周报告问题和风险
□项目组成员每周报告变更发生情况和变更状态
□项目组成员报告每个任务的实际工作量花费,每个任务的总的花费天数,每个任务的预计工作量
□项目成员的任务与计划任务匹配
□项目组成员每周重新估计需要完成任务的工作量
□否(说明原因):
是否对识别的风险进行管理,监控和报告潜在的风险?
□是
□更新风险项清单
□风险发生的实际对策
□更新风险优先级
□风险状态跟踪和控制
□风险的责任人跟踪风险
□调整风险管理进度
□定期检查和更新每个风险发生概率和影响
□识别新的风险并进行分析
□否(说明原因):
项目经理是否定期更新任务分配?
□是
安排任务频率:
□每天□每2-3天□每周
□每月□其他
□否(说明原因):
是否控制和解决项目问题?
□是
□定期召开项目会议,交流项目的活动状态,问题和风险
□项目的会议有会议纪要
□在项目状态报告和会议纪要中记录发现的问题
□分配人员执行每个问题的纠错活动和解决问题
□跟踪问题直至关闭
□否(说明原因):
项目经理是否定期形成项目状态报告?
□是
□形成项目状态报告(频率)
□项目状态报告是否提交/分发takeholders:
用户,项目经理/高级经理,相关支持组,小组成员。
□项目状态报告内容是否包括本周项目的完成状况,问题,风险,变更?
□项目的进度度量和其他度量数据是否包括在报告中?
□项目控制下的进度数据反映当前的情况
□项目经理计算和分析关键的实际数据度量,并在项目状态报告中记录
□否(说明原因):
配置人员是否管理项目的配置情况?
□是
□管理计划基线
□SCM基线报告(频率)
□SCM基线变更状态报告
(频率)
□配置报告分发给相关人员
□管理计划变更和发布变更通知
□否(说明原因):
SQA是否定期检查项目的活动?
□是
□软件过程审计报告(频率)
□审计报告分发给相关人员
□否(说明原因):
3.4.需求分析过程检查表
检查内容
实施情况
评价
(10分制)
是否对项目的需求分析和管理活动分配任务和进度?
□是
□项目开发计划书/项目开发计划表
□需求分析活动描述
□责任人
□否(说明原因):
是否对用户的需求进行收集?
□是
□项目需求调研
□项目功能清单
□其他用户文档
□否(原因说明):
□可选
是否对用户需求进行检查并与用户的一致?
□是
□项目需求调研评审
□用户代表确认/签字
□项目经理确认/签字
□其他人员确认
□否(原因说明):
□可选
系统分析人员是否接收过相关培训?
□是
□已具备能力
□正式培训
□小组培训
□自学
□否(原因说明):
系统分析结果是否形成文档
□需求规格说明书/需求表
□评审问题清单(可选)
□评审通知和确认表(可选)
□项目评审表
□项目评审问题追踪表
□评审人员签字
□批准人确认/签字
□评审时间
□验证人签
□SQA人员验证
□系统功能清单
□否(原因说明):
文档格式是否正确?
□是
□文件编号
□配置项编号
□项目版本号
□审核人
□审核时间
□批准人
□批准时间
□符合模板
□否(说明原因):
需求规格说明书是否按计划完成?
□是
□按计划完成:
□提前完成并评审
□按计划完成并评审
□按计划完成,评审延迟。
□未按计划完成,延迟天
□采取纠正措施
□否(说明原因):
需求是否被标识、管理、度、跟踪和关闭?
□是
□需求跟踪矩阵表:
□需求被唯一标识
□需求状态被描述
□统计需求个数
□否(说明原因):
□没有变更
作为潜在问题的需求,在需求说明书中是否被标识?
□是
□潜在问题被描述
□潜在问题被追踪至关闭
□其他说明:
;
□否(原因说明):
□不适用
配置人员是否管理项目的配置情况?
□是
□管理需求基线
□SCM基线报告(频率)
□配置报告分发给相关人员
□否(说明原因):
SQA是否定期检查项目的需求分析活动,标识偏离项目计划或组织结构的内容?
□是
□软件过程审计报告(频率)
□审计报告分发给相关人员
□否(说明原因):
3.5.系统设计过程检查表
检查内容
实施情况
评价
(10分制)
是否形成概要设计说明书?
□是
□评审问题清单(可选)
□评审通知和确认表(可选)
□项目评审表
□项目评审问题追踪表
□评审人员签字
□批准人签字
□评审时间
□验证人签字
□SQA人员验证
□否(说明原因):
是否形成详细设计说明书?
□是
□评审问题清单(可选)
□评审通知和确认表(可选)
□项目评审表
□项目评审问题追踪表
□评审人员签字
□批准人签字
□评审时间
□验证人签字
□SQA人员验证
□否(说明原因):
□可选
文档格式是否正确?
□是
□文件编号
□配置项编号
□项目版本号
□审核人
□审核时间
□批准人
□批准时间
□符合模板
□否(说明原因):
概要设计说明书是否按计划完成?
□是
□按计划完成:
□提前完成并评审
□按计划完成并评审
□按计划完成,评审延迟。
□未按计划完成,延迟天
□采取纠正措施
□否(说明原因):
详细设计说明书是否按计划完成?
□是
□按计划完成:
□提前完成并评审
□按计划完成并评审
□按计划完成,评审延迟。
□未按计划完成,延迟天
□否(说明原因):
配置人员是否管理项目的配置情况?
□是
□管理设计基线
□SCM基线报告(频率)
□SCM基线变更状态报告
(频率)
□配置报告分发给相关人员
□否(说明原因):
SQA是否定期检查项目的需求管理活动,标识偏离项目计划或组织结构的内容?
□是
□软件过程审计报告(频率)
□审计报告分发给相关人员
□否(说明原因):
3.6.需求和设计管理过程检查表
检查内容
实施情况
评价
(10分制)
需求是否被标识、管理、度、跟踪和关闭?
□是
□需求跟踪矩阵表:
□需求状态被跟踪
□和需求文档保持一致
□设计模块和需求保持一致
□测试用例和需求保持一致
□统计需求变更数
□否(说明原因):
变更是否遵守变更流程?
□是
□变更类型:
(□需求□设计)
□变更控制表
□变更问题编号
□变更来源
□变更提出者
□申请时间
□修改人
□变更批准人
(□项目经理/□变更控制委员会)
□评审方式
□评审
(□项目评审表/□评审问题追踪表)
□签字
□变更状态追踪
□对变更请求产生影响进行评估
□项目版本状态
□修改描述
□修订页变更说明
□修改开发计划和进度
□修改设计文档,测试文档和其他文档
□修改人签字
□批准人签字
□验证变更结果与修改说明一致
□验证人签字
□验证日期
□SQA人员验证
□SQA人员检查日期
□变更结果通知变更执行人和受变更影响人员
□否(说明原因):
□没有变更
需求变更是否反映在设计中?
□是
□需求跟踪矩阵表
□需求状态变化
□设计文档变更
□验证人
□相关需求变更请求文档
□否(说明原因):
在设计中标识的缺陷和选择项是否被追踪和关闭?
□是
□设计状态标识
□设计状态跟踪
□验证人签字
□否(说明原因):
□不适用
如果变更不执行,是否有相关的的原因说明?
□是
□变更控制表
□变更不批准原因说明
□变更请求状态为“拒绝”
□否(说明原因):
□不适用
配置人员是否管理项目的配置情况?
□是
□管理需求变更基线
□SCM基线变更状态报告
(频率)
□配置报告分发给相关人员
□否(说明原因):
SQA是否定期检查项目的需求管理活动,标识偏离项目计划或组织结构的内容?
□是
□软件过程审计报告(频率)
□审计报告分发给相关人员
□否(说明原因):
3.7.软件编码过程检查表
检查内容
实施情况
评价
(10分制)
是否进行代码走查?
□是
□频率和形式:
□走查问题被跟踪和解决
□重大缺陷和问题被记录
□否(说明原因):
□其他情况:
编码是否按形成文档的准则执行?
□是
□编码方法经过批准
□采用文档和编程规范
□自定义规范
□否(说明原因):
源代码是否进行配置管理?
□是
□采用配置工具:
□配置库管理:
□否(说明原因):
代码的变更是否被标识,检查和关闭?
□是
□变更记录
□变更批准
□修改说明
□修改人和修改时间记录
□变更被检查和关闭
□否(说明原因):
单元测试是否进行?
□是
□和规程要求一致
□单元测试用例
□单元测试分析报告
□BUG统计
□无记录要求;
□否(说明原因):
SQA是否定期检查项目的编码过程活动,标识偏离项目管理或组织结构的内容?
□是
□软件过程审计报告(频率)
□审计报告分发给相关人员
□否(说明原因):
3.8.软件测试过程检查表
检查内容
实施情况
评价
(10分制)
是否有测试计划?
□系统
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 过程 检查表