IPD 度量.docx

上传人:b****2 文档编号:23248538 上传时间:2023-05-15 格式:DOCX 页数:17 大小:124.47KB
下载 相关 举报
IPD 度量.docx_第1页
第1页 / 共17页
IPD 度量.docx_第2页
第2页 / 共17页
IPD 度量.docx_第3页
第3页 / 共17页
IPD 度量.docx_第4页
第4页 / 共17页
IPD 度量.docx_第5页
第5页 / 共17页
点击查看更多>>
下载资源
资源描述

IPD 度量.docx

《IPD 度量.docx》由会员分享,可在线阅读,更多相关《IPD 度量.docx(17页珍藏版)》请在冰豆网上搜索。

IPD 度量.docx

IPD度量

IPD度量

IPD度量指标定义和度量数据收集指导书

一、硬件项目

1、硬件第一次投板前缺陷发现数目2、硬件遗留缺陷数目

3、样机投板次数

4、返回率(硬件原因)

二、软件项目

5、软件发布前缺陷发现密度

6、编码缺陷发现密度

7、软件遗留缺陷密度

三、公共部分

8、硬件/软件进度偏差率

9、硬件/软件总体设计缺陷发现数目10、硬件/软件详细设计缺陷发现数目

11(文档齐套性

1、硬件第一次样机制作完成前缺陷发现数目

【指标名称】硬件第一次样机制作完成前缺陷发现数目

【指标定义】从TR1到硬件详细设计评审,在期间发现的硬件缺陷数目【测

量对象】硬件项目组

【设置目的】反映硬件总体设计和详细设计的质量。

【统计部门】开发管理部

【统计方法】

1、交付件发现缺陷数定义:

TR2和硬件详细设计(SUB-TR)评审时发现的非提示(包括致命,严重和一般)问

题的缺陷总数;

2、各阶段关键交付件定义:

关键交付件发现缺陷密度TR阶段

系统总体设计方案系统总体设计方案评审和检视发现的硬件缺陷数TR2目硬

件总体方案硬件总体方案评审和检视发现的缺陷数目

产品文档SUB-TR硬件在详细设计评审时发现的缺陷数

【计算公式】

硬件第一次样机制作完成前缺陷发现数目,TR2发现的缺陷数,SUB-TR发现的

缺陷数

缺陷的严重等级分类标准参考如下表格:

严重程度发现问题的严重程度统一规定致命基本功能完全丧失

严重引起系统某一功能失效且不能简单恢复的问题;设计出现严重错误或

漏洞,如果不加修改会导致严重后果或留下质量隐患一般引起系统某一功能

失效但可简单恢复或较难重现的问题;设计中出现

的错误,如果不修改可能会导致后续的错误,但不是特别严重提示从操作或

维护的角度发现的问题或建议;属于文字上的错误或者表达

方式的问题,不修改可能会导致歧义

【计量单位】个

【指标统计时间】从TR2开始

【统计周期】月度

2、硬件遗留缺陷数目

【指标名称】硬件遗留缺陷数目

【指标定义】

【测量对象】

【设置目的】

【统计部门】

【统计方法】。

【计算公式】

【计量单位】%

【指标统计时间】

【统计周期】

3、样机投板次数

【指标名称】样机制作次数

【指标定义】在TR2通过后到TR3通过前累计进行的样机制作次数

【测量对象】硬件项目组

【设置目的】通过制作样机的次数反映硬件总体设计和详细设计的成熟程度,

从侧面反应硬件设计水平。

【统计部门】开发管理部

【统计方法】

各阶段样机制作次数:

关键交付件制作次数TR阶段

系统总体设计方案为系统总体设计方案(硬件部分)进行的试验次

数TR2,TR3硬件总体方案为确定硬件总体设计方案进行的试验次数

产品文档为验证硬件详细设计进行的样机制作次数

【计算公式】样机制作次数,TR2,TR3进行的试验次数,样机制作次数

【计量单位】个

【指标统计时间】在TR2通过后到TR3通过前

【统计周期】月

4、返回率(硬件原因)

【指标名称】返回率(FieldReplaceableUnitReturns,RR)【指标定义】

按照TL9000体系定义的返回产品运行时间,分成ERI初始返回指数、YRR一年返

回率、LTR长期返回率和NYR归一化年返回率。

1、ERI初始返回指数(硬件原因):

提报月前第六个月至提报月共七个月期间交

付产品的返回率(硬件原因,折合成年度返修率);(单位:

%/年)

2、YRR中期返修率(硬件原因):

提报月前第七个月至第十八个月期间(共12个

月)交付产品的返回率(硬件原因,折合成年度返修率);(单位:

%/年)

3、LTR长期返修率(硬件原因):

提报月前第十九个月与以前交付产品的返回率

(硬件原因,折合成年度返修率);(单位:

%/年)

4、NYR归一化年返回率(硬件原因):

提报月前第七个月至第十八个月期间(共

12个月)交付产品的返回率(硬件原因,折合成年度返修率);(单位:

%/年)

年度化因子(AnnualizationFactor,Afactor):

一年中须提报的周期数。

公司按日历月提报,故Afactor=12

【测量对象】PDT

【设置目的】衡量产品在客户环境运行的返回率(硬件原因),牵引对引起产品

失效的故障原因的分析,促进产品故障率(硬件原因)的减低,降低维护成本,提升

产品质量。

【统计部门】质量保证部

【统计方法】参见公司文件《TL9000-3衡量指标计算准则》

【计算公式】

1、ERI(硬件原因)(初始返回指数,%每年)

=(FRri/FRsi)*Afactor*100

FRri二提报月前第六个月至提报月共七个月期间交付的产品在提报月返回的

件数

FRsi二在提报月的前六个月期间(共6个月)交付的产品件数

Afactor=12

2、YRR(硬件原因)(一年返回率,%每年)

=(FRry/FRsy)*Afactor*100

FRry二提报月前第七个月至第十八个月期间(共12个月)交付的产品在提报月

返回的件数

FRsy二提报月前第七个月至第十八个月期间交付的产品件数

Afactor=12

3、LTR(硬件原因)(长期返回率,%每年)

=(FRrt/FRst)*Afactor*100

FRrt二提报月前第十九个月与以前交付的产品在提报月返回的件数

FRst=提报月前第十九个月与以前交付的产品件数

Afactor=12

4、归一化年返回率(硬件原因)(NYR,每归一化单位返回数)

=(FRry/S)*Afactor

Ry=提报月前第七个月至第十八个月期间(共12个月)交付的产品在提报月返

回的件数

S=归一化因子,等于FRsy

Afactor=12

【计量单位】%/年

【指标统计时间】受控销售产品首次发货后开始统计

【统计周期】月度

11月12

141219

【计算案例】

月返回数(2005年)

发货月发货数1月2月3月4月5月6月7月8月9月10月

03年300003944424631354836464132306月前

03-07825322*********71081516503-0894231111

61399201204-121052823302022251515151612161105-01

 

13933430233205-1013725

4342205-111446733605-12149054总返

414445449449476463

回数355335366374398397

计算2005年1月的FR:

FRsi=8833+8954+9368+9818+9787+10528=57288

Frsi=14+16+20+39+36+23+5=153

ERI=100*12*FRri/Frsi=100*12*153/57288=3.20%

FRsy=8253+9243+9261+9721+10131+10140+6263+6436+7244+7275+7396+8263=9

9626

Frry=22+11+17+19+16+24+11+7+14+10+6+6=163

YRR=100*12*FRry/FRsy=100*12*163/99626=1.96%

FRst=30000

FRrt=39

LTR=100*12*FRrt/FRst=100*12*39/30000=1.56%

5、软件发布前缺陷发现密度

【指标名称】软件发布前缺陷发现密度

【指标定义】在TR2到TR5期间的缺陷发现密度

【测量对象】软件项目组

【设置目的】反映软件项目的质量状况,以及整个生命周期中,关键交付件发

现缺陷密度的变化趋势。

通过分析原因,改进软件项目交付件质量。

【统计部门】开发管理部

【统计方法】

1、交付件规模定义:

文档按照页数计算规模;软件代码按非空非注释千行KLOC计算规模。

2、交付件发现缺陷数定义:

TR2和TR3缺陷数定义为SUB-TR评审时发现的非提示(包括致命,严重和一般)

问题的缺陷总数;

TIM和TR5的缺陷数定义为在各SUB-TR评审时,样机确认测试、中试验证、试

产验证和BETA测试报告中反映的非提示(包括致命,严重和一般)问题的缺陷总

数。

3、各阶段关键交付件定义:

关键交付件发现缺陷密度TR阶段

系统总体设计方案TR2系统总体设计方案评审和检视发现的缺陷数/文

档总页数

软件代码软件在样机确认测试发现的缺陷数/软件规模TR2KLOC

软件代码TR4软件在中试验证中发现的缺陷数/软件规模KLOC

软件代码TR5软件在试产验证中发现/硬件规模KLOC

【计算公式】

版本的关键交付件发现缺陷密度,发现软件项目交付件缺陷数之和/交付件

规模

缺陷的严重等级分类标准参考如下表格:

严重程度评审、检视、测试等各种活动中发现问题的严重程度统一规定致命

基本功能完全丧失

严重引起系统某一功能失效且不能简单恢复的问题;设计出现严重错误或

漏洞,如果不加修改会导致严重后果或留下质量隐患一般引起系统某一功能

失效但可简单恢复或较难重现的问题;设计中出现

的错误,如果不修改可能会导致后续的错误,但不是特别严重提示从操作或

维护的角度发现的问题或建议;属于文字上的错误或者表达

方式的问题,不修改可能会导致歧义

【计量单位】个/KLOC

【指标统计时间】从TR2开始

【统计周期】月度

6、编码缺陷发现密度

【指标名称】编码缺陷发现密度

【指标定义】每KLOC发现的缺陷数

【测量对象】软件源代码(文档)

【设置目的】反映软件编码质量,评估软件编码活动的

【统计部门】开发管理部

【统计方法】如下:

软件编码缺陷分类

缺陷类型描述缺陷类型编号

如逻辑,指针,循环,递归,功能等缺陷10F-功能

拼写、标点符号、打字20G-语法

如声明、重复命名,作用域30A-赋值

40I-接口与其他构件或驱动程序、调用参数、控制块

或参数列表相互影响的缺陷50B-联编打包由于配置库、变更管理或版本控

制引起的错

需求、设计类文档60D-文档

70U-用户接口人机交互特性:

通讯协议格式,确认用户

输入,功能有效性

80P-性能不满足系统可测量的属性值,如:

执行时

间,处理速率等

90N-标准不符合各种标准的要求,如编码标准、设计

符号等

设计、编译、其他支持系统问题100E-环境

编码缺陷严重等级

#缺陷严重等级描述

严重缺陷1不能执行正常工作功能或重要功能。

或者危及人身安全

(Critical)

严重地影响系统要求或基本功能的实现,且没有办法更较大缺陷2正。

(Major)(重新安装或重新启动该软件不属于更正办法)3严重地影响系统要求或

基本功能的实现,但存在合理的更

较小缺陷正办

(Minor)法。

(重新安装或重新启动该软件不属于更正办法)4使操作者不方

便或遇到麻烦,但它不影响执行工作功能或

轻微缺陷重要

(Cosmetic)功能。

5其它错误其他缺陷

(Other)

通常为了收集编码缺陷数据,可以采用缺陷记录日志来登记所发现的每一个缺

陷。

如下表所示

缺陷记录日志

缺陷排除修改修复日期编号状态类型来源阶段时间缺陷

描述:

描述:

描述:

【计算公式】

编码缺陷发现密度二软件交付件缺陷数之和/代码行总数

【计量单位】个/KLOC

【指标统计时间】从软件详细设计正规检视起【统计周期】月度

7、软件遗留缺陷密度

【指标名称】软件遗留缺陷密度

【指标定义】

【测量对象】

【设置目的】

【统计部门】

【统计方法】o

【计算公式】

【计量单位】%

【指标统计时间】

【统计周期】

8、硬件/软件进度偏差率

【指标名称】硬件/软件进度偏差率

【指标定义】硬件/软件进度偏差(与受控的项目计划比较)与实际时间到项目

计划中止点的时间

的比率

【测量对象】硬件/软件项目组

【设置目的】反映项目组项目计划进度的执行情况,通过对偏差产生原因地分

析,找出问题,并

加以改进,提高项目组的进度监控能力。

【统计部门】开发管理部

【统计方法】从“项目过程数据库”中获得实际进度数据,从受控的项目计划

或PDT经理批准的“计划变更请求单”中获得与PDT经理最新批准的进度基线,

PQA依据该基线估计进度偏差【计算公式】项目进度偏差率,截止统计期项目实际

发生的进度偏差/(PDT最新批准的项目计划中规定的终止点,实际时间)

【指标说明】

1)该指标只衡量计划决策评审之后的开发活动,概念和计划阶段版本不计算该

