嵌入式软件缺陷率

Question

在为嵌入式处理器(DSP)编写的C++代码库中,我可以期待什么样的缺陷率,因为没有单元测试,没有代码评审,没有静态代码分析,并且编译项目会产生大约1500个警告.5个缺陷/ 100行代码是否合理估计？

Answer 1

您的问题是"5个缺陷/ 100行代码是否合理估计？" 这个问题极难回答,而且高度依赖于代码库和代码复杂性.

您还在评论中提到"向管理层显示代码库中可能存在大量错误" - 这很好,很有价值,正确.

为了打开管理层的形象,我建议至少采用三管齐下的方法:

• 采取特定的编译器警告,并显示其中一些可能导致未定义/灾难性行为.并非所有警告都会如此重要.例如,如果你有人使用未初始化的指针,那就是纯金.如果你有人将无符号的16位值填充到无符号的8位值中,并且可以证明16位值总是<= 255,那么这个值就不会让你的情况变得强烈.
• 运行静态分析工具. PC-Lint(或Flexelint)便宜并提供良好的"降压".它几乎肯定会捕获编译器不会捕获的东西,并且它也可以跨翻译单元运行(将所有内容组合在一起,即使有2次或更多次传递)并找到更微妙的错误.再次,使用其中一些作为指示.
• 运行一个工具,提供代码复杂性的其他指标,另一个错误来源.我推荐中号平方的资源标准指标(RSM) ,这将给你更多的信息和指标(包括代码复杂度)比你能期待.当你告诉管理是一个复杂的分数超过50是"基本上不可测"和你有一个得分200在一个程序中,应打开一些眼睛.

另一点:我需要在我的组中进行干净的编译,并清理Lint输出.通常,这可以通过编写好的代码单独完成的,但偶尔的编译器/ lint警告需要进行调整,以安静的东西,都不是问题(使用明智)的工具.

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

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

祝好运!

Answer 2

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

在本文中，作者引用了《软件评估、基准和最佳实践》 （Jones，2000）中发表的“大量实证研究”中的数据。在SIE CMM 1 级（听起来像此代码的级别），预计每个功能点的缺陷率为 0.75 。我将让您自行确定功能点和 LOC 在代码中的关系 - 您可能需要一个度量工具来执行该分析。

Steve McConnell 在 Code Complete 中引用了对同一团队开发的 11 个项目的研究，其中 5 个没有代码审查，6 个有代码审查。未经审查的代码的缺陷率为每 100 个 LOC 4.5，而经过审查的代码的缺陷率为 0.82。因此，在此基础上，在没有任何其他信息的情况下，您的估计似乎是公平的。然而，我必须假设这个团队具有一定的专业水平（仅仅因为他们认为有必要进行这项研究），并且他们至少会注意警告；你的缺陷率可能会高得多。

关于警告的一点是，有些是良性的，有些是错误的（即会导致软件出现不良行为），如果您假设它们都是良性的而忽略它们，则会引入错误。此外，当其他条件发生变化时，有些在维护过程中会出现错误，但如果您已经选择接受警告，则您无法防御此类错误的引入。