项目管理-软件配置管理-CSDN博客

每个配置项的主要属性有名称、标识符、状态、版本、作者、日期等。配置项是一个独立存在的信息项，可以把它看成一个元素，单独的一个元素发挥不了什么作用，但随着工作的进展，出于不同的要求，需要将这些元素进行不同的组合，这个组合称为配置。配置是一个信息系统产品在生存期各个阶段的不同形式(记录特定信息的不同媒体)和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合，它具有完整的意义。

2.2.2 确定配置项

软件项目中形成的技术性文档和管理性文档，除一些临时性的文档外一般都应该进行配置管理。一般来讲，判定一个文档是否进行配置管理的标准应该是此文档是否有多个人需要使用，这些文档往往在开发的过程中不断地修正和扩展，要保证每个使用者都使用同一版本的文档，就必须将这些文档纳入配置管理，成为受控的配置项。

2.2.2.1 识别配置项

可能成为配置项组成部分的主要工作产品有过程描述、需求、设计、测试计划和规程、测试结果、代码/模块、工具、接口描述等。在软件工程方面，RogerS.Pressman 认为至少以下所列的文档应该成为配置项:系统规格说明书、项目计划、需求规格说明书、用户手册、设计规格说明、源代码、测试规格说明、操作和安装手册、可执行程序、数据库描述、联机用户手册、维护文档、软件工程标准和规程。

2.2.2.2 配置项命名

确定了配置项后，还需要对配置项进行合理、科学的命名。配置项的命名绝不能随意为之，必须满足唯一性和可追溯性。一个典型的实例是采用层次式的命名规则来反映树状结构，树状结构上节点之间存在着层次的继承关系。

2.2.2.3 配置项的描述

由于配置项除了名称外还有一些其他属性和与其他配置项的关系，因此，它可以采用描述对象的方式来进行描述。每个配置项用一组特征信息(名字描述、一组资源、实现)唯一地标识。配置项间的关系有整体和部分的关系及层次关系也有关联关系。配置项间的关系可以用MIL(Module Interconnection Language，模块内连接语言)表示，MI,描述的是配置项间的相互依赖关系，可自动构造系统的任何版本。

2.2.3 基线

基线(baseline)是项目生存期各开发阶段末尾的特定点，也称为里程碑(milestone)在这些特定点上，阶段工作已结束，并且已经形成了正式的(通过了正式的技术评审)阶段产品。

建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。

如果把软件看做是系统的一个组成部分，以下3种基线是最受人们关注的，分别是功能基线、分配基线和产品基线。

2.2.3.1 功能基线

指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明;或是指经过项目业主和承建单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。

2.2.3.2 指派基线(分配基线)

指在软件需求分析阶段结束时，经过正式评审和批准的 SRS。指派基线是最初批准的指派配置标志。

2.2.3.3 产品基线

指在软件组装与系统测试阶段结束时，经过正式评审和批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。另外，交付给项目组所在企业的外部客户的基线一般称为发行基线，企业内部使用的基线称为构造基线。释放(release)是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付(delivery)。提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及到基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。

2.2.4 建立配置管理系统

在配置管理中，要建立并维护配置管理系统和变更管理系统。建立配置管理系统的主要步骤如下：

建立适用于多控制等级配置管理的管理机制。软件生存周期中不同时间所需的控制等级不同，不同的系统类型所需的控制等级也不同。
存储和检索配置项。
共享和转换配置项。
存储和复原配置项的归档版本。
存储、更新和检索配置管理记录。
创建配置管理报告。
保护配置管理系统的内容。配置管理系统的主要功能有文档的备份与恢复、文档的建档、从配置管理的差错状态下复原。
权限分配。配置管理员为每个项目成员分配对配置库的操作权限。配置管理员的权限最高，一般项目成员可拥有添加、检入/检出(checkin/checkout)、下载的权限，但是不能有删除的权限。

2.2.5 配置库

配置库也称为配置项库，是用来存放配置项的工具。

配置库记录与配置相关的所有信息，其中存放受控的配置项是很重要的内容，利用配置库中的信息可评价变更的后果，这对变更控制有着重要的意义。

