1 　引言

随着软件产品规模增大、生命周期时间延长、产品开发团队扩大和环境复杂化,软件业对配置管理在保证产品及其开发过程的标识和可追溯性方面具有的重要意义已形成了共识。

但是,实用中仍然会令人感到配置管理工作影响效率,有些活动做起来僵化笨拙,做过了得不偿失。较常被引用的配置管理定义是Babich W提出的“协调软件开发以减少不理解性到最小程度的技术称为配置管理。

配置管理是对正在被一个项目组建造的软件的修改标识、组织和控制的技术,其目标是通过最大限度地减少错误来最大限度地提高生产率” 。按照软件工程术语的国家标准,配置管理是“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征,
控制这些特征的变更,记录和报告变更处理和实现状态并验证与规定需求的遵循性”。按照SW2CMM 的软件配置管理关键过程域:“软件配置管理的目的是建立和维护在项目的整个软件生存周期中软件项目产品的完整性”。
要求的四个目标( Goal) 是:

(1)软件配置管理活动是有计划的;

(2) 所选定的软件工作产品是已标识的、受控的和适用的;

(3) 对已标识的软件工作产品的更改是受控的;

(4) 受影响的组和个人得到软件基线的状态和内容的通知 。

按照CMMI 模型中的配置管理过程域:“‘配置管理’过程的目的在于运用配置标识、配置控制、配置状态统计和配置审核,建立和维护工作产品的完整性”。

要求的三个特定目标是: (1) 建立基线; (2) 跟踪并控制变更; (3) 建立完整性 。

综合以上的说法,配置管理的目的是“建立和维护工作产品的完整性”;基本活动是“配置标识、配置控制、配置状态统计和配置审核”,以及相关的制订配置管理计划、配置状态报告等活动。经典的定义、标准、模型可以视为业界标准的软件过程,从业界标准软件过程到组织标准软件过程,再到项目定义软件过程有相当长的路要走。标准的软件过程模型要与具体组织、项目的特点相结合“, 工作产品的完整性”需要具体规定。否则,可能出现从方法、过程层面看起来配置管理的基本活动都做到了,但所做活动与业务目标不协调、与约束条件不一致,不清楚活动该做到什么程度,做起来事倍功半、流于形式,仍然不能保证产品的完整性,难以收到实效。为了使配置管理活动有效、适宜、充分地支持软件业务活动,可以先从引起配置管理问题的深层原因即混乱源开始分析,再研究不同层次的“完整性”及其相关的主要活动和能力、资源等约束,最后提出一组实用、有效配置管理的原则和策略。

2 　配置管理失效的深层次原因

在配置管理中,简单层次的原因包括缺乏基本的版本记录、缺乏基本的变更控制、缺乏配置状态审计及沟通不畅等。解决简单层次的难题也需要做认真工作,但一般只要认真去做就不难做到。真正把配置管理做到既完整、有序又提高效率则很不容易,
除了对配置管理的一般目标、实践要有足够理解外,还与组织的业务流程、技术及管理能力密切相关,仅靠配置管理过程难以消除复杂、深层次的原因(混乱源) 。

2. 1 　多版本、多分支

许多软件产品是以演进式发布版本方式开发的,面向多个客户的产品更可能增加工作产品的版本数,需要同时管理多个版本。从根源上减少多版本、多分支的问题,需要在产品策划时就考虑好版本演进策略,把握好顾客定位、顾客核心需求及自己产品核心功能的能力,以及与顾客沟通(识别及引导用户) 的能力。在技术上要有实现版本向前兼容的能力,合并多版本、多分支的工件。

2. 2 　频繁、重大变更

由于顾客沟通不畅、需求开发不完整、业务能力不足,以及产品、需求本身复杂等原因,在软件设计和开发的生命周期中可能频繁发生变更。频繁、重大变更会引起可观的配置管理工作量,如果要执行严格的配置管理策略,则流程笨拙、响应速度慢、管理成本高;
如果放松配置管理,则变更环境太宽松,可能更加加剧变更的频度及变更申请的随意性。根本上解决频繁、重大变更本身不是配置管理的直接任务,需要提高整体的管理、业务能力,从项目管理的角度可以考虑选择演进、叠代型的生命周期模型,在配置管理方面可以考虑分层控制。

