从软件项目管理探讨软件配置管理

高媛

四川长虹网络科技有限责任公司    621000

摘要：项目的目地是为了创造一项产品或提供服务，因此，产品本身的生产过程必然会成为项目管理过程的核心内容。在复杂的软件项目管理中，控制是十分重要的管理活动，软件质量保证 (Software Quality Insurance, SQA)是在软件过程中的每一步都进行的“保护性活动”，还有一种技术管理手段会帮助项目人员趟过软件开发过程中的泥潭，它就是目前正被日益重视的—软件配置管理（SCM)。软件配置管理是贯穿整个软件生存周期的一项技术，作为相对独立的管理分支，有着其自身特殊的作用和要求。

关键字：项目管理；软件配置管理；配置项；变更   

1概述

项目管理是指把各种系统、方法和人员结合在一起,在规定的时间、预算和质量目标范围内完成项目的各项工作。即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。在CMMI中，支持类过程域涵盖了支持产品开发与维护的活动，并能够应对通用于组织的过程。配置管理（SCM）属于过程支持域。在CMMI中配置管理（Configuration Management，CM）的定义是，通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。

2软件配置管理的意义

要谈项目软件项目管理中配置管理的意义，得先从软件项目的特点开始分析，软件的特点是什么呢？

软件产品，它是逻辑实体，是不可见的、抽象的智力产品，以“信息”的形式存放在计算机中，因此，与硬件比较而言，极容易被修改（不考虑权限问题）和变化。

软件项目的规模日益庞大和复杂，会有大量的所谓“产品”产生，典型的如代码、文档（包括技术文档、产品文档、管理文档）、数据、脚本、执行文件、安装文件、配置文件、甚至一些参数等，这些产品实际上都是软件项目的直接产品，同时也都是项目资产。

参与项目的人员数量增加，人员间的沟通渠道数量也倍增。若团组中人员数为n，则人员间存在着n*（n-1）/2个需要互相沟通的渠道。

软件时时处在演化和变更状态。这包括：技术的快速发展；业务环境的不断演变；不同用户的不同需求；软件需求在开发中的频繁变更；开发人员对阶段产品的灵活、易变更等。

2.1忽视软件配置管理可能导致的混乱现象

    项目管理过程中，没有做好配置管理工作，带给项目的是无止境的混乱，难以判断出你现在看到的或者使用的产品是否是经过验证的产物。比如：发给用户的软件产品的操作手册是老版本；某个软件已开发完成，可是开发对应的需求未经过评审；上周已解决的缺陷，现在又出现；源码文件被人误删除；最新修改的源程序找不到；前天用户让做某个变更，今天又说不要了，以前的版本去哪里了？

2.2配置管理的落实

在项目范围管理中，需要识别和控制项目的交付成果，要描述交付物应有的各种特性。这些交付物及其特性，就是配置管理中的配置项。从项目管理的角度，CMMI中常用的WBS更重视进度和资源，只需要分解到可管理的程度，而配置管理则要求分解到最终可操作的程度，落实到产出物管理的粒度更为精细。因此，良好的配置管理机制，是项目范围管理得到最终落实的保证。

项目范围管理是整个项目管理中，最基础的一项工作任务，也是一种功能性管理，是对工作范围，以及产品进行全方位的识别和定义、确认、控制的管理过程，以及活动。如，编写的程序模块，实现的功能，部署的地点，这都是项目范围管理所要关注的内容，配置管理就是在项目中识别产品的物理属性和功能属性以及服务的属性，便于记录和跟踪。做好软件配置管理，才能真正把项目的范围管理做实，所以软件配置管理在项目管理中不可或缺的重要技术手段，它是管理工作的“落地”部分。

2.3配置管理关键点

2.3.1软件配置标识

软件配置标识是软件配置管理的基础性工作，是管理配置的前提。首先要确定配置项，就是要决定需要被保存、被管理的产物。项目在开发过程中会产生很多技术性和管理性的产物。技术性内容随着开发进程演化，版本之间互相衔接，后期版本是对前期的修正和扩展，两者间具有继承关系；而管理性文档如计划书等，也有类似的变化和变更。在很长一段时间内，认为配置项只包括各里程碑输入输出的文档性内容，其实不是，比如源码也是配置项。

