软件工程原理与实践（硕士）课件 11 软件研发效能度量

高级软件工程

SoftwareEngineering软件研发效能度量为什么关注研发效能在数字化的时代，研发效能已经成为一家科技公司的核心竞争力在软件研发领域，能够有助于效能提升的方法论和实践一直在快速发展比如，敏捷开发方法已经诞生了二十年，DevOps也已经发展了十多年。但是，我们经常遇到的一种现象是，当一个组织或者团队在消耗了大量的“变革”时间、花费了大量的人力资源和成本后，却无法有效回答一些看似非常基本的问题：我们的研发效能到底怎么样？可否量化？比所在行业平均水平、比别的公司、比别的团队更好还是更差？研发效能的瓶颈点和问题是什么？在采纳了敏捷或DevOps实践之后，有没有效果？有没有实质上的提升？下一步应该采取什么样的行动以继续优化效能？996Vs955,哪个更能产生效能？……2研发效能度量软件工程数字化，将大数据技术用于软件研发中。软件企业的数字化转型让效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和改善效能。3研发效能度量的挑战软件研发过程中的可视性差软件研发过程中工作切分的随意性敏捷研发过程中工作是并行开展的402-软件度量过程01-软件度量和GQM模型03-研发效能度量指标504-研发效能度量的反模式和原则“没有度量就没有改进”--PeterDrucker“没有度量就没有控制”--TomDemarco6软件度量的价值认知：认知和理解过程、产品、资源和环境，建立比较基线；评估：比较同步跟踪软件项目的状态，管理进展；及时发现实施和计划的偏差，评估质量目标的达成情况，以及技术和过程的改进对产品和过程的影响；预测：是建立在适当资源下，达到成本、进度和质量目标的计划的基础。也可根据度量的实证，预测项目发展的倾向，估计分析风险，做出设计／成本权衡；改进：帮助识别问题根源，判断可以改进的机会，交流改进的目标和理由等;调整资源分配等。7更好地管理软件开发与运维度量的定义度量关注的是在一定规则下获取关于实体属性的信息一个实体可以是一个实物，如软件产品；或者是一个事件，如软件测试；属性是我们所关注的实体的特征或特性．8度量的分类主观/客观objective/subjective绝对/相对absolute/relative动态/静态dynamic/static预测/解释predictive/explanatory过程/产品/项目/资源process/product/project/resource9按度量对象分产品度量，是以某种方式实现软件过程中所指定的产品指标的合理量化，从而衡量软件工作产品的规模、质量和复杂度等属性，如代码行数、McCabe圈复杂度、模块的耦合度、测试覆盖率、用户平均响应时间等。过程度量，是以某种方式实现所指定的过程能力指标的合理量化，从而衡量组织级别上软件过程的质量、成本、盈利、投资回报率和生产率等属性，如需求变更率、缺陷的修复成本占总开发成本的比率、生产率等。项目度量，是以某种方式实现软件项目指标的合理量化，从而衡量项目的质量、成本、盈利、生产率和进度等属性，如项目质量目标的达成率、人均开发效率等。资源度量，是以某种方式实现资源指标的合理量化，从而衡量资源的利用、胜任力、分布合理性等属性，如程序员的能力、工具的使用效率、库存周转率等。10研发效能是综合性度量度量模型：GQM11GQM（Goal-Question-Metric）模型是基于这样的假设：对一个机构而言，度量是应当有目的性的，即它应首先定义其自身或该机构内某个项目的目标，根据这些目标去跟踪那些定义这些目标的数据，最后提供一个框架用于解释这些数据与所确定的目标之间的关系。GQM度量模型第一层：概念层（目标G）。包含一个目标、目标涉及的度量对象及其属性等信息。目标所涉及的对象类型有：产品（Product）：软件生存期中产生、发布的各种软件产品、文档等；过程（Process）：与软件生产相关的各种活动；资源（Resourse）：被过程所利用，以便产生其输出产品的所有对象，如人、硬件、软件、办公空间等。第二层：运作层（问题Q）。问题是有上一层的目标细化而来，用于描述实现该目标的方式。一个目标能细化出多个问题。第三层：量化层（度量M）。一组以量化的方式回答上层问题的数据。这组数据可以是：客观的：若该组数据全部是通过对对象的测量获得的，而不是以什么人的主观认识取得的；主观的：若该组数据是通过实测和人们的主观判断获得的。举例目标：分析开发过程中的软件错误，以便找出降低成本的可能点问题：Q1：在哪些地方出现了错误？Q2：这些错误的来源在哪里？Q3：发现的错误是否得到更改？Q4：从发现错误、确认错误、到更改错误所需要的时间？Q5：从过程改进小组的角度看，目前的纠错、改错过程是否合理？度量：(Q5得到的度量)M51（错误延迟）=M52（纠错人工）=1302-软件度量过程01-软件度量和GQM模型03-研发效能度量指标1404-研发效能度量的反模式和原则软件度量过程15步骤1确立和维持度量承诺接受度量需求度量的范围定义为组织单元，可以是单一项目、功能领域、整个企业、单一场所或多场所的组织。由组织单元确定对度量过程的资源承诺以及维护这种承诺的意愿。分配资源度量发起者把度量职责分配给有能力胜任的人，胜任力为度量原理，以及数据收集、数据分析和信息通报等知识。所涉及的角色至少包括度量用户和度量分析员。度量发起者应确保资金和人员等资源供给。16步骤2准备度量定义度量策略描述度量组织的特性确定度量的信息需求，例如“如何评价设计过程中的软件产品质量？”从业务目标出发，根据已确定的信息需求，按GQM确定度量指标定义数据收集、分析和报告规程明确度量评价的准则识别和策划度量工具评审和批准度量计划获取并部署支持技术，包括度量工具和培训课程等17Metric示例18建议：从研发工具中自动收集数据从项目管理工具、需求管理工具、版本管理工具、IDE和代码、评审工具、测试工具、持续集成工具、运维工具等自动收集数据采用埋点方式收集数据从database/file,trace,log等收集数据19数据集成，构建软件工程关联数据（linkeddata）20步骤3实施度量把数据的产生、收集、分析与报告过程与相关的软件过程进行集成收集、存储和验证数据分析数据，得到度量结果记录并通报度量结果21分析技术22可视化展示23步骤4评价度量评价度量信息和度量过程通过审核，对度量信息（例如度量指标、数据、规程、方法和工具等）和度量过程进行评价，识别它们的弱项和强项。把通过评价得到的经验教训存入度量经验库。识别潜在的改进契机例如软件规模度量指标从代码行变为功能点，重新分类软件缺陷等。24建立组织级研发效能度量体系2502-软件度量过程01-软件度量和GQM模型03-研发效能度量指标2604-研发效能度量的反模式和原则3+1度量指标体系27研发效能度量指标集28阿里巴巴的效能度量指标29阿里巴巴的“2-1-1”愿景目标30蚂蚁集团的效能度量31Facebook的效能度量32DevOps全球调查报告中的度量指标StateofDevOpsReport讨论：设计软件度量指标项目组A在最终的系统测试时发现了384个bug,项目组B则发现了184个。要决定哪个项目组发现bug更有效，应采用哪些度量？