配置库有三类:

2.2.5.1 开发库

存放开发过程中需要保密的各种信息，供开发人员个人专用。开发库中的信息可能有较为频繁的修改，只要使用者认为有必要，无需对其做任何限制。因为这通常不会影响到项目的其他部分。开发库对应配置管理系统中的动态系统(开发者系统、开发系统、工作空间)。

2.2.5.2 受控库

在开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的和人工可读的文档资料。应该对受控库内的信息的读写和修改加以控制。受控库也称为主库，对应配置管理系统中的主系统(受控系统)。

2.2.5.3 产品库

在开发的产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。产品库内的信息也应加以控制。产品库也称为备份库，对应配置管理系统中的静态系统。

2.3 变更管理

2.3.1 概述

配置管理最重要的任务就是对(配置项的)变更加以控制和管理，其目的是对于复杂而无形的软件，防止在多次变更下失控，出现混乱。

2.3.2 变更控制

2.3.2.1 定义

变更是指在项目的实施过程中，由于项目环境或者其他的各种原因对项目的部分或项目的全部功能、性能、体系结构、技术、指标、集成方法和项目进度等方面做出改变。项目变更是正常的、不可避免的。

2.3.2.2 项目变更原因

在项目实施过程中，变更越早，损失越小；变更越迟，难度越大，损失也越大。项目在失控的情况下，任何微小变化的积累，最终都会对项目的质量、成本和进度产生较大影响，这是一个从量变到质变的过程。

变更产生的原因主要有以下几个方面：

项目外部环境发生变化，例如，政府政策的变化等。
项目总体设计、需求分析不够周密详细，有一定的错误或遗漏
新技术的出现，设计人员提出了新的设计方案或新的实现手段。
建设单位由于机构重组等原因造成业务流程的变化。

2.3.2.3 变更控制系统

变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件、责任追踪，以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。在审批变更时，要加强对变更风险和变更效果的评估，并选择对项目影响最小的变更方案尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当与项目管理信息系统一起通盘考虑，形成整体。

2.3.2.4 变更控制委员会

变更控制委员会(Change ControlBoard,CCB)也称为配置控制委员会(ConfigurationControl Board)，其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，可以根据工作的需要组成，其中的人员可以全职的，也可以是兼职的。

如果CCB 不只是控制变更，而是承担更多的配置管理任务，那就应该包括基线的审定、标识的审定，以及产品的审定等工作，并且可能实际的工作需分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。

2.3.2.5 变更控制的流程

2.3.2.5.1 变更基本流程

一般来说，变更控制应该遵循以下的基本流程:

变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析
变更决策。由CCB 决定是否实施变更。
变更实施。由管理者指定的工作人员在受控状态下实施变更
变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。

2.3.2.5.2 变更申请内容

变更申请需要采用书面的形式提出，主要内容有如下3个方面：

变更描述。包括变更理由、变更的影响、变更的优先级等，就是要描述做什么变更，为什么要做，以及打算怎么做的问题。
对变更的审批。对变更的必要性、可行性的审批意见，主要是由配置管理员和CCB对此项变更把关。
变更实施的信息。

在变更请求批准后，实施变更需要一段时间，要设置一种管理手段来反映变更所处的状态，这就是变更状态说明，它可供项目经理和CCB追踪变更的情况。状态说明的信息可以通过变更请求和故障报告得到，变更状态可分为三种:活动(正在实施变更)完成状态(已完成变更)和未列入变更状态。

2.3.2.6 利用配置库实现变更控制

配置项可以有三种状态：工作状态、评审状态和受控状态。

开发中的配置项尚未稳定下来，对于其他配置项来说是处于工作状态下(自由状态、草稿状态)，此时它并未受到配置管理的控制，开发人员的变更并未受到限制。

但当开发人员认为工作已告完成，可供其他配置项使用时，它就开始于稳定。把它交出评审，就开始进入评审状态；若通过评审，可作为基线进入配置库，开始冻结，此时，开发人员不允许对其任意修改，因为它已处于受控状态。