2. 3 　产品结构混乱不清

规模较大、历史较长的产品结构可能存在产品结构差的问题,甚至由于文档缺失、人员更替而连产品的历史状态也不清楚。这会直接加大变更分析及确定变更后回归测试范围的难度。从根本上解决结构混乱问题可能需整理产品结构,自动化测试技术对控制回归测试工作量有所帮助。配置管理的直接贡献包括支持了解、管理配置项本身的特征、相互之间的联系,以及对回归测试用例、脚本等配置项的管理等。

2. 4 　异地、并行开发

由于信息安全、系统环境约束等原因,在软件公司内部可能无法得到用户的真实数据和软、硬件运行环境。为了提高效率,可能会有多名程序员对同一配置项并行开发或并行维护。配置管理对并行开发的贡献包括完整地标识、记录配置项的状态和分支版本,以及对版本变更、通知、审计、报告的控制;使用配置管理工具有助于支持并行开发管理。对配置项可以采取主负责人机制,其它程序员的修订需要得到主负责人批准或确认。在异地开发环境下还要求人员有更高的资质和素质。特别是在短期、小团队的用户现场工作时,在配置项的版本、权限等方面可能需要在严格控制与工作效率之间寻求平衡。

2. 5 　涉众不清、策略不当

非技术的管理性问题同样可能给配置管理造成重大混乱。不同的软件工作产品有不同的涉众(Stakeholder) ,如果涉众不清楚,就容易出现让非涉众的人来控制配置项或配置项没有受到其涉众控制等问题。配置管理需要支持项目经理等人员识别并管理配置项的涉众属性。项目配置管理的具体策略需要结合项目、组织的特点而定,脱离具体条件要求配置管理单独实现高层次的目标难免会事倍功半。

3 　配置管理的层次

配置管理的根本业务目的是促进组织、部门、项目团队的业绩,其具体业务目标和管理力度可以是分级的。对具体工作产品(Work Product ,简称工件) 的“完整性”可以在空间上从高层产品深入到底层工件、从单项目到多项目,时间上由静态到动态、从输入输出控制到加上过程控制来分层考虑,并根据特定的业务要求、能力、资源等约束条件来确定具体目的和相应力度的配置管理活动。如果不消除混乱源,想要达到高层次目标就难免会劳而无功。

3. 1 　了解、把握产品的组成

完整地将该交付产品的所有相关工件(即配置项) 及其版本信息一起打包,再加上一个工件清单,就可以作为基本的配置管理,可实现高层、静态配置管理目标。静态配置管理暂不关注产品配置项的历史演变、变更控制。过程能力不成熟的组织可以从静态配置管理做起。

3. 2 　支持产品的物理完整性和一致性

为了防止产品各阶段工件之间不一致以及需求遗漏或需求冗余等问题,可以在高层、静态配置管理的基础上加上一个需求跟踪矩阵,以证实软件产品对需求的完整覆盖,并保持各阶段工件之间的双向可追溯关系。

3. 3 　支持使用正确的配置项

配置项可能有多个版本。支持物理上使用正确配置项的基本要求一是使用经过审批的有效版本,二是在若干个有效版本中使用针对特定用户的版本。为了支持使用正确的配置项,配置管理需要做到前述的各类基本活动。严格地讲,在功能上使用正确配置项是评审、验证、确认等质量控制活动而不是配置管理的直接任务,在本文中不展开说明。

3. 4 　支持高效使用配置项

为了高效查找到针对特定用户的配置项和产品配置,除了引入配置管理工具以外,提高配置项检索效率的有效手段还包括:良好设计的、与产品结构一致的配置项结构关系,唯一、清晰、便于检索的配置项标识规范,多样化的配置项检索途径(如按软件产品结构、生命周期模型或配置项演变历史等逻辑关系) 等。高效使用配置项的更高境界是控制配置项的有效版本数,要求良好的版本策划、向下兼容及合并分支版本的技术能力和整体管理能力。

3. 5 　支持提高变更效率和控制变更数

