软件开发项目指标_重要的软件开发指标

软件开发项目指标

作为一个行业，我们在衡量我们所做的工作以及做得如何出色方面做得非常差。 除了少数组织购买了昂贵的重量级模型（如CMMI或TSP / PSP（全部都是在微观水平上进行测量）或6 Sigma）之外，我们中的大多数人没有足够的能力去衡量，正确的事情或了解如何处理我们所衡量的事情。 我们无法就如何衡量程序员的生产力甚至是对系统大小的一致度量这一基本问题达成共识–我们应该对代码行（LOC，SLOC，NCLOC，ELOC）或IFPUG功能点或面向对象功能点或权重进行计数微型功能点或COSMIC全功能点，还是类数或其他一些东西？

Capers Jones在其职业生涯的大部分时间里都试图理解我们收集的数据，他这样说： 软件行业缺乏标准的度量和度量实践。 几乎每个软件指标都有多个定义和模糊的计数规则…指标问题的结果是缺乏关于软件成本，工作量，进度，质量和其他有形问题的可靠的经验数据。 2006年软件指标的优势和劣势

但是，我们如何才能变得更好，或者知道我们需要变得更好，或者知道我们是否正在变得更好，是否我们无法衡量或无法衡量某件事？ 在没有证据的情况下，我们如何判断新方法是否有帮助，或者为更多人提供业务案例或进行重写，或者甚至在困难时期证明我们的现有成本合理？

您真正要测量什么？

不同的指标对管理层，团队和客户至关重要。 由于管理或合规性要求，或者由于某些人比您说的重要，因此必须跟踪一些指标。 团队希望跟踪一些指标，因为他们发现它们很有用并希望共享。 作为经理，您想悄悄地跟踪一些隐性指标，因为您认为它们可以使您更好地了解团队的绩效并发现问题，但是您不确定还是不希望人们适应并尝试游戏您正在测量的东西。 最重要的是，客户真正关心的措施：您是否在需要时提供了他们所需要的东西，软件是否可靠且可用？

像大多数管理开发商店的人一样，对我而言，完成工作比收集度量数据更为重要。 任何数据都必须易于收集，廉价且易于使用和理解。 如果需要太多的工作，人们将无法长期保持下去–他们会走捷径，或者只是停止这样做。 最好的指标是免费的，作为我们已经在做的工作的一部分。 http://www.amazon.com/Managing-Design-Factory-Donald-Reinertsen/dp/0684839911我需要少量的指标，它们可以起到双重作用，可以将它们组合并以不同的方式使用。

尺寸

为了在时间或系统和团队之间的比较数据，就需要系统的大小一致的措施，代码库的大小，这是怎么changing.Counting的代码行 ，无论是源代码行（SLOC）或有效代码行（ELOC）或NCLOC（非注释代码行），对于代码库而言，测量起来既简单又便宜，并且易于理解（只要您能够始终如一地处理空白行和其他格式问题 ），但您不能使用它来比较以不同语言和不同平台编写的代码。

这就是功能点的所在–一种独立于平台，标准化工作估算和成本估算的方法。 不幸的是，理解或测量功能点并不容易-尽管有很多工具可以测量代码库中的代码行数，并且每个程序员都可以看到并理解某种语言中100或1000行代码的样子。 ，功能点的计算需要由经过认证的功能点计数器（我不是在开玩笑）的人员使用不同的技术，具体取决于他们选择遵循20种不同的功能点测量方法中的哪一种。

自从1970年代末以来，功能点就已经存在，但由于它不实用，因此这种测量方法尚未广泛流行 -太多的程序员和管理人员不了解它，也不相信它值得进行这项工作。 请参阅“ 功能点是幻想点 ”。

粗略的折衷方案是使用“反向触发”的经验法则将每种语言的LOC转换为功能点（您需要找到一个良好的反向触发转换表 ）。 使用反向射击时，1个功能点平均大约需要55行Java代码，或58行C＃代码，或148行C代码。 使用此方法时 ，对于爬网不精确性存在很多担忧，但需要对系统之间的大小进行粗略比较用不同的语言，这就是我们目前真正拥有的全部。

您在哪里花费时间和金钱，并且您负责任地这样做？

每个人都必须至少跟踪一些基本成本数据，这是运行任何项目或业务的一部分。 有趣的是提出了有用的成本数据细分。 您想知道人们在新产品，增强功能和其他更改，错误修复和其他返工，支持，大规模测试工作，学习上花了多少钱，以及浪费了多少时间。 无论您想出什么类型的存储桶，都应进行粗粒度处理–您不需要详细，昂贵的时间跟踪和其他成本数据来制定管理决策。 如果每个人都在跟踪时间以进行计费，项目成本核算，OPEX / CAPEX财务报告或其他原因，那么这很容易。 否则，采样就足够了。 让每个人跟踪一段时间，使用此数据，然后再次跟踪一段时间以查看发生了什么变化。 使用跨系统大小的通用定义（请参见上文），您可以比较团队和系统之间的成本，以及查看随时间变化的趋势。

对于维护团队，Capers Jones建议团队跟踪分配范围：一个程序员一年可以维护和支持的代码量。 您可以将其用于计划目的（您需要多少人来维护系统），随时间推移观察此变化并在团队和系统之间进行比较（再次基于规模），甚至可以与行业基准进行比较。 根据Capers Jones的数据，一个普通的程序员每年应该能够维护和支持大约1,000个功能点代码，具体取决于程序员的经验，语言，代码质量和工具。

