跟踪和预测质量水平

Question

人们推荐什么技术来跟踪一个新程序的质量水平？他们的方法是采用一个定义不明确的术语，比如“质量水平”，量化它，然后做出预测吗？目前我使用bug率和S曲线，但我正在寻找其他方法来评估、估计和预测质量水平。

Answer 1

你在找this measure吗？

更严重的是，对我来说，代码质量是关于可维护性的：

• 修复错误、添加/删除/修改功能有多容易，
• 重构有多容易:回归测试套件是否可用？
• 多少错误

请记住，您只需编写一次代码，就可以多次阅读它。

Answer 2

我不确定统计你的bug会有什么用来比较它。如果你做的软件很难，有很多边缘案例，那会怎么样呢？你需要某种类型的比较。

尽管其他答案中的一个显然是个笑话，但代码审查也可能是一个好主意。如果你有太多的bug，雇佣更好的工程师或者让他们写更少的代码。

编辑:考虑评论后添加...

每一个虫子都像一个独特的可口的雪花(可恶的雪花？)它们对您的客户和开发人员有不同程度的影响。我至少会考虑到这一点。也许增加严重性(客户推动修复的衡量标准)和修复它所花费的工程时间可能有助于提高准确性。我想我担心的是，当涉及到软件开发时，这仍然是对“质量”的过于简单化。

可悲的是软件质量!=产品质量。最近发布的一款名为Fallout 3的游戏赢得了大量奖项，赚了很多钱(至少我认为是这样)，但至少在PC上也是一堆垃圾。

只要确保你跟踪和优化的是正确的东西。跟踪#bug与时间的关系就是跟踪#bug与时间的关系。对它的解读需要一定程度的假设，无论是正确还是错误。

你的目标是什么？Bug只是软件质量的一部分。如果您想继续，那么支持您的软件的可维护性是关键。很多时候，如果你的程序员做事情很匆忙，错误修复可能会使事情变得更难维护。这反过来会使未来的修复和功能变得更加困难，修复可能会添加新的bug。

Answer 3

这在很大程度上取决于您试图进行的比较类型。如果随着时间的推移，您正在查看单个项目，并且团队没有变化，那么bug率可能是有意义的。然而，如果你比较不同的项目，不同的团队，你真的没有办法比较像bug率这样的东西，因为你实际上是在比较已知bug的比率。一个团队可能比另一个团队更善于识别bug，使他们的bug率看起来更高，但他们实际上是具有更好软件质量的团队。