软件质量管理实践.docx

软件质量管理实践.docx

《软件质量管理实践.docx》由会员分享，可在线阅读，更多相关《软件质量管理实践.docx（20页珍藏版）》请在冰豆网上搜索。

软件质量管理实践

软件质量管理实践

——软件缺点预防、清除、管理实用方式

第7章软件气宇

软件气宇是针对软件开发项目、进程及产品进行数据概念、搜集和分析的持续性定量化的进程。

有效气宇的作用在于能够帮忙软件组织认清自身的能力，理解、评价、控制、预测和改良软件工作产品或软件进程。

本末节为大家介绍的是软件气宇及其方针。

随着技术的进步和软件应用领域的拓展，用户需要更大规模、更靠得住的软件，此时，软件气宇工作显得更为重要了。

若是一个组织能够对其生产的产品做出预测和许诺，那么就可以够说这个组织是成功的。

有效气宇的作用在于能够帮忙软件组织认清自己的能力，按照对气宇数据结果的分析，进一步为他们的生产和服务制订出可行的计划；及时找到转变趋势，预测问题，发现或采取有效手腕预防缺点；不断改良软件开发进程。

需求的变更直接致使规模的变更、进度的延期和本钱的增加，公司要求项目领导按期气宇需求变更（包括新增的、修改的和删除的需求数）的数量及需求总数的转变，控制需求变更并采取相应的办法。

图7-1中两条线别离表示需求总数的变更和每周需求变更的数量。

曲线中的数据表明，第二周的需求评审后，第三周需求总数又有了明显的增加，而且第三、第四和第五周需求变更的数量都很大。

为了查找具体原因，须继续分析加倍详细的数据，如图7-2所示。

图7-2中显示，通过了第二周的"第1次评审"，需求变更仍是很大，其中大量的需求处于修改状态。

而且第七周"第2次评审"后，需求在相当长的时间内依旧没有稳定下来。

目前，项目已经进入到设计阶段，大量的需求变更是项目失败的一个隐患。

为了控制不断需求的变更，项目可能采取包括从头分派资源，从头估量规模、工作量和进度等具体办法。

另外，还可以详细地分析需求变更的具体原因（如误解、不清楚、不完善和不正确等）、需求变更的类型（如功能、性能和接口需求等）和细化跟踪的粒度到每一个模块。

通过这些详细的分析，可肯定造成需求频繁变更的根本来源，以便有针对性地采取办法。

 缺点气宇

缺点气宇是软件气宇的一部份，其本身并非能发现缺点、剔除缺点，可是有助于这些问题的解决。

另外，当正确、持续地进行了缺点气宇时，产品和进程的质量属性的数据为实施和管理进程改良活动提供了有效的基础。

数据的质量等因素，咱们在本章节中已经考虑了，这里仍将遵循。

 什么是缺点气宇

软件产品质量气宇，主要集中在软件的缺点气宇上。

缺点气宇就是对项目进程中产生的缺点数据进行收集和量化，将分散的缺点数据统一管理，使其有序而清楚，然后通过采用一系列数学函数，对数据进行处置，分析缺点密度和趋势等信息，从而提高产品质量和改良开发进程。

一般来讲，在软件质量保证进程中，需要气宇的缺点数据包括6大类缺点发现手腕发现的所有缺点。

如测试相关的缺点，需要气宇包括测试投入的工作量和本钱数据、测试任务完成情况、测试规模数据、测试结果数据（包括缺点数据、覆盖率数据）等。

（1）组织级缺点气宇，目的是了解组织的整体缺点情况，了解客户对组织的质量满意度，成立组织基线，肯定改良活动。

（2）项目级缺点气宇，目的是了解项目实时质量情况（很多项目只在最后气宇，包括那些迭代式开发的项目，实际上为时已晚），预测缺点造成的发布后保护工作量，了解客户对项目的质量满意度。

（3）个体缺点气宇，目的是了解个体缺点产生的详细原因，并实实施动进行改良。

前两种气宇大家接触较多，但第三种气宇常常被忽略。

这常常致使：

项目反复取得关于自己的质量评价，但很难了解如何去提高；

测试组常常能做一些改良（如增加测试覆盖、延长测试周期）来提高缺点排除效率，但开发组没有降低缺点产生数量的有效办法；

软件开发遵循了编码规范，但似乎对提高质量没有太多帮忙。

