构型管理（Configuration Management）

构型管理，是一种分辨不同时点的系统配置的方法，它处理工作项或系统的物理特性和功能特征，并对这些特征的任何变更实施控制，审计这些工作项和系统以证实其与需求相一致，以确保项目产品描述的正确和完整。

构型管理的目标是系统地控制此构型发生的变化，并在系统的整个生命周期中保证此配置的完整性和可追溯性。

构型管理必须在项目刚开始的最早阶段就确定，最理想的时间是——项目开始。确定之后，在系统的整个生命周期内都要始终保持存在，以便在系统拆散之前，它仍可用于系统的维护。

一、构型管理的由来

要了解一个陌生的事物，最好的办法就是追本溯源，从它的产生及演变的历史入手，这样会得到一个比较全面的认识。

构型管理的概念最早来源于制造工业，尤其是在美国的国防工业中。当时开发的产品规模是比较小的，复杂程度也不高，在整个生产过程中所有的生产开发、设计和变更常常是由一个人或一组人来管理。但是后来，产品的复杂性开始增加，例如产品中增加了飞行器、坦克、枪支等等，此时，就不可能再由一个人或一组人来控制设计和生产。更重要的是，设计在不断地变化。此外，这些产品的开发可能经历几年，并由不同的人负责进行。当控制权从一个交给另一个人时，很可能丢失了一些相关的信息，因为没有正规的方法要求将文档、设计和在开发期间所做的修改记录下来。

在1962年，美国空军在做它的喷气飞机设计时，为解决控制和通讯问题，制定和发布了一个标准用于构型管理——AFSCM375-1，这是第一个用于构型管理的标准。美国军队和国防部的很多其它标准（MIL和DoD标准）都遵循这一标准而制定。

二、构型管理的基本概念

1．可辨体

构型管理中的可辨体，是在项目的开发中得到的某一部分组成了可辨体的构型，这种可辨体可能只有经过系统的批准和记录后，才能有所改变。这些可辨体可以是一系列要求、规定、操作手册、软件模块的纲要，部件硬件的图画，测试计划等，实际上任何可以分辨并以某种方式为产品的最终使用做出贡献的都是可辨体。

2．构型

构型一词指可辨体的全体及其相互关系。

构型管理的一个关键是了解构型中哪一部分依赖于另一给定部分。例如：在冰箱的设计中，门把手的说明书可能与门的说明有关，但与冰箱的其他很多部分无关，如马达。了解这种依赖关系，将有利于界定任何一部分所发生变化的影响范围。

构型随着个部分的开发逐渐形成，项目刚开始时，构型由说明项目范围的文件组成要求说明。从定义看，一旦此规定正式成为构型的一部分，它就得经过变化控制程序后才能改变。

注意：构型不包括尚在形成中的部分，对仍在积极开发的部分实施变化控制的工作量太大。因此，在开发过程中，“构型”仅由所有已确定的设计部分组成。

设计客体尚不属于构型的一部分，因为它们天天都在变，尚未达到进行适当变化控制的充分成熟程度。

3．构型项

构型项属于构型之内的部分，这些已确定的部分及其以后的进度都会被记录，它们在尚未授权的情况下不会发生变化。

从变化控制的角度来看，我们仅关心构型项；设计者仍有随意支配设计客体的自由。保持对设计客体的变化的跟踪是设计者自己的责任，其他人则没有必要知道这些变化。

在项目组成员之间就相互依赖的部分的交接达成一致并定义为构型项是很有用的。仍旧是制造冰箱的例子，如果冰箱门和门把手是单独设计的，首先就门把手怎样安装在门上达成协议是合理的。这样，门把手设计者和门的设计者才能独立进行设计。这种对交界处的一致规定将成为两类设计者共同依赖的构型项，没有双方的一致同意，就不会发生变化。如果出现其他需要达成一致的时间，在此之前，互相依赖的部分中的某一方的设计无法继续，则我们可能需要添加另一些规定。

4．基线

基线是构型管理中的另一个重要的术语。基线是开发过程中某特定时点的构型状态或某个已明确的构型项，这些时点通常在系统生命周期的大里程碑处。基线可能定义为某时点的一系列受到变化控制的已知构型项，并已取得相关各方的同意，其后的进度可以以此为基点详细计划。

