软件缺陷度量与分析技术研究

第２８卷第９期　２０１１年９月　计算机应用与软件　Ｃｏｍｐｕｔｅｒ　Ａｐｐｌｉｃａｔｉｏｎｓ　ａｎｄ　Ｓｏｆｔｗａｒｅ　Ｖｏ１．２８　Ｎｏ．９　Ｓｅｐ．２０１１　软件缺陷度量与分析技术研究　闰振兴　郑　骏　（华东师范大学计算中心上海２０００６２）　摘要　软件能力成熟度模型第４级中要求在项目中定量管理，建立组织级过程，构成完整的量化管理，采用统计或其它定量方　法管理软件过程，并通过对过程中出现的方法、技术等问题进行因果分析和寻找解决方案…。在仔细研究了现有的缺陷度量分类　方法和分析指标后，通过运用缺陷数据分析方法，在开发过程中运用缺陷分析的结果，可以采取合适的对策尽早发现和消除存在的　缺陷，以提高软件产品的开发质量和成功率。　关键词　中图分类号软件缺陷　缺陷度量　缺陷分析　软件过程　ＴＰ３１１　文献标识码Ａ　ＲＥＳＥＡＲＣＨ　ｏＮ　ＳｏＦＴＷＡＲＥ　ＤＥＦＥＣＴ　ＡＮＡＬＹＳＩＳ　ＴＥＣＨＮ０Ｌ０ＧＹ　ＡＮＤ　Ｙａｎ　Ｚｈｅｎｘｉｎｇ　Ｚｈｅｎｇ　ｊｕｎ　（Ｃｏｍｐｕｔｅｒ　Ｃｅｎｔｅｒ，Ｅａｓｔ　Ｃｈｉｎａ　Ｎｏｒｍａｌ　Ｕｎｉｖｅｒｓｉｔｙ，Ｓｈａｎｇｈａｉ　２０００６２，Ｃｈｉｎａ）　Ａｂｓｔｒａｃｔ　ＣＭＭＩ４（Ｃａｐａｂｉｌｉｔｙ　Ｍａｔｕｒｉｔｙ　Ｍｏｄｅｌ　Ｉｎｔｅｇｒａｔｉｏｎ）ｒｅｑｕｉｒｅｓ　ａ　ｐｒｏｊｅｃｔ　ｔｏ　ｂｅ　ｑｕａｎｔｉｔａｔｉｖｅｌｙ　ｍａｎａｇｅｄ．Ｏｒｇａｎｉｚａｔｉｏｎａｌ　ｐｒｏｃｅｓｓ　ｉｓ　ｅｓｔａｂｌｉｓｈｅｄ，ｃｏｍｐｌｅｔｅ　ｑｕａｎｔｉｔａｔｉｖｅ　ｍａｎａｇｅｍｅｎｔ　ｉｓ　ｆｏｒｍｅｄ，ａｎｄ　ｓｔａｔｉｓｔｉｃａｌ　ｏｒ　ｏｔｈｅｒ　ｑｕａｎｔｉｔａｔｉｖｅ　ａｐｐｒｏａｃｈｅｓ　ｔｏ　ｍａｎａｇｅ　ｓｏｆｔｗａｒｅ　ｐｒｏｃｅｓｓ　ａｒｅ　ａｄｏｐｔｅｄ．Ｃａｕｓｅｓ　ｏｆ　ａｎｄ　ｓｏｌｕｔｉｏｎｓ　ｔｏ　ｍｅｔｈｏｄｓ　ａｎｄ　ｔｅｃｈｎｏｌ呼ｃａｌ　ｐｒｏｂｌｅｍｓ　ｅｎｃｏｕｎｔｅｒｅｄ　ｄｕｒｉｎｇ　ｔｈｅ　ｐｒｏｃｅｓｓ　ａｒｅ　ｕｎｖｅｉｌｅｄ．Ａｆｔｅｒ　ｃａｒｅｆｕｌ　ｓｔｕｄｙ　ｏｆ　ｅｘｉｓｔｉｎｇ　ｄｅｆｅｃｔ　ｍｅａｓｕｒｅｍｅｎｔ　ｍｅｔｈｏｄｓ　ａｎｄ　ａｎａｌｙｓｉｓ　ｉｎｄｉｃａｔｏｒｓ，ｂｙ　ｕｓｉｎｇ　ｄｅｆｅｃｔ　ｄａｔａ　ａｎａｌｙｓｉｓ　ａｐｐｒｏａｃｈ　ａｎｄ　ｉｔｓ　ｒｅｓｕｌｔｓ　ｄｕｒｉｎｇ　ｔｈｅ　ｄｅｖｅｌｏｐｍｅｎｔ　ｐｒｏｃｅｓｓ，ａｎ　ａｐｐｒｏｐｒｉａｔｅ　ｔａｃｔｉｃ　ｃａｎ　ｂｅ　ｅｍｐｌｏｙｅｄ　ｔｏ　ｆｉｎｄ　ｏｕｔ　ａｎｄ　ｅｌｉｍｉｎａｔｅ　ｔｈｅ　ｅｘｉｓｔｉｎｇ　ｄｅｆｅｃｔｓ　ａｓ　ｅａｒｌｙ　ａｓ　ｐｏｓｓｉｂｌｅ，ＳＯ　ｔｈａｔ　ｔｈｅ　ｓｏｆｔｗａｒｅ　ｄｅｖｅｌｏｐｍｅｎｔ　ｑｕａｌｉｔｙ　ａｎｄ　ｓｕｃｃｅｓｓ　ｒａｔｉｏ　ｉＳ　ｉｍｐｒｏｖｅｄ．　Ｋｅｙｗｏｒｄｓ　Ｓｏｆｔｗａｒｅ　ｄｅｆｅｃｔ　Ｄｅｆｅｃｔ　ｍｅａｓｕｒｅｍｅｎｔ　Ｄｅｆｅｃｔ　ａｎａｌｙｓｉｓ　Ｓｏｆｔｗａｒｅ　ｐｒｏｃｅｓｓ　软件过程质量并实施缺陷预防措施。　０引　言　ｌ　问题描述　软件产品的生产过程决定了所开发出的软件的质量，提高　软件质量是软件生产过程中各项活动的共同目标，因此，必须对　软件的生产过程进行有效的质量控制与管理　Ｊ。软件缺陷是　软件在生命周期各个阶段存在的一种不满足给定需求属性的问　题　。目前发布的软件中，都存在着这样或那样的缺陷，某些　目前多数中小型软件项目的开发对于缺陷信息的控制和管　理处于一种混乱的状态中，对测试前期的设计和开发阶段的缺　陷数据统计和分析的程度严重不足。基本上是在进入测试阶段　后才开始报告出大量的缺陷，进行缺陷的修正，再测试，再修正　这样一个无序的过程。由于缺乏缺陷数据的统计与分析，以及　缺陷的预防机制，使得软件项目开发周期变得难以控制。　根据缺陷分类方法的目的、观察角度和复杂度的不同，已经　出现了几种软件缺陷的分类方法。例如，比较流行的是ＩＢＭ公　缺陷可能成为软件的致命隐患，从而导致应用软件或操作系统　崩溃，所以软件开发公司和个人必须都积极采取有效的方法，尽　可能地减少缺陷　。　在软件开发过程中实施缺陷的度量与分析对于提高软件开　发和测试效率，预防缺陷发生，保证软件产品质量有着十分重要　的作用。缺陷分析是将软件开发各个阶段产生的缺陷信息进行　分类和汇总统计，计算分析指标，编写分析报告的活动。通过软　件缺陷分析可以发现各种类型缺陷发生的概率，掌握缺陷集中　的区域、明确缺陷发展趋势、挖掘缺陷产生的根本原因，便于有　针对性地提出遏制缺陷发生的措施、降低缺陷数量　。缺陷分　析报告中的统计数据及分析指标既是对当前软件质量状况的评　估，也是判定软件是否能按期发布或交付使用的重要依据。实　施缺陷分析的前提是需要一个符合项目要求的缺陷数据管理系　统，通过采集完整的缺陷数据信息，进行缺陷数据分析，来改进　司制定的缺陷正交分类方法ＯＤＣ（Ｏｒｔｈｏｇｏｎａｌ　Ｄｅｆｅｃｔｓ　Ｃｌａｓｓｉｉｆｃａ－　ｔｉｏｎ）。该方法提供了一种从缺陷中提取关键信息的测量范例，　适用于评价软件开发过程，提出过程改进方案，其缺点在于分类　复杂，难以把握缺陷分类的标准。Ｔｈａｙｅｒ软件错误分类方法是　通过错误性质来划分缺陷，适用于指导开发人员消除缺陷。美　国电气和电子工程师协会ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｅｌｅｃｔｒｉｃａｌ　ａｎｄ　Ｅｌｅｃ・　ｔｒｏｎｉｃｓ　Ｅｎｇｉｎｅｅｒｓ）制定的软件异常分类标准提供了一个统一的　方法对软件和文档中发现的异常进行详细的分类，具有较高的　收稿日期：２０１０一ｏ４—０６。闰振兴（ＣＣＦ会员：Ｅ２０００１５４５１Ｇ），硕士　生，主研领域：软件工程，软件测试，ＷＥＢ应用技术。　第９期　闰振兴等：软件缺陷度量与分析技术研究　１３ｌ　权威性，不足之处在于没有考虑软件工程的过程缺陷、分类过程　下六个缺陷度量分析指标　，如表１所示。　复杂　Ｊ。软件生产是以过程为主线的，各种活动都围绕过程进　表１常用的缺陷度量分析指标　行，各种工具和方法的使用都和过程紧密联系，过程由一系列的　Ｔ、ｆ、，　一．Ｔ、…　一、Ｔ、ｒ、已知缺陷数量　活动组成，这些活动由开发者使用工具、方法和技术来完成。过　一…　“　一软件规模　程之间是相互联系的，前一过程结果会影响到相关的以该过程　缺陷密度　依据软件产品的生命周期可将缺陷密度再细分为需求　结果为基础的后一过程。将分类方法建立在过程基础上可以更　缺陷密度，设计缺陷密度，编码缺陷密度，软件规模度量　好地理解缺陷形成的过程，把握缺陷的本质，从根本上预防　的单位可以是文档，功能点，代码行等。　缺陷　，　。　ＤＤＥ（Ｄｅｆｅｃｔ　Ｄｅｔｅｃｔｉｏｎ　Ｅｆｆｉｃｉｅｎｃｙ），ＤＤＥ＝　，　∑Ｘ：　现在市场上的已经开发了几种缺陷管理系统工具，例如　Ｍｅｒｃｕｒｙ公司的Ｑｕａｌｉｔｙ　Ｃｅｎｔｅｒ，ＩＢＭ公司的Ｒａｔｉｏｎａｌ系列管理工　（Ｉ－１，…，ｋ；ｊ＝１，…，ｋ）Ｚｘ　，表示第ｉ阶段流出并在　本阶段就发现的巳知缺陷总数量。　具，微软公司的ＶＳＴＳ等。类似的商用的缺陷管理系统的特性　ｋ　基本上都大同小异，对于缺陷属性的分类方法没有一个统一的　缺陷探测　Ｊ∑ｘ：，　１‘　表示从第ｉ阶段中流出的所有缺陷数量。ｋ表示　标准，现有的缺陷管理工具在缺陷数据的分析方面普遍比较薄　效率　软件开发过程中的ｋ个开发阶段。例如ＤＤＥ为１００％，　弱，通常只是提供一些缺陷属性数量的简单统计功能，用户不得　则表明该开发阶段中产生的所有缺陷，都在本阶段中被　不借助一些其它的统计分析软件或自行开发缺陷数据分析组件　测试出并消除，没有缺陷传播到下一个阶段。例如　来进行缺陷数据的分析。在实际软件开发过程中，对于缺陷数　ＤＤＥ＝３０％，则表明该开发阶段产生的所有缺陷只有　３０％在本阶段中测试出并消除，另有７０％本阶段中产　据的分析还没有给予足够的重视。　生的缺陷流出到了后面的开发阶段中。　本文基于上述思考，重点研究了缺陷数据的分析指标和分　ＤＤＥ说明了软件开发过程的效率。　析方法，并结合某项目中的缺陷数据实例进行了分析说明。　ＰＤＲＥ（Ｐｒｅ—Ｄｅｌｉｖｅｒｙ　Ｄｅｆｅｃｔ　Ｒｅｍｏｖａｌ　Ｅｆｉｆｃｉｅｎｃｙ），　ｋ　∑Ｘ；　２缺陷分析的时机　ＰＤＲＥ＝Ｔ　—一，（ｉ＿１，…，ｋ；ｊ＝ｋ＋１）　ｉ　ｘｉ＋∑ｘｊ　发布前的　ｋ　在软件产品正式发布前，在软件项目开发的早期就应该构　缺陷消除　ｘ　，表示软件开发过程中的各阶段所流出并消除的缺陷　Ｉ＝１　建缺陷分析的模式。进行缺陷分析的必备条件是所需要的缺陷　蛊　数量。２ｘ；，表示软件发布后发现的缺陷数量。通过为　数据都有相应的记录，便于过滤出分析所需要的数据。缺陷分　软件升级或打补丁包的方式消除缺陷。例如，发布前发现　析是一个持续的过程，通过缺陷管理系统，登录了缺陷数据后就　了３９０个缺陷，发布后使用系统中又发现的和隐含着共１Ｏ　应及时进行分析工作。　个缺陷，那么发布前的缺陷消除率为　软件发布前分析的对象是软件开发阶段发生的缺陷，需求、　ＰＤＲＥ＝３９０／（３９０＋ｌ０）×１００％＝９７．５％。　ＤＣＥ（Ｄｅｆｅｃｔ　Ｃｏｒｒｅｃｔｉｏｎ　Ｅｆｉｆｃｉｅｎｃｙ），　设计、编码中引Ａ／流出的缺陷居多，通过分析计算缺陷指标，评　ｎ　∑已修正完的缺陷数量一∑由已修正完的缺陷新引起的缺陷数量　估开发阶段软件的质量，判定软件产品是否能够发布。软件发　～一　∑已修正完的缺陷数量　缺陷纠正　例如布后的缺陷分析，分析的对象是软件运行阶段发生的缺陷，通过　，修复了１００个缺陷，后来发现其中５个修复　蛊　由于未测试完全等原因定期分析掌握缺陷的分布和发展趋势，以便控制预防缺陷的发　，又引入了新的缺陷，则缺　生，降低维护成本。缺陷分析需要收集大量缺陷信息，是一项费　陷纠正率为ＤＣＥ＝（１００—５）／１００｝１００％＝９５％。　这个度量指标对软件过程改进很有用。　时费力的工作，一些分析指标数据没有长期的积累其指导意义　ＭＴｒＲ（Ｍｅａｎ　Ｔｉｍｅ　Ｔｏ　Ｒｅｐａｉｒ），ＭＴＴＲ＝　并不大，因此缺陷分析需要制度化、纳入Ｅｔ常工作中定期进行。　平均修复　∑缺陷从报出到修正完毕所用的时间　时间　缺陷数量　一。　３缺陷分析的方法　缺陷所花费的平均工时，可用于估算工作量及工作效率。　平均修复　ＭＣＴＲ（Ｍｅａｎ　Ｃｏｓｔ　Ｔｏ　Ｒｅｐａｉｒ），　成本　ＭＣＴＲ＝单位缺陷修正成本×ＭＴＹＲ这里单位缺陷　软件缺陷分析是一个含义广泛的概念，具有数量繁多的分　修正成本即修正一个缺陷所所花的人工和资源所需成本。　析方法和分析指标，不同的方法和指标面向不同的度量目标，一　个缺陷管理系统不可能支持所有的分析方法，但应该支持常用　这些度量分析指标为定量分析缺陷提供了基础，对于改进　的基本方法　…。本文中采用的缺陷分析方法为定量分析与定　软件过程非常有意义　。根据需要收集数据实施定量分析，分　性分析相结合，基于缺陷正交分类法　设计的单一属性分析法　析缺陷的分布状态和宏观趋势，以量化的统计结果作为定性分　和复合属性分析法。单一属性分析法主要针对软件缺陷某一属　析的依据。针对缺陷引入和流出的原因，以及有关人员、管理等　性的分布进行分析，例如缺陷所处的不同生命周期状态、缺陷不　方面的深层次原因进行定性分析，并给出有效的解决方案，以预　同严重程度级别、不同功能模块／项目组中缺陷的数量分布等统　防该类缺陷的产生。　计信息。当通过单一属性分析法反映出问题后，需要采用复合　属性分析法协同分析多个缺陷属性，进一步发掘出引起这些变　４缺陷分析的应用研究　化的根本原因。　软件缺陷可以分为两种，即通过测试和评审等方法发现的　４．１基于缺陷数量分布的统计分析　已知缺陷，及尚未发现的潜在缺陷。软件缺陷管理主要关注以　缺陷分析指标中最重要的一类就是能反应软件产品质量的　ｌ３２　计算机应用与软件　２０１１丘　缺陷密度指标，在缺陷分析中最常使用统计缺陷数量的方法是　对收集的数据进行分类汇总。缺陷分布状况参照缺陷统计属　性，主要分析不同模块，不同严重级别，不同开发阶段的缺陷分　布　。在某项目的系统测试阶段，统计的缺陷机能模块，严重　级别及开发阶段的分布情况如图１所示。　时间　２９１　…统计超过一定时间但未修正的缺陷，反映各部门／组对缺陷修　缺陷修正　正能力。通常我们统计分析缺陷修正日期时，还会统计参与修　能力　正该缺陷的每个责任人所花费的工时，以便缺陷分析修正该缺　陷所花费的成本。如果超过一定时间（３天，５天，１周，２周，　）未修正的缺陷数量比较多，那么再结合其它指标一起分析。　通常通过计算缺陷的平均修正时间来评价各部门对　缺陷的修正能力。参见表１常用的缺陷度量分析指标　缺陷修正　如某项目在系统测试阶段前，已报告的缺陷增长趋势如图　２中所示。　Ｉ４■　蹦　（ａ）缺陷机　擞：　市　缺陷严ｔ缓错分布　…　主藿　譬至　：ｌ　ｌ　ｌ茎　ｌ　图２周缺陷增长趋势图　ｌ　ｉ　分析其中所包含的信息，关闭缺陷和打开缺陷曲线之间的　（ｃ）缺陷严醐Ｕ　开发阶｛曼总体分布　间距能够反映开发人员对缺陷的反应速度，由于当前系统测试　还未开始，所以各种状态的缺陷数量仍在持续增长。这条曲线　如按日进行统计缺陷增长趋势通常为ｓ型或凹型，理想的情况　图１缺陷分布图　图中（ａ）和（ｂ）采用了单一属性分析法，图（ａ）给出了不同　模块中发现的缺陷比例分布，缺陷数量最多的６个模块，占了缺　陷总数的８１％，其余的９个模块的缺陷数量占了缺陷总数的　１９％，通过这一分布，找到了改善软件质量的几个关键模块。　（ｂ）给出了这一开发阶段的不同严重级别的缺陷分布。（ｃ）利　下，系统测试阶段后期几种缺陷状态的曲线应该逐步趋向平缓，　最终保持一致。　图３为某项目中的基于缺陷修正时间统计的平均分布情况　的示例。　用复合属性分析法，给出了集成测试开始之前和之后的不同严　重级别的缺陷分布。这些分布信息在不同的角度反映了软件产　品的缺陷密度，利用这些定量统计分析结果，采取定性分析方法　对缺陷数据深入分析，有助于了解项目中影响软件质量的瓶颈。　Ｏ　∞　∞　＊　”　¨＋　缸缎缺陷的謦正时问分布　４．２基于缺陷变化趋势的统计分析　这一分析指标依赖的缺陷数据主要是软件产品正式发布之　ｔ＊　搬　谢　惭　琳十　均啊重工时　均对应工Ｈ　（　缺喻沓正的平均时间　前测试出的缺陷，定期分析计算采集的缺陷数据。对于处在不　同开发阶段产生的缺陷，采用的改进对策是不尽相同的，并且原　则上所有被发现的缺陷都应该在软件产品正式发布之前被修　正。在项目开发中，分析缺陷的变化趋势可以从以下几个方面　着手，如表２所示。　表２缺陷变化趋势的分析指标　ｓ２．Ｓ３．ｓ嘲缺陷的惨芷时闻分布　幽３缺陷修正时间　图中（ａ）和（ｂ）中描绘了ｓ１及ｓ２、ｓ３、Ｓ４严重级别的缺陷　修正时间分布，原则上，ｓ１级的缺陷应于１０天内处理完。ｓ２级　的缺陷，应于７天内处理完，ｓ３，Ｓ４级的缺陷，应于４天内处理　完。对于超出时间处理的缺陷，着重分析缺陷修正延期的原因，　识别出修正缺陷延期的原因类型，并制定预防措施。从（ｃ）中　可以看出，调查一个缺陷所需的平均调查时间约为３．６小时，修　正一个缺陷所需的时间约为１．３小时。这只是总的缺陷修正时　间分布情况，在应用中，通常结合部Ｉ＇１／模块／严重级别三个方面　通常把时间单位（目，周等）引人数据分析，结合其它缺陷属　性指标一起分析，反映连续时间或者某个时间段中缺陷状态　缺陷总体　的趋势／特性等信息，可以把每周采集的缺陷数据做成折线图。　发展趋势　理想的情况下，关闭状态的缺陷数量应该逐步趋向于预测的　缺陷总数，新增的其它类型状态数的应该趋向于０。利用折　分别进行统计分析，可以评价对缺陷的修正能力。　线图分析可以看出项目质量的走势，如果缺陷关闭以外的某一　类型缺陷数目保持不变或者持续增长，需要做进一步的分析。　按缺陷生命周期状态（／模块／严重级别）分类，以采集的缺陷　数据总数为数据源做成折线图，如果有必要，可单独区分状态　缺陷增长　（／模块／严重级别）。利用折线图分析，理想情况下，折线图上　４．３基于缺陷产生原因的统计分析　根据开发人员填写的缺陷原因，找出导致缺陷最多的原因，然后　集中资源解决它。基于缺陷产生原因的统计分析目标如表３所示。　表３缺陷产生原因的分析指标　统计分析缺陷在哪一个开发阶段被引入／流出。并结合缺陷总体　趋势　的斜率应该逐步趋向于０，如果出现大幅度增加，可以通过分析　缺陷引入　识别共通问题及其产生原因，并制定　图表判断问题出现集中于哪些模块，这些模块中出现的缺陷　／流出阶　发展趋势和缺陷增长趋势，分布情况是如何的。　段分析　关过程，技术和人员管理方面的改进措施，预防类似缺陷的产生。　／流出原　陷管理系统中可以根据经验预先定义一部分缺陷引入／流出原因　逐个分析缺陷引入／流出原因等属性，确定缺陷的触发条件，在缺　从总体上对不同模块／不同级别的每周已关闭状况的缺陷进行　缺陷引入　缺陷修正　分析，找出缺陷关闭比较慢的模块，并调查原因。缺陷修正走　趋势　势可根据需要选择缺陷状态数据进行分析，通常与打开状态，　已修正状况，确认状况的缺陷协同分析，把握缺陷修正的进度　因分析　罱性的类型，随着缺陷数目的增加，归纳出的引入／流出原因类型．　并进行统计增加到缺陷管理系统。　第９期　闰振兴等：软件缺陷度量与分析技术研究　１３３　表４中给出了某项目的缺陷引入／流出阶段的缺陷统计情　理系统对发现的缺陷进行跟踪和修复，但是利用缺陷数据进行　分析统计的却不多。本文中设计了适用于指导项目实施缺陷分　析的评价指标，通过实施缺陷分析把握软件开发过程的质量状　况，应用分析结果可以帮助项目组及时了解缺陷集中区域和发　展趋势。通过在软件开发过程中实施缺陷过程度量管理，深入　挖掘缺陷出现的各种原因，找出产生缺陷的技术和流程上的不　足，采取应对措施消除当前存在的缺陷，总结经验制定缺陷预防　方案，防止类似缺陷再次发生。通过采取严格的软件过程质量　控制手段，对整个软件开发过程的质量情况进行评估，利用缺陷　分析的结果改进缺陷度量与分析标准，使软件产品的开发周期　更加可控。　况。从表４中可以了解到，需求缺陷中有约７５％是在需求阶段　之后发现，设计缺陷中有约５０％的缺陷是在编码阶段开始之后　发现的，在测试阶段开始后，发现了编码和单体测试阶段未发现　的中的６７％的缺陷。应注意的是，对于每种类型缺陷的修改所　花费的资源并不相同。例如，在测试阶段发现了设计阶段出现　的缺陷，那么会引起设计文档的变更，相应的编码修正，测试文　档的修改等连锁反应，所以应在每一开发阶段中加强评审工作，　防止本阶段出现的缺陷流出到之后的开发阶段。　表４缺陷引入阶段统计表　缺陷移除　单体　集成　系统　运行　引入　缺陷　阶段　需求　设计　编码　测试　测试　测试　维护　总计　移除率　需求缺陷　１２　１０　设计缺陷　编码缺陷　总计　５２　５　１７　１４　１６　４　９　２　７　３３　Ｏ　４７　２５．５３％　参考文献　［１］朱少民，左智．软件过程管理［Ｍ］．北京：清华大学出版社，２００７．　［２］苏秦，何进，张涑贤．软件过程质量管理［Ｍ］．北京：科学出版　社，２００８．　２　１０３　５０．４９％　６　１６６　３３．７３％　８　３１６　１０　４６　７１　１２　６２　３２　７６　８４　４２　［３］袁玉宇．软件测试与质量保证［Ｍ］．北京：北京邮电大学出版　社，２００８．　缺陷分析的目的是找出缺陷引入的原因，如图４中为某项　［４］Ｈｕｔｅｈｅｓｏｎ　Ｍ　Ｌ．软件测试基础：方法与度量［Ｍ］．北京：人民邮电出　版社，２００７．　目中对缺陷引入原因分类示例。（ａ）中根据引起缺陷的原因的　不同，对缺陷进行了简单的分类统计。但只有这些信息无法了　解缺陷引入的根本原因，需要将缺陷产生的原因进行更详细的　分类。（ｂ）中对于设计阶段引入的缺陷数据，划分为更小的分　类，以反映缺陷产生的本质。对于详细分类后的缺陷原因，应提　供消除与预防原因分类缺陷引入的措施。如针对需求变更设计　书未同步修正这一缺陷引入原因，可采取预防措施，需求变更　后，需求设计书负责人应及时发布变更通知，与需求变更内容有　关联的设计书负责人，接收该通知并修正设计书。　［５］聂林波，刘孟仁．软件缺陷分类的研究［Ｊ］．计算机应用研究，　２００４，２１（６）：８４—８６．　［６］贺赞．基于ＣＭＭＩ的软件过程度量［Ｊ］．电脑知识与技术，２００８，４　（７）：１６４７—１６４９．　［７］车美儒，姜楠，勾朗，等．面向开发阶段的软件缺陷分类方法研究　［Ｊ］．计算机应用研究，２００８（３）：７５９—７６３．　［８］刘海，郝克刚．软件缺陷原因分析方法［Ｊ］．计算机科学，２００９（１）：　２４２—２４３，２５１．　［９］ＩＢＭ　Ｒｅｓｅａｒｃｈ　Ｃｅｎｔｅｒ　ｆｏｒ　Ｓｏｆｔｗａｒｅ　Ｅｎｇｉｎｅｅｒｉｎｇ．Ｏｒｔｈｏｇｏｎａｌ　Ｄｅｆｅｃｔ　Ｃｌａｓ．　ｓｉｉｆｃａｔｉｏｎ［ＯＬ］．２００２．ｈｔｔｐ：／／ｗｗｗ．ｒｅｓｅａｒｃｈ．ｉｂｍ．ｃｏｍ／ｓｏｆｔｅｎｇ／ＯＤＣ／　ＯＤＣ．ＨＴＭ．　［１０］刘海，郝克刚．软件缺陷数据分析方法及其实现［Ｊ］．计算机科学，　２００８（８）：２６２—２６４．　需求阃暖接口ｆ母置理螺不足謇曩脯设计『嗣题主囊蕨因特分析　（上接第１１５页）　（盘）缺陷引入曩周分粪　以使用系统中心控制台来配置、部署和执行企业网络策略，预先　配置防病毒、防火墙和入侵检测。　（３）集成化响应原来由多个安全系统提供的响应措施现　在通过协同防御体系的整合，可以做到更加合理、安全的响应部　署。集成化响应功能还能够使企业对于违背安全策略和病毒发　作更快地作出响应。　设计阶段酲陌引＾屎凼诨羽分类　网络安全的协同防御体系是新一代安全防御战略的重要组　成部分，是未来网络安全防御发展的必然选择。希望通过本策　略的提出，可以建立较完善的信息安全体系，有效地防范信息系　统来自各方面的攻击和威胁，把风险降到最低。　图４缺陷引入原因　由于篇幅所限，本节中仅对软件开发过程中几种常用的缺　陷分析指标进行了说明。在实际项目开发中，可根据需要选择　参考文献　［１］Ｓｅａｎ　Ｃｏｎｖｅｒｙ．网络安全体系结构［Ｍ］．北京：人民邮电出版　社，２００５．　合适的指标进行缺陷分析。项目管理人员可通过分析导致缺陷　产生的不同原因，了解产品质量状况，定期总结缺陷引入原因的　详细分类，为软件过程改进提供支持。　［２］苏铁明．计算机支持的协同设计框架及若干技术研究［Ｄ］．大连：　大连理工大学，２００３．　５结语　［３］ＰｅｔｅｒＮｏｒｔｏｎ，Ｍｉｋｅ　Ｓｔｏｃｋｍａｎ．网络安全指南［Ｍ］．人民邮电出版　社，２０００．　软件项目开发过程需要一种方法能够持续地对其进行监控　和改善其中存在的问题。以往的软件开发过程使用软件缺陷管　［４］唐正军．网络人侵检测系统的设计与实现［Ｍ］．电子工业出版　社。２００２．