气宇取得的缺点相关数据，分析方式可参见本章稍后的"缺点分析"相关内容。

 缺点气宇元

缺点气宇元的选择，也需要从气宇目标动身，肯定适当的气宇元。

例如，可以依照如下表所示的思路肯定组织整体或项目组个体利用哪些缺点气宇元。

信息需要

可度量概念

度量目的

度量元

派生度量元

通过模块的各类型缺陷数来评价软件质量

模块缺陷分布

反映缺陷按类型、严重程度、所属模块分布情况。

通过度量可以客观上看出哪个模块的缺陷比较高，这样可加大对这个模块的开发投入

每个模块的各类缺陷数目

各模块的缺陷个数百分比

通过总体的各类型缺陷数来评价软件质量

总体缺陷分布

反映总体缺陷的分布情况，可看出软件的缺陷主要是哪些方面的缺陷，可帮助项目组找出问题，提高质量

每类缺陷的数目

每类缺陷占总缺陷的比例

通过缺陷密度评价模块稳定性

缺陷密度

通过按模块的缺陷密度倒序排列，通过二八定理确定缺陷密集模块，确定修复重点

每个模块的各类缺陷数目

每个模块的各类缺陷密度及比例

判断缺陷数量的趋势

总体趋势

反映新缺陷数、被解决的缺陷数和遗留的缺陷数的趋势，了解缺陷解决是否及时和全面

各种状态缺陷的数量

各种状态缺陷的数量的比例

判断缺陷驻留时间

缺陷排除情况

判断缺陷产生的原因

缺陷数量排行、缺陷发现时间、缺陷清除时间

整体缺陷清除率、阶段性缺陷清除率、缺陷的驻留时间

确定哪种缺陷发现方式有效

缺陷数量和种类

选择合适的降低缺陷的方法

缺陷种类

缺陷密度、同行评审发现错误率、测试发现的缺陷数、PPQA发现的缺陷数

除上边重点描述的气宇元外，还可以考虑其他与缺点气宇有关的因素。

例如：

缺点散布气宇、基于时间的缺点抵达模式、PTR积累模型、测试用例的深度、质量和有效性、测试执行的效率和质量、基于需求的测试覆盖评估、基于代码的测试覆盖评估。

再说一下前面的"前人栽树、后人纳凉"的5个气宇元。

通过需求转变率、同一需求转变次数、配置项转变率、同一配置项转变次数、同一缺点转变率这5个气宇元的气宇数据，查找一下是不是由转变最多的需求引发的，是不是由转变最大的配置项引发的，可使保护的效率提高40%左右。

有效选择缺点气宇元，对缺点预防、缺点清除和缺点管理有着相当重要的意义和作用。

 缺点密度的概念

对于一个软件工作产品，软件缺点可以分为通过评审或测试等方式发现的已知缺点（knowndefect）僧人未发现的潜在缺点（1atencydefect）两种。

Myers有一个关于软件测试的著名反直觉原则：

在测试中发现缺点多的地方，还有更多的潜在缺点将会被发现。

这个原则背后的原因是，发现缺点越多的地方，漏掉的缺点可能性也会越大，或说测试效率没有被显著改善之前，在纠正缺点时将引入较多的错误。

其数学表达就是缺点密度的气宇--每KLOC或每一个功能点（或类似的气宇--对象点、数据点、特征点等）的缺点数，缺点密度越低意味着产品质量越高。

缺点密度的概念如下：

缺点密度=已知缺点数量/产品规模

缺点密度与缺点率、整体缺点清除率、缺点趋势、预期缺点发现率等都有必然的关系，相关内容可以参考

 缺点密度的用途

缺点密度是软件缺点的大体气宇，可用于设定产品质量目标，支持软件靠得住性模型（如Rayleigh模型）预测暗藏的软件缺点，进而对软件质量进行跟踪和管理，支持基于缺点计数的软件靠得住性增加模型（如Musa-Okumoto模型），对软件质量目标进行跟踪并评判可否结束软件测试。

若是缺点密度跟上一个版本相同或更低，就应该分析当前版本的测试效率是不是降低了？

若是不是，意味着质量的前景是乐观的；若是是，那么就需要额外的测试，还需要对开发和测试的进程进行改善。

