7

我想知道是否有人在用于衡量软件质量的指标方面有经验。我知道有代码复杂度指标,但我想知道是否有一种特定的方法来衡量它在其生命周期内的实际执行情况。我不是指运行时性能,而是对质量的衡量。也欢迎任何有助于收集这些的建议工具。

是否有测量来回答这些问题:

  • 更改/增强软件有多容易,稳健性
  • 如果它是一个足够通用/通用的软件,它的可重用性如何
  • 有多少缺陷与代码相关联
  • 是否需要重新设计/重新编码
  • 这段代码存在多久了
  • 开发人员是否喜欢代码的设计和实现方式

似乎其中大部分都需要与 CM 和错误报告工具密切相关。

4

7 回答 7

1

如果您使用 Ruby,有一些工具可以帮助您处理从 LOCs/Method 和 Methods/Class Saikuros Cyclomatic 复杂度等指标。

实际上,我的老板在去年的一次 ruby​​ 会议上就我们使用的软件度量进行了演示,这些是幻灯片。

metric_fu是一个有趣的工具,可以同时为您带来大量指标。它会检查代码中很多有趣的方面。高度相似的东西,变化很大,有很多分支。所有迹象表明您的代码可能会更好:)

我想其他语言也有更多这样的工具。

于 2009-06-30T00:00:01.930 回答
1

如果按照您所说的方式衡量代码质量将是一项如此简单的工作并且指标准确,那么可能不再需要项目经理了。更重要的是,好经理和差经理之间的区别很小。因为事实并非如此,这只是表明要准确了解软件的质量并非易事。

您的问题涉及多个量化不同或对量化非常主观的领域,因此您应该将它们分组到对应于共同目标的类别中。然后,您可以为每个类别分配一个“重要性”因素,并从中得出一些指标。

例如,您可以使用静态代码分析工具来测量代码的语法质量并从中得出一些指标。

您还可以使用与版本控制系统集成的错误跟踪工具从错误/代码行中获取指标。

为了衡量编码过程的健壮性、重用性和效率,您可以评估每个开发的功能的设计模式的使用(当然在有意义的地方)。没有任何工具可以帮助您实现这一目标,但是如果您监控您的软件变得越来越大并在上面加上数字,它可以让您很好地了解您的项目是如何发展的,以及它是否朝着正确的方向发展。引入代码审查程序可以帮助您更轻松地跟踪这些问题,并可能在开发过程的早期解决它们。放在这些上的一个数字可能是使用适当的设计模式实现的功能的百分比。

虽然指标可能非常抽象和主观,但如果您花时间研究它并始终尝试改进它们,它可以为您提供有用的信息。

不过,关于软件过程中的指标有几点需要注意:

  1. 除非你做得好,否则指标可能弊大于利。
  2. 指标很难做好。
  3. 在使用指标评估个人表现或提供奖金计划时,您应该谨慎。一旦你这样做了,每个人都会试图欺骗系统,你的指标将被证明毫无价值。
于 2009-06-29T22:59:22.520 回答
0

您可能需要查看以下页面,该页面描述了软件质量的各个不同方面,包括示例图。您需要测量的一些质量特征可以使用 Sonar 等工具得出。弄清楚您希望如何对以下某些方面进行建模非常重要:

  1. 可维护性:您确实提到了更改/测试代码或重用代码是多么容易。这些与可维护性的可测试性和可重用性方面有关,可维护性被认为是关键的软件质量特征。因此,您可以根据可测试性(单元测试覆盖率)和可重用性(代码的内聚性指数)来衡量可维护性。
  2. 缺陷:单独衡量缺陷可能不是一个好主意。但是,如果您可以对缺陷密度进行建模,它可以为您提供良好的画面。
于 2013-02-14T18:57:31.640 回答
0

旧的 Joel 在软件讨论组中有一个关于此的好帖子。

于 2009-06-29T21:12:16.057 回答
0

我知道一些 SVN 统计程序提供了每次提交更改行的概述。如果您有错误跟踪系统并且修复错误的人员添加功能等在修复错误时说明他们的提交编号,那么您可以计算每个错误/新功能请求影响了多少行。这可以让您衡量可变性。

接下来就是简单地计算发现的错误数量,并将它们与代码行数成比例。一个高质量的软件每个代码行应该有多少错误是有一些价值的。

于 2009-06-29T21:14:50.687 回答
0

你可以以某种经济的方式程序员的方式来做到这一点。

在经济方式的情况下,您可以衡量改进代码、修复错误、添加新功能等的成本。如果您选择第二种方式,您可能想要衡量有多少员工在使用您的程序,以及在人工小时内找到并修复平均错误的难易程度。当然它们也不是完美无缺的,因为成本取决于市场情况,人工时间取决于实际人员和他们的技能,所以最好将这两种方法结合起来。

通过这种方式,您可以获得一些工具来测量代码的质量。当然,您应该考虑项目的规模和其他因素,但我希望主要思想是明确的。

于 2009-06-29T21:37:26.710 回答
0

更以客户为中心的指标是软件供应商修复错误和实施新功能所需的平均时间。

根据您的错误跟踪软件的创建日期和关闭信息,计算非常容易。

如果您的平均错误修复/功能实现时间非常长,这也可能是软件质量不佳的一个指标。

于 2009-10-03T12:37:06.867 回答