变更管理是软件工程的基本活动之一。需求变更驱动设计变更，设计变更又会影响代码。然后，测试会发现导致进一步变更的问题，有时甚至是原始需求的变更。变更过程从概念上讲十分简单，但在细节上却十分复杂。即使是中等规模的项目，参与的人员和变更的数量也都较大，因此一般需要用一个正式的变更管理系统。这正是引入软件配置管理的原因。
软件过程的一个关键目标是在最终产品足够稳定可以交付之前集中变更活动，所以对所有变更进行管理十分重要。本章主要关注代码控制，这是初期需要关注的最实际的问题。需求和设计变更的控制同样十分重要，但这些功能通常可以视为代码管理系统的增强因素，与之有关的详细讨论，参见第12章。
1、配置管理的意义
最令人头疼的软件问题往往是配置管理不善造成的。这些问题之所以令人头疼，是因为它们需要时间去确定，经常在最糟的时刻发生，而且是不必要的。例如，一个已花较大精力和成本修复的高难度软件错误突然再次出现，一个已开发和测试的特征神秘消失，或者已通过全部测试的软件突然瘫痪。配置管理通过协调同一项目中不同人员的工作产品来帮助我们减轻这些问题。缺乏这种控制，同一项目中不同人员的工作就会发生冲突，结果导致如下问题[1]：
● 同时更新。当两个或更多的程序员独立开发统一软件时，最后一个人所作的变更很容易损害其他人的工作。
● 共享代码。当共享代码中的一个错误得以修复时，常常不能让共享代码的所有人都知道。
● 公共代码。在大型系统中，当修改通用软件功能时，所有使用公共代码的人都有必要知道。但如果缺乏有效的代码管理，就无法保证一一找到并提醒每个使用者。
● 版本。很多大型软件的发布是以渐进式发布的方式进行开发的。一个发布版本交付用户使用的同时，另一个版本还在测试中，可能第三个版本正处于开发阶段，错误的修补必须周到地考虑所有这些版本。例如，如果客户发现了错误，那么，在随后的所有版本中，都需要修复这个错误。同样，如果在正在开发的版本中发现了错误，就需要修复包含这一错误的以前的版本。在大型系统中，可能会同时发布多个活动版本，参与错误修复和软件增强的人员很多，这样很容易产生冲突和混沌。
这些问题由混沌和缺乏控制引起的，处理它们可能会耗费大量的时间。解决方案便是要有一个能回答以下问题的控制系统：
● 我目前的软件配置是什么？
● 状态如何？
● 如何控制配置的变更？
● 如何将我的配置变更通知其他每个人？
● 我的软件经过了哪些变更？
● 其他人的变更会影响我的软件吗？
软件配置管理（Software Configuration Management，简称SCM）的关键任务是控制变更活动，以便回答这些问题。如果仅仅将SCM视为一个管理工具或者合同规定的义务，它就很容易变成有碍工作的、官僚性的绊脚石。虽然很多合同会提出对SCM的要求，但是，我们需要变更管理的真正目的是，为程序员控制和跟踪自己的工作提供支持，同时确保不会出现遗漏或对工作和软件造成损害。
2、软件产品术语
由于配置管理的任务是在构建系统元素、然后将其集成为一个整体系统时控制系统元素的开发，因此，使用统一的系统术语十分重要。设计过程从成功分解系统开始，直到获得一个令人满意的细节。在这一点上，实现从最小的这些元素开始，逐一组装和测试，直到完成整个系统。对于这些中间级别没有标准的命名法则，我们将使用图7.1中的术语：
● 系统：满足用户要求的所有软件组成的软件包。
● 子系统：大型系统包括很多子系统，如通信、显示和处理等。
● 产品：典型的子系统包括很多产品。例如，一个操作系统可能包括控制程序和编译器、实用程序等。
● 组件：在下一层，一个控制程序由监控、调度程序、输入/输出控制系统等组件构成。
● 模块：在最底层，组件是由一些模块组成的。模块实现相对较小、自包含的独立功能，如队列管理、中断调度程序、命令解释程序等。
在实现过程中，同时发生两件事情。第一，从详细设计、实现到系统测试，模块不停地被开发、加强、测试和修改，第二，逐渐将模块组装成组建、产品、子系统和系统。在开发过程中，模块将不断变更以增加功能和修改存在的问题。通过不同层次的一套测试支持这一过程：
● 单元测试 对每个模块进行的独立测试。
● 集成测试 随着模块组装成组件、产品、子系统和系统，对其接口和相互关系进行测试，确保设计和实现正确。
● 功能测试 当集成为一个功能上可操作的版本时，可以成功地进行组件测试、产品测试、子系统测试和最终的系统测试。
● 回归测试 在集成的每一步（这里称之为一次编造）会产生一个新的构造，首先要进行测试，以确保它没有回归，或说没有丢失上一个版本具有的功能。
虽然不同组织可能赋予这些活动不同的名称，但基本过程是一致的。第11章将详细讨论各个测试阶段。