若是缺点密度比上一个版本高，那么就应该考虑在此之前是不是为显著提高测试效率进行了有效的策划，并在本次测试中取得实施？

若是是，虽然需要开发人员更多的尽力去修正缺点，但质量仍是取得更好的保证；若是没有，意味着质量恶化，质量很宝贵到保证。

这时，要保证质量，就必需延长开发周期或投入更多的资源。

当软件产品或项目第一次发布，并规定利用LOC计数时，可以比较容易地说出它的计划或实际的质量品级，如"本产品共有83KLOC，在此后的3年时间里，潜在的缺点率是个缺点/KLOC"。

但当进行了修改、增强后进行产品的后续发布时，问题就会愈来愈复杂。

缺点跟踪：

缺点必需被跟踪到版本源头，其中包括此缺点的代码段，和在哪个版本中加入、修改或增强的。

当计算整个产品的缺点率时，要用到所有缺点；当计算新的和更改代码的缺点率时，则只需要包括新的和更改代码的版本源头中的缺点即可。

缺点率气宇在每一个单位的基础上气宇代码质量。

从用户的角度来看，缺点率远没有缺点总数那么重要，对他们来讲，产品应该确保缺点总数与发布版本大小无关，而随着发布版本下降。

若是一个新发布版本的大小比它的前一版本大很多，则需要新的和更改代码的缺点率应该明显地好于以往版本。

咱们可以考虑如下假设的例子：

产品A最初发布时期码总量为50KLOC，估量残留缺点总数是100个，平均有2个缺点/KLOC。

发布第二版时，新增代码行为20KLOC，包括修改原来的4KLOC行代码（需要剔除，避免重复计算），可以计算出该版本代码总数为5020466KLOC，该版本对上一版本的缺点率有10%的改良，估量当前版本残留缺点新增总数可以控制在36个之内，则平均残留缺点数为个/KLOC。

此时，由于这次发布版本较小，在缺点率有10%的改良的同时，用户在缺点数方面经历了（10036）/10064%的明显下降。

若是进行第三版的发布时，新增代码行为40KLOC，这比第二次发布大得多，其中包括修改原来的10KLOC行代码，则该版本代码总数为66401096KLOC，为了利用户的缺点体验不至于失望，增加的缺点总数不该该多于上个版本的36个，所以缺点率目标需要控制在36/40或更低，即该版本的缺点率必需比第二版的好50%。

 缺点管理库

从缺点发现、缺点修复，直到缺点解决、经验证、关闭缺点为止，在缺点管理的整个生命周期中记录了大量相关资料，它们是进行缺点分析、提高产品质量所需要的宝贵信息。

气宇这些缺点的发现本钱、修改效益，对缺点管理及其改良是超级有帮忙的。

一般地，要求将通过同行评审、测试、管理评审、PPQA发现、项目组内部发现和客户反馈等几种手腕发现的缺点，都需要统一寄存在缺点跟踪系统（如TD、BUGZILLA等）中，进行统一管理、统计。

其中涉及缺点的大体信息在第1章已经描述过，包括缺点标识、缺点描述/主题、发现时间、所处阶段、发现手腕、缺点原因、发生条件、发生缺点的子系统、所处的模块、发生缺点的机械、软硬件平台、严重程度、优先级、缺点状态、缺点起源、发现人、计划修正时间、修正方式、跟踪验证人等信息项。

其中，软件发布前的缺点原因关键字，可能包括以下几种：

（1）需求文档：

需求分析文档不明确、不详尽等原因引发。

（2）信息交流：

信息交流不顺畅，开发成员间沟通不及时引发。

（3）编程：

原始编程犯错，没有客观原因。

（4）修改：

由于修改缺点而引入的新缺点，而且引发的变更与原变更的错误是相关的。

（5）外部问题：

涉及软件模块外部问题而引发。

（6）培训：

项目组新成员培训不充分，或利用新工具不熟练引发。

（7）其他：

指以上各类原因之外所产生的缺点。

软件发布后缺点原因的关键字，可以有以下几种实例：

（1）需求分析：

需求分析不足等原因引发。

（2）系统设计：

软件系统设计各种原因引发。

（3）程序编码：

软件开发阶段中编程错误引发。

（4）保护：

软件发布后程序保护时引发。

（5）实施：

实施人员做软件初始化设置或系统参数设置不妥等所引发。

（6）用户：