指标;

2)“项目进度偏差”为当前进度与PDT最新批准的WBS3/4级项目计划比较的

偏差;

3)项目进度偏差率统计范围是目前已经过了PDCP的在研项目和今年结束的项

目。

4)如果项目进度偏差率为负,说明实际进度比基准进度提前;如果过程进度

偏差率为正,说明实际进度比基准进度有所延迟。

5)如果某个项目的进度偏差率为负值,则计算该项目进度偏差率时计为0o

【计量单位】,

【统计周期】月

9、硬件/软件总体设计缺陷发现数目

【指标名称】硬件/软件总体设计缺陷发现数目

【指标定义】在TR2时发现的硬件缺陷数目

【测量对象】硬件/软件项目组

【设置目的】反映硬件/软件总体设计的质量。

【统计部门】开发管理部

【统计方法】

1、交付件发现缺陷数定义:

TR2时发现的硬件/软件总体设计非提示(包括致命,严重和一般)问题的缺陷总

数;

2、各阶段关键交付件定义:

TR阶段关键交付件发现缺陷密度

系统总体设计方案系统总体设计方案评审和检视发现的硬件缺陷数TR2目硬

件/软件总体方案硬件/软件总体方案评审和检视发现的缺陷数目

【计算公式】

硬件/软件总体设计缺陷发现数目,TR2发现的缺陷数,SUB-TR发现的缺陷数