项目中的基线可以提前在客户和承包商的磋商下确定，以使项目的状态具有更高的可见度。

基线不一定用于整个构型，它可能仅用于构型中已定义好的部分。这使基线的运用相当灵活，因为系统的所有部分不必同时达到设定基线。

任何给定的基线必须唯一界定，以使调查基线情况的任何人都有一个确定的起点。

三、构型的构筑方法

大部分项目都是从上至下一级一级地构筑的，即先形成项目的高层设计，然后分为低层次的、还可再分的设计部分。这种设计和构筑方法适用于大部分有形的物体和系统。在每一个层次的每一个部分中，各部分应该区分开来，使它们的概念和实施方法可以由个别项目团队成员掌握。项目的设计结构就是选择构型项的现成基础。

评估变化的影响时，主要的焦点很自然的放在直接依赖于变化的部分所受的影响，但这样极易导致变化的蔓延。从变化控制角度来看，最令人满意的设计应该将各部分之间的关联减至最少。

对构型控制来说，将各部分细分既有好处又有坏处。将构型项细分为更小的可区别的部分，其好处是任何变化要求都能更准确地集中于相关领域。然而，超过了一定的详细程度后，进一步细分就会导致相反的效果。分辨各部分的高准确度的好处会被过低层次的细分项容量及解释集中于过细的细节变化的困难所抵消。

四、构型管理的组成要素

构型管理主要由四大因素构成：构型鉴别、构型控制、构型情况报告和构型审计。

A、构型鉴别

构型鉴别，为了确定一套要求变化的有效办法，在构型中必须采用清晰的鉴别系统。因此，一旦选定构型的结构和控制单位，就必须区分每一项，使系统的每一部分都独一无二，并登记其代号，登记代号的行为即称为构型鉴别。不难看出构型鉴别的目的是单独的分辨所有构型项。

构型中，要求每一项都身份唯一，并一直保持一致，几个人会不同程度的参与某一项的工作，一旦其身份改变，就会引起混乱。只要做到唯一性和一致性，选择哪一种鉴别系统并不重要。通常是将每一项的身份分解为“名字”和“参考版本号”。

在选择各部分的名称时，最好选择那些既适当又简短的名称，但这些名称必须是唯一的并且是有意义的。由象课文段落一般的段落构成的名称冗长难记，而仅有一个字的名称又没有意义。在大型项目中，命名方法必须提前做好计划，以防未来出现名字发生冲突的问题。

此外，每一项构型项都需要以某种方式标出来，以代表其身份。标签表示这一实体部分是构型登记册中记录的某部分。文件的标签通常为文件名和写在某显眼处的版本号，实体部分的标签则可能是一种身份标记或在制造过程中刻上去的某种标志。关键在于要用标签来毫无疑义的代表此客体，将其与构型登记册中的身份对应起来。

但是多个构型的情况是存在的，这就是说，使硬件或软件的一个以上构型并存往往是必要的。例如，当你设计电冰箱时，你可能需要在欧洲使用的一种构型和在美国使用的另一种构型。这些并存的构型通常称为变异形式，各种构型之间并不互相替代，而是并存。

出现不同形式的构型的另一种情况是产品有所改善或者随时间发生了变化时。此时，新构型会代替旧构型。但是，若老产品仍然存在，就必须保留其旧构型。

B、构型控制

指一种用来保护构型的过程，它使各部分只有经过确保对变化影响进行分析的程序后才能改变。保护构型，是说一旦某部分被作为构型项，它就需要被保护。保护它不会在未经授权的情况下被改变和保护它免于受到意外毁坏。提供这种保护的通常方式是建立档案处或构型储存处，即一种保存构型项的有形场所。

变化控制的实质是构型项的所有变化都要求被授权负责控制此部分的构型控制者事先批准。

控制项目等级最高层次变化的典型权力机构是变化控制委员会，它由下列人员组成：

（i）客户方的技术代表；

（ii）客户方的商业代表；

（iii）项目经理（来自承包组织）；

（iv）高级设计员。

使用构型管理进行变化控制的机制的基本运作步骤如下：

1．要求者发现变化的必要性，并向构型管理员提出变化要求和交待理由。

2．管理员记下要求，并送交相应的配置控制者。

