缺陷率跟踪最适合什么？每个KLOC的缺陷？

Question

我想创建一些内部指标来演示（确定？）TDD如何改善代码中的缺陷率。

有没有比缺陷/ KLOC更好的方法？一种语言的“功能密度”呢？

任何意见或建议将是有帮助的。

谢谢 - 乔纳森

Answer 1

您也可以考虑映射缺陷发现率和缺陷解决率...要花多长时间才能发现错误，而且一旦他们发现，他们是否需要多长时间才能修复？据我所知，TDD应该在修复时间方面有所改进，因为它会使得早期的缺陷被发现......对吗？

Answer 2

任何措施是缺陷与代码大小的任意比较;只要比较相似，它应该可以工作。例如，C中的缺陷/ kloc与C中的缺陷/ kloc。如果您更改了语言，则会影响度量标准，因为使用其他语言编写的相同程序可能不太容易出现缺陷。

Answer 3

我建议使用的时间之间的比：

1. 的时间花费修正错误
2. 的时间花费写其他代码

这种跨似乎有效语言...

---

它也适用，如果你只是粗略估计一些大的代码库。您仍然可以将其与您正在编写的新代码进行比较，以打动您的管理;-)

Answer 4

测量缺陷并非易事。人们想说明代码的复杂性，但这是令人难以置信的混乱和不愉快。当测量代码质量，我建议：

1. 测量电流状态（你现在的不良率）
2. 进行更改（同行评审，培训，准则的指导原则等）
3. 衡量新缺陷率（有事情好转？）
4. 转到2

如果你要比较程序员确保你比较编码器做类似的工作，在相同的语言。不要将在最复杂的计算引擎的深层内部工作的编码人员与编写存储数据库中代码的代码的编码人员进行比较。

我尝试确保编码员知道该过程正在被测量而不是编码器。这有助于提高指标的质量。

Answer 5

我对所有与LOC相关的度量都持怀疑态度，不仅仅因为语言的相对表达能力不同，而且因为各个程序员在代码的表达能力上会有足够的差异，使得这个度量最好是“模糊”的。

我会在项目管理中的利益衡量的事情是：

• 对项目开放缺陷的数量。没有任何一个标量可以告诉你项目在哪里，它与可释放状态有多接近，但这仍然是一个方便的数字，可以随时随地观看。
• 缺陷的检测率。这不是将新缺陷引入系统的速度，但它可能是您找到的最接近的代理。
• 缺陷解决率。如果这个数字低于检测率，那么你落后了 - 如果它更大，你就会领先。

如果将这些数字与严重性信息结合使用，所有这些数字都会更有用。具有20个小错误的产品可能比具有2个崩溃错误的产品更接近释放。如果你正在清理小错误而不是严重错误，你必须让开发人员重新关注它。

我会跟踪每个项目和每个开发这些数字。每个项目的理由应该清楚。每个开发人员的数字当然不是个人贡献者的技能或生产力的全貌，但可以指出可能需要培训或补救的人员。

您可能还希望通过项目模块标记在你的缺陷跟踪系统中所有的门票，以及（特别是对于较大的项目），这样，当关键模块处于脆弱状态，你可以告诉。

Answer 6

你为什么不考虑按使用情况下的缺陷？或每个要求的缺陷。我们在抵达KLOC时遇到了实际问题。