软件过程检查表.docx

软件过程检查表.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分制）

是否有测试计划？

□系统

□评审问题清单（可选）

□评审通知和确认表（可选）

□项目评审表

□项目评审问题追踪表

□评审人员签字

□批准人签字

□评审时间