千行代码缺陷率标准_千行代码缺陷率参考值

项目成本估算方法的面向规模(LOC)的度量

面向规模的软件度量通过规范化质量和生产率测量的方法得到，这种测量是基于所生产软件的规模(Size)确定的。为了与其他项目中的同类度量相比较，选择代码行作为规范化，这样，就可以为每个项目产生一组简单的、面向规模的度量标准：

千行代码缺陷率标准_千行代码缺陷率参考值

软件代码缺陷率标准？

缺陷如何度量？缺陷度量的三大标准

2年前

软件度量包含三个维度的内容：产品设计指标度量、过程度量和项目度量。产品设计指标度量是指从产品设计角度的一些特性指标角度度量，如规模大小、复杂程度、设计特点、性能和质量水平。过程度量主要是用于提高开发和维护的效率，如开发过程中缺陷去除的效果、测试过程中的缺陷模型和修复过程的响应时间。项目度量是从项目特点和执行的角度进行度量，如开发商数量、生命周期、成本、进度等。

一、缺陷密度度量

缺陷密度也就是平常所说的缺陷率，缺陷率看似很简单，但是如果我们不能讨论清楚缺陷率中分子与分母的值，那么就不可能很好地确定缺陷率的概念。一般缺陷率的概念是指一个特定的时间帧中缺陷出现的机会。

分母通常指的是软件的大小，通常使用千万代码(KLOC)或功能数来形容。时间帧是指产品生命期中的一系列操作，生命期少则一年，多则几年，通常95%的缺陷会在产品发布的四年之内发现，而绝大多数数据缺陷通常是在两年内被发现。

千行代码这个度量其实很简单，主要的问题是如何精确地计数实际的代码行数，在早期的汇编语言中，一行物理代码就相当于我们要计数的一行代码，但在高级语言中可能就不会这样，一行物理行并不一定是一行代码，即使同一个代码片段使用不同的计数工具计数，也可能导致结果存在差异，通常统计代码行有以下几种方法：

1)只统计可执行的行代码;

2)只统计带数据定义的可执行的行代码;

3)统计可执行行代码、数据定义和注释;

4)统计可执行行代码、数据定义、注释和控制语句;

5)统计在输入屏幕中做为物理行的代码;

6)统计做为逻辑分隔符的终止行代码;

上面是常见的关于代码行的统计方法，不同的公司可能会有着不同的统计方法，但不管使用什么方法进行统计，统计的方法只能使用一种。不同的项目使用不同的统计方法，这样数据之间没有参考价值。

通常说的代码是程序文件中的一行代码，但是注释行或空行除外，代码通常包括程序头、函数声明、可执行的语句和不可执行的语句。

在统计过程中，统计物理行代码和统计指令语句是存在差异的，有时候甚至会差得很多，如Basic、Pascal和C语言，在一行物理行上就可能出现多个指令。另一方面，一条指令语句和数据声明也可能跨越几条物理行代码，特别是在编程时，如果为了维护方便，写代码时就很容易出现这种问题。使用逻辑行和物理行进行统计各有优缺点，但是可能逻辑行来统计代码行会

如何描述项目内容?

1、 进度，计划进度曲线图及实际进度曲线图进行对比，总结出入原因。

2、 风险，按各里程碑阶段出现的风险分类进行分析，如质量、时间、人力、沟通、需求变更。

3、 需求，按个里程碑阶段计划需求数量、实际需求数量柱形图进行分析；描述需求变更给项目带来的影响。

4、 质量，从功能测试阶段、回归测试阶段、验收测试阶段等测试阶段入手，分析各阶段有效BUG数，以及分析BUG分布情况；根据BUG情况分析千行代码缺陷率趋势。

5、 成本，按里程碑阶段，计算各阶段投入的人日，以及计算开发和测试的人员比例，按市场人月价格可估算成本。

检查绩效目标的有效性有哪些原则

1.是否具体：

无效的目标：我要提高代码质量

具体的表达：我要降低Bug率（千行代码缺陷率）

无效的目标：我要成为一个程序员

具体的表达：我要掌握C++语言

2.是否可以衡量：有无衡量的标准。

目标1：我要将Bug率控制在千分之2.39以内（CMMI3的标准）

目标2：我要掌握C++基本语法、继承、多态、虚函数、STL中的常见容器类的用法，并完成一个10000代码行的项目

3.是否可以实现：目标必须是可以通过努力实现、达到的。应该高于现状，但又是跳一下能够得着的。

4.是否可以分解：大的目标是否能分解成若干小目标，一步步来实现完成。

4.是否相关：分解目标的下级目标是否跟上级目标相关。就是说实现了下级目标是不是对实现上级目标有作用。

5.有没有规定完成的时限

总之有没有起到激励的作用是检测绩效目标的唯一标准。

软件质量评估的软件质量评估指标体系

通常，我们在软件的测试与评估时，主要侧重于功能特征、可靠特征、易用特征和效率特征等几个方面。在评价活动的具体实施中，应该把被评估软件的研制任务书作为主要依据，采用自顶向下逐层分解的方法，并参照有关国家软件质量标准。功能性是软件最重要的质量特征之一，可以细化成完备性和正确性。对软件的功能性评价主要采用定性评价方法。

a.完备性

完备性是与软件功能完整、齐全有关的软件属性。如果软件实际完成的功能少于或不符合研制任务书所规定的明确或隐含的那些功能，则不能说该软件的功能是完备的。

b.正确性

正确性是与能否得到正确或相符的结果或效果有关的软件属性。软件的正确性在很大程度上与软件模块的工程模型（直接影响辅助计算的精度与辅助决策方案的优劣）和软件编制人员的编程水平有关。