泛指用户不了解业务和软件、不熟悉操作等原因产生的异样问题。

（7）数据异样：

运行中不明原因引发的用户数据混乱和异样。

（8）升级：

软件版本升级进程中发生的问题，包括用户在升级时未按规程操作产生的问题。

（9）外部问题：

所涉及软件外部问题引发的变更，包括操作系统、数据库软件、第三方软件所引发的问题。

（10）其他：

指以上各类原因之外的变更，包括变更原因不明。

但需要强调，记录缺点信息的关键是注意信息正确性。

不能有人为因素失真，尤其像变更产生根本原因、变更测试情况。

只有正确的信息，才能保障正确的分析结果。

节"缺点分析"。

利用缺点密度时，有一点需要注意：

百分比气宇表示相对频率，需要给出足够的上下关系信息。

通常的描述在利用百分比和比率时不够小心，例如：

"需求缺点占总数的15%，设计缺点占总数的25%，编码缺点占总数的50%，其他的缺点占总数的10%"。

还不能提供加倍详细有力的信息，若是依照如下所述，将可以取得更多的信息，即"一个包括了8000行代码的工程，在其开发期间，检测并排除约200个缺点，因此缺点排除率为每千行代码25个缺点。

在这200个缺点中，需求缺点占总数的15%，设计缺点占总数的25%，编码缺点占总数的50%，其他的缺点占总数的10%"。

 缺点种类分析

下面以一个项目的系统测试故障为例进行分析，如图7-9所示。

图7-9 系统测试缺陷类型分布图

从系统测试故障来看，有较多故障是由接口原因造成的，细分有以下几种原因。

（1）跨项目间的接口：

接口设计文档的更改没有成立彼此通知的机制，致使接口问题到系统测试时才暴露出来；

（2）部门内部跨子系统的接口：

由于本项目设计文档按功能计划编写，而不是依照产品组件编写，一般由主要承接功能工作的组编写该文档，接口内容可能不为其他开发组理解并熟悉，致使因接口问题而犯错；

（3）系统设计基线化后，更改系统接口：

没有走严格的变更流程，进行波及分析，致使该接口变更只在某个子系统中被修改，而使错误遗留下来。

按照图7-9，可以制定有针对性的改良建议：

（1）对接口文档的评审，必然要识别受影响的相关关连人，使他们了解并参与接口设计的把关；

（2）对基线化的接口设计文档的变更必然要提交变更单给CCB决策，并做好充分的波及影响分析，以便同步修改所有关联的下游代码；

（3）概要设计文档按子系统计划，详细设计文档按模块计划，通过相关组参加评审的办法来协调接口设计。

以上例子的缺点分类只是为了描述方便，本身描述并非尽合理。

实际概念缺点分类可能有很多个维度，可以将前面所说的6种缺点发现方式发现的缺点，依照缺点严重程度、缺点来源、缺点类型、注入阶段、发现阶段、修复阶段、缺点性质、所属模块等方面进行分类和统计，计算以下各类缺点的散布情况。

（1）缺点按发现方式的散布；

（2）缺点按生命周期注入阶段的散布；

（3）缺点按生命周期修复阶段的散布；

（4）缺点按严重程度品级的散布；

（5）缺点按系统模块的散布，并按模块缺点密度排序。

 缺点本源分析

对于同行评审、测试出来的缺点进行缺点分类，依照其类型散布，找出那些关键的缺点类型，进一步分析其产生的本源，从而制定针对性的改良办法。

通过对功能上的散布情况进行分析，可以了解哪些模块处置比较难，哪些模块程序质量比较差，有利于程序质量的改良和提高。

缺点起源散布报告，显示了缺点产生的根本原因上的散布情况，这种分析会帮忙改良程序代码质量。

利用鱼骨图、柏拉图等分析缺点产生的根本原因，按照这些根本原因采取办法，可以改良开发和测试进程，有重点地避免缺点发生，提高软件产品的质量。

 缺点注入-发现矩阵

缺点有"注入阶段"和"发现阶段"两个重要指标，注入阶段和发现阶段可以是软件生命周期的各个阶段。

按照这两个阶段可以绘制出一个"缺点注入-发现矩阵"，从中分析出软件开发各个环节的质量，找到最需要改良的环节（见表7-7）。

表7-7 缺点注入-发现矩阵

缺陷注入阶段

