#度量维度
能力 |
描述 |
备注 |
项目管理能力 |
通过度量手段来识别项目管理方面的能力,具体能力展现为进度和成本管控方面的执行能力。 |
实际结束日期-计划结束日期/(计划开始-实际结束日期);加班率=总工作时间/正常工作时间 |
范围管理能力 |
通过度量手段识别项目范围管理能力,通过评估项目研发过程中需求变更率来识别范围的稳定性。 |
评估系统范围稳定性,例如需求变更率,无设计报告功能点,无需求说明书的功能点数 |
质量管理能力 |
来识别研发管理团队在质量方面的执行能力,质量管理能力划分为三个阶段的展现,开发阶段,测试阶段,交付阶段,对这三个阶段的质量数据进行统计分析形成质量度量指标,来评估团队的质量方面的管理能力 |
开发质量: 代码质量,功能单元质量;测试质量:系统功能,业务功能质量;交付质量:业务支撑能力,系统稳定性等质量 |
效率管理能力 |
效率管理能力是通过对开发人员,测试人员的工作效率进行统计度量。 |
代码效率=代码行数/总研发工时 代码审查效率 代码审查的缺陷数/代码审查花费的工时;工程故障数 产品release后1个月,来自工程现场的故障 |
技术提升能力 |
在研发过程中对技术提升指标进行监控,评估研发团队的技术提升能力。 |
例如持续集成覆盖度,测试用例有效率,自动化测试覆盖率等。 |
客户满意度 |
客户对提供的功能认可度 |
|
#管理目标举例
进度:项目工期偏差率介于+-15%之间;
质量:项目的缺陷逃逸率不高于5%;
项目交付的缺陷密度不高于1个bugs/KLOC;
规模:需求变更率不超过15%;
成本:工作量偏差率不超过+-30%;
每人月实际投入项目的时间不少于上班时间的50%;
项目返工工作量不高于20%;
效率:全生命周期生产率不小于1KLOC/MM;
其他:人员变更率不超过20%;
进度:阶段工期偏差率不超过+-15%;
质量:需求评审的缺陷密度不少于0.2/页;
设计评审的缺陷密度不少于0.5/页;
系统测试的缺陷密度不少于2个/KLOC;
单元测试的缺陷密度不少于5个/KLOC;
代码走查的缺陷密度不少于10个/KLOC;
集成一次通过率不少于90%;
静态检查的缺陷密度不高于10个/KLOC;
测试缺陷重现率不高于10%;
规模:需求文档的页数不多于15CFP/页;
代码复用率不少于20%;
每月平均加班工时不超过2天;
文档中的图表数量平均每页不少于1个;
需求评审的工作量:需求开发的工作量>50%;
设计评审的工作量:设计的工作量>50%;
需求、设计评审的速度不高于10页/小时;
注释代码比例不少于10%;
代码评审速度不高于250行/小时;
代码走查的投入工作量不少于1小时/人天;
单元测试的用例密度不少于50个测试用例/KLOC;
系统测试的投入工作量不少于100人天;
系统测试的用例密度不少于10个测试用例/KLOC.
No |
指标名称 |
指标描述 |
能力维度 |
1 |
进度偏差 |
实际结束日期-计划结束日期/(计划开始-实际结束日期) |
项目管理能力 |
2 |
加班率 |
总工作时间/正常工作时间 |
项目管理能力 |
3 |
成本分布 |
开发成本:测试成本 |
项目管理能力 |
4 |
需求变更率 |
需求变更数/需求总数 |
范围管理能力 |
5 |
上线需求数 |
当月上线需求数 |
范围管理能力 |
6 |
UT用例数 |
单元测试用例数 |
质量管理能力 |
7 |
UT通过率 |
失败用例数/UT用例总数 |
质量管理能力 |
8 |
UT覆盖率 |
覆盖代码行/项目代码行 |
质量管理能力 |
9 |
UT变更代码覆盖率 |
变更代码覆盖行/变更代码总行数 |
量管理能力 |
10 |
代码评审率 |
评审文件数/提交文件总数 |
质量管理能力 |
11 |
评审效率 |
评审问题数/项目代码总数 |
质量管理能力 |
12 |
变更代码评审效率 |
评审问题数/变更代码总行数 |
质量管理能力 |
13 |
代码合规率 |
Sonar 代码合规指标 |
质量管理能力 |
14 |
测试需求覆盖度 |
已覆盖需求数/项目需求总数 |
质量管理能力 |
15 |
测试用例通过率 |
测试用例通过数/项目测试用例总数 |
质量管理能力 |
16 |
测试缺陷分布 |
测试分布=(集成测试+系统测试)缺陷数/缺陷总数(包括集成,系统,验收,线上缺陷)*100 |
质量管理能力 |
17 |
Cancel缺陷率 |
集成测试+系统测试阶段无效的缺陷数/集成测试+系统测试阶段缺陷总数 |
技术提升能力 |
18 |
缺陷密度 |
(集成+系统+验收+线上缺陷总数)/(研发+测试总工时) |
质量管理能力 |
19 |
缺陷逃逸率 |
(验收测试+线上缺陷数)/(研发+测试总工时) |
质量管理能力 |
20 |
缺陷关闭率 |
(集成+系统+验收 阶段的关闭缺陷数)/三个阶段缺陷总数(注去掉无效缺陷数) |
质量管理能力 |
21 |
线上缺陷 |
线上缺陷数量 |
质量管理能力 |
22 |
线上故障分布 |
按照线上问题原因类型进行分布统计 |
质量管理能力 |
23 |
上线需求测试覆盖度 |
上线需求测试数/上线需求总数(月度周期) |
质量管理能力 |
24 |
缺陷移除有效率 |
DRE=上线前发现的缺陷数/(上线前+上线后发现缺陷总数) |
|
25 |
工程故障数 |
产品release后3个月,来自工程现场的故障 |
质量管理能力 |
26 |
线上缺陷解决效率 |
|
|
27 |
测试用例贡献度 |
个人测试用例数/项目用例总数 |
效率管理能力 |
28 |
测试缺陷贡献度 |
个人提出缺陷数/项目缺陷总数 |
效率管理能力 |
29 |
代码效率 |
代码行数/总研发工时 |
效率管理能力 |
30 |
代码审查效率 |
审查代码行/代码审查总工时 |
效率管理能力 |
31 |
持续集编译成率 |
Build成功率/build总次数 |
技术提升能力 |
32 |
持续集成部署成功率 |
部署成功数/持续集成执行总次数 |
技术提升能力 |
33 |
持续集成测试成功率 |
测试执行成功数/持续集成执行总次数 |
技术提升能力 |
34 |
测试用例自动化率 |
自动测试用例数/总测试用例数 |
技术提升能力 |
35 |
自动化测试覆盖率 |
测试覆盖代码行/项目代码总行数 |
技术提升能力 |
维度 |
指示器/评价维度 |
评价手段 |
粒度 |
优秀 |
良好 |
一般 |
较差 |
复杂度 |
方法平均圈复杂度 |
自动采集 |
团队 |
(0,2] |
(2,3] |
(3,4] |
>4 |
|
变动代码的方法圈复杂度 |
自动采集 |
个人/团队 |
<=5 |
(5,8] |
(8,10] |
>10 |
|
Top-N方法平均圈复杂度 |
自动采集 |
团队 |
<=5 |
(5,8] |
(8,10] |
>10 |
|
方法/函数深度 |
自动采集 |
团队 |
(0,5] |
(5,6] |
(6,7] |
>=8 |
|
方法最大圈复杂度 |
自动采集 |
方法/团队 |
(0,8] |
[8,10) |
(10,12] |
>12 |
|
方法/函数有效行数 |
自动采集 |
方法/团队 |
(0,30] |
(30,40] |
(40,50] |
>50 |
|
类有效行数 |
自动采集 |
类/团队 |
(0,200] |
(200,300] |
(300,500] |
>500 |
|
内部类有效行数 |
自动采集 |
类/团队 |
(0,30] |
(30,40] |
(40,50] |
>50 |
设计 |
模块分层清晰,业务模型精炼 |
评审/走查 |
团队 |
标准:参考设计模式,5大原则 |
|
|
|
|
包耦合指数 |
自动采集 |
团队 |
0 |
- |
- |
>0 |
CC原则 |
代码重复率 |
自动采集 |
团队 |
0 |
(0,1%] |
(1%,3%] |
>3% |
|
Findbugs/Sonar/PCLint/Coverity/Klocwork等工具检查缺陷 |
自动采集 |
团队 |
总缺陷数为0 |
总缺陷数不为0,无严重、中等缺陷 |
总缺陷数不为0,无严重缺陷 |
总缺陷数不为0,各级别缺陷均有 |
|
书写风格 |
统一格式文件 |
团队 |
标准:每个团队有统一的格式文件 |
|
|
|
|
类名/方法名/变量名自表达 |
评审/走查 |
团队 |
标准:类名、方法名、变量名自表达,无多余注释 |
|
|
|
可测试 |
UT/FT代码行覆盖率 |
自动采集 |
团队 |
>90% |
(70%,90%] |
(50%,70%] |
<=50% |
|
UT/FT代码分支覆盖率 |
自动采集 |
团队 |
>75% |
(60%,75%] |
(45%,60%] |
<=45% |
|
UT用例通过率 |
自动采集 |
团队 |
100% |
[95%,100%) |
[90%,95%) |
<90% |
|
FT用例通过率 |
自动采集 |
团队 |
100% |
[95%,100%) |
[90%,95%) |
<90% |
|
UT/FT测试有效性 |
评审/走查 |
团队 |
标准:覆盖所有测试场景 |
|
|
|
|
测试用例体现外部接口的使用方法 |
评审/走查 |
团队 |
标准:测试用例的代码中包含接口使用方法 |
|
|
|
|
性能测试 |
自动采集 |
团队 |
标准:有内存、CPU、吞吐量、请求成功率等测试 |
|
|
|