《软件研发效能度量规范(T-IQA 15—2022).pdf》由会员分享，可在线阅读，更多相关《软件研发效能度量规范(T-IQA 15—2022).pdf（56页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、团体标准团体标准 软件研发效能度量规范 Measurement Specification of Software Development Efficiency,Effectiveness and Excellence（发布稿）ICS 35.240 L70 中关村智联软件服务业质量创新联盟中关村智联软件服务业质量创新联盟 发布 T/IQA 15-2022 2022-09-08 实施 2022-09-07 发布 T/IQA 15-2022 II 目 次 前 言.V 1 范围.1 2 规范性引用文件.1 3 术语和定义.1 3.1 组件 component.1 3.2 数据 data.1 3.3
2、信息需要 information need.1 3.4 软件产品 software product.2 3.5 软件服务 software service.2 3.6 软件组织 software organization.2 3.7 软件绩效改进 software performance improvement.2 4 软件研发效能度量框架.2 4.1 软件研发效能.2 4.1.1 效率.2 4.1.2 效果.2 4.1.3 卓越能力.2 4.2 度量框架.2 4.2.1 认知域.3 4.2.2 改进域.3 4.3 度量方法.3 4.3.1 确立目标和范围.3 4.3.2 选取度量指标.4 4
3、.3.3 实施度量和改进.4 4.4 度量原则.5 4.4.1 适用性.5 4.4.2 系统性.5 4.4.3 可靠性.5 4.4.4 持续性.5 5 软件研发效能度量指标.5 5.1 度量指标模型.5 5.1.1 数据集.5 5.1.2 指标.5 5.1.3 度量.5 5.1.4 视图.6 5.1.5 模型定义.6 5.1.6 指标定义.6 5.2 度量指标集.7 T/IQA 15-2022 III 6 软件研发效能视图应用.11 6.1 视图模型.12 6.2 视图卡片.12 附录 A.15 指标定义.15 A.1 交付价值.15 表 A.1.1 产品价值达成率.15 表 A.1.2 客户
4、满意率.16 表 A.1.3 客户问题响应时长.17 表 A.1.4 客户问题解决时长.18 表 A.1.5 用户增长率.19 表 A.1.6 市场占有率.20 表 A.1.7 营收增长率.21 A.2 交付速率.21 表 A.2.1 需求交付周期.21 表 A.2.2 开发交付周期.22 表 A.2.3 里程碑偏差.23 表 A.2.4 需求吞吐量（流速率）.23 表 A.2.5 流效率.24 表 A.2.6 需求颗粒度.24 表 A.2.7 需求按时交付率.25 表 A.2.8 需求变更率.26 表 A.2.9 组件按时交付率.26 表 A.2.10 组件复用率.27 表 A.2.11 接
5、口变更率.27 表 A.2.12 代码开发当量.27 表 A.2.13 代码提交频率.28 表 A.2.14 测试一次通过率.29 A.3 交付质量.29 表 A.3.1 演示频率.29 表 A.3.2 需求评审缺陷密度.29 表 A.3.3 需求评审通过率.30 表 A.3.4 设计评审缺陷密度.30 表 A.3.5 设计评审通过率.30 表 A.3.6 代码重复率.31 表 A.3.7 圈复杂度.31 表 A.3.8 静态扫描缺陷密度.32 表 A.3.9 代码走查缺陷密度.32 表 A.3.10 代码评审轮数.32 表 A.3.11 提测成功率.33 表 A.3.12 用例评审缺陷密度.
6、33 表 A.3.13 用例评审通过率.33 表 A.3.14 测试覆盖率.34 T/IQA 15-2022 IV 表 A.3.15 测试缺陷密度.34 表 A.3.16 缺陷逃逸率.35 表 A.3.17 发布成功率.35 表 A.3.18 系统可用性.35 表 A.3.19 线上故障数.36 表 A.3.20 平均故障间隔时长.36 表 A.3.21 平均故障修复时长.36 A.4 交付成本.37 表 A.4.1 挣值.37 表 A.4.2 预算执行率.38 表 A.4.3 返工率.38 表 A.4.4 人力成本.39 表 A.4.5 非人力成本.40 表 A.4.6 工作量分布.40 表
7、 A.4.7 技能指数.41 表 A.4.8 人员流动率.41 A.5 交付能力.42 表 A.5.1 流负载.42 表 A.5.2 构建频率.42 表 A.5.3 构建时长.43 表 A.5.4 构建成功率.43 表 A.5.5 缺陷重开率.43 表 A.5.6 测试自动化率.44 表 A.5.7 环境整备时长.44 表 A.5.8 部署频率.44 表 A.5.9 部署时长.45 表 A.5.10 部署成功率.45 表 A.5.11 回滚成功率.46 表 A.5.12 发布频率.46 表 A.5.13 发布时长.47 A.6 持续改进.47 表 A.6.1 改进效果评价.47 表 A.6.2
8、 专项改进完成率.47 表 A.6.3 审计问题关闭率.48 表 A.6.4 审计频率.48 表 A.6.5 过程符合度.49 参 考 文 献.51 T/IQA 15-2022 V 前 言 本标准按照 GB/T 1.12020标准化工作导则第 1 部分：标准化文件的结构和起草规则的规定起草。请注意本标准的某些内容可能涉及专利。本标准的发布机构不承担识别专利的责任。本标准由中关村智联软件服务业质量创新联盟提出并归口。本标准起草单位：中关村智联软件服务业质量创新联盟、京东科技控股股份有限公司、横琴人寿保险有限公司、北京昊诚亚旭科技有限公司、北京思码逸科技有限公司、腾讯云计算（北京）有限公司、云加速
9、（北京）科技有限公司、浙江中控技术股份有限公司、中国人寿财产保险股份有限公司、中电万维信息技术有限责任公司、金邦达有限公司北京分公司、紫光软件系统有限公司、北京四方继保自动化股份有限公司、中兴通讯股份有限公司、中国光大银行股份有限公司、株洲中车时代电气股份有限公司、平安银行股份有限公司、河北远东通信系统工程有限公司、网易（杭州）网络有限公司、中电海康集团有限公司、北京百度网讯科技有限公司、望海康信（北京）科技股份公司、京东方科技集团股份有限公司、潍柴动力股份有限公司、新华三技术有限公司、北京经纬恒润科技股份有限公司、华为技术有限公司、广联达科技股份有限公司、北京轩宇信息技术有限公司、科大讯飞股
10、份有限公司、北京字节跳动网络技术有限公司、天翼云科技有限公司、中国民航信息网络股份有限公司、北京奕斯伟计算技术有限公司、中核控制系统工程有限公司、北京奇艺世纪科技有限公司、中国东方航空股份有限公司、黑龙江邮政易通信息网络有限责任公司、中国太平洋人寿保险股份有限公司、云智慧(北京)科技有限公司。本标准主要起草人：胡延军、任晶磊、唐洪山、茹炳晟、马骏、郑伟娜、刘建军、陈敏华、张立明、葛田子、吕婧、胡晓天、高杨、徐延明、詹庆才、叶文华、陈晨、曾嵘、郭炜、付鸿飞、唐斐、钱峰、马国伟、张伟军、廖君仪、张茜、刘兴义、杨兰、刘毅、孟玉旺、徐毅、李强、吕芳、孙春艳、钟欣、董璐、林一鸣、孙静、宋晓旭、王冬、兴连
11、博、陈连生、张瑜瑾、李景哲、高驰涛、蔡斌哲、关钦杰、李隽。T/IQA 15-2022 1 软件研发效能度量规范 1 范围 本标准提供了软件研发效能的基本框架、度量指标模型、基本度量指标集和视图应用。本标准所列的度量并非一个完整集合，使用者可以从本标准中选取合适的度量，或使用本标准未包含的其他度量。本标准适用于各类软件研发过程和组织，但并非每种度量均适用。本标准适用于软件研发组织的以下活动：(1)打造并展现软件研发和交付水平；(2)通过持续改进提升软件研发和交付水平；(3)寻求软件研发提供商并要求其确保软件交付水平；(4)建设软件研发效能数据和分析平台；(5)进行软件研发效能度量培训及审计。本标
12、准适用于以下使用者：(1)软件研发组织管理者；(2)软件研发组织中的产品经理、项目经理、技术经理、测试经理等；(3)软件产品和服务的开发者；(4)软件研发效能平台的开发者；(5)软件研发效能分析师、咨询师、审计师、培训师等。2 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，仅注日期的版本（包括勘误的内容）适用于本标准。凡不注日期的引用文件，其最新版本（包括所有的修改单）适用于本标准。GB/T 5271.1 信息技术 词汇 第 1 部分：基本术语 GB/T 5271.20 信息技术 词汇 第 20 部分：系统开发 GB/T 11457 信息技术 软件工
13、程术语 3 术语和定义 下列术语和定义适用于本标准。3.1 组件 component 在一个特定的分析层次上考虑的系统中带有分立结构的实体。诸如一个组合或软件模块。GB/T 184922001，定义 3.1 3.2 数据 data 信息的可再解释的形式化表示，以适用于通信、解释或处理。ISO/IEC 25012:2008，定义 4.2 3.3 信息需要 information need 管理目的、目标、风险和问题所需的洞察。ISO/IEC 15939:2007，定义 2.12 T/IQA 15-2022 2 3.4 软件产品 software product 一组计算机程序、规程以及可能的相关
14、文档和数据。GB/T 85662007，定义 3.27 3.5 软件服务 software service 实施与软件产品有关的活动、工作或义务，比如软件开发、维护和运作。GB/T 85662007，定义 3.28 3.6 软件组织 software organization 以软件研发、交付和运营为主要业务的组织，包括：项目型组织、产品型组织等，通常以产品中心、研发中心、开发中心、交付中心、运营中心等形式存在，涉及应用软件、系统软件、平台软件、嵌入式软件的研发、交付和运营业务等。3.7 软件绩效改进 software performance improvement 绩效改进能力是软件组织的关
15、键能力，通常以 EPG、PMO、产品管理中心、质量管理中心等职能运行，采取强矩阵、弱矩阵、平衡矩阵等形式履行管理和改进职责，并针对人员能力、工具/平台、过程/子过程的进行持续改进以提升软件研发、交付和运营的卓越能力。4 软件研发效能度量框架 软件研发效能度量框架（以下简称度量框架），规定软件研发效能度量的基本构成及其相互关系，用于指导对研发效能度量的全面理解。4.1 软件研发效能 软件研发效能是持续快速交付高质量有价值的软件产品和服务的能力，包括效率（efficiency）、效果（effectiveness）和卓越能力（excellence）三个方面。4.1.1 效率 效率要求软件研发过程能够
16、多、快、好、省地交付产品和服务，即价值高、速度快、质量好、成本低。4.1.2 效果 效果要求软件研发过程交付的产品和服务能够达成用户和业务的目标。4.1.3 卓越能力 卓越能力要求软件研发过程以健康的、可持续的方式交付产品和服务。4.2 度量框架 软件研发效能度量框架由研发效能目标（E3CI objectives）、认知域（cognition area）和改进域（improvement area）三部分构成。研发效能目标，即研发效能定义的效率（efficiency）、效果（effectiveness）和卓越能力（excellence）（参见 4.1 节），统称为“E3”；认知域是认知研发效能主
17、要方面的度量领域；改进域是对改进本身进行度量的领域，三个部分共同构成 E3CI 软件研发效能度量框架，如图 1 所示。T/IQA 15-2022 3 图 1 软件研发效能度量框架概要图 4.2.1 认知域 4.2.1.1 交付价值 交付价值（delivery value）认知域反映软件研发过程满足用户或业务目标的程度。4.2.1.2 交付速率 交付速率（delivery velocity）认知域反映软件研发过程交付产品和服务的快慢程度。4.2.1.3 交付质量 交付质量（delivery quality）认知域反映软件研发过程交付的产品和服务满足用户和业务需求的程度。4.2.1.4 交付成本
18、交付成本（delivery cost）认知域反映软件研发过程交付产品和服务的开销。4.2.1.5 交付能力 交付能力（delivery capability）认知域反映软件研发过程交付产品和服务的可持续性。4.2.2 改进域 改进域主要侧重持续改进（continuous improvement），反映在认知的基础上进行研发效能改进过程的成效。改进过程宜针对交付价值、交付速率、交付质量、交付成本、交付能力等领域进行系统或专项提升，以达成效率、效果和卓越能力等效能目标。4.3 度量方法 软件研发度量应按照确立目标和范围、选取度量指标、实施度量和改进三个步骤进行。4.3.1 确立目标和范围 软件研发
19、效能度量应首先明确度量的目标，围绕目标提出问题，并进一步展开度量，防止贪大求全。目标的设立可从研发组织面临的挑战入手，宜在研发组织主要管理者或领导者间达成共识。度量目标应聚焦，可根据其重要性、迫切性和可行性对目标进行排序。度量的范围由目标针对的团队、项目或周期T/IQA 15-2022 4 确定，分别是从人、事、时间维度上界定度量的范围。4.3.2 选取度量指标 软件研发组织可根据度量目标选择认知域，并从认知域中选择相应指标；如果目标是研发效能改进本身，应选择相应的认知域和改进域及相应指标。软件研发效能的提升，依赖于组织认知的提升，只有对组织现状及其与目标的差距有充分的认知，才能够实施改进。确
20、定认知域/改进域后，应从目标需要回答的问题或信息需要出发，选取能够回答当前问题或者满足当前信息需要的指标；在选取度量指标时，应充分考虑软件组织的现状和约束，可对度量指标进行优先级排序或基于权重进行计算，适当的变通是贴合实际和有效运用的要点。图 2 展示研发效能度量框架展开后各认知域/改进域中的主要指标，并对应于或者横跨研发的需求、设计、开发、测试、发布和运营等各个阶段，各指标归属于其主认知域或改进域，同时也反映其他域的必要信息。认知域需求交付周期里程碑偏差测试一次通过率代码重复率静态扫描缺陷密度圈复杂度测试缺陷密度提测成功率发布成功率流负载项目/产品.版本构建频率构建时长构建成功率测试自动化率
21、 部署时长部署频率开发交付周期需求吞吐量（流速率）流效率需求按时交付率设计评审通过率代码开发当量代码提交频率用例评审缺陷密度缺陷逃逸率交付速率端到端快速交付交付质量端到端高质量交付交付能力持续交付能力代码走查缺陷密度代码评审轮数组件复用率组件按时交付率需求评审通过率实践域交付价值持续交付价值交付成本控制交付成本用户增长率市场占有率产品价值达成率客户满意率营收增长率工作量分布技能指数人员流动率人力成本改进效果评价实践域过程指标结果指标图例改进域需求变更率接口变更率需求评审缺陷密度演示频率设计评审缺陷密度线上故障数平均故障间隔时长平均故障修复时长挣值预算执行率返工率部署成功率回滚成功率发布频率价值
22、流需求颗粒度测试覆盖率用例评审通过率缺陷重开率环境整备时长专项改进完成率审计问题关闭率审计频率过程符合度非人力成本客户问题响应时长客户问题解决时长系统可用性发布时长 图 2 软件研发效能框架展开图 4.3.3 实施度量和改进 软件组织在确定度量指标和范围后，进入度量实施阶段，并可针对性地进行改进。根据指标的数据来源、适用范围、适宜频率和计算方法，软件组织应进行数据收集、数据质量校验、数据分析，并合理展示度量指标。相对于人工输入，度量数据宜更多采用代码或工具平台中存留的数据，使之更具客观性，提升数据质量并降低度量成本。度量指标分析可采用基本的分析图表，如：散点图、直方图、箱线图、饼状图、柱状图、
23、趋势图、雷达图、累积图等；也可进一步采用统计技术，如描述统计、相关分析、方差分析、回归分析、控制图、T/IQA 15-2022 5 能力分析、假设检验等。本规范对基本度量指标进行了定义和说明，筛选并包括了影响软件研发的主要因子。软件组织应根据自身所处发展阶段、现状和约束，针对性地选择度量指标，应用基本或高级的数据分析技术，进行数据分析和挖掘，以满足基本分析决策，或通过建模仿真和优化以实现量化的业务目标。4.4 度量原则 软件研发效能度量应遵循适用性、系统性、可靠性和持续性原则。4.4.1 适用性 软件研发效能度量应根据软件研发组织的目标和现状选择度量的范围和方法。适用性包括两个方面：一是软件研
24、发组织应根据改进的目标，选择适用的度量范围和指标，而不应在目标不明确的情况下，盲目过度实施度量；二是软件研发组织应根据软件交付模式、软件周期模型、软件组织特点等，选择适用的度量范围和指标。4.4.2 系统性 软件研发效能度量应根据度量的目标，选取全面反映认知并且相互关联的指标。系统性包括两个方面：一是指标能够反映度量目标的主要方面，满足认知或改进需要；二是指标之间应能够相互印证或制约。度量的系统性可有效防止研发组织面向单一指标优化，造成局部最优而整体不优，从而影响研发效能整体提升。4.4.3 可靠性 软件研发效能度量的可靠性源于数据的及时性、真实性和客观性。可靠性包括三个方面：一是数据是否及时
25、采集、及时分析，并支持及时采取措施；二是数据是否是真实数据，人工填报数据，往往真实性会打折扣；三是数据的客观性是否可通过多视角相互校验和排查予以保证。4.4.4 持续性 研发效能改进通常无法一蹴而就，宜基于系统视角、采用迭代的方式组合实施。每个迭代应聚焦少数重点目标，通过根因分析寻找并确定改进方案、实施专项改进、度量和验证改进效果，并沉淀最佳实践。如果改进效果达到预期，下一轮迭代可选取其他目标；如果改进效果未达预期，应改度量以反映更本质的问题，并支持下一轮迭代的目标设定和改进。5 软件研发效能度量指标 5.1 度量指标模型 5.1.1 数据集 数据集是来自不同数据源的数据集合，完整的数据集合亦
26、称为数据湖。5.1.2 指标 指标是用于解决研发实践问题、获得研发效能认知、产生研发效能价值而定义的可量化的概念和相应的计算方法。一个指标的数值可依赖其他指标的数值进行计算，依赖其他指标的指标称为衍生指标，无依赖的指标称为基础指标。5.1.3 度量 度量是将指标应用于特定研发数据集的过程。度量计算出的数值结果，称为度量值。对于研发数据集 D，指标的度量 m(D)为 T/IQA 15-2022 6 m(D)=f(D，M(D)，其中，D 为数据集，M 为其依赖的其他度量值的集合，f 为指标的计算方法；对应基础指标的 M 为空集。5.1.4 视图 视图是基于研发数据集，将指标的度量值应用于实际场景的
27、展示。5.1.5 模型定义 软件研发效能度量指标模型是基于研发数据集、选择指标、计算并展示结果，支持分析和决策的最佳实践范式。图 3 研发效能度量指标模型 端到端的研发价值流（value stream）是效能度量的基础和出发点。基于价值流认知，用户提出不同的信息需要，从而选择指标和实施度量，并使用视图整合强相关的度量值进行分析与决策，以促进系统思考、平衡和决策。5.1.6 指标定义 一个度量指标的定义和说明通常包括如下部分：表 1 度量指标定义 指标名称 指标概念的简要名称。起名应遵从言简意赅、避免歧义、尊重习惯等原则。概念描述 对指标含义、目的和作用的描述。计算方法 指标度量值如何进行计算。
28、计量单位 指标度量值计算时需要的计量。T/IQA 15-2022 7 分类 度量主要反映的认知域或改进域，包括交付价值、交付速率、交付质量、交付成本、交付能力和持续改进；以及指标涉及的典型生命周期阶段，包括需求、设计、开发、测试、发布、运营中的一个或多个等。补充说明 需要补充说明部分，利于对指标的深入理解和应用，可包含数据展现图表示例，以及在实施中应注意或考虑的问题等。5.2 度量指标集 度量指标集是基于 E3CI 研发效能度量框架，按认知域和改进域汇总的度量指标集合，包括指标名称、基本定义和应用说明等基本信息。软件组织可根据需要，快速查找适用的度量指标，特别是基于系统思维，选择多个相关或约束
29、的度量指标，以利于综合分析和支持决策。选择的度量指标的定义和说明，可通过查阅附件 A 中相应的指标定义获取以供参考。表 2 度量指标集 认知域/改进域 指标名称 单位 基本定义 应用说明 交付 价值 产品价值 达成率%产品对用户的需求的满足度。指标反映了是否在用户规定的时间内完整、正确的完成了用户提出的需求。客户满意率%产品交付满足客户/用户需要和期望的程度。指标反映了客户/用户的综合体验，通常是关键业务指标之一。客户问题 响应时长 时长 客户问题响应时间与客户问题提出时间之差。指标反映了响应客户的问题的及时性，是 SLA 的关键指标，也是客户体验的关键指标之一。客户问题 解决时长 时长 客户
30、问题解决时间与客户问题首次响应时间之差。指标反映了解决客户问题的及时性，是 SLA 的关键指标，也是客户体验的关键指标之一。用户增长率%统计范围内，增加的用户数量相对于用户总量的比例。指标反映了企业的产品能力和运营能力。市场占有率%统计范围内,企业销售或运行的产品台套数占市场整体的比例。指标反映了企业在市场上的产品竞争力和销售能力。营收增长率%统计范围内，增加的营收相对于总营收的比例。指标反映了企业销售和经营的能力。交付 速率 需求 交付周期 天 从需求创建到发布的时长。反映整个团队（包括业务、产品、设计、开发、测试、运营等各职能）针对客户问题或业务机会的交付速率，也是团队协作能力的体现。开发
31、 交付周期 天 需求被研发团队确认，到完成开发、测试、业务验收，达到可上线状态的时长 指标反映了研发团队的交付速率，依赖需求拆分和版本规划以及研发、测试和业务团队的分工协作。T/IQA 15-2022 8 里程碑偏差 天 在统计范围内，里程碑实际完成时间与计划完成时间之差。指标反映了项目进度以及里程碑的计划和控制能力。需求吞吐量（流速率）个 在统计范围内完成交付的需求数量。指标反映了需求交付的产能或产量。流效率%研发活动时间占研发活动时间与等待时间之和的比例。指标反映了研发活动协同流转的效率，通过持续改进，可减少等待、提高效率，是关键改进指标之一。需求颗粒度 功能点/故事点 单个需求的大小或规
32、模。指标反映了需求进行设计开发的复杂度。通过需求颗粒度的估算和核算，逐步提高对需求粒度的把握，有利于提高计划可行性、资源利用率、交付速率等。需求按时 交付率%在统计范围内，需求按时交付的数量占交付需求总数的比例。指标反映了需求按期交付能力，也一定程度反映了计划能力。需求变更率%在统计范围内，需求确认后发生变更的数量占已确认需求总数的比例。指标反映了需求理解及变更控制能力，经确认后发生的需求变更尽管难以完全避免，但其变更对项目进度、质量、成本等往往带来不利影响。组件按时 交付率%在统计范围内，组件按时交付的数量占交付组件总数的比例。指标反映了组件按期交付能力，也一定程度反映了计划能力。组件复用率
33、%在统计范围内，复用组件的数量占组件总数的比例。指标反映了组件的功能、性能、质量和可扩展性，也一定程度上反映了设计能力。接口变更率%在统计范围内，接口确认后发生变更的比例。指标反映了接口设计及变更控制能力。约定的接口如果发生变更通常会对其他组件产生影响，并带来额外的成本或返工。代码 开发当量#对每次代码提交所做的逻辑修改的量化。指标反映了代码修改及其逻辑复杂度，不受源代码级噪音（如代码风格、重复、自动生成、字面修改等）的影响。代码 提交频率 次/时长 在单位时间内，代码版本控制系统记录的代码变更次数。指标反映了代码开发的活跃度，同时可用于提倡小步提交。测试一次 通过率%在统计范围内，由开发提交
34、测试的版本一次性通过测试的比例。指标反映了开发质量，测试一次通过率的提高利于减少返工和提高交付速率。交付 质量 演示频率 次/时长或版本 单位时间或版本演示的次数。指标反映了与需求方进行持续沟通并获取反馈的程度，有助于拥抱变化，降低风险。需求评审 缺陷密度 个/需求颗粒度 在需求评审中发现的单位需求规模的缺陷数。指标反映了需求评审的效果。T/IQA 15-2022 9 需求评审 通过率%在统计范围内，评审通过的需求数占提交评审的需求总数的比例。指标反映了需求定义和需求理解的质量，利于减少需求返工和提高交付速率。设计评审 缺陷密度 个/设计规模 在设计评审中发现的单位设计规模的缺陷数。指标反映了
35、设计评审的效果。设计评审 通过率%在统计范围内，评审通过的组件数占提交设计评审的组件总数的比例。指标反映了组件及接口定义和设计的质量，利于减少返工和提高交付速率。代码重复率%在统计范围内，重复的代码量占代码总量的比例。指标反映了代码的可维护性。重复代码宜进行抽象和复用，以利于减少缺陷，更快地进行交付。圈复杂度#软件代码中独立线性路径的数量。指标反映了系统中控制或信息流的复杂度，有利于降低测试和维护的难度。静态扫描 缺陷密度 个/代码规模 静态扫描发现的单位代码规模的缺陷数。指标反映了编程规范的符合度和代码质量。代码走查 缺陷密度 个/代码规模 代码走查发现的单位代码规模的缺陷数。指标反映了代码
36、质量及走查效果，有利于及早发现缺陷，减少返工。代码 评审轮数#一次代码合并或提测经过的代码评审的轮数。指标反映了代码合并或提测的质量。控制代码评审轮数有利于提高代码开发者的责任心和和质量意识。提测成功率%在统计范围内，由开发提交的满足测试准入条件的版本的比例。指标反映了开发质量和开发过程的规范性，提高提测成功率高利于减少返工、减少测试周期和提高交付速率。用例评审 缺陷密度 个/用例数 在统计范围内，测试用例评审发现的缺陷与测试用例数的比例。指标反映了测试用例的质量，可按缺陷类型、严重程度进行统计，宜注意和软件缺陷进行区分。用例评审 通过率%在统计范围内，评审通过的测试用例数占提交评审的测试用例
37、总数的比例。指标反映了编写测试用例和理解需求的质量，有利于减少返工和提高交付速率。测试覆盖率%被测试覆盖的条目占总的需要测试条目的比例。指标反映了测试对需求或代码的覆盖程度，利于保证测试质量。条目如果是代码行，就是测试代码覆盖率；条目如果是需求，就是测试需求覆盖率。测试 缺陷密度 个/代码规模 测试时发现的单位代码规模的缺陷数。指标反映了测试的结果、用于评估开发的质量。T/IQA 15-2022 10 缺陷逃逸率%统计范围内，线上发现的缺陷数量与检出缺陷总数量的比值。指标反映了缺陷检出的效果，利于需求、设计、开发、测试团队进行针对性改进。发布成功率%在统计范围内，成功发布次数占发布总次数的比例
38、。指标反映了发布过程和脚本质量及生产环境的一致性、稳定性。系统可用性%在统计范围内，系统可用时长占系统全部运行时间的比例。指标反映了系统的质量和可靠性，有利于衡量设计、开发和运维的质量。线上故障数#系统运行时出现的故障数量。指标反映了系统质量水平。平均故障 间隔时长 时长 在正常运行过程中，系统两次相邻故障之间的平均时长。指标反映了线上系统的可靠性，有助于预测系统在下一次计划外故障发生之前可以运行多长时间。平均故障 修复时长 时长 修复系统故障并将其恢复到完整功能所需的平均时长。指标反映了线上故障恢复能力，通过缺陷快速修复或回滚降低平均故障修复时长是改进的重点之一。交付 成本 挣值 分值 已完
39、成工作的成本和预算的比值，基于组件的WBS。指标反映了成本策划和控制能力，利于及早识别成本超支和进行调整。预算执行率%在统计范围内，实际支出资金与实际到位资金的百分比 指标反映了项目资金使用效率和进程。返工率%花费在返工上的工作量占总工作量的比例。指标反映了由于缺陷修复、需求理解偏差等原因而产生的额外工作量投入。人力成本 货币 软件研发各活动的工作量投入按人员费率折算的总成本。指标反映了软件研发活动的人力投入。非人力成本 货币 直接用于项目的设备、培训、差旅等及分摊费用的总和。指标反映了软件研发活动的非人力投入。工作量分布%工作量按选定维度的统计值和分布比例。指标反映了企业交付过程中不同维度下
40、的工作投入比例，可支持优化不同维度的工作分配。技能指数 分值 对员工技能的分值。指标反映了员工的知识、经验、能力等级，对人员工作分配和成本有显著影响。人员流动率%统计范围内，离职、调入或调出员工与员工总数的百分比。该指标反映企业组织与员工队伍的稳定性。除了整体计算，宜对骨干员工和新员工进行分类统计。交付 能力 流负载#研发过程中正处于设计、开发、测试、发布中的需求数量。指标反映了设计、开发、测试、发布各环节的平衡状态，分析流负载利于识别瓶颈和积压。T/IQA 15-2022 11 构建频率 次/时长 单位时间内软件进行统一编译构建的次数。指标反映了持续构建的能力，有助于及早发现和修复缺陷。构建
41、时长 时长 软件单次统一编译构建的时长。指标反映了系统复杂度和基础设施等状况，过长的时间应考虑编译构建的优化。构建成功率%在统计范围内，统一编译构建成功次数占统一编译构建总次数的百分比。指标反映了代码质量、编译环境的稳定性。缺陷重开率%在统计范围内，重新打开的缺陷占总缺陷的比率 指标反映了缺陷修复的效果，重开率高应触发针对性的改进。测试 自动化率%自动化测试用例占测试用例总数的百分比。指标反映了自动化测试的能力，有助于提高测试效率和快速交付能力。环境 整备时长 时长 环境整备所需的时长。指标反映了环境的复杂度和基础设施等状况，过长的时间应考虑环境的优化。部署频率 次/时长 在单位时间内，软件进
42、行统一部署的次数。指标反映了持续部署的能力，有助于及早发现和修复缺陷以及环境的不一致性。部署时长 时长 软件单次统一部署的时长。指标反映了系统复杂度和基础设施等状况，过长的时间应考虑软件部署的优化。部署成功率%在统计范围内，统一部署成功次数占统一部署总次数的百分比。指标反映了部署脚本质量和部署环境的一致性、稳定性。回滚成功率%在统计范围内，回滚成功次数占回滚总次数的百分比。指标反映了回滚脚本质量和基础设施的能力，回滚成功率是降低持续交付风险的关键指标。发布频率 次/时长 在单位时间内，软件发布的次数。指标反映了软硬件基础设施、交付过程、研发团队质量和效率等多种能力。发布时长 时长 软件单次发布
43、的时长。指标反映了系统复杂度和基础设施等状况，过长的时间应考虑软件发布过程的优化。持续改进 改进效果 评价%改进前后选定度量数据的变化比例。指标反映了专项整改的量化的效果。专项改进 完成率%统计范围内，专项改进项目的完成比例。指标反映了专项改进在公司级、部门级、产品线的实施情况。审计问题 关闭率%统计范围内，审计发现问题已关闭的比例。指标反映了及时处理并解决审计所发现问题的能力。审计频率 次/时长 在单位时间内，内外部审计的次数。指标反映了外部合规和内部管控的力度。过程符合度%统计范围内，体系和成果物审计合规的比例。指标反映了制度和规范的落实情况。6 软件研发效能视图应用 T/IQA 15-2
44、022 12 6.1 视图模型 在实际应用中，软件研发效能度量指标通常需要组合使用。使用 E3CI 视图模型（如下图所示）将有助于系统地分析度量数据，以支持业务决策，主要步骤如下：1.确定使用角色，考虑使用者和汇报对象，可包括管理者、产品负责人、技术/测试负责人、项目负责人等；2.确定关注视角，可包括业务、产品、项目、工程等；3.确定视图卡片的数量及其关联关系，以利于系统分析；4.针对每一个视图卡片，明确其意图、所聚焦的问题、关键指标、相应图表及分析方法；5.进行系统分析，以支持业务决策。图 4 度量视图模型 6.2 视图卡片 视图卡片是视图模型在实践中的具体应用。根据业务实际需要，可将相关度
45、量指标组合成一个或多个视图卡片，通过多维度分析回答遇到的问题，以支持决策和采取措施。相应的视图卡片可嵌入 IT 系统、分析报告或 PPT 中，支持向相关角色汇报。T/IQA 15-2022 13 图 5 视图卡片应用示例 以项目经理站在项目视角，进行项目进展汇报为例，视图卡片应用示例如上：主要意图：汇报项目进展和问题，以支持项目级决策和采取纠正措施；聚焦问题：1）项目能否按时交付？2）产品质量如何？3）存在哪些问题？主要指标涉及：1）项目进度；2）开发进展；3）测试进展；4）缺陷修复进展；分析方法：1）根据项目特点，从进度、质量、缺陷多维度进行分析；2）关注计划、时间和偏差，必要时，进行根因分
46、析；3）和项目目标进行比较，和历史基线进行比较，以便作出决策；数据分析及结论：版本 1 进度延迟，问题主要集中在编码和单元测试，同时委外定制的数据转换软件进度滞后，项目进度（甘特图）如下图所示：T/IQA 15-2022 14 测试基本按计划执行，但测试通过率低，11 月初表现尤为明显；目前缺陷修复速率远低于缺陷检出速率，如测试进展（按用例）报告和缺陷报告所示：延迟主要集中在组件编码和测试阶段，在 11 月初表现明显。目前项目组进度赶上来了，但无暇快速修复发现的缺陷，如开发进展（按组件）报告所示。需要进一步进行根因分析，可能的原因包括计划安排不合理、人员能力不足、缺乏自动化工具支持等，以便针对
47、性地采取纠正措施。T/IQA 15-2022 15 附录 A(资料性)指标定义 A.1 交付价值表 A.1.1 产品价值达成率 指标名称 产品价值达成率 概念描述 产品价值达成率是产品对用户需求满足的程度。指标反映了是否在用户规定的时间内完整、正确的完成了用户提出的需求。产品价值达成率是由客户或业务代表进行打分的方法进行计算得出。应在策划/需求澄清环节和产品交付/演示环节分别评分。计算方法 产品价值达成率=（产品价值评分*权重）/（需求价值评分*权重）其中需求价值评分通常在策划/需求澄清环节，产品价值评分通常在产品交付/演示环节，分别由客户或业务打分。需求概述 策划/澄清 （1-10）交付/演
48、示 （1-10）权重 需求 1 8 5 10.0 需求 2 9 10 3.0 需求 N 10 6 1.0 加权分值 117 86 达成率 73.5%计量单位%分类 认知域/改进域 交付价值 阶段 需求、发布 T/IQA 15-2022 16 补充说明 随着多版本的持续交付，产品价值达成率指标体现了团队交付的产品或服务的时序变化。如果与目标值/基线值比较，则能突出产品价值的变化，利于业务决策。产品价值达成率，可以按项目、产品、产品线、部门进行统计和分析，目标值设定可根据实际业务需要设定，其变化趋势有助于支持决策和改进。表 A.1.2 客户满意率 指标名称 客户满意率 概念描述 客户满意率是产品交
49、付满足客户/用户需要和期望的程度。指标反映了客户/用户综合体验，通常是关键业务指标之一。计算方法 客户满意率=(分项得分*权重)/(分项总分*权重)客户满意度分值，通常包括很满意、满意、基本满意、不满意，亦可按对应取值或取值范围进行打分，如下表所示：定序取值 对应取值 取值范围 很满意 100 90-99 满意 80 80-89 基本满意 60 60-79 不满意 0 0-59 客户满意度调查，应设定几个分项，针对各分项应设定相应权重。分项的设立可以按认知域定义，也可以用需求实现、产品质量、进度控制、服务能力、管控能力等更通俗的用词定义。计量单位%分类 认知域/改进域 交付价值 T/IQA 1
50、5-2022 17 阶段 发布、运营 补充说明 为了充分利用客户满意度数据，应收集必要的数据属性，如所属：部门、产品线、产品、项目、版本、满意度调查时间等，以便进行分析和改进，示例如下：示例 1：客户满意率 vs.交付版本，展现了随着各个版本的交付，客户满意度调查的结果的变化。示例 2：客户满意率 vs.交付质量得分。使用时序分析，针对总分（客户满意率）和分项（如：交付质量得分），进行比较，显示交付质量得分的变化对客户满意率的影响。在客户满意度调查中，应遵循及时有效原则，如：在发布后及时推送并获取客户满意度反馈。表 A.1.3 客户问题响应时长 指标名称 客户问题响应时长 概念描述 客户问题响