缺陷发现阶段

需求

设计

编码

注入总计

需求阶段

4

4

设计阶段

13

62

75

编码、单元测试阶段

2

11

16

29

系统测试阶段

2

3

97

102

验收测试阶段

0

0

21

21

发现总计

21

76

134

231

本阶段缺陷移除率

19%

82%

12%

在分析例子之前，先简单介绍一下其中的一些大体概念。

缺点注入分析矩阵的每行表示该阶段或活动发现的各阶段产生的缺点数；矩阵的每列表示该阶段或活动注入的缺点泄漏到后续各环节的缺点数。

还可以通过修复阶段、缺点性质、所属模块这样的整理（这部份内容见上一节"缺点本源分析"），进一步扩展成缺点注入发现修复矩阵，可是此矩阵表现起来就不会像"缺点注入发现矩阵"那么直观了。

缺点移除率概念为：

缺点移除率=（本阶段发现的缺点数/本阶段注入的缺点数）100%

如需求阶段一共注入了21个缺点，需求评审时只发现了4个，设计进程中发现了13个，编码和单元测试阶段发现了2个，还有2个直到系统测试阶段才被发现。

这样，需求阶段的缺点移除率4/21100%19%。

它反映的是该活动阶段的缺点清除能力。

相应的还有一个概念就是"缺点泄漏率"，即有多少本阶段注入的缺点没有在本阶段发现而是被泄漏到后阶段环节才被发现。

其计算公式为：

缺点泄漏率=（下游发现的本阶段的缺点数/本阶段注入的缺点总数）100%

显然，它等于（1缺点移除率）。

它反映的是本阶段质量控制办法落实的成效。

从表7-7可以看到，编码进程的缺点大部份依赖系统测试发现。

很显然，项目开发进程中的单元测试和集成测试活动开展不够深切。

咱们可以进一步分析这些系统测试出来的测试缺点，是不是可以被更前端的评审/测试/设计讨论活动所替代。

另外，咱们看到，需求阶段注入的缺点绝大部份是在设计阶段发现的。

这可能是目前国内公司大部份项目的现实，需求不稳定、不明确，很多东西需要在设计进程中才能明确下来。

从分析结果也可以看出，在设计评审时，也需要从头审视需求规格说明书，必要时可利用需求追踪矩阵辅助发现上游需求的缺点。

固然，实际计划"缺点注入发现矩阵"时，可以依据自己的管理要求，对缺点的发现活动和注入阶段进行细分或粗分，而且在Bug系统中提交时，需要准确地填写这些属性字段。

 收敛趋势分析

进行趋势分析的前提是研发进程稳定，其质量表现大体一致，这样数据反映的趋势才具有可信度。

本节先给出一个比较常常利用的分析图（见图7-10），管理者可以从中发现一些简单的缺点发展趋势（这种缺点可以是本文论述的广义缺点发现手腕肯定的，也可以是单纯的测试手腕发现的），从而了解软件质量趋势。

更严格和准确的趋势分析图，可以参考节"质量控制工具"和节"统计技术应用"。

图7-10 缺陷发展趋势图

横轴（时间轴）：

若干个均匀的时间点，以天、周或月为单位，视项目的规模而定。

纵轴：

同一类性质的缺点数量的个数。

按照具体的缺点发现情况，可以绘制出如下4条曲线。

（1）发现数，累计的所有被发现的缺点数量。

（2）关闭数，累计的所有被关闭的缺点数量。

（3）日发现，当日（当期）发现的缺点数量。

（4）日关闭，当日（当期）关闭的缺点数量。

其中，发现数和关闭数是两条关键的趋势曲线。

对于利用如此分析的缺点趋势图，可以初步分析出如下几种情况。

（1）可以关闭的情况（见图7-11）

当发现数和关闭数两条曲线恰好聚集在一路时，表明所有发现的缺点都已经被关闭了，但此时仍然存在风险。

因为对于最新的这个版本，只完成了回归，还需要一些时间再进行最后一轮（乃至几轮）验证。

图7-11 可以关闭的趋势图

（2）暂时不能结束的状态（见图7-12）

图7-12 暂时不能结束的趋势图

图7-12中发现和关闭的缺点都比较少，两条曲线没有聚集，区间也还比较大，可是都很平。

可能是研发和几种缺点发现的效率都有了问题。

