软件项目开发度量分析
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2、代码行已发布上线的为准，以部门为组织单位
3、缺陷数以人员为准，以部门（缺陷所属的责任组）为单位
CQ
Jira
代码统计工具
衡量研发团队提交产品质量的指标
以下情况不纳入当月线下缺陷的统计分析范畴：
1、系统自动提交的如合并冲突缺陷
2、SIT和预发布环节发生的新增需求类的不算
3、已推迟缺陷放入本月处理的，不纳入本月缺陷统计范围
统计规则：
1、线下缺陷数不包括invalid状态；去掉系统自动提交的如（mvn和合并冲突的缺陷数），去掉ccadmin或scmadmin提交的缺陷，和此项目关联的缺陷数，去掉历史遗留缺陷
CQ
Jira
代码统计工具
衡量标准项目线下质量的指标
不纳入当月线下缺陷的统计分析范畴描述同上
12
项目
质量
升级包的线下缺陷密度
重复故障的认定标准同服务台一致：如果是一个因引起的 并且在24h内 算一个故障 超过时间了 还是按2个来算的
B）发布前测试已经发现的故障，需同时满足如下条件：
a) 提交有线下缺陷（走到已推迟状态）；
b) 在质量评估报告中有明确提示；（仅针对标准项目这种有质量评估报告的情况适用，其他情况，如升级包，无需满足此条件）
计算公式：1000*本月发布上线的升级包所属线下缺陷总数/本月发布上线的升级包代码行（业务代码新增，修改和删除）
统计规则：
1、线下缺陷数不包括invalid状态；去掉系统自动提交的如（mvn和合并冲突的缺陷数），去掉ccadmin或scmadmin提交的缺陷，和此项目关联的缺陷数，去掉历史遗留缺陷
2、代码行已发布上线的为准，以项目为组织单位
2、PRD评审通过时间以CQ中的PRD评审通过时间为准"
CQ
反映团队对外在需求的处理时间周期和响应速度
5
组织
周期
小需求研发周期
计算公式：实际发布上线时间-需求提交时间（open时间）
统计规则：需求不包括废弃的需求和标准项目的需求
CQ
反映团队对外在需求的处理时间周期和响应速度
6
项目
周期
市场响应速度
计算公式：所有业务类的项目研发周期的平均
CQ
Jira
代码统计工具
衡量升级包线下质量的指标
13
组织
质量
测试漏检率
计算公式：测试漏检率=所属的测试责任组的线上故障总数/提交人所属测试责任组的线下缺陷数。
统计规则：
1、线下缺陷统计规则：按人员所属组确定各小组线下缺陷提交数，统计时间按提交时间计算，去除测试代码修改类型的缺陷。
2、线上故障漏测认定：所有开发团队的线上故障，认定为其对应测试组的故障漏测。
1、实际发布上线时间以Cq中项目的已提交运维为准。
2、计划发布时间以kickoff时确定的发布时间为准
项目周报和CQ
反映项目在发布时间上的整体控制能力
8
组织
效率
整体开发效率
计算公式：部门的开发效率=本月部门已发布上线的代码行/本月发布上线的部门相应投入的工作量
统计规则：
1、代码行和工作量以人员所属部门为准，在发布上线项目中所产生的代码量和投入的工作量
2、代码行只计算业务代码的新增，修改，删除总和
CQ
Jira
日报
代码统计工具
团队在固定时间内的产出
9
项目
效率
项目开发效率
计算公式：标准项目的开发效率=本月已发布上线的代码行（业务代码新增，修改和删除）/本月已发布上线项目的所属工作量
统计规则：
1、代码行只计算业务代码的新增，修改，删除总和
CQ
Jira
日报
1、部门的reopen按照reopen的时间来算，缺陷数按照缺陷的所属责任组
2、以发布上线时间为准。
3、线下缺陷数不包括invalid状态；去掉系统自动提交的如（mvn和合并冲突的缺陷数），去掉ccadmin或scmadmin提交的缺陷
CQ
衡量项目研发修复缺陷质量的指标
15
项目
质量
项目的reopen率
Hale Waihona Puke Baidu日报
降低团队成员在部门支持上的资源消耗，使团队有限的资源能够更多投入到需求研发中
19
组织
成本
成本投入-提案研发资源投入
计算公式：团队投入在提案研发类型上的投入
统计规则：以日报为准，按照技术和业务资源投入来区分，以关联提案的类型为准。
日报
反映团队在研发上的成本投入情况
20
组织
成本
成本投入-日常升级包投入
2、对于系统自动提交的缺陷不纳入分析范畴。
反馈合并之后SIT缺陷数的占比，衡量测试团队的功能测试质量。
SIT缺陷分类填写指南：http://www.alisoup.net/ContentRichText.aspx?id=58
14
组织
质量
部门的reopen率
计算公式：所属部门的reopen次数/所属部门的有效总缺陷数；
2、紧急发布的责任组为单位
3、紧急发布区分故障，技术需求和业务需求；技术部VP审核的为技术需求；事业部部门总经理审核的需求为业务需求；紧急发布关联的线上故障为故障
CQ
反映产品紧急发布个数以及对线上环境的稳定情况
18
组织
成本
成本投入-部门工作投入
计算公式：100*部门工作的工作量/部门总工作量
统计规则：以日报为准
4、其他情况（第三方故障/申请预发权限的如Alonestatic预发/测试类代码）
缺陷责任组界定和调整原则：
1、 按照技术部组织架构归属到责任组，按照线下缺陷的责任组统计分析；责任组为具体引入此缺陷根源的开发责任组。
2、 若调整线下缺陷的责任组，双方开发主管得到认同即可。
代码行统计说明：
1、统计分支从创建到项目结束的代码增、删、改的行数，通过目录结构区分测试用例代码和非测试代码
E）在质量总监层面事先确认的，不属于测试团队职责范围内的产品的故障
a) 备注：此类情况由质量总监进行认定，原则上仅对事先明确的产品生效，不进行具体项目的认定。
CQ
反映测试团队的测试质量
14
组织
质量
SIT缺陷占比
计算公式：SIT缺陷占比=SIT缺陷数/总线下缺陷数。
统计规则：
1、SIT阶段发现的业务代码的bug，不包括测试代码变更，在CQ中的表现形式为：ucm_project=release2010
序号
级别维度
数据维度
数据指标
指标定义
数据来源
说明
1
组织
效率
小需求吞吐力
计算公式：
1：小需求吞吐力=100%*（本月发布需求数/本月新增需求数）
统计规则：
1、新增小需求按照需求提交日期时间段（submitted）来过滤，需求状态不包括废弃的需求和标准项目的需求
2、发布小需求按照需求发布时间段来过滤，需求不包括废弃的需求和标准项目的需求
3、责任转移：如下情况可以完成故障漏测的跨测试组转移
A）双方测试主管达成一致
B）双方测试主管无法达成一致，由质量总监确定并更改责任归属
4、责任豁免：如下情况可认定具体故障为非漏测，此类情况都需要邮件报备给质量总监，并抄送测试主管和SQA群组
总体原则：明确为测试同学职责范围之外故障，可算作非漏测。
A）重复故障不累加，仅计算一次即可
2、框架自动生成而导入的代码也会统计进去，因此新系统代码变化量会比较大
3、因重构进行目录移动或重名会统计两次变更，比如一个文件重命名了会计算成为分别新增和删除一个文件
4、统计内容中不包括空行
5、从主干或者其他分支rebase过来的代码不会算在统计范围内
11
项目
质量
标准项目的线下缺陷密度
计算公式：1000*有效线下缺陷/代码行（业务代码新增，修改和删除）
计算公式：reopen次数/有效总缺陷数；
统计规则：
1、按照所属项目来计算，缺陷按照项目关联
2、线下缺陷数不包括invalid状态；去掉系统自动提交的如（mvn和合并冲突的缺陷数），去掉ccadmin或scmadmin提交的缺陷
CQ
衡量项目研发修复缺陷质量的指标
16
组织
质量
线上故障个数
计算公式：线上故障个数之和
c) 邮件发送质量总监（或其授权人）确认可带缺陷上线
C）发布过程或线上环境中由开发、运维误操作导致的非应用系统故障
a) 备注：若本身为应用系统故障，仅因为人为操作触发，仍因算作漏测
D）因机房迁移、硬件环境等因素导致的非应用系统故障
a) 备注：若本身为应用系统故障，仅因为外界环境变化触发，仍因算作漏测
代码统计工具
反映项目的开发效率
10
组织
质量
部门的线下缺陷密度
计算公式：1000*发布上线的有效线下缺陷总数/发布上线的代码行总数（业务代码新增，修改和删除）
统计规则：
1、线下缺陷数不包括invalid状态；去掉系统自动提交的如（mvn和合并冲突的缺陷数），去掉ccadmin或scmadmin提交的缺陷和需求类的缺陷
统计规则：
1、周期按照技术类和业务类区分，类型以立项审批平台为准
2、对于业务类的市场响应速度仅仅统计业务类的，不包含运营支撑，数据平台以及基础平台搭建的需求。
CQ和立项平台
反映项目对外在需求的处理时间周期和响应速度
7
项目
进度
标准项目的发布时间点偏差
计算公式：实际发布完成时间-计划发布完成时间
统计规则：
目前仅作为参考
3
组织
效率
小需求遗留率
计算公式：
小需求遗留率=100%*（本月新增需求数-本月提交并发布需求数）/本月新增需求数
CQ
Jira
有效展示团队目前对需求的吞噬处理能力
4
组织
周期
标准项目的研发周期
计算公式：实际发布上线时间-PRD评审通过时间
统计规则：
1、实际发布上线时间以Cq中项目的已提交运维为准
计算公式：团队投入日常升级包的工作量
统计规则：以日报为准，项目没有关联提案的都计算为日常升级包
日报
降低团队成员在零碎需求支持，更多的时间投入到提案研发中，使团队有限的资源能够更多投入到有价值的需求研发中
3、技术需求类型为技术类和业务类
CQ
有效展示团队目前对需求的吞噬处理能力
2
组织
效率
技术类需求占比
计算公式：
1：技术类需求占比= 100%*（本月发布上线的技术类小需求数/本月发布小需求数）
统计规则：
1、发布小需求按照需求发布时间段来过滤，需求不包括废弃的需求和标准项目的需求
CQ
衡量团队在技术改造需求的投入情况
统计规则：
1、以ITIL为准，按照关闭时间过滤
2、去掉重复和需求类的线上故障，线上故障类型以服务台为准
3、线上故障以开发责任组和责任子系统为单位，可按照等级为单位
ITIL
衡量团队最终产品质量的指标
17
组织
质量
紧急发布数
计算公式：紧急发布数之和
统计规则：
1、紧急发布申请为准，按照紧急发布的发布时间过滤
3、缺陷数以人员为准，以部门（缺陷所属的责任组）为单位
CQ
Jira
代码统计工具
衡量研发团队提交产品质量的指标
以下情况不纳入当月线下缺陷的统计分析范畴：
1、系统自动提交的如合并冲突缺陷
2、SIT和预发布环节发生的新增需求类的不算
3、已推迟缺陷放入本月处理的，不纳入本月缺陷统计范围
统计规则：
1、线下缺陷数不包括invalid状态；去掉系统自动提交的如（mvn和合并冲突的缺陷数），去掉ccadmin或scmadmin提交的缺陷，和此项目关联的缺陷数，去掉历史遗留缺陷
CQ
Jira
代码统计工具
衡量标准项目线下质量的指标
不纳入当月线下缺陷的统计分析范畴描述同上
12
项目
质量
升级包的线下缺陷密度
重复故障的认定标准同服务台一致：如果是一个因引起的 并且在24h内 算一个故障 超过时间了 还是按2个来算的
B）发布前测试已经发现的故障，需同时满足如下条件：
a) 提交有线下缺陷（走到已推迟状态）；
b) 在质量评估报告中有明确提示；（仅针对标准项目这种有质量评估报告的情况适用，其他情况，如升级包，无需满足此条件）
计算公式：1000*本月发布上线的升级包所属线下缺陷总数/本月发布上线的升级包代码行（业务代码新增，修改和删除）
统计规则：
1、线下缺陷数不包括invalid状态；去掉系统自动提交的如（mvn和合并冲突的缺陷数），去掉ccadmin或scmadmin提交的缺陷，和此项目关联的缺陷数，去掉历史遗留缺陷
2、代码行已发布上线的为准，以项目为组织单位
2、PRD评审通过时间以CQ中的PRD评审通过时间为准"
CQ
反映团队对外在需求的处理时间周期和响应速度
5
组织
周期
小需求研发周期
计算公式：实际发布上线时间-需求提交时间（open时间）
统计规则：需求不包括废弃的需求和标准项目的需求
CQ
反映团队对外在需求的处理时间周期和响应速度
6
项目
周期
市场响应速度
计算公式：所有业务类的项目研发周期的平均
CQ
Jira
代码统计工具
衡量升级包线下质量的指标
13
组织
质量
测试漏检率
计算公式：测试漏检率=所属的测试责任组的线上故障总数/提交人所属测试责任组的线下缺陷数。
统计规则：
1、线下缺陷统计规则：按人员所属组确定各小组线下缺陷提交数，统计时间按提交时间计算，去除测试代码修改类型的缺陷。
2、线上故障漏测认定：所有开发团队的线上故障，认定为其对应测试组的故障漏测。
1、实际发布上线时间以Cq中项目的已提交运维为准。
2、计划发布时间以kickoff时确定的发布时间为准
项目周报和CQ
反映项目在发布时间上的整体控制能力
8
组织
效率
整体开发效率
计算公式：部门的开发效率=本月部门已发布上线的代码行/本月发布上线的部门相应投入的工作量
统计规则：
1、代码行和工作量以人员所属部门为准，在发布上线项目中所产生的代码量和投入的工作量
2、代码行只计算业务代码的新增，修改，删除总和
CQ
Jira
日报
代码统计工具
团队在固定时间内的产出
9
项目
效率
项目开发效率
计算公式：标准项目的开发效率=本月已发布上线的代码行（业务代码新增，修改和删除）/本月已发布上线项目的所属工作量
统计规则：
1、代码行只计算业务代码的新增，修改，删除总和
CQ
Jira
日报
1、部门的reopen按照reopen的时间来算，缺陷数按照缺陷的所属责任组
2、以发布上线时间为准。
3、线下缺陷数不包括invalid状态；去掉系统自动提交的如（mvn和合并冲突的缺陷数），去掉ccadmin或scmadmin提交的缺陷
CQ
衡量项目研发修复缺陷质量的指标
15
项目
质量
项目的reopen率
Hale Waihona Puke Baidu日报
降低团队成员在部门支持上的资源消耗，使团队有限的资源能够更多投入到需求研发中
19
组织
成本
成本投入-提案研发资源投入
计算公式：团队投入在提案研发类型上的投入
统计规则：以日报为准，按照技术和业务资源投入来区分，以关联提案的类型为准。
日报
反映团队在研发上的成本投入情况
20
组织
成本
成本投入-日常升级包投入
2、对于系统自动提交的缺陷不纳入分析范畴。
反馈合并之后SIT缺陷数的占比，衡量测试团队的功能测试质量。
SIT缺陷分类填写指南：http://www.alisoup.net/ContentRichText.aspx?id=58
14
组织
质量
部门的reopen率
计算公式：所属部门的reopen次数/所属部门的有效总缺陷数；
2、紧急发布的责任组为单位
3、紧急发布区分故障，技术需求和业务需求；技术部VP审核的为技术需求；事业部部门总经理审核的需求为业务需求；紧急发布关联的线上故障为故障
CQ
反映产品紧急发布个数以及对线上环境的稳定情况
18
组织
成本
成本投入-部门工作投入
计算公式：100*部门工作的工作量/部门总工作量
统计规则：以日报为准
4、其他情况（第三方故障/申请预发权限的如Alonestatic预发/测试类代码）
缺陷责任组界定和调整原则：
1、 按照技术部组织架构归属到责任组，按照线下缺陷的责任组统计分析；责任组为具体引入此缺陷根源的开发责任组。
2、 若调整线下缺陷的责任组，双方开发主管得到认同即可。
代码行统计说明：
1、统计分支从创建到项目结束的代码增、删、改的行数，通过目录结构区分测试用例代码和非测试代码
E）在质量总监层面事先确认的，不属于测试团队职责范围内的产品的故障
a) 备注：此类情况由质量总监进行认定，原则上仅对事先明确的产品生效，不进行具体项目的认定。
CQ
反映测试团队的测试质量
14
组织
质量
SIT缺陷占比
计算公式：SIT缺陷占比=SIT缺陷数/总线下缺陷数。
统计规则：
1、SIT阶段发现的业务代码的bug，不包括测试代码变更，在CQ中的表现形式为：ucm_project=release2010
序号
级别维度
数据维度
数据指标
指标定义
数据来源
说明
1
组织
效率
小需求吞吐力
计算公式：
1：小需求吞吐力=100%*（本月发布需求数/本月新增需求数）
统计规则：
1、新增小需求按照需求提交日期时间段（submitted）来过滤，需求状态不包括废弃的需求和标准项目的需求
2、发布小需求按照需求发布时间段来过滤，需求不包括废弃的需求和标准项目的需求
3、责任转移：如下情况可以完成故障漏测的跨测试组转移
A）双方测试主管达成一致
B）双方测试主管无法达成一致，由质量总监确定并更改责任归属
4、责任豁免：如下情况可认定具体故障为非漏测，此类情况都需要邮件报备给质量总监，并抄送测试主管和SQA群组
总体原则：明确为测试同学职责范围之外故障，可算作非漏测。
A）重复故障不累加，仅计算一次即可
2、框架自动生成而导入的代码也会统计进去，因此新系统代码变化量会比较大
3、因重构进行目录移动或重名会统计两次变更，比如一个文件重命名了会计算成为分别新增和删除一个文件
4、统计内容中不包括空行
5、从主干或者其他分支rebase过来的代码不会算在统计范围内
11
项目
质量
标准项目的线下缺陷密度
计算公式：1000*有效线下缺陷/代码行（业务代码新增，修改和删除）
计算公式：reopen次数/有效总缺陷数；
统计规则：
1、按照所属项目来计算，缺陷按照项目关联
2、线下缺陷数不包括invalid状态；去掉系统自动提交的如（mvn和合并冲突的缺陷数），去掉ccadmin或scmadmin提交的缺陷
CQ
衡量项目研发修复缺陷质量的指标
16
组织
质量
线上故障个数
计算公式：线上故障个数之和
c) 邮件发送质量总监（或其授权人）确认可带缺陷上线
C）发布过程或线上环境中由开发、运维误操作导致的非应用系统故障
a) 备注：若本身为应用系统故障，仅因为人为操作触发，仍因算作漏测
D）因机房迁移、硬件环境等因素导致的非应用系统故障
a) 备注：若本身为应用系统故障，仅因为外界环境变化触发，仍因算作漏测
代码统计工具
反映项目的开发效率
10
组织
质量
部门的线下缺陷密度
计算公式：1000*发布上线的有效线下缺陷总数/发布上线的代码行总数（业务代码新增，修改和删除）
统计规则：
1、线下缺陷数不包括invalid状态；去掉系统自动提交的如（mvn和合并冲突的缺陷数），去掉ccadmin或scmadmin提交的缺陷和需求类的缺陷
统计规则：
1、周期按照技术类和业务类区分，类型以立项审批平台为准
2、对于业务类的市场响应速度仅仅统计业务类的，不包含运营支撑，数据平台以及基础平台搭建的需求。
CQ和立项平台
反映项目对外在需求的处理时间周期和响应速度
7
项目
进度
标准项目的发布时间点偏差
计算公式：实际发布完成时间-计划发布完成时间
统计规则：
目前仅作为参考
3
组织
效率
小需求遗留率
计算公式：
小需求遗留率=100%*（本月新增需求数-本月提交并发布需求数）/本月新增需求数
CQ
Jira
有效展示团队目前对需求的吞噬处理能力
4
组织
周期
标准项目的研发周期
计算公式：实际发布上线时间-PRD评审通过时间
统计规则：
1、实际发布上线时间以Cq中项目的已提交运维为准
计算公式：团队投入日常升级包的工作量
统计规则：以日报为准，项目没有关联提案的都计算为日常升级包
日报
降低团队成员在零碎需求支持，更多的时间投入到提案研发中，使团队有限的资源能够更多投入到有价值的需求研发中
3、技术需求类型为技术类和业务类
CQ
有效展示团队目前对需求的吞噬处理能力
2
组织
效率
技术类需求占比
计算公式：
1：技术类需求占比= 100%*（本月发布上线的技术类小需求数/本月发布小需求数）
统计规则：
1、发布小需求按照需求发布时间段来过滤，需求不包括废弃的需求和标准项目的需求
CQ
衡量团队在技术改造需求的投入情况
统计规则：
1、以ITIL为准，按照关闭时间过滤
2、去掉重复和需求类的线上故障，线上故障类型以服务台为准
3、线上故障以开发责任组和责任子系统为单位，可按照等级为单位
ITIL
衡量团队最终产品质量的指标
17
组织
质量
紧急发布数
计算公式：紧急发布数之和
统计规则：
1、紧急发布申请为准，按照紧急发布的发布时间过滤