速度

每个人都希望尽快交付软件 。 敏捷团队测量“ 速度”以查看他们在任何时间点的交付速度，但是正如迈克·科恩（Mike Cohn）和其他人详细解释的那样，速度问题是无法在团队之间甚至同一团队内进行比较在很长一段时间内，因为在“故事点”中交付的定义是不稳定的或标准化的–故事点对不同团队而言意味着不同，甚至在相同的时间内对同一团队而言也意味着不同时间（随着人们进入和离开团队，以及他们处理各种问题）。 速度仅可用作一个团队交付速度的短期/中期预测指标。

不断交付生产的团队可以通过他们进行的更改数量以及更改的数量来衡量速度（我们又回到了衡量规模）。 Etsy测量变更的频率和变更集的大小，并将其与生产事件数据 （频率和影响以及恢复时间）相关联，以帮助了解它们是否变化太大或太快以至于不安全。

速度最有用的度量可能来自精益和看板。 要确定您是否满足客户需求，请测量重要更改和修正的周转时间或周期时间：从客户发现问题或要求更改到获得所需的时间需要多长时间。 周转率很容易衡量，对企业和团队来说都很明显，尤其是当您使用诸如“ 累积流程图”之类的方法使周期时间可见时。 很容易看出自己是在跟上还是落后，是在加快还是在减速。 专注于周转将您与对企业和客户重要的事情直接联系起来。

可靠性和质量

但是速度不是一切-如果您要交付的内容是垃圾，那么尽可能快地交付毫无意义。 您还需要一些质量和可靠性的基本度量。

对于在线业务，正常运行时间是可靠性的最常见和最有用的度量：度量操作问题的数量，两次操作故障之间的时间（MTTF）以及从每个故障中恢复的时间（MTTR）。 基本操作内容。

您还需要某种缺陷数据，如果您使用的是Bugzilla或Jira等错误跟踪系统，这些数据将免费提供 。 确定代码中漏洞最多的区域，衡量修复漏洞所需的时间以及团队每个月可以修复的漏洞数量。 从长远来看，跟踪漏洞的打开/关闭比率，以查看是否发现了比正常错误多的漏洞，团队是否在修复错误方面落后，是否需要放慢速度并检查和修复代码而不是尝试交付错误尚未实际使用的功能。

为了在团队或系统之间进行比较或观察随时间变化的趋势，关键指标之一是缺陷密度 ：每个KLOC的错误数（或您使用的任何代码大小量度–再次返回大小量度）。 有了足够的数据，您甚至可以尝试使用缺陷密度来帮助确定何时真正准备好交付代码 。

守则的健康程度如何？

您还希望使用代码分析工具来衡量代码库的运行状况，所承担的技术债务。 代码覆盖范围是一个有用的起点，特别是在进行自动化测试时，或者即使您只是想衡量手动测试的有效性，也是如此。 诸如EMMA和Clover之类的工具会在测试过程中对代码进行编码并跟踪执行情况，以使您了解测试涵盖了哪些代码，更重要的是，未涵盖哪些代码。 向下钻取并查看测试漏洞的位置，并根据这些数据建立趋势很容易，以设置代码覆盖率目标，并提防有人在压力下减少测试。

测量代码复杂性 ，识别最复杂的代码并观察复杂性是否随着时间而增加，有助于您决定将重点放在哪里以及进行检查和测试以及重构工作。 如果您同时测量测试覆盖率和复杂性，则可以将数据关联在一起，以识别高风险代码：未经测试的复杂例程。 代码的健康状况也可以通过静态分析检查器（如Findbugs和PMD或Coverity或Klocwork）进行评估，这些工具可以查找编码错误和安全漏洞以及是否违反了良好的编码习惯。 诸如Sonar和CodeExcellence之类的高级代码质量管理工具，可以合并和关联来自多个静态分析工具的数据，为您提供所有代码的运行状况的总体摘要图，并让您了解随着时间的推移以及整个团队的代码运行状况和系统。

以非邪恶的方式使用指标

许多程序员认为度量标准是无用的或邪恶的，尤其是如果管理层将其用于评估和比较程序员的生产率 。 例如，IBM显然使用静态度量数据来对应用程序开发人员和团队进行记分卡 ，并试图量化程序员的性能。 使用此类数据对开发人员进行人力资源评估很容易导致滥用行为和错误行为的加剧。 如果您通过大小和简单的代码质量度量来衡量“生产率”，那么程序员就不会遇到棘手的问题或加紧维护陈旧的旧代码，因为他们的得分总是很糟糕。 编写许多简单的代码来使工具满意并不能使一个人成为更好的程序员。

仅测量事物以识别代码和开发过程中的潜在问题和负面趋势，优缺点。 如果您要为团队设定目标以提高速度或质量成本，请让他们决定要测量的内容和方法。 并衡量构建业务案例所需的一切–向其他人证明团队正在前进并做得很好，或者为变更做辩护。 使指标适用于团队。 您可以在不增加开发成本和邪恶的情况下完成所有这些工作。

参考： Building Real Software博客上来自我们JCG合作伙伴 Jim Bird的重要软件开发指标 。

翻译自: https://www.javacodegeeks.com/2012/05/software-development-metrics-that.html

软件开发项目指标