软件过程检查表

第1页共22页1.过程检查要素表检查内容产品研发项目客户定制或应用开发项目平台或中间件项目维护项目检查时间检查结果参加成员计划过程√√√（可选）√（可选）计划阶段结束软件过程审计报告SQA人员，项目组成员计划跟踪和监督过程√√√√设计阶段结束测试阶段结束软件过程审计报告SQA人员，项目组成员软件产品审查过程√√√（可选）√（可选）正式评审结束软件过程审计报告SQA人员项目经理需求分析过程√√√√需求分析阶段结束测试阶段结束软件过程审计报告SQA人员，项目经理，系统分析员系统设计过程√设计阶段结束测试阶段结束软件过程审计报告SQA人员，项目经理，系统分析员需求和设计管理过程√√√编码阶段结束软件过程审计报告SQA人员，项目经理，软件编码过程√√√（可选）编码阶段结束软件过程审计报告SQA人员，项目组成员软件测试过程√测试阶段结束软件过程审计报告SQA人员，项目组成员产品验收和发布过程√√√√项目验收后软件过程审计报告SQA人员，项目经理，测试人员，配置人员，用户代表配置管理过程√√√√设计阶段结束测试阶段结束软件过程审计报告SQA人员，项目经理，配置管理员软件质量保证过程√√√√验收阶段结束软件过程审计报告高级经理，SQA经理，项目经理2.过程打分2.1.过程打分原则：1)过程打分占整个项目得分的30％，以30分为满分，最低分不低于9分。2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。第2页共22页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.7C=5.3＋5.6＋5.3＋5.7＋5.6＝27.5第3页共22页3.过程检查表3.1.计划过程检查表检查内容实施情况评价（10分制）是否有项目开发计划？□项目开发计划书□评审问题清单（可选）□评审通知和确认表（可选）□项目评审表□项目评审问题追踪表□评审人员签字□批准人确认/签字□评审时间□验证人签字□SQA人员验证□否（说明原因）：文档格式是否正确？□是□文件编号□配置项编号□项目版本号□审核人□审核时间□批准人□批准时间□符合模板□否（说明原因）：项目计划文档是否按计划完成？□是□按计划完成：□提前完成并评审□按计划完成并评审□按计划完成，评审延迟。□未按计划完成，延迟天□采取纠正措施□否（说明原因）：项目计划是否以确定的需求为依据？□是□否（说明原因）：第4页共22页是否有对项目计划的承诺？□是□项目组成员和相关人员参与计划过程，并和项目经理就计划达成一致意见□计划被SQA，SCM和其他相关组检查并达成一致意见□计划被负责项目的负责人检查并达成一致意见□项目计划在提交给用户以前在组织内部得到批准□形成项目责任矩阵表□若有外部用户，与外部用户就项目计划达成一致意见□和用户协商的计划变更在最后提交给用户时得到项目内部组的批准□已承诺项目计划被基线化（如进行配置控制）□否（说明原因）：关键因素是否被识别和定义？□是□项目的进度□任务预期开始和结束□工作产品被识别□项目的工作量□里程碑开始和实现日期□预算的费用□计划的关键计算机资源□项目组成员任务分配□为软件开发确定的生命周期模型□工作产品的验收标准被定义□其他因素□否（说明原因）：是否明确指定估算策略对项目的规模进行估计？□是□按已定义的方法执行估计过程：□是否采用历史数据□无历史数据□规模估计的量度：□功能点□需求数□代码行□其他□规模估计结果文档化□规模估计结果经过评审□否（说明原因）：是否为员工的培训需要制定计划？□是□培训方式：□正式培训/□非正式培训□识别需参加培训人员□计划参加培训时间□识别须培训的内容□否（说明原因）：第5页共22页是否为项目内和项目间的沟通制定计划？□是□定义内部沟通方式□定义内部沟通时间和频率□识别外部沟通方□定义外部沟通方式□定义外部沟通时间和频率□否（说明原因）：是否确定项目的度量目标？□是□定义项目度量目标□定义需收集的数据和频率□定义数据收集方式和负责人□定义度量分析结果□定义度量分析报告方式□否（说明原因）：是否识别和分析风险？□风险管理计划□风险项清单□风险发生的应急对策□风险优先级□确定各类风险的责任人□制定风险管理进度□否（说明原因）：是否选择合适的生命周期模型？□是□选择已定义的生命周期模型□形成新的生命周期模型□经过批准□未经过批准□否（说明原因）：是否进行成本估计？□是□否（说明原因）：项目计划是否进行进度细化？□是□按生命周期模型划分里程碑□形成项目的WBS，包括管理，技术和支持活动□WBS活动有预留时间□每个WBS活动分配责任人，开始和完成时间□基于过去类似项目的经验□小组和个人参与制定和检查WBS□WBS任务被定义到可以进行进度估算的级别：□每小时□每天□每2-3天□每周□其他□否（说明原因）：配置人员是否管理项目的配置情况？□是□管理计划基线□计划基线分发给相关人员□否（说明原因）：SQA是否定期检查项目的活动？□是□软件过程审计报告(频率)□软件问题管理□跟踪和关闭问题□没有问题□审计报告分发给相关人员□否（说明原因）：第6页共22页3.2.软件产品审查过程检查表检查内容实施情况评价（10分制）工作产品在决定评审前是否经过审核人的检查和审核？□是□否（说明原因）：是否采用工作产品检查单进行评审？□是□工作产品检查单□否（说明原因）：软件评审和检查通知是否有记录？每一个参与者是否分配了角色？□是□评审通知和确认表□否（说明原因）：评审重点是否放在缺陷检查，而不是纠错上□是□否（说明原因）：评审结果是否形成文档□是□项目评审表□项目评审问题追踪表□否（说明原因）：评审者是否在评审会议前做了充分的准备？评审准备数据和次数是否被收集？□是□评审问题清单□评审准备工作量□发现问题描述详细□标识缺陷严重程度□标识缺陷类型□预审结论□否（说明原因）：评审准备数据和频率是否被收集，以便可以充分应用与将来的准备和评审？□是度量表格：□评审人数□评审前准备工作量□评审工作量□评审次数□否（说明原因）：评审会议是否经常有调整？□是□否（说明原因）：仲裁者是否接到过执行评审的培训？□是□否（说明原因）：评审会议时间是否按计划完成？□是□否（说明原因）：在每个评审中的发现的问题是否被SQA追踪或验证人检查□是□验证人签字□问题完成情况描述□按时完成修改和验证□SQA人员验证过程完整性□否（说明原因）：第7页共22页3.3.计划跟踪和监督过程检查表检查内容实施情况评价（10分制）开发工作是否按计划开始？□是不按计划开始原因说明：□否（说明原因）：项目跟踪是否以形成基线的计划为基础？□是□项目开始跟踪以首次计划为基准□计划变更后跟踪以变更后的计划为基准□否（说明原因）：计划变更是否执行变更管理过程？是否对计划的变更进行记录和追踪？□是□计划变更最新版本□变更次数□变更控制表□变更问题编号□变更来源□变更提出者□申请时间□修改人□变更批准人（□项目经理□变更控制委员会）□评审方式□评审（□项目评审表□评审问题追踪表）□签字□变更状态追踪□对变更请求产生影响进行评估□项目版本状态□修改描述□修订页变更说明□修改开发计划和进度□修改相关文档□修改人签字□批准人签字□验证变更结果与修改说明一致□验证人签字□验证日期□SQA人员验证□SQA人员检查日期□变更结果通知变更执行人和受变更影响人员□否（说明原因）：□没有变更如果变更不执行，是否有相关的的原因说明？□是□变更控制表□变更不批准原因说明□变更请求状态为“拒绝”□否（说明原因）：第8页共22页关键因素是否被监控？□是□监控项目的进度□任务预期开始和结束□项目规模□里程碑开始和实现日期□预算的费用□计划的关键计算机资源□项目组成员任务分配□工作产品完成情况□项目的工作量□其他因素□否（说明原因）：是否跟踪项目规模？□是□跟踪定义的项目计划规模□跟踪项目实际规模□实际规模和计划规模比较分析□事件驱动调整项目规模□按已定义的规模估计方法调整规模□调整后的规模结果文档化并经过评审□记录实际的项目规模□否（说明原因）：是否跟踪项目工作量？□是□跟踪计划的项目工作量□跟踪项目实际工作量□实际工作量和计划工作量比较分析□按规程调整工作量□调整后工作量数据文档化并经过评审□否（说明原因）：是否跟踪项目进度？□是□跟踪计划的里程碑开始结束时间□跟踪计划任务开始完成时间□跟踪项目成员任务分配情况□比较和分析实际，计划的进度差异□根据实际情况调整项目进度，并经过评审□否（说明原因）：项目组成员是否每周提□是□项目组成员每周报告分配的任务第9页共22页交工作情况汇报表，报告度量和分析结果？□否（说明原因）：状态□所有报告的已完成的任务被检查□项目组成员每周报告问题和风险□项目组成员每周报告变更发生情况和变更状态□项目组成员报告每个任务的实际工作量花费，每个任务的总的花费天数，每个任务的预计工作量□项目成员的任务与计划任务匹配□项目组成员每周重新估计需要完成任务的工作量是否对识别的风险进行管理，监控和报告潜在的风险？□是□更新风险项清单□风险发生的实际对策□更新风险优先级□风险状态跟踪和控制□风险的责任人跟踪风险□调整风险管理进度□定期检查和更新每个风险发生概率和影响□识别新的风险并进行分析□否（说明原因）：项目经理是否定期更新任务分配？□是安排任务频率：□每天□每2-3天□每周□每月□其他□否（说明原因）：是否控制和解决项目问题？□是□定期召开项目会议，交流项目的活动状态，问题和风险□项目的会议有会议纪要□在项目状态报告和会议纪要中记录发现的问题□分配人员执行每个问题的纠错活动和解决问题□跟踪问题直至关闭□否（说明原因）：第10页共22页项目经理是否定期形成项目状态报告？□是□形成项目状态报告(频率)□项目状态报告是否提交/分发takeholders:用户，项目经理/高级经理，相关支持组，小组成员。□项目状态报告内容是否包括本周项目的完成状况，问题，风险，变更？□项目的进度度量和其他度量数据是否包括在报告中？□项目控制下的进度数据反映当前的情况□项目经理计算和分析关键的实际数据度量，并在项目状态报告中记录□否（说明原因）：配置人员是否管理项目