通过评审表明它确已达到质量要求；但若未能通过评审，则将其回归到工作状态，重新进行调整。配置项的状态变化过程如下图所示：

处于受控状态下的配置项原则上不允许修改，但这不是绝对的，如果由于多种原因需要变更，就需要提出变更请求。在变更请求得到批准的情况下，允许配置项从库中检出，待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。

2.4 配置控制

2.4.1 版本控制

2.4.1.1 概述

在配置管理中，所有的配置项都应列入版本控制的范畴。对于软件产品的版本有两个方面的意思，一是为满足不同用户的不同使用要求，如用于不同运行环境的系列产品。

如适合 Linux、Windows、Solaris用户的软件产品分别称为 Linux 版、Windows 版和 Solaris版。它们在功能和性能上是相当的，原则上没有差别，或者说，这些是并列的系列产品。对于这类差别很小的不同版本，互相也称为变体(variant)。

另一种版本的含义是在软件产品投入使用后，经过一系列的变更(例如，纠错、增加功能、提高性能的更改等)，而形成的一系列的顺序演化的产品，这些产品也称为一个版本，每个版本都可说出它是从哪个版本导出的演化过程。

必须注意到，修正后的新版本往往不能完全代替老版本，尽管新版本有某些优越的特性。因为一些用户仍然使用着老版本，并且不容易立刻做到“以旧换新”，否则，可能会打扰老版本原有的工作环境。显然，多个版本被多个用户同时使用的情况是不可避免的现实。这就要求多个版本共存，这也就是配置管理要解决的一个重要课题。

2.4.1.2 版本控制流程

一般来说，版本控制的流程如下：

创建配置项。
修改处于工作状态的配置项。
技术评审或领导审批。
正式发布。
变更，修改版本号。

版本管理要解决的第一个问题是版本标识，也就是为区分不同的版本，要给它们科学的命名。通常有2种版本命名的方法，分别是号码版本标识和符号版本标识。其中号码版本标识以数字表示，如用 1.0，2.0，1.2，2.1.1等表示版本号；符号版本标识是将重要的版本属性有选择地给出，例如，SOLServer2008、Jbuilder2005 等将版本产生的时间给出。为了从版本标识上看到更多信息，可能给出更多的属性，例如，面向的客户群、开发语言、硬件平台、生成日期等。

在配置管理中，版本包括配置项的版本和配置的版本，这两种版本的标识应该各有特点，配置项的版本应该体现出其版本的继承关系，它主要是在开发人员内部进行区分。另外，还需要对重要的版本做一些标记，例如，对纳入基线的配置项版本应该做一个标识。

2.5 配置状态说明

2.5.1 定义

配置状态说明也称为配置状态报告，其任务是有效地记录、报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。

2.5.2 状态报告

为了清楚、及时地记载配置的变化，不至于到后期造成贻误，需要对开发的过程作出系统的记录，以反映开发活动的历史情况，这就是配置状态记录。该项活动主要是完成配置状态报告的编制工作。

2.5.2.1 状态报告信息流图

在配置状态报告中，需要对每一项变更进行详细的记录，包括：发生了什么?为什么会发生?谁做的?什么时候发生的?会有什么影响?整个配置状态报告的信息流如下图所示：

正如上图所示，每次新分配一个配置项，或者更新一个已有配置项或配置项标识，或者一项变更申请被变更控制负责人批准，并给出了一个工程变更顺序时，在配置状态报告中就要增加一条变更记录条目；一旦进行了配置审核，其结果也应该写入报告中。配置状态报告可以放在一个联机数据库中，以便开发人员或者维护人员可以对它进行查询或修改。此外，在配置状态报告中，新记录的变更应当及时通知给管理人员和其他项目干系人。

2.5.2.2 状态报告内容

配置状态报告对于大型开发项目的成功起着至关重要的作用。它提高了所有开发人员之间的通信能力，避免了可能出现的不一致和冲突。它通过支持创建和修改记录、管理报告配置项的状态或需求变化并审核变化来实现，它提供用户需要的功能，跟踪任意模式的软件项，提供完整的各种变化的历史版本和汇总信息。配置状态报告的内容一般包括以下各项：