嵌入式软件的缺陷率

Question

什么缺陷率可以我希望在C++的代码编写的用于嵌入式处理器(DSP)，鉴于没有单元的测试，没有代码评论，没有静态的代码分析，并编制项目产生大约1500警告。5缺陷/100行的代码一个合理的估计?

Answer 1

尽管我在这种情况下，任何估计的有效性持怀疑态度，我已经发现了一些统计数据，可能是相关的。

在这篇文章，作者引用数字从“庞大的身躯的实证研究”，发表于的软件评估，基准和最佳做法（琼斯，2000）。在 SIE CMM等级1 ，这听起来像这样的代码的水平，谁也无法预料0.75的缺陷率每 功能点 。我要把它留给你来决定如何的功能点的和LOC可以在你的代码有关 - 你可能需要一个的度量工具执行分析。

史蒂夫奈尔在代码完成引用了研究没有代码审查，6代码审查由同一个团队，5个已开发11个项目。用于非审查代码缺陷率为4.5每100 LOC，以及用于审查它为0.82。所以，在这个基础上，你的估计似乎是公平的在没有任何其他信息。不过，我必须承担的敬业精神之中这支球队（距离，他们认为进行研究，需要的事实）的水平，他们将至少有出席的警告;你的不良率可能的高得多的。

有关警告的一点是，有些是良性的，有些是错误的（即会导致软件的不希望的行为），如果你忽略他们的假设，他们都是良性的，你会引入误差。而且有些人会的变成的下维修差错时等条件的变化，但如果你已经选择接受警告，你对引进这样的错误没有防守。

Answer 2

您的问题是“ 5条缺陷/100行代码是合理的估计？”这个问题非常困难，并且高度取决于代码库和代码复杂性。

您还在评论中提到“向管理层表明代码库中可能存在很多错误”——这很好，值得称赞，就这样。

为了打开管理层的形象视野，我建议至少采取三管齐下的方法：

• 采取特定的编译器警告，并显示其中一些警告如何导致未定义/灾难性的行为。并非所有警告都会如此重要。例如，如果有人使用未初始化的指针，那就是纯金。如果有人将一个无符号的 16 位值填充到一个无符号的 8 位值中，并且可以证明 16 位值将始终 <= 255，那么这个人不会帮助你证明这一点。
• 运行静态分析工具。 PC-Lint （或 Flexelint）价格便宜且“物有所值”。它几乎肯定会捕获编译器不会捕获的内容，并且它还可以跨翻译单元运行（将所有内容整理在一起，即使有 2 次或更多遍）并发现更微妙的错误。再次，使用其中一些作为指示。
• 运行一个工具，该工具将提供有关代码复杂性的其他指标，这是错误的另一个来源。我会推荐 M Squared 的资源标准指标 (RSM) 这将为您提供比您希望的更多的信息和指标（包括代码复杂性）。当你告诉管理层 复杂度分数超过 50 表示“基本上无法测试” 而且你在一项例行训练中获得了 200 分，这应该会让一些人大开眼界。

另外一点：我需要在我的组中进行干净的编译，并且也需要干净的 Lint 输出。通常，这可以通过编写良好的代码来完成，但有时需要调整编译器/lint 警告，以使工具安静下来，处理不存在问题的事情（明智地使用）。

但我想说的重要一点是： 进入并修复编译器和 lint 警告时要非常小心. 。这是一个令人钦佩的目标，但您也可能会无意中破坏工作代码，和/或发现意外在“损坏”代码中工作的未定义行为。是的，这确实发生了。所以要小心行事。

最后，如果您已经有了一套可靠的测试，这将帮助您确定在重构时是否意外破坏了某些内容。

祝你好运！

Answer 3

看一看代码质量。它会很快给你躲在源问题量的指示。如果源是难看和需要很长的时间来了解会有很多错误的代码。

用一贯的风格结构良好的代码，这是很容易理解将要包含较少的问题。代码显示了多么大的努力和思想走进它。

我的猜测是，如果源包含许多警告，有将是一个很大的错误代码躲藏的。

Answer 4

这也要看是谁写的代码（经验水平）和代码库有多大。

我将所有警告视为错误。

有多少错误，当您运行的代码静态分析工具，你得到什么？

修改

运行CCCC，并检查McCabe的环状的复杂性。它应该告诉多么复杂的代码吧。

http://sourceforge.net/projects/cccc/

运行其他静态分析工具。

Answer 5

如果你想获得的缺陷数量的估计值，统计estimatation的通常的方法是二次采样数据。我会挑三个中型子程序随机的，并仔细检查他们的错误（消除编译器警告，运行静态分析工具等）。如果发现在随机选择的代码100条总线3级的错误，它似乎是合理的错误的相似密度是在代码的其余部分。

这里的问题引入新的bug提到的是一个重要的问题，但你并不需要检查修改后的代码回分公司生产运行该测试。修改任何子程序，和清理之前我建议一个透彻组的单元测试所有的代码，接着非常彻底的系统测试发布新的代码来生产之前。

Answer 6

如果您想演示的单元测试，代码审查，静态分析工具的好处，我建议做一个试验性研究。

做一些单元测试，代码评审，并在代码的一部分运行的静态分析工具。显示管理你发现多少错误使用这些方法。我们希望，结果不言自明。

Answer 7

以下文章中有一些数字的基础上现实生活中的项目，其静态分析已经适用于： http://www.stsc.hill.af.mil/crosstalk/2003/11/0311German.html

当然标准不正常的计算可能会影响的结果极大，导致大变化图表1所示。在该表中，数量异常每万行代码C范围从500(!) 约10(自动生成)。