软件项目开发度量分析

1、 序 级别 数据 数据指标 指标定义 数据来源 说明 号 维度 维度 1 组织 效率 小需求吞吐力 计算公式： 1 :小需求吞吐力=100%* 本月发布需求数/本月新增 需求数 统计规那么： 1、 新增小需求按照需求提交日期时间段 submitted 来过滤，需求状态不包括废弃的需求和标准工程的需求 2、 发布小需求按照需求发布时间段来过滤，需求不包 括废弃的需求和标准工程的需求 3、 技术需求类型为技术类和业务类 CQ 有效展示团队目前对需求的吞噬处理能力 2 组织 效率 技术类需求占比 计算公式： 1:技术类需求占比=100%* 本月发布上线的技术类 小需求数/本月发布小需求数 统计规那么

2、： CQ 衡量团队在技术改造需求的投入情况 目前仅作为参考 1、发布小需求按照需求发布时间段来过滤，需求不包 括废弃的需求和标准工程的需求 3 组织 效率 小需求遗留率 计算公式： 小需求遗留率=100%* 本月新增需求数-本月提交并发 布需求数/本月新增需求数 CQ Jira 有效展示团队目前对需求的吞噬处理能力 4 组织 周期 标准工程的研发周期 计算公式：实际发布上线时间 -PRD评审通过时间 统计规那么： 1、 实际发布上线时间以 Cq中工程的已提交运维为准 2、 PRD评审通过时间以 CQ中的PRD评审通过时间为 准 CQ 反映团队对夕卜在需求的处理时间周期和响应速度 5 组织 周期

3、 小需求研发周期 计算公式：实际发布上线时间 -需求提交时间open时 间 统计规那么：需求不包括废弃的需求和标准工程的需求 CQ 反映团队对夕卜在需求的处理时间周期和响应速度 6 工程 周期 市场响应速度 计算公式：所有业务类的工程研发周期的平均 统计规那么： CQ和立项平 台 反映工程对外在需求的处理时间周期和响应速度 1、 周期按照技术类和业务类区分，类型以立项审批平 台为准 2、 对于业务类的市场响应速度仅仅统计业务类的，不 包含运营支撑，数据平台以及根底平台搭建的需求。 7 工程 进度 标准工程的发布时间 点偏差 计算公式：实际发布元成时间 -方案发布元成时间 统计规那么： 1、 实

4、际发布上线时间以 Cq中工程的已提交运维为准。 2、 方案发布时间以 kickoff时确定的发布时间为准 工程周报和 CQ 反映工程在发布时间上的整体控制能力 8 组织 效率 整体开发效率 计算公式：部门的开发效率 =本月部门已发布上线的代 码行/本月发布上线的部门相应投入的工作量 统计规那么： 1、 代码行和工作量以人员所属部门为准，在发布上线 工程中所产生的代码量和投入的工作量 2、 代码行只计算业务代码的新增，修改，删除总和 CQ Jira 日报 代码统计工 具 团队在固定时间内的产出 9 工程 效率 工程开发效率 计算公式：标准工程的开发效率 =本月已发布上线的代 码行业务代码新增，修

5、改和删除 /本月已发布上线 CQ Jira 反映工程的开发效率 工程的所属工作量 统计规那么： 1、代码行只计算业务代码的新增，修改，删除总和 日报 代码统计工 具 10 组织 质量 部门的线下缺陷密度 计算公式：1000*发布上线的有效线下缺陷总数 /发布上 线的代码行总数业务代码新增，修改和删除 统计规那么： 1、 线下缺陷数不包括invalid状态；去掉系统自动提交 的如mvn和合并冲突的缺陷数，去掉 ccadmin 或 scmadmin 提交的缺陷和需求类的缺陷 2、 代码行已发布上线的为准，以部门为组织单位 3、 缺陷数以人员为准，以部门缺陷所属的责任组 为单位 CQ Jira 代码

6、统计工 具 衡量研发团队提交产品质量的指标 以下情况不纳入当月线下缺陷的统计分析范畴： 1、 系统自动提交的如合并冲突缺陷 2、 SIT和预发布环节发生的新增需求类的不算 3、 已推迟缺陷放入本月处理的，不纳入本月缺陷统计范 围 4、 其他情况第二方故障/申请预发权限的如 Alonestatic 预发/测试类代码 缺陷责任组界定和调整原那么： 1、 按照技术部组织架构归属到责任组，按照线下缺陷的 责任组统计分析；责任组为具体引入此缺陷根源的开发责 任组。 2、 假设调整线下缺陷的责任组，双方开发主管得到认同即 可。 代码行统计说明： 1、 统计分支从创立到工程结束的代码增、删、改的行数， 通过

7、目录结构区分测试用例代码和非测试代码 2、 框架自动生成而导入的代码也会统计进去，因此新系 统代码变化量会比拟大 3、 因重构进行目录移动或重名会统计两次变更，比方一 个文件重命名了会计算成为分别新增和删除一个文件 4、 统计内容中不包括空行 5、 从主干或者其他分支 rebase过来的代码不会算在统计 范围内 11 工程 质量 标准工程的线下缺陷 密度 计算公式：1000*有效线下缺陷/代码行业务代码新增， 修改和删除 统计规那么： 1、线下缺陷数不包括invalid状态；去掉系统自动提交 的如mvn和合并冲突的缺陷数，去掉 ccadmin 或 CQ Jira 代码统计工 具 衡量标准工程线

