软件项目开发度量分析.docx

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