对这两个子特征的评价依据主要是软件功能性测试的结果，评价标准则是软件实际运行中所表现的功能与规定功能的符合程度。在软件的研制任务书中，明确规定了该软件应该完成的功能，如信息管理、提供辅助决策方案、辅助办公和资源更新等。那么即将进行验收测试的软件就应该具备这些明确或隐含的功能。

对于软件的功能性测试主要针对每种功能设计若干典型测试用例，软件测试过程中运行测试用例，然后将得到的结果与已知标准答案进行比较。所以，测试用例集的全面性、典型性和权威性是功能性评价的关键。根据相关的软件测试与评估要求，可靠性可以细化为成熟性、稳定性、易恢复性等。对于软件的可靠性评价主要采用定量评价方法。即选择合适的可靠性度量因子（可靠性参数），然后分析可靠性数据而得到参数具体值，最后进行评价。

经过对软件可靠性细化分解并参照研制任务书，可以得到软件的可靠性度量因子（可靠性参数）。

a.可用度

可用度指软件运行后在任一随机时刻需要执行规定任务或完成规定功能时，软件处于可使用状态的概率。可用度是对应用软件可靠性的综合（即综合各种运行环境以及完成各种任务和功能）度量。

b.初期故障率

初期故障率指软件在初期故障期（一般以软件交付给用户后的三个月内为初期故障期）内单位时间的故障数。一般以每100小时的故障数为单位。可以用它来评价交付使用的软件质量与预测什么时候软件可靠性基本稳定。初期故障率的大小取决于软件设计水平、检查项目数、软件规模、软件调试彻底与否等因素。

c.偶然故障率

指软件在偶然故障期（一般以软件交付给用户后的四个月以后为偶然故障期）内单位时间的故障数。一般以每1000小时的故障数为单位，它反映了软件处于稳定状态下的质量。

d.平均失效前时间（MTTF）

指软件在失效前正常工作的平均统计时间。

e.平均失效间隔时间（MTBF）

指软件在相继两次失效之间正常工作的平均统计时间。在实际使用时，MTBF通常是指当n很大时，系统第n次失效与第n1次失效之间的平均统计时间。对于失效率为常数和系统恢复正常时间很短的情况下，MTBF与MTTF几乎是相等的。

国外一般民用软件的MTBF大体在1000小时左右。对于可靠性要求高的软件，则要求在1000~10000小时之间。

f.缺陷密度（FD）

指软件单位源代码中隐藏的缺陷数量。通常以每千行无注解源代码为一个单位。一般情况下，可以根据同类软件系统的早期版本估计FD的具体值。如果没有早期版本信息，也可以按照通常的统计结果来估计。“典型的统计表明，在开发阶段，平均每千行源代码有50~60个缺陷，交付后平均每千行源代码有15~18个缺陷”。

g.平均失效恢复时间（MTTR）

指软件失效后恢复正常工作所需的平均统计时间。对于软件，其失效恢复时间为排除故障或系统重新启动所用的时间，而不是对软件本身进行修改的时间（因软件已经固化在机器内，修改软件势必涉及重新固化问题，而这个过程的时间是无法确定的）。易用性可以细化为易理解性、易学习性和易操作性等。这三个特征主要是针对用户而言的。对软件的易用性评价主要采用定性评价方法。

a.易理解性

易理解性是与用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性。该特征要求软件研制过程中形成的所有文档语言简练、前后一致、易于理解以及语句无歧义。

b.易学习性

易学习性是与用户为学习软件应用（例如运行控制、输入、输出）所花的努力有关的软件属性。该特征要求研制方提供的用户文档（主要是《计算机系统操作员手册》、《软件用户手册》和《软件程序员手册》）内容详细、结构清晰以及语言准确。

c.易操作性

易操作性是与用户为操作和运行控制所花的努力有关的软件属性。该特征要求软件的人机界面友好、界面设计科学合理以及操作简单等。

3.4效率特征指标

效率特征可以细化成时间特征和资源特征。对软件的效率特征评价采用定量方法。

a.输出结果更新周期

输出结果更新周期是软件相邻两次输出结果的间隔时间。为了整个系统能够协调工作，软件的输出结果更新周期应该与系统的信息更新周期相同。

b.处理时间

处理时间是软件完成某项功能（辅助计算或辅助决策）所用的处理时间（注意：不应包含人机交互的时间）。

c.吞吐率

吞吐率是单位时间软件的信息处理能力（即各种目标的处理批数）。未来的社会情况复杂、信息众多，软件必须具有处理海量数据的能力。吞吐率就是体现该能力的参数。随着信息的泛滥，要求软件的吞吐率应该达到数百批。

d.代码规模

代码规模是软件源程序的行数（不包括注释），属于软件的静态属性。软件的代码规模过大不仅要占用过多的硬盘存储空间，而且显得程序不简洁、结构不清晰，容易存在缺陷。

因为这些参数属于软件的内部表现，所以需要用专门的测试工具和特殊的途径才可以获得。将测试数据与研制任务书中的指标进行比较，得到的结果可以作为效率特征评价的依据。随着计算机技术、数据融合技术、网络技术和通信技术的飞速发展，对软件功能提出的要求也越来越高，如何评估软件质量已成为一个迫切需要解决的课题。选择合适的指标体系并使其量化是做好软件质量评估的关键。当然，由于软件的评估具有其特有的规范和要求，其评估指标涉及面广、不确定性因素较多、量化困难，至今还没有统一的标准。