在软件产品的内部模块、模块接口等等，每一个程序，甚至一个类、对象都能作为一个单独的配置项进行管理。在开发过程中对于程序的修改都纳入配置管理，跟踪程序变化过程。这种对软件产品从技术角度的不断分解和定义，是与软件结构设计相对应的，配置项的划分是否合理，使用起来是否灵活、方便，哪些可以成为公共组件（Component），其实反映的是软件设计思想。如今，越来越多的企业重视配置管理，它已经成为工程技术管理的重要手段。

识别软件配置项后，首要做的就是对配置项命名，简言之，配置项的命名标识应科学合理、便于区分。命名的基本要求是唯一性和可追溯性。在项目管理中，在一个项目内不能出现重名的配置项，以避免混淆，同时名字应能体现相邻配置项之间的关系。确定可交付物，当项目中业务涉及的需求发生变更时，其实就是对配置项的变更管理。因此，在软件工程过程中，配置管理也可以说是需求管理的基本手段，通过科学、严谨的配置管理方法，对业务需求进行识别、分解、跟踪、控制，直接决定了对业务需求的管理能力。目前，许多公司在需求管理方面还处于粗放型的管理，管理粒度还比较粗，而且缺乏明确的配置项的定义，缺少有效的跟踪控制手段，还需要更精细的管理。

实际工作中，往往需要多个软件产品配合同步进行修改。既要保证业务产品的完整性和多样性，又要保证软件产品的一致性和兼容性。因此，对于项目管理来说，对配置管理的要求，是必须在企业级来考虑的。

所以，如何有效地管理这些产品以及它们之间的关系成为一个棘手的问题。其实，配置管理是一个非常宽泛的概念，项目中只要是需要进行管理的任何特性，都可以被纳入配置管理。通常我们说配置管理是技术手段，随着认识的逐步深入，配置管理不只是操作层面的问题，更是管理理念、管理方法的问题。

2.3.2配置管理中的版本管理和变更管理

配置管理中要记录、控制、报告各种属性（配置项）的变化状态，这就是配置管理中的版本管理和变更管理，有变更才有不同的版本，版本又成为变更控制的主要对象，这两者是紧密关联的。

前面我们提到了哪些是配置项，每个配置项的每个状态都可以称为一个版本，配置项随着项目的开展而演变。通常说的版本，实际是指软件产品的版本，不是具体配置项的版本。一个软件产品版本是由众多识别的配置项组成的，当产生一个特定产品版本时，则每个配置项只能选取它的一个版本，确保唯一性。

变更管理的本质就是控制修改，杜绝项目中出现改错、改乱的情况。变更管理的任务是：分析变更：研究变更的必要性、经济可行性（成本-效益比，是否合算）和技术可行性（能否实现）。记录和追踪变更。采取措施保证变更在受授状态下进行。

软件变更的来源为干系人发起，项目需求的提出者或者另一来自于软件开发人员或者项目管理人员。随着项目的进展，干系人对问题本身和设计方案有了更深入的认识，项目中提出变更，是符合人们认识规律的。当变更产生时，组织评估，评估成本、进度、范围的影响，由变更控制委员会（CCB）来确定是否同意变更。

2.3.3配置库

配置管理所有用于管理的产物都放于“库”中，可以分为逻辑库和物理库来管理。项目的库，一般分为开发库、受控库、产品库。利用配置库实现配置管理是非常有效的，它可以把软件开发过程中的各种工作产物管理得井井有条，使其不致管乱、管混、管丢。配置项一旦升级到配置库工作，就享受到VIP保镖服务，如配置库“入库检查”（check-in）和“出库检查”（check-out），同时配合访问权限的措施。做到库内存放的产物谁可以“查看”， 谁可以“获取”， 谁可以“修改”， 谁可以“存入”等等的控制。随着项目的壮大，人员越来越多，通常人员按组的形式来管理权限。所以，配置库从某种意义上而言，就是实现配置管理工作的“保险柜”，你有什么权限，就有什么样的钥匙。

