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