1.6.4 缺陷预防的活动

缺陷预防的活动在软件开发活动中体现为对需求管理、配置管理以及变更管理等各个软件开发的关键过程进行预防和控制，以确保过程的有效和成果的合格，本书将对这几个过程分章节专门讲述。

其他的缺陷预防方法，如模式、复用和重构等技术方面内容在这里简单介绍一下。

模式：模式是技术的回归，从不断重复出现的事件中发现和抽象出的规律，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。为了可重用代码，让代码更容易被他人理解，保证代码可靠性，它使代码编制真正工程化，标志了对象之间隐藏的规律关系，强调的是形式上的规律，而非实质上的规律。一般包括开发模式、设计模式等。目前使用较多的是设计模式，设计模式是用以解决在特定设计情况下出现的重复设计问题，并给出该问题的一种解决方案，它描述了对象之间是如何通信的，而且彼此的数据模型和方法没有任何牵连。例如，工厂方法、参观者、代理等设计模式。

软件复用：就是将已有的软件成分用于构造新的软件系统。可以被复用的软件成分一般称为“可复用构件”，无论对可复用构件原封不动地使用还是做适当的修改后再使用，只要是用来构造新软件，这些活动都可称做复用。软件复用不仅仅是对程序的复用，还包括对软件生产过程中任何活动所产生的制成品的复用，如项目计划、可行性报告、需求定义、分析模型、设计模型、详细说明、源程序、测试用例等。软件复用一般包括复用专家经验（从其他软件中所学到的知识或者经验）、复用设计标准（架构复用通过实现符合框架要求的接口来替换原有的功能或者添加新的功能）、复用标准算法、复用各种构件（公司已有的构件或者外购构件，也包括测试信息的复用，如测试用例、测试过程信息等）。

重构：在不改变代码外在行为的前提下，对代码进行修改，以改进代码的内部结构的过程。经过重构可以使软件模块易于阅读和修改。软件产品制造之初，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，需要不断地修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免地要违反最初的设计架构。经过一段时间以后，软件的架构就千疮百孔了。此时，软件的架构对新的需求渐渐地失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。重构就能够最大限度地避免这样一种现象发生。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新整理。通过重构，不断地调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。

任何缺陷预防的手段，必然是上面管理方式和技术方法的一个有机结合体。

具体的某种缺陷预防过程，一般都可以分为如下活动步骤：

（1）软件项目为其缺陷预防活动开发和维护一个计划。

（2）在软件任务的开始阶段，有关人员要共同研讨任务活动和相关的缺陷预防活动。

（3）根据文档化的过程定期召开分析会议。

（4）组织要定期开会来检查和协作完成会议上所制订计划的实施工作。

（5）对缺陷预防活动进行有效度量，获得的数据要记录，并由负责缺陷预防活动的组织或人员进行跟踪。

（6）根据缺陷预防活动的结果而对组织标准过程进行修改。

（7）根据缺陷预防活动的结果而对项目定义好的软件过程进行修改。

（8）开发组和相关组定期接受缺陷预防活动的反馈。

分析共性的用户错误，必要时更新文档：当大量的缺陷被分类成用户错误后，很可能是由于产品文档不太清楚。用户错误发生时的数量相对较高时，应该对产品所有相关文档进行检查，包括用户手册和联机帮助，确保清除任何的误导和二义性描述。

分析共性的用户错误，必要时更改产品：当大量的缺陷被分类成用户错误后，也可能不是文档不清楚，而是对产品需求最初的理解不清楚。用户错误发生的数量相对较高时，可能有必要更改产品的设计以和用户预期的行为匹配。

进行问题根本原因的范围分析，并清楚该范围内的代码：当一个问题反复来自一个范围时，它预示着有周期性的不同人员维护所造成的意大利面条似的代码。当产品某个部分有超过一定数量限度的缺陷被改正后，重新审视这部分的代码或设计，并重写、重构是比较好的办法。

加强对关键/经常出现的缺陷回归测试：当某些范围被确定为容易发生错误时，针对它们需要进行更深入的回归测试。