2.3.4配置库配置基线

建立基线的目的是为了把各开发阶段的工作划分得更加明确，对当前的工作产物固化，形成里程碑，从而有利于检验和肯定阶段工作的成果，同时也有利于变更控制。基线具备可重现、可追踪性和可报告的特性。基线的“基”很好的说明了一切，即为基线是一切的标准，只有建立基线才有评价偏差的依据，有了基线的规定后，阶段就有了明确的、稳定的输出产物，禁止跨越基线去修改工作成果。还有一种说法是，基线就是项目过程中某个时期的“快照”，可以把它理解为在某个点咔嚓拍了一张照片，这产物都被冻结了，点穴了。基线就好比大门钥匙，只有通过审批的“变更钥匙”才可以打开它。

在配置管理计划中，需对基线的划分和产物予以明确。通常软件开发项目中，计划需求基线、设计基线、测试基线、产品发布基线。每个基线都有唯一的标识，每个基线包括若干配置项的指定版本，比如：项目名+Baseline需求V1.1中可能包含《用户需求文档V1.6》和《软件需求规格说明书V1.2》，在每条基线发布后，项目干系人从配置库里提取基线时，实际上提取出对基线中对应的产物版本。

2.3.5配置审核

配置审核的目的是分别从技术和管理层面来保证产品配置和配置管理过程的完整性和正确性。分为物理配置审核、功能配置审核和配置管理审核。物理审核的时机应该是在入受控库之前或建立基线之前，因为配置项或基线经审核通过后再受控或再建立是合理的，且物理审核的目的是验证配置项或基线是否与定义和描述它的文档一致。功能审核的时机是功能或分配基线已经建立之后，通常可以在产品基线建立之前，且功能审核最主要的目的是验证产品是否满足需求或者技术协议。配置审计是指，在配置标识、配置控制、配置状态记录的基础上对所有配置项的功能及内容进行审查，以保证软件配置项的可追溯性。按照审核的内容也可以理解为日常审核和基线审核。其中，日常审核按一定频度定期进行，在项目配置管理计划中进行明确。

在软件项目管理过程中，有了技术手段的来进行配置管理，如，对配置项做了标识，实行了变更控制和版本控制，但如果不做检查或验证，仍然会出现混乱。这种验证包括：对配置项的处理是否有背离初始的说明或已批准的变更请求的现象；配置标识的准则是否得到了遵循；变更控制规程是否已遵循，变更记录是否可供使用；在规格说明、软件产品和变更请求之间是否保持了可追溯性等 。

2.3.6配置状态报告

在软件开发进行中，所有的软件配置项都在不停地演化着，配置状态报告就是要在某个特定的时刻观察当时的配置状态，也就是在观察动态演化着的配置项时咔嚓，拍个瞬时的“照片”，以便于在分析状态报告信息的基础上更好地进行控制。

在项目管理过程中，需要跟踪捕捉的状态报告信息有：配置项的当前标识、已交付软件的配置、变更请求或问题报告的状态、已获准变更的状态等。

综上所述，软件配置管理，贯穿于整个软件生命周期，是一套规范的、高效的管理方法，在开发活动中是一项支持性、保障性的工作，同时也提高软件项目质量管理的技术手段。在项目管理的诸多支持活动中，配置管理处于支持活动的中心位置，它把其他支持活动有机地结合起来，相互影响，相互促进。正确应用软件配置管理，规范的使用配置管理技术，有力的保障了项目开展，可以说，软件配置管理的过程是软件开发过程中质量管理的精髄。

参考文献

[1]郑明华;浅析软件质量管理中的配置管理[A];第二届中国质量学术论坛会议论文集[C];2005年;

[2]赵文杰;刘俊萍;南振岐;;软件配置管理理论与实践[J];现代计算机(专业版);2010年15期;

[3]王志敏;小型软件项目配置管理的实施[J];上海应用技术学院学报(自然科学版);2010年02期;