进展受到影响，关闭数的那条曲线很平，可能是发生了比较严重的技术难题，同时这个难题影响了测试进度（发现数曲线也很平，表明测试发现问题的进度也明显受到了影响）。

（3）无停止的情况（见图7-13）

图7-13 无休止的趋势图

发现数和关闭数两条线都呈上升趋势，而且都比较高，说明研发和缺点发现的效率都比较高。

可是，严重的是，两条线的开口愈来愈大，短时间内看不到聚集的趋势。

关闭数持续走高，代表了3种情况：

要么是产品代码质量不高，存在大量问题；要么是大量已关闭的问题又从头被打开；再有可能就是测试领导把关不严，致使重复提单。

此时，需要PPQA和管理人员介入，协助指导发现问题所在。

（4）比较理想的状态（见图7-14）

该图中，发现数和关闭数两条曲线已经聚集，并持续了一段时间，此时的产品质量应该视为比较稳定，可以批准对外发布。

图7-14 比较理想的趋势图

这是缺点发现关闭趋势图的几种典型状况解析，有利于在质量管理进程中及时观察现象，通过对进程的监控来降低产品质量风险。

 回归分析

所谓回归分析法，是在掌握大量观察数据的基础上，利用数理统计方式成立因变量与自变量之间的回归关系函数表达式（称回归方程式）。

在回归分析中，当研究的因果关系只涉及因变量和一个自变量时，叫做一元回归分析；当研究的因果关系涉及因变量和两个或两个以上自变量时，叫做多元回归分析。

另外，在回归分析中，又依据描述自变量与因变量之间因果关系的函数表达式是线性的仍是非线性的，分为线性回归分析和非线性回归分析。

通常线性回归分析法是最大体的分析方式，碰到非线性回归问题，可以借助数学手腕转化为线性回归问题处置。

回归缺点是由于修合法前缺点时而引发相关的、新的缺点，所以即便在测试阶段，也会产生新的缺点。

咱们的一个项目数据表明，严格地执行需求/设计评审和代码审查，可使开发质量有200%的提高，其因果分析表明，常有一些缺点本来可以在开发周期的初期发现，对缺点源数据的分析指出，代码开发阶段的缺点注入是最高的。

强烈重视评审和代码审查，使得审查覆盖率更高，效果更好。

可以分析开发和测试在人力资源的配比上是不是适当，可以分析出某个严重的缺点所造成的项目质量的波动。

对于异样的波动，如本来应该越测试越收敛的，但到了某个时间点处，发现的缺点数反而呈上升趋势，那么，这些点往往发生了一些特殊的事件。

例如：

（1）在该时间段，送测的回归版本增加了新的功能，致使缺点注入；

（2）该回归版本开发部没有进行集成测试就直接送测。

类似等等问题。

前面反复强调，越到后端发现的缺点，用于问题复现、问题定位和缺点修复花费的时间和本钱就越多，软件工程经济学中"1:

10:

100规则"也揭露了这种情况。

那么有什么方式可以在项目初期识别哪些活动没有充分投入，或没有运用适合的技术方式致使缺点被泄漏到下游，从而防范于未然呢？

咱们可以在组织的典型项目中运用必然的抽样原则，抽样出某个阶段的若干个缺点，从技术、流程、方式等方面去分析更适合、更经济的清除方式，然后把这些方式固化到日常的项目实施进程中，就可以够慢慢降低上游对后端的缺点泄漏。

下面以一个项目的系统测试阶段发现的故障为例，进行进程有效性回归分析，如表7-8 回归分析举例

实际发现活动

最佳发现活动

计数

百分比

系统测试

代码评审

2

14%

集成测试

7

50%

设计评审

4

29%

系统测试

1

7%

从表7-8可以看出，真正需要遗留到系统测试阶段才能发现的故障只有7%，大部份故障在集成测试和设计评审进程中就应该被发现。

致使在集成测试进程中未能充分发现这些缺点的原因主要有：

（1）测试环境不具有，致使部份测试项必需到系统测试阶段才具有测试条件；

（2）测试设计中某些测试项的缺失，需要增强测试设计的评审工作；

（3）在回归测试进程中，开发部只对测试进行了验证，而对缺点修复波及的范围缺乏分析和验证。

针对这些分析结论，咱们就可以够制定针对性的整改办法。

例如：

（1）增强开发部的