|
|
|
按国际标准ISO9000的说法，配置管理是一个管理学科，它对配置项的开发和支持生存期给予技术和管理上的指导。配置管理的应用取决于项目的规模、复杂程序和风险大小。
|
|
|
|
《软件工程术语》国家标准GB/T 11457—1995给配置管理下了定义：配置管理是标识和确定系统中配置项的过程，在系统整个生存期内控制这些配置项的投放和更动，记录并报告配置的状态和变动要求，验证配置项的完整性和正确性，并对下列工作进行技术和行动指导与监督的一套规范：
|
|
|
|
（1）对配置项的功能特性和物理特性进行标识和文件编制工作。
|
|
|
|
|
|
|
|
CMMI对配置管理的定义：配置管理的目的在于运用配置标识、配置控制、配置状态和配置审计，建立和维护工作产品的完整性。CMMI把配置管理分为9大部分，分别是制定配置管理计划、识别配置项、建立配置管理系统、创建或发行基线、跟踪变更、控制变更、建立配置管理记录、执行配置审核、版本控制。
|
|
|
|
《信息技术——软件生存周期过程》国际标准ISO/IEC 12207：1995所规定的软件配置管理过程的活动有过程实施、配置标识、配置控制、配置状态报告、配置评价、发行管理和交付。
|
|
|
|
|
|
配置管理的活动主要有编制项目配置管理计划、配置标识、变更管理和配置控制、配置状态说明、配置审核，以及进行版本管理和发行管理。
|
|
|
|
（1）编制项目配置管理计划。在项目启动阶段，项目经理首先要制定整个项目的开发计划，它是整个项目研发工作的基础。配置管理计划是项目管理计划的一部分，通常要涉及该项目对配置管理的要求，实施配置管理的责任人、责任组织及其职责，开展的配置管理活动、方法和工具等。
|
|
|
|
（2）配置标识。配置标识是配置管理的基础性工作，是管理配置管理的前提。配置标识是确定哪些内容应该进入配置管理形成配置项，并确定配置项如何命名，用哪些信息来描述该配置项。
|
|
|
|
（3）变更管理和配置控制。配置管理的最重要的任务就是对变更加以控制和管理，其目的是对于复杂，无形的软件，防止在多次变更下失控，出现混乱。
|
|
|
|
（4）配置状态说明。配置状态说明也称为配置状态报告，它是配置管理的一个组成部分，其任务是有效地记录报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
|
|
|
|
（5）配置审核。配置审核的任务便是验证配置项对配置标识的一致性。软件开发的实践表明，尽管对配置项做了标识，实现了变更控制和版本控制，但如果不做检查或验证仍然会出现混乱。配置审核的实施是为了确保软件配置管理的有效性，体现配置管理的最根本要求，不允许出现任何混乱。
|
|
|
|
（6）版本管理和发行管理。版本控制用于将管理信息工程中生成的各种不同的配置的规程和相关管理工具结合起来。配置管理中，版本包括配置项的版本和配置的版本，这两种版本的标识应该各有特点，配置项的版本应该体现出其版本的继承关系，它主要是在开发人员内部进行区分，另外还需要对重要的版本做一些标记，如对纳入基线的配置项版本就应该做一个标识。
|
|
|
|
|
|
配置标识是配置管理的基础性工作，是配置管理的前提。配置标识是确定哪些内容应该进入配置管理形成配置项，并确定配置项如何命名，用哪些信息来描述该配置项。
|
|
|
|
|
|
信息系统项目中形成的技术性文档和管理性文档，除一些临时性的文档外一般都应该进行配置管理。一般来讲，判定一个文档是否进行配置管理的标准应该是此文档是否有多个人需要使用，这些文档往往在项目的进程中不断地修正和扩展，要保证每个使用者都使用同一版本的文档，就必须将这些文档纳入配置管理，成为受控的配置项。
|
|
|
|
（1）识别配置项。可能成为配置项组成部分的主要工作产品有过程描述、需求、设计、测试计划和规程、测试结果、代码／模块、工具（如编辑器）、接口描述等。在软件工程方面，Roger S. Pressman认为至少以下所列的文档应该成为配置项：系统规格说明书、项目计划、需求规格说明书、用户手册、设计规格说明、源代码、测试规格说明、操作和安装手册、可执行程序、数据库描述、联机用户手册、维护文档、软件工程标准和规程。
|
|
|
|
（2）配置项命名。确定了配置项后，还需要对配置项进行合理、科学的命名。配置项的命名绝不能随意为之，必须满足唯一性和可追溯性。一个典型的实例是采用层次式的命名规则来反映树状结构，树状结构上结点之间存在着层次的继承关系。
|
|
|
|
（3）配置项的描述。由于配置项除了名称外还有一些其他属性和与其他配置项的关系，因此它可以采用描述对象的方式来进行描述。每个配置项用一组特征信息（名字、描述、一组资源、实现）唯一地标识。配置项间的关系有整体和部分的关系及层次关系，也有关联关系。配置项间的关系可以用MIL语言（Module Interconnection Language）表示。MIL描述的是配置项间的相互依赖关系，可自动构造系统的任何版本。
|
|
|
|
（4）识别配置项的步骤。识别配置项的主要步骤如下：
|
|
|
|
|
|
|
|
.确定每个配置项的重要特征。配置项的特征主要包括作者、文档类型、代码文档的程序设计语言。
|
|
|
|
|
|
|
|
|
|
.审批配置管理表。CCB审查配置管理表是否符合配置管理计划和项目计划文档的规定，审批配置管理表。
|
|
|
|
|
|
基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段性产品。
|
|
|
|
建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。
|
|
|
|
作为阶段工作的正式产品，基线应该是稳定的，如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿，就不能作为基线，不能被冻结。
|
|
|
|
如果把软件看作是系统的一个组成部分，以下3种基线最受人们关注的：功能基线、分配基线、产品基线。
|
|
|
|
（1）功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
|
|
|
|
（2）分配基线（指派基线）：指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
|
|
|
|
（3）产品基线：指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
|
|
|
|
另外，交付给外部顾客的基线一般称为发行基线，内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
|
|
|
|
：提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。
|
|
|
|
|
|
在配置管理中，要建立并维护配置管理系统和变更管理系统。建立配置管理系统的主要步骤如下：
|
|
|
|
（1）建立适用于多控制等级配置管理的管理机制。生存周期中不同时间所需的控制等级不同，不同的系统类型所需的控制等级不同，满足专属性和安全性方面的不同的控制等级。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（7）保护配置管理系统的内容。配置管理系统的主要功能有文档的备份与恢复、文档的建档、从配置管理的差错状态下复原。
|
|
|
|
（8）权限分配。CMO的权限最高，一般项目成员可拥有添加、检入／检出、下载的权限，但是不能有删除的权限。
|
|
|
|
|
|
|
|
（1）获得CCB的授权。CMO根据项目进展情况或项目组的要求和基线计划规定，提出创建基线的书面请求，提请CCB授权。
|
|
|
|
|
|
|
|
|
|
|
|
变更是指在信息系统项目的实施过程中，由于项目环境或者其他的各种原因对项目的部分或项目的全部功能、性能、架构、技术、指标、集成方法和项目进度等方面做出改变。项目变更是正常的、不可避免的。在项目实施过程中，变更越早，损失越小；变更越迟，难度越大，损失也越大。项目在失控的情况下，任何微小变化的积累，最终都会对项目的质量、成本和进度产生较大影响，这是一个从量变到质变的过程。
|
|
|
|
|
|
|
|
（2）项目总体设计、项目需求分析不够周密详细，有一定的错误或遗漏。
|
|
|
|
（3）新技术的出现，设计人员提出了新的设计方案或新的实现手段。
|
|
|
|
（4）建设单位由于机构重组等原因造成业务流程的变化。
|
|
|
|
|
|
配置库也称为配置项库，是用来存放配置项的工具。配置库记录与配置相关的所有信息，其中存放受控的配置项是很重要的内容，利用库中的信息可评价变更的后果，这对变更控制有着重要的意义。
|
|
|
|
|
|
（1）开发库（development library）。存放开发过程中需要保留的各种信息，供开发人员个人专用。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其做任何限制。因为这通常不会影响到项目的其他部分。开发库对应配置管理系统中的动态系统（开发者系统、开发系统、工作空间）。
|
|
|
|
（2）受控库（controlled library）。在信息系统开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的，以及人工可读的文档资料。应该对库内信息的读写和修改加以控制。受控库也称为主库，对应配置管理系统中的主系统（受控系统）。
|
|
|
|
（3）产品库（product library）。在开发的信息系统产品完成系统测试之后，作为最终产品存入库内，等待交付用户或现场安装。库内的信息也应加以控制。产品库也称为备份库，对应配置管理系统中的静态系统（受控系统）。
|
|
|
|
作为配置管理的重要手段，上述受控库和产品库的规范化运行能够实现对信息系统配置项的管理。
|
|
|
|
|
|
变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件，责任追踪，以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。在审批变更时，要加强对变更风险和变更效果的评估，并选择对项目影响最小的变更方案，尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑，形成整体。
|
|
|
|
|
|
变更控制委员会（Change Control Board，CCB）也称配置控制委员会（Configuration Control Board），其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，可以根据工作的需要组成，其中的人员可以全职的，也可以是兼职的。
|
|
|
|
如果CCB除控制变更以外，还要承担更多的配置管理任务，那就应该包括基线的审定、标识的审定，以及产品的审定，并且可能实际的工作需分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。
|
|
|
|
|
|
|
|
①变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
|
|
|
|
②变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
|
|
|
|
③变更决策。由具有相应权限的人员或机构决定是否实施变更。
|
|
|
|
④变更实施。由管理者指定的工作人员在受控状态下实施变更。
|
|
|
|
⑤变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
|
|
|
|
⑥沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。
|
|
|
|
变更申请需要采用书面的形式提出，主要内容有如下3个方面：
|
|
|
|
①变更描述。包括变更理由、变更的影响、变更的优先级等，就是要描述做什么变更，为什么要做，以及打算怎么做的问题。
|
|
|
|
②对变更的审批。对变更的必要性、可行性的审批意见，主要是由配置管理员和CCB对此项变更把关。
|
|
|
|
|
|
|
|
配置项可以有3种状态，分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来，对于其他配置项来说是处于不处理工作状态下（自由状态），此时它并未受到配置管理的控制，开发人员的变更并未受到限制。但当开发人员认为工作已告完成，可供其他配置项使用时，它就开始于稳定。把它交出评审，就开始进入评审状态；若通过评审，可作为基线进入配置库（实施检入），开始冻结，此时开发人员不允许对其任意修改，因为它已处于受控状态。通过评审表明它确已达到质量要求；但若未能通过评审，则将其回归到工作状态，重新进行调整。配置项的状态变化过程如下图所示。
|
|
|
|
|
|
|
|
处于受控状态下的配置项原则上不允许修改，但这不是绝对的，如果由于多种原因需要变更，就需要提出变更请求。在变更请求得到批准的情况下，允许配置项从库中检出，待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。
|
|
|
|
|
|
在配置管理中，所有的配置项都应列入版本控制的范畴。对于信息产品的版本有两个方面的意思，一是为满足不同用户的不同使用要求，如用于不同运行环境的系列产品。如适合Linux、Windows、Solaris用户的软件产品分别称为Linux版、Windows版和Solaris版。它们在功能和性能上是相当的，原则上没有差别，或者说，这些是并列的系列产品。对于这类差别很小的不同版本，互相也称为变体（variant）。
|
|
|
|
另一种版本的含义是在信息系统产品投产使用后，产品经过一系列的变更，如纠错，增加功能，提高性能，而形成的一系列的顺序演化的产品，这些产品也称为一个版本，每个版本都可说出它是从哪个版本导出的演化过程。
|
|
|
|
必须注意到，修正后的新版本往往不能完全代替老版本，尽管新版本有某些优越的特性。因为一些用户仍然使用着老版本，并且不能立刻做到以旧换新，否则可能会打扰老版本原有的工作环境。显然，多个版本被多个用户同时使用的情况是不可避免的现实，这就要求多个版本共存，这也就是配置管理要解决的一个重要课题。
|
|
|
|
配置项的状态通常有3种，分别是草稿、正式发布和正在修改。一般来说，配置项版本控制的流程如下：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
版本管理要解决的第一个问题是版本标识，也就是为区分不同的版本，要给它们科学的命名。通常有两种版本命名的方法，分别是号码版本标识和符号版本标识。其中号码版本标识以数字表示，如用1.0，2.0，1.2，2.1.1等表示版本号；符号版本标识是将重要的版本属性有选择地给出，如Windows XP、Windows 2003、Jbuilder 2005将版本产生的时间给出。为了从版本标识上看到更多信息，可能给出更多的属性，如面向的客户群、开发语言、硬件平台、生成日期等。
|
|
|
|
在配置管理中，版本包括配置项的版本和配置的版本，这两种的版本的标识应该各有特点，配置项的版本应该体现出其版本的继承关系，它主要是在开发人员内部进行区分。另外，还需要对重要的版本做一些标记，如对纳入基线的配置项版本应该做一个标识。
|
|
|
|
|
|
配置审核的任务是验证配置项对配置标识的一致性。信息系统开发的实践表明，尽管对配置项做了标识，实践了变更控制和版本控制，但如果不做检查或验证仍然会出现混乱。这种验证包括：
|
|
|
|
（1）对配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象。
|
|
|
|
|
|
（3）变更控制规程是否已遵循，变更记录是否可供使用。
|
|
|
|
（4）在规格说明、信息系统产品和变更请求之间是否保持了可追溯性。
|
|
|
|
配置审核工作主要集中在两个方面，一是功能配置审核，即验证配置项的实际功效是与其信息系统需求是一致的；二是物理配置审核，即确定配置项符预期的物理特性。这里所说的物理特性是指定的媒体形式。
|
|
|
|
配置审核要选择适当的时机，由项目经理决定何时进行配置审核工作。一般来说，应该选择以下几种情况实施配置审核：
|
|
|
|
|
|
|
|
|
|
实施配置审核的审核人员可以包括项目组人员及非项目组人员，例如，其他项目的配置管理人员、组织的内部审核员，以及组织的配置管理人员。
|
|
|
|
配置审核的目的就是要证实整个项目生存期中各项产品在技术上和管理上的完整性。同时，还要确保所有文档的内容变动不超出当初确定的信息系统要求范围。使得配置具有良好的可跟踪性。这是项目变更控制人员掌握配置情况、进行审批的依据，除了进行配置审核外，还可以进行正式技术评审。
|
|
|
|
正式的技术评审着重检查已完成修改的配置项的技术正确性，评审者评价配置项，决定它与其他配置项的一致性，是否有遗漏或可能引起的副作用。正式技术评审应对所有的变更进行，除了那些最无价值的变更之外。
|
|
|
|
配置审核作为正式技术评审的补充，评价在评审期间通常没有被考虑的配置项的特性。在某些情形下，配置审核的问题是作为正式技术评审的一部分提出的。但是当配置管理成为一项正式活动时，配置审核就被分开，而由质量保证小组执行了。
|
|
|
|
|
|
配置状态报告是配置管理的一个组成部分，其任务是有效地记录报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。为了清楚、及时地记载配置的变化，不致于到后期造成延误，需要对开发的过程作出系统的记录，以反映开发活动的历史情况，这就是配置状态记录。该项活动主要是完成配置状态报告的编制工作。
|
|
|
|
在配置状态报告中，需要对每一项变更进行详细的记录，包括发生了什么？为什么会发生？谁做的？什么时候发生的？会有什么影响？整个配置状态报告的信息流如下图所示。
|
|
|
|
|
|
|
|
正如上图所示，每次新分配一个配置项或更新一个已有配置项或更新一个已有配置项的标识，或者一项变更申请被变更控制负责人批准，并给出了一个工程变更顺序时，在配置状态报告中就要增加一条变更记录条目，一旦进行了配置审计，其结果也应该写入报告中。配置状态报告可以放在一个联机数据库中，以便开发人员或者维护人员可以对它进行查询或修改。此外在配置报告中新记录的变更应当及时通知给管理人员和其他工程师。
|
|
|
|
配置状态报告对于大型开发项目的成功起着至关重要的作用。它提高了所有开发人员之间的通信能力，避免了可能出现的不一致和冲突。它通过支持创建和修改记录、管理报告配置项的状态或需求变化并审核变化来实现，它提供用户需要的功能，跟踪任意模式的软件项，提供完整的各种变化的历史版本和汇总信息。
|
|
|
|
|
|
（1）各变更请求概要：变更请求号、日期、申请人、状态、估计工作量、实际工作量、发行版本、变更结束日期。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在变更请求批准后，实施变更需要一段时间，要设置一种管理手段来反映变更所处的状态，这就是变更状态说明，它可供项目经理和CCB追踪变更的情况。状态说明的信息可以通过变更请求和故障报告得到，变更状态可分为活动（正在实施变更）、完成状态（已完成变更）和未列入变更状态3种。
|
|
|