3．配置控制者任命某人去分析变化的可行性及其影响。

4．分析员向受到潜在影响的设计员和用户咨询，并把分析结果交给控制者作决策用。

5．配置控制者批准或不批准变化。

6．管理员记录决策，并向所有相关人员报告。

7．项目经理或小组领导任命某人执行变化。

8．执行者向管理员报告变化的完成情况。

9．配置控制者认可新的配置。

10．管理员记录和公开新的配置情况。

关于这个机制，似乎有很多人参与：要求者、构型管理员、配置控制者、分析员和执行者，这些不一定是不同的人，而仅仅是要履行的职能名称。在决策之前，必须分析变化的影响，所有重大事件都要记录并公布。

当变化的建议提出时，应该首先分析该变化可能产生的影响。由谁来分析所建议变化的影响在很大程度上取决于变化的范围，变化的范围通常由变化部分在配置等级中的位置来反映。

为了决定是否应该实施某变化，下列工作是必要的：

1．评估变化的效用和不进行变化的后果；

2．预测和分析变化是否会影响整个系统以及每一种影响可能是什么样的：从系统用户的角度来看问题往往特别有用；

3．评估原来的变化会要求设计的哪些其他部分也有所改变，以及变化在设计层级的每一层的衍生结果可能是什么；

4．评估变化对完成项目的总成本和总时间的影响。

C、构型情况记录

目的是为了保持对开发中的系统所发生的一切的记录，以便于和开发计划作比较并保持可追溯性。

数据库中保存的记录包括：

1．新构型项的产生以及负责其变化控制的人或机构；

2．事故报告（即可能造成变化要求的错误报告）

3．变化要求

4．批准/拒绝变化的决定

5．变化通知（构型项改变后公布）

6．更新系统本身储存的构型项

7．基线构型

D、构型审计

目的是要审查各部分产品是否按当前的规定生产，所有应到位的质量保证程序是否已确实充分的实施，尽管要求和设计可能会发生变化。

要使审计可行，就必须区分产出的每一部分产品，并记录为制造此产品而进行的所有活动。

审计工作应该能确保正确实施和记录变化。

使用手工的变化控制程序，常常会出现产成品与其规定之间的差别，这是审计工作应该发现的。

五、构型管理中应该注意的几个问题

1．积极主动的控制

如果构型管理纯粹是一种被动体系，它就不可能有效。项目经理需要实施积极主动的控制，一是为了保证设计客体在适当的时候被置于控制之下，而是为了确保其他组员使用的构型项版本尽可能为刚经过批准的最新版本。

2．选时

对某部分实施变化控制的选时非常关键。实施过早，变化控制会通过引入对变化的控制而减缓这部分工作的进度；实施过晚，变化控制的缺乏会导致各部分之间的混乱。项目经理必须在考虑这部分工作的变化率和其他组员的要求的前提下，判断使这部分工作接受变化控制的最佳时点。

3．检查点（checkpoints）

理想的安排是设计者应该与项目经理商定工作过程中的一系列时点。在这些时点处，作为控制基础的最新版本必须更新。但是在使用过多检查点造成效率低下和检查点过少会导致必要工作未实施的风险之间，存在一种权衡关系。

如果要在合理的时间内采用最新版本，就有必要建立某种检查在用版本的程序。三种可能程序如下：

（1）．规定一个时点，要求所有项目组员必须同时换用刚刚被批准的最新版本，如“每周星期四早上7点”。这种方法最容易执行，但是它要求所有人在同一时刻停止各自的假设过程和测试循环：这样做不是总能够实现对人员的最佳利用。

（2）．检查人们正在使用的版本并实施一种定时原则，如“对已存在后续版本的旧版本，继续使用不能超过两周”。

定时的方法很实用，但要依赖于项目经理说服开发人员自律的能力，它执行起来相当方便，但你不能保证所有人都同步。

（3）．检查人们正在使用的版本，根据当时情况判断其使用是否合理。

这种方法最友好，但执行起来也最难，因为它在较大程度上依赖于人员之间的关系和明智的决策。除非这种检查工作授权给其他人完成，否则会占用项目经理大量的时间。

具体项目选择哪种程序将取决于项目经理对开发小组的信心和维持同步工作的重要性，同时还取决于项目经理有多少时间可以用于工作检查。