缺陷的严重等级分类标准参考如下表格:

严重程度发现问题的严重程度统一规定

致命基本功能完全丧失

严重引起系统某一功能失效且不能简单恢复的问题;设计出现严重错误或

漏洞,如果不加修改会导致严重后果或留下质量隐患一般引起系统某一功能

失效但可简单恢复或较难重现的问题;设计中出现

的错误,如果不修改可能会导致后续的错误,但不是特别严重提示从操作或

维护的角度发现的问题或建议;属于文字上的错误或者表达

方式的问题,不修改可能会导致歧义

【计量单位】个

【指标统计时间】TR2和为TR2而进行的SUB-TR

【统计周期】月度

10、硬件/软件详细设计缺陷发现数目

【指标名称】硬件/软件详细设计缺陷发现数目

【指标定义】详细设计的SUB-TR发现的硬件/软件缺陷数目

【测量对象】硬件/软件项目组

【设置目的】反映硬件/软件详细设计的质量。

【统计部门】开发管理部

【统计方法】

1、交付件发现缺陷数定义:

详细设计的SUB-TR发现的硬件/软件详细设计非提示(包括致命,严重和一般)

问题的缺陷总数;

2、各阶段关键交付件定义:

TR阶段关键交付件发现缺陷密度

硬件/软件详细设计详细设计的SUB-TR发现的硬件/软件发现的硬件SUB-TR