变更控制的基本活动包括变更分析、变更状态管理、变更通知等,其中变更分析直接影响变更效率。在配置管理层面主要分析变更会影响到哪些涉众、哪些工件和哪些项目。为此,在配置管理系统中需要保持配置项与其涉众、产品和项目的关联信息。技术、整体管理层面的变更分析包括变更对产品结构的影响、技术难度、所需要的工作量和成本等;涉及具体用户的变更还需要分析对用户实现使用价值、组织实现顾客满意的影响。控制变更的更高境界则是通过有效的需求开发、顾客沟通、项目策划及管理等方式减少变更数。这些都不是配置管理系统能单独实现的任务。

3. 6 　支持配置项的复用

支持复用的软件部件配置库中的配置项能映射到所有拟使用配置项的产品和项目。对配置项的功能、对外接口及其使用规则有完整的描述,执行严格的质量控制、变更控制程序,并与可能使用这些配置项的产品、项目保持有效沟通。
支持软件部件复用需要有覆盖整个待复用范围,超越单项目、单产品区域的整体复用意识和良好的分析、设计能力。此外,还可以采取一定的管理措施,如要求产品、项目在策划时必须首先到可复用配置库中寻找部件,并承认产品、项目团队为复用库提供新配置项的业绩等。

4 　配置管理的策略

实用、有效配置管理的核心是基于业绩、约束确定配置管理的目标,需要基于组织、项目的具体特点选择策略和实践,并基于产品和过程度量来改进。

4. 1 　配置管理、版本管理和工作产品管理

基于配置项的重要性及发生变更的可能性制定适当力度的控制策略。配置管理指严格执行变更控制流程,适用于重要且相对稳定的配置项。版本管理则对变更的决策过程相对弱化,重点管理配置项的版本变更历程,适用于比较重要且变更较频繁的配置项。工作产品管理适用于那些不是由项目直接产生的且几乎不会发生变更的配置项。

4. 2 　CCB的组织及决策机制

基于产品、配置库的规模及团队合作经验等要素确定适当的变更决策方式。变更控制委员会(Chang Cont rolBureau ,简称CCB) 的基本组织方式包括统一或分散两种,前者由一个统一的CCB 来审批所有配置项的变更,后者为各类配置项分别建立CCB。CCB 的决策机制包括少数服从多数、一票否决、主席裁决等方式。

4. 3 　配置项的粒度划分

粒度是指配置项的规模。配置管理的粒度越细,看起来可视性越清晰,但配置项的数量会增大。粒度粗则大粒度的配置项可能因为多个局部变更而频繁整体变更,难以形成相对稳定的基线;
相关涉众在变更分析时难免需要关注整个配置项,从而加大分析工作量。当有良好的配置管理工具支持和熟练的配置管理人员时,可以优先考虑细粒度管理;否则,可以考虑对可能较频繁变更的工作产品采用细粒度管理,相对稳定的工作产品采用粗粒度管理。

4. 4 　配置管理的力度投入

配置管理是一种管理活动,管理活动存在适度投入、过投入和欠投入等可能性。理想状态当然是适度投入,但具体怎样把握“度”需要实践和学习,往往不容易确定。投入要重视实效,抓住关键目标。如果在过投入和欠投入之间难以决策,则可以优先选择欠投入策略。欠投入可能使工作做得不到位,但毕竟没有投入,经过实践、度量、分析后再改进、再增加投入,在心理上相对容易接受,容易达成共识。

5 　结束语

为了实现实用、有效的配置管理,需要考虑业绩导向,为支持业务要求而开展配置管理活动;基于技术、整体管理能力约束来设定配置管理过程的目标和要素;根据项目及其配置项的特点确定项目配置管理的层次、重点和策略;了解影响本组织配置管理过程业绩的主要难点并确定相关的改进计划等基本原则。“建立和维护工作产品的完整性”是配置管理过程的直接目的,但抽象的“完整性”本身还只是形式层面的目的,处在过程域、方法域层面,还不是业务层面的目标,没有深入到目标域、问题域层面。对不同的项目,“完整性”的层次、评价标准也可能不同,基本活动怎么做、做到什么程度可能不同,需要以业务目标、组织和团队业绩导向。要达到功能正确性、高效率、控制变更及复用等较高层次的“完整性”目标,只有直接的配置管理活动远远不够,还需要资源、技术能力、整体管理能力等配置管理活动以外的其他要素保证,在有限的资源、能力等约束条件下采用分层次管理、实效优先等策略。