代码评审是软件质量管理的最佳实践，现需要设计代码评审的度量指标，度量目标为：推进代码评审的实践，从而提升软件的质量代码评审时，评审者每分钟骂脏话的次数？34代码评审的度量指标3502-软件度量过程01-软件度量和GQM模型03-研发效能度量指标3604-研发效能度量的反模式和原则古德哈特定律

当某个度量变成了目标，它便不再是一个好的度量。37“千行代码缺陷率”引发的“血”案从千行代码缺陷率来看工程师A属于正常水平，无功也无过。工程师B会因此受到表扬？不一定！他很有可能会被判定为没有进行充分的测试，被责令加强测试。工程师C必然会遭受批评，被责令改进代码质量。基于千行代码缺陷率对这三个工程师的评价显然是有失公允的。38需求变更后…软件需求发生了变化……工程师B和工程师C的代码具有较好的可维护性，可以方便地变更，所以很快完成变更任务，只引入了少量的新缺陷。工程师A的代码由于缺乏设计模式的支持，大量代码需要重写，同时还会引入了很多新缺陷。度量结果：由于代码量够大，工程师A的千行代码缺陷率依旧在平均范围内，所以依然无功也无过工程师B和工程师C则继续得到差评，因为他们的工作看起来太简单了，明显工作量“不饱满”。39结论千行代码缺陷率的度量体系是失败的，其所传达的价值观与我们所期望的背道而驰从工程师B的遭遇可以看出“我们不相信你能够写出高质量的代码”从工程师C的遭遇可以看出“我们不鼓励技术提升阶段的阵痛”从工程师A那边看到的是“我们欢迎那些平庸的程序员”40陷入“算法对抗”的窘境程序员：稀释代码采取稀释代码的方式来降低千行代码缺陷率，而不是实际去减少缺陷数量。因为与减少缺陷数量相比，直接稀释代码（比如：一行写成多行、括弧必须换行、多写注释、多加空行等）的难度更低，而且更可控。度量员：改进度量算法，用基于AST的开发当量代替代码行数程序员：通过人为增加开发当量（比如减少封装等）来降低代码缺陷率度量员：再次改进度量算法……41正确的做法是什么呢？研发效能度量的反模式把度量和KPI进行绑定片面性的度量数据采集依赖于人工录入在没有任何明确改进目