管理信息 |
度量指标 |
意义 |
基本度量(单位) |
计算说明 |
改善项目按时交付 |
项目按时交付率(%) |
了解研发项目的按时交付情况,改善偏差,提高项目按时交付率 |
按时交付的项目数(个) |
项目按时交付率=按时交付的项目数/项目总数*100% |
项目总数(个) |
||||
项目平均进度偏差率(%) |
每个项目进度偏差率(%) |
项目平均进度偏差率=∑每个项目进度偏差率/项目总数 |
||
项目平均工作量偏差率(%) |
了解项目估算的准确性 |
每个项目计划总工作量(人日) |
项目平均工作量偏差率=(实际总工作量-计划总工作量)/计划总工作量*100% |
|
每个项目实际总工作量(人日) |
||||
软件平均生产率(KLOC/天) |
了解软件的生产效率 |
每个项目的软件生产率(KLOC/天) |
每个项目的软件生产率/项目数 |
|
项目总数(个) |
||||
提高研发开发质量 |
硬件平均工程改动单数(个) |
了解硬件、软件所提供的正式版本的质量状况 |
硬件工程改动单数(个) |
硬件平均工程改动单数=工程改动单数总数/改动的产品数 |
硬件改动的产品数(个) |
||||
软件平均工程改动单数(个) |
软件工程改动单数(个) |
软件平均工程改动单数=工程改动单数总数/改动的产品数 |
||
软件改动的产品数(个) |
||||
项目平均一次性测试通过率 |
了解开发对版本质量的控制情况 |
一次性测试通过的用例数 |
∑每个项目一次性测试通过率/项目数 |
|
测试的总用例数 |
||||
项目平均一次性缺陷修复率 |
了解开发对缺陷的修复能力 |
一次性修复的缺陷数 |
∑每个项目一次性缺陷修复率/项目数 |
|
缺陷总数 |
||||
平均缺陷解决周期(天/个) |
了解缺陷修复的效率 |
缺陷总数 |
解决缺陷所用的周期/缺陷总数 |
|
解决缺陷所用的周期 |
||||
项目平均软件系统测试缺陷数密度(个/KLOC) |
了解软件加大了代码评审、自测试力度后效果状况 |
每个项目软件系统测试缺陷密度(个/KLOC) |
项目平均软件系统测试缺陷数密度=∑项目软件系统测试缺陷密度/项目总数 |
|
项目总数(个) |
||||
平均风险规避率(%) |
了解研发项目对风险规避的能力的改善与否 |
项目风险规避率(%) |
平均风险规避率=∑项目风险规避率/项目总数 |
|
项目总数(个) |
||||
提高流程执行效率 |
工程改动单平均审批效率(%) |
了解对工程改动单的审批执行效率的改善状况 |
每个工程改动单审批周期(天) |
评审效率=评审交付件规模/(评审时长*评审人数) |
工程改动单总数 |
意义 |
基本度量(单位) |
计算说明 |
裁剪说明 |
|
了解项目进展健康状况,通过偏差控制,提高项目进度的按时达成率 |
计划各阶段工期(天) |
累计进度偏差率=(实际各阶段工期-计划各阶段工期)/计划各阶段工期*100% |
第一次发布的进度计划 |
不可裁剪 |
实际各阶段工期(天) |
PLM上实际完成 |
|||
计划总工期(天) |
项目总体进度偏差率=实际总工期-计划总工期/计划总工期*100% |
/ |
不可裁剪 |
|
实际总工期(天) |
||||
计划任务数(条) |
周任务达成率=∑实际完成的任务数/∑计划任务数*100% |
项目周 |
如果项目经理对大跨度的阶段控制有把握,不需要把任务进行细化来监控周任务达成的,可以裁剪。一般情况下,建议不要裁剪,只有将任务细化后,周任务达成,才能保证大阶段关键任务达成。 |
|
实际完成任务书(条) |
||||
了解项目资源投入的健康状况,通过控制,确保项目资源的正常投入与使用,来确保项目进度、质量的达成 |
计划各阶段工作量(人日) |
累计工作量偏差率=(实际各阶段工作量-计划各阶段工作量)/计划各阶段工作量*100% |
第一次发布的进度计划 |
如有以下情况为不可裁剪: |
累计计划各阶段工作量(人日) |
||||
实际各阶段工作量(人日) |
项目周 |
|||
累计实际各阶段工作量(人日) |
||||
计划总工作量(人日) |
项目总体工作量偏差率=(实际总工作量-计划总工作量)/计划总工作量*100% |
第一次发布的进度计划 |
||
实际总工作量(人日) |
项目周 |
|||
通过对评审质量的了解,便于采取改进措施,做好缺陷预防工作 |
总体设计评审发现缺陷数 |
评审缺陷密度=评审发现的缺陷数/评审交付件规模 |
评审 告 |
如有以下情况为不可裁剪: |
测试方案评审发现的缺陷数 |
||||
软件概要设计评审发现缺陷数 |
||||
原理图评审发现缺陷数 |
||||
评审交付件规模(页) |
评审效率=评审交付件规模/(评审时长*评审人数) |
|||
参加评审的人数 |
||||
评审时长(小时) |
||||
漏审缺陷数(个) |
评审有效性=评审发现的缺陷数/(漏审缺陷数+评审发现问题数)*100% |
评审 告 |
||
了解需求变更情况 |
需求变更次数 |
需求变更率=需求变更次数/需求总数*100% |
PLM系统 |
如有以下情况为不可裁剪: |
需求总数 |
||||
了解缺陷的收敛状况,以进行控制 |
各严重程度缺陷数(个) |
缺陷关闭率=关闭缺陷数/总缺陷数*100% |
PLM系统 |
如有以下情况为不可裁剪: |
总缺陷数(个) |
||||
了解缺陷解决的有效性 |
关闭的缺陷数(个) |
|||
了解开发的质量 |
重新激活的缺陷数(个) |
|||
了解人员开发质量,及各模块的难以程度 |
产品发布之后的缺陷数(个) |
|||
了解开发对版本质量的控制情况 |
第一次测试通过的用例数/测试的总用例数*100% |
测试 告 |
||
驳回次数 |
软件版本驳回率=软件版本驳回次数/提交软件版本次数 |
PLM系统 |
||
提交次数 |
||||
1、了解一下常态下项目的改版次数平均次数是多少,便于更准确地制定计划,因为一次改版差不多要半个月时间,例如:正常情况下,项目中改版的次数为3次,那么制定计划时,就不能以1次来算,否则计划就会延期。 |
MESH板改版次数 |
硬件改版次数=MAX(MESH板改版次数,PCBWALL板改版次数,PORT板改版次数,RF板改版次数,接口板改版次数,主板改版次数) |
PLM系统关于版次升级记录 |
|
PCBWALL板改版次数 |
||||
PORT板改版次数 |
||||
RF板改版次数 |
||||
接口板改版次数 |
||||
主板改版次数 |
||||
GPRS板 |
||||
CDMA板 |
||||
了解测试质量 |
开发且被执行的测试用例数 |
(开发且被执行的测试用例数+重用已有的且被执行的测试用例数)/总需求数*100% |
测试 告 |
|
已有的被执行的测试用例数 |
测试漏测率=(生产发现的缺陷数+客户现场发现的缺陷数)/(生产发现的缺陷数+客户现场发现的缺陷数+系统测试发现的缺陷数(包括小批量)) |
试产 告、售后 |
||
了解测试效率 |
开发用例数/开发用例工作量 |
|||
执行用例数/执行用例工作量 |
||||
了解项目缺陷预防的有效性 |
软件缺陷数 |
软件缺陷数/代码行数 |
PLM系统 |
|
硬件缺陷数 |
硬件缺陷数/焊接点数 |
|||
了解缺陷修复的效率 |
缺陷总数 |
解决缺陷总工期/缺陷总数 |
不可裁剪 |
|
解决缺陷总工期 |
||||
了解缺陷修复质量 |
一次性修复的缺陷数 |
一次性修复的缺陷数/缺陷总数 |
不可裁剪 |
|
缺陷总数 |
||||
了解人员对流程的执行情况 |
及时解决的不符合项数(个) |
及时解决的不符合项数=及时解决的缺陷数/审计的不符合项总数*100% |
审计 告 |
如有以下情况为不可裁剪: |
审计的不符合项总数(个) |
||||
了解PM对风险的控制能力 |
被有效控制未发生的风险数(个) |
风险规避率=被有效控制未发生的风险数/所识别的风险总数*100% |
审计 告 |
如有以下情况为不可裁剪: |
所识别的风险总数(个) |
管理信息 |
度量指标 |
意义 |
基本度量(单位) |
计算说明 |
控制产品变更 |
产品变更率(次/个) |
了解产品变更情况 |
产品变更次数 |
需求变更率=产品变更次数/配置个数 |
配置个数 |
||||
工程变更率(次/个) |
了解产品的设计与实现质量 |
产品交付后工程改动单提交次数 |
工程变更率=产品交付后工程改动单提交次数/配置个数 |
|
提高产品研发质量 |
平均每个版本缺陷漏测数 |
客户现场反馈的缺陷 |
平均每个版本缺陷漏测率=客户现场反馈的缺陷/所发布的软件版本数 |
|
所发布的软件版本数 |
||||
降成本耗时率 |
降成本周期 |
降成本周期/产品开发周期 |
||
产品开发周期 |
||||
漏测率 |
了解测试质量 |
客户现场发现的缺陷数 |
客户现场发现的缺陷数/产品缺陷总数 |
|
产品缺陷总数 |
||||
提高研发对客户响应效率 |
需要研发处理的缺陷解决周期(天/个) |
了解缺陷修复的效率 |
反馈到研发的缺陷总数 |
解决缺陷总工期/反馈到研发的缺陷总数 |
解决缺陷总工期 |
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!