8、下质量的指标 不纳入当月线下缺陷的统计分析范畴描述同上 scmadmin 提交的缺陷，和此工程关联的缺陷数，去掉 历史遗留缺陷 12 工程 质量 升级包的线下缺陷密 度 计算公式：1000*本月发布上线的升级包所属线下缺陷 总数/本月发布上线的升级包代码行业务代码新增， 修改和删除 统计规那么： 1、 线下缺陷数不包括invalid状态；去掉系统自动提交 的如mvn和合并冲突的缺陷数，去掉 ccadmin 或 scmadmin 提交的缺陷，和此工程关联的缺陷数，去掉 历史遗留缺陷 2、 代码行已发布上线的为准，以工程为组织单位 CQ Jira 代码统计工 具 衡量升级包线下质量的指标 13 组

9、织 质量 测试漏检率 计算公式：测试漏检率 =所属的测试责任组的线上故障 总数/提交人所属测试责任组的线下缺陷数。 统计规那么： 1、线下缺陷统计规那么：按人员所属组确定各小组线下 缺陷提交数，统计时间按提交时间计算，去除测试代码 CQ 反映测试团队的测试质量 修改类型的缺陷。 2、 线上故障漏测认定：所有开发团队的线上故障，认 定为其对应测试组的故障漏测。 3、 责任转移：如下情况可以完成故障漏测的跨测试组 转移 A 双方测试主管达成一致 B 双方测试主管无法达成一致，由质重总监确TE并更 改责任归属 4、 责任豁免：如下情况可认定具体故障为非漏测，此 类情况都需要邮件报备给质量总监，并抄送

10、测试主管和 SQA群组 总体原那么：明确为测试问学职柄围之外故障， 可算 作非漏测。 A重复故障不累加，仅计算一次即可 重复故障的认定标准同效劳台一致：如果是一 个因引起的 并且在24h内算一个故障 超过时 间了还是按2个来算的 B 发布前测试已经发现的故障，需同时满足 如下条件： a 提交有线下缺陷走到已推迟状态； b 在质量评估报告中有明确提示； 仅 针对标准工程这种有质量评估报告的情 况适用，其他情况，如升级包， 无需满足 此条件 c 邮件发送质量总监或其授权人确 认可带缺陷上线 C 发布过程或线上环境中由开发、运维误操 作导致的非应用系统故障 a备注：假设本身为应用系统故障，仅因 为人

11、为操作触发，仍因算作漏测 D 因机房迁移、硬件环境等因素导致的非应 用系统故障 a备注：假设本身为应用系统故障，仅因 为外界环境变化触发，仍因算作漏测 E在质量总监层面事先确认的，不属于测试 团队职责范围内的产品的故障 a备注：此类情况由质量总监进行认 定，原那么上仅对事先明确的产品生效， 不 进行具体工程的认定。 14 组织 质量 SIT缺陷占比 计算公式：SIT缺陷占比=SIT缺陷数/总线下缺陷数。 统计规那么： 1、 SIT阶段发现的业务代码的 bug ,不包括测试代码 变更，在CQ中的表现形式为： ucm_project=release2021 2、 对于系统自动提交的缺陷不纳入分析范

12、畴。 反应合并之后 SIT缺陷数的占比，衡量测试团队的功能测 试质量。 SIT缺陷分类填写指南： :/ 14 组织 质量 部门的reopen 率 计算公式：所属部门的reopen次数/所属部门的有效总 缺陷数； 1、部门的reopen按照reopen的时间来算，缺陷数按 CQ 衡量工程研发修复缺陷质量的指标 照缺陷的所属责任组 2、 以发布上线时间为准。 3、 线下缺陷数不包括invalid状态；去掉系统自动提交 的如mvn和合并冲突的缺陷数，去掉 ccadmin 或 scmadmin 提交的缺陷 15 工程 质量 工程的reopen 率 计算公式：reopen次数/有效总缺陷数； 统计规那么

13、： 1、 按照所属工程来计算，缺陷按照工程关联 2、 线下缺陷数不包括invalid状态；去掉系统自动提交 的如mvn和合并冲突的缺陷数，去掉 ccadmin 或 scmadmin 提交的缺陷 CQ 衡量工程研发修复缺陷质量的指标 16 组织 质量 线上故障个数 计算公式：线上故障个数之和 统计规那么： 1、 以ITIL为准，按照关闭时间过滤 2、 去掉重复和需求类的线上故障， 线上故障类型以服 ITIL 衡量团队最终产品质量的指标 务台为准 3、线上故障以开发责任组和责任子系统为单位，可按 照等级为单位 17 组织 质量 紧急发布数 计算公式：紧急发布数之和 统计规那么： 1、 紧急发布申请为准，按照紧急发布的发布时间过滤 2、 紧急发布的责任组为单位 3、 紧急发布区分故障，技术需求和业务需求； 技术部 VP审核的为技术需求；事业部部门总经理审核的需求 为业务需求；紧急发布关联的线上故障为故障 CQ 反映产品紧急发布个数以及对线上环境的稳定情况 18 组织 本钱 本钱投入-部门工作投 入 计算公式：100*部门工作的工作量/部门总工作量 统计规那么：以日报为准 日报 降低团队成员在部门支持上的资源消耗，使团队有限的资 源能够更多投入到需求研发中 19 组织 本钱 本钱投入-提案研发资