/软件缺陷数目

【计算公式】

缺陷的严重等级分类标准参考如下表格:

严重程度发现问题的严重程度统一规定致命基本功能完全丧失

严重引起系统某一功能失效且不能简单恢复的问题;设计出现严重错误或

漏洞,如果不加修改会导致严重后果或留下质量隐患一般引起系统某一功能

失效但可简单恢复或较难重现的问题;设计中出现

的错误,如果不修改可能会导致后续的错误,但不是特别严重提示从操作或

维护的角度发现的问题或建议;属于文字上的错误或者表达

方式的问题,不修改可能会导致歧义

【计量单位】个

【指标统计时间】详细设计的SUB-TR

【统计周期】月度

11、文档齐套性

【指标名称】文档齐套性

【指标定义】在各个开发阶段交付文档的齐套程度

【测量对象】项目组

【设置目的】保证在开发的各个阶段,交付件的齐套性,降低项目风险。

【统计部门】开发管理部

【统计方法】在TR1,TR5后对受控的交付文档的齐套性进行审计并提取数据

【计算公式】

文档齐套性,TRI,TR5实际受控的交付文档数目之和/TR1,TR5应交付受控的交

付文档数目之和

【计量单位】%

【指标统计时间】从TR1开始执行

【统计周期】月

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > PPT模板 > 卡通动漫

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1