软件项目的配置管理

第一篇：软件项目的配置管理

软件项目的配置管理

[摘要]：

2004年6月，我作为项目经理开始参与某航空公司航空票务系统项目的开发，主要负责系统的组织规划实施开发与项目管理，该系统具有严格的安全，稳定，时实高效和可靠性能要求，该系统由票务管理系统和呼叫中心系统两部分组成，呼叫中心系统主要实现电话，传真和短信业务，票务管理系统是整个系统的核心，采用了struts+hibernate+spring主流WEB应用框架，实现了WEB应用服务器websphere与协作应用服务器lotus domino 的高度集成.随着软件系统的日益复杂化和用户需求，软件更新的频繁化，配置管理在软件项目中显得越来越重要了。本文以该项目为例，结合作者时间，主要通过在项目前期，做好需求调研，总体设计和详细设计并制定完整的配置管理计划。在该项目全过程中规范化配置管理，注意员工培训并加强沟通与协调，来实施项目的配置管理。目前，该系统已开发完毕，正式投入运行，状况良好，受到客户一致好评。

[正文]：

2004年6月，2004年6月，我作为项目经理开始参与某航空公司航空票务系统项目的开发，主要负责系统的组织规划实施开发与项目管理，当然还做一些编码工作，主要是公用基础代码和核心代码的编写与维护。航空票务系统是将呼叫中心系统和票务管理系统有效的结合起来，采用先进的ＣＴＩ技术和语音板卡技术，充分利用电话，短信，传真，因特网等信息化手段，解决航空公司的机票销售问题，规范了业务流程，强化了内部管理，与电子商务的完美结合，使应用系统功能更加完善，提高了整个航空业务的工作效率。其中，票务管理系统包括：客户管理，机票管理，票证管理，销售管理，财务结算，调度管理，远程营业部（代理商／分销商）管理，系统管理八大功能模块，并统一于服务器端软件模块。呼叫中心系统由电话呼叫系统，短信分发系统，传真呼叫系统三部分组成。票务管理系统是整个系统的核心，采用了struts+hibernate+spring主流WEB应用框架，实现了WEB应用服务器websphere与协作应用服务器lotus domino 的高度集成,在本次开发中，我把它视为整个项目的重点

由于考虑到寒假和春运期间将会是旅客的高峰期，客户要求系统必须在12月底前交付，项目开发周期为6个月，为此我做了如下安排：前4个月主要集中精力用于开发票务管理系统，后两个月主要完成票务管理系统和呼叫中心系统的集成以及项目收尾工作

随着软件系统的日益复杂化和用户要求，软件更新的频繁化，配置管理逐渐成为软件生命周期中的主要控制过程。在软件开发过程中，扮演越来越重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面，同时对软件开发过程的客观管理，即项目管理也有重要的支持作用。在该系统项目中，我主要使用intersolv公司的pvcs配置管理工具，并通过在项目前期作好需求调研，总体设计和详细设计并制定完整的配置管理计划。在项目全过程规范化配置管理，注意员工培训并加强沟通与协调等方法和策略来实施配置管理。项目前期做好要求调研，总体设计和详细设计，并制定完整的配置管理计划。

项目计划阶段，我对需求分析，总体设计和详细设计这三项活动工期安排如下：需求分析12天，总体设计和详细设计总共20天，时间尽量充足。在做需求调研的时候，我要求一定要和客户充分沟通，深入挖掘客户的隐性需求。不仅要实现客户需求的功能，在界面上也要让客户满意，为此我们作出了航空系统的虚拟界面，让客户对系统 有一个感官上的整体了解，在需求分析完成工作之后，我们还通过小组会议的形式进行了确认和评审。并邀请客户方代表参与。最终的《需求规格说明》我们也要求客户方代表一定要签字确认。在总体设计和详细设计过程中，我们尽量使用适合本项目团队特点的工具和技术，并充分考虑其先进性和成熟性。在设计完成之后，我们仍旧对其进行了评审，总结和讨论，对争议比较大的地

方交公司资深专家审核评定。

配置管理计划的制定也使配置管理中不可少的一步，它能有效的指导后期配置管理工作。在本项目中，配置管理计划由配置管理员完成，我只做一些审核工作，软件资源配置管理计划，配置项目计划，交付计划，备份计划，CCB审批计划等．．．．总之，我认为项目前期做好以上铺垫工作可以减少变更，对后面一些工作可以说是水到渠成。同时，一个比较完整的计划，也可以避免不必要的项目反工，而且项目管理员的工作也会比较好做一些。项目全过程规范化配置管理。

开发过程中，对文档修改非常麻烦，在配置管理中，对任何一配置项的修改都可能导致版本的变化。因此，对配置管理规范化势在必行，在本项目中，我要求配置标识一定要规范，必须独立命名配置项，配置对象的标识要充分考虑命名对象间存才联系。在配置管理中，项目组成员要各司其职，不得越权操作，同时还要根据自己的权限操作配置项。我的工作在配置管理中主要是：定制开发子系统，定制访问控制，制定常用策略，制定集成里程碑，进行系统集成．．．．．而配置管理员的职责主要是：创建配置序，为项目成员分配权限，对存储库进行日常备份恢复等．．．软件开发人员主要根据项目的开发配管理策略，创建，修改和测试工件等。软件生存期内全部软件配置是软件产品的真正代表，必须保持精确，软件工程中某一阶段的变更都会引起软件配置的变更，对这种变更也必须做到严格规范的控制和管理。为此，我做了如下规定：处于工作状态的产品开发人员可对其修改，而作为基线进入配置库的产品，则不允许开发人员对其进行修改。在本项目中，我们还成立了临时CCB,由项目经理，用户代表，软件质量控制人员，配置管理员5人组成。我们要求对于用户提出的变更请求要严格按照变更控制流程处理。在用户提交更多请求后，开发人员对其进行评价，并产生变更报告。在由变更控制委员会〈CCB〉作出决定是否进行变更。通过批准，就重新检出变更的配置项，建立测试基准程序，并执行质量保证和测试活动，必须通过CCB的鉴定审批后，方可实施变更。

注意员工培训并加强协调与沟通。

项目组成员大多来自不同部门，对项目环境还不熟悉，为了能实施配置管理系统，我建议公司对项目组成员进行相关培训。针对配置管理员，我们要求他学习配置管理工具管理相关的内容。针对开发人员，主要学习配置管理工具与开发相关的常用操作。针对全体人员，要让他们了解配置管理策略和流程，以及如何与开发管理，项目管理相结合。同时，我要求项目组成员要加强协调和沟通。可以使用PVCS，通过ressionmanger文档共享和连锁机制。Tracker与电子邮件的集成，加强项目成员之间的沟通，做到有问题及时发现，及时修改，及时通知，但又不额外增加很多的工作量，这样有助于营造一个和谐，公平，竞争的气氛和环境。

航空票务系统在2004年12月下旬正式上线，提前完成了项目，目前系统运行正常，受到客户和有关部门的一致好评，对项目的满意度较高。重新回顾该项目也存在一些问题不足，比如：项目初期，大多数成员对版本管理一点都不重视，总是敷衍了事。代码编写人员编写得代码也混乱不堪，给测试人员和维护人员带来了很大不便，一些没多大用的垃圾资料也被放置到配置服务器上，给配置管理人员带了很多麻烦。因此我建议在项目一开始，就要让项目成员认识到版本管理的好处。对源码的管理，要保证书写代码的规范性，强化注释力度，还应作好build和relase工作.

第二篇：软件配置管理解决方案

软件配置管理解决方案

目的:

● 通过使用配置管理软件,遵守版本控制、变更控制等规程,保证所有配置项的完整性和可跟踪性。

范围:

● 适用于公司的软件开发项目,它规定了软件配置管理活动的具体规程及其工作产品。

角色与职责:

● 配置管理员:编制项目配置管理计划；创建并维护配置库。

● 配置变更控制委员会(SCCB):审批配置变更申请。

● 软件开发组成员:在权限内使用配置管理工具操作配置库。

● 项目SQA人员:审计配置管理活动的规范性。

进入准则:

● 项目计划已制定。

● 项目软件过程已定义

● 配置管理员和SCCB人员已确定。

输入:

● 项目计划

● 项目软件过程

结束准则:

● 对项目配置库的操作和管理持续到项目结束。

● 只要存在用户使用配置管理就要进行。

输出:

● 配置管理计划

● 产品配置库

● 软件基线审计报告

主要活动: 在项目早期(在项目计划初稿后,并与项目计划一起评审)编制项目配置管理计划。

● 确定项目配置管理员。

● 项目经理和项目配置管理员共同指定项目组的SCCB。

● 项目经理与项目配置管理员按确定的软件生命周期,识别出项目要进行控制的软件配置项和纳入配置管理的日期。

● 项目经理与项目配置管理员依据项目定义软件过程,共同确定项目的基线,并标识每个基线的配置项。

● 项目经理确认由项目配置管理员制定的在软件生命周期各个阶段配置项的使用权限清单。

● 项目配置管理员按照《配置管理计划模板》制定项目的SCM计划。

● 项目配置管理员根据项目所使用的开发工具确定项目使用的配置管理工具。

● 项目配置管理员根据项目计划的变动,适时调整项目的SCM计划。具体规程见《项目跟踪与监控过程》计划变更相关步骤。

● 由项目主管主持,项目经理、公司配置管理主管、项目配置管理员、软件工程组、软件相关组参加对配置管理计划书的评

审。具体规程参见《同行评审过程》。

按照配置管理计划,进行项目的配置库管理。

● 项目配置管理员规划、建立项目的目录结构。该结构支持对配置项的存储和检索功能。

● 项目配置管理员根据项目的规模,规划和配置管理工具相关的配置库结构。

● 项目配置管理员依据经项目经理确认的权限清单对目录结构进行权限分配,以达到在相关组之间或配置库内部之间进行共

享和传输。

● 项目配置管理员将配置项用配置管理工具统一管理,将软件工作产品存放在指定的服务器的软件基线库中。

● 项目配置管理员保证由软件基线库制造的产品的正确生成。

● 公司配置管理员定期对服务器的软件开发库、软件基线库进行备份,对配置项的归档版本提供存储和恢复功能。3 配置识别

● 项目配置管理员在制定项目的SCM计划时,与项目经理共同识别出将置于配置管理之下的软件工作产品。可标识为配置项的 软件工作产品的例子有:

◇与过程有关的文档；

◇软件需求；

◇软件设计；

◇软件源代码；

◇软件可执行代码；

◇软件测试规程；

◇为软件测试活动建立的软件系统；

◇编译程序；

◇交付给用户的或最终用户的软件系统；

◇其它支持工具等。

● 项目配置管理员依据项目配置计划书在给定的时间点上标识配置项/单元。

● 项目配置管理员依据开发规范,保证每个配置项赋予唯一的标识符。

● 项目组成员应用配置管理工具,标明每个配置项的修订版本号。

● 项目配置管理员可用配置管理工具中的label功能,说明每个配置项所属的软件基线。

● 项目配置管理员使用配置管理工具记录每个配置项/单元置于软件配置管理之下的时间,并标明其生成者。配置变更

● 变更分类

对软件及其相关文档的变更按照变更的影响范围进行分类:

1)A级:变更会影响系统级需求、外部接口、产品价格或者交付期；这类变更必须经过SCCB审核并有客户批准和确认。

2)B级:变更会影响配置项间的功能接口、组件级成本或者项目Schedule；这类变更必须由SCCB或上级管理部门的批准和认可。

3)C级:变更会影响配置项内部功能的设计和分配；这类变更可以由配置项的管理人员负责批准。

● 变更请求的提出

◇如果需对已纳入基线管理的配置项提出修改,项目组或其他相关人员应在配置项变更请求评审记录中填写变更请求,交给项目

经理。相关表格参见《配置项变更申请单》。

◇项目经理组织人员对变更请求进行评估,描述实施变更所影响的配置项、文档和资源,确定变更的分类；如果是属于A类

或B类,需要组织SCCB评审会进行评审。

● 变更实施

◇项目经理将需解决并批准的问题通知相关人员进行修改。

◇项目组成员实施《配置项变更申请单》中的所有变更,并确保相关文档得到更改。

◇测试人员对已修改的问题进行确认,并将跟踪结果记入CQ中。

◇当确认无误后,项目组成员检入配置库。

◇项目配置管理员跟踪配置项变更解决的过程。跟踪的主要内容有:

1)解决人；

2)解决日期；

3)解决方法；

4)修改的文件；

5)受影响的文件；

6)受影响的数据；

7)是否经过验证等。

● SCCB定期召开评审会,确认基线修改的正确性、完整性和一致性,并保证不会对基线造成意外的后果。保证由软件基线库生成产品并控制它们的发行。

● 项目经理或指定人员依据SDP中的build计划和软件产品测试申请单,对存放于软件配置库中的源程序进行编译,生成软件产

品,并提交测试人员进行测试。

● 测试人员依据产品测试通过标准,对待测产品进行确认测试,形成测试报告。

● SCCB依据测试报告,审计由软件基线库生成的软件产品与测试通过标准的符合性,并生成SCCB会议纪要。

● 对审计通过的产品build,项目配置管理员将其升级为基线。

● 项目配置管理员对审计通过的软件工作产品建立版本标识号(用配置管理工具的label加以标识)。

● 项目配置管理员将审计通过的软件产品(release)放入软件产品库。

当软件工作产品纳入基线管理时,进行软件基线审计。

● 根据项目配置管理计划,SCCB确认在适当的时间需要审计的软件基线,明确该基线包括的配置项。

● 在该基线包含的配置项经评审和检查通过后,项目配置管理员通过配置管理工具将配置项升级为基线状态,并为配置项标注

LABEL等。该基线所包含的所有配置项都升级为基线状态时,该基线正式建立。

● 项目配置管理员验证该基线是按照项目的配置管理计划所明确的配置项组成的。

● 项目配置管理员验证已建立的基线所包含的配置项是完备、准确的。

● 项目配置管理员将审计发现的问题记入基线审计报告,并对问题进行跟踪直至解决。

● 项目配置管理员将基线审计报告向项目经理报告。

过程裁剪说明:

◆创建配置库时,库结构需要使用公司统一目录结构,但是项目可以根据需要增加目录结构；除在公司外部连接不到公司服务器情况

外,不可以使用公司规定以外的配置管理工具。

相关文档:

◆配置管理计划模板

◆配置项变更申请表表样

◆软件基线审计报告表样

第三篇：软件配置管理最佳实践

软件配置管理最佳实践

PMTeam杂志 Li Ben 编

现在大家都已经认识到了有效的软件配置管理工作对于提高团队开发效率、保障软件产品质量的重要意义，很多朋友也开始了在配置管理实施方面的一些研究，市场上我们也可以看到一些软件配置管理工具厂商针对具体配置管理工具提供的实施服务；但是，实施软件配置管理到底应该做哪些东西？团队的配置管理现状怎么评估？在哪些方面还可以进行改进？我们相信，这些问题可能正困扰着大多数研发主管和项目经理。

国外软件产业界在软件配置管理这个专题上已经进行了多年的理论和实践上的研究。在多年经验积累的基础上，产业界总结出来一系列“最佳实践”（Best Practices），我们可以使用这些“最佳实践”来作为评估一个组织软件配置管理能力的标尺，也可以作为我们实施软件配置管理的指南。这些“最佳实践”包括：

1、标识需要进行存储的工件（Artifact）并保障安全存储；

2、控制并且审计（Audit）对于工件的修改；

3、设立并管理基线（Baseline）；

4、记录并跟踪变更请求；

5、维护稳定、一致的工作空间；

6、支持对于工件和控件的并发修改；

7、尽早集成、持续集成；

8、保证软件构建的重现能力；

9、以控件（Component）为单位实施版本控制；

10、使用“活动”（Activity）来组织和整合版本集。

下文将介绍前5条最佳实践。

1、标识需要进行存储的工件（Artifact）并保障安全存储

在软件开发过程中，我们会得到各种各样的产出，比如各种文档、模型、源代码以及测试脚本等，我们把这些大家劳动的成果统称为工件（Artifact）。对于一个软件开发组织来说，这些工件就构成了组织的核心资产。对于如现金、有价证券之类的资产，我们都会准备一个保险箱，好好地保存；对于软件资产，我们也需要相似的措施。所以，软件配置管理工作的第一步就是建立一个安全、可靠的存储库（Repository），用于保存组织的核心软件资产。这个库对于开发团队来说，就像是财务室里的保险箱。因此，容错能力和高可靠性是这个库最重要的属性。除此之外，随着

组织的增长，置于库中的数据会越来越多，为保证运行效率，库的可扩展性也是非常重要的一个属性。

对于存储库来说，良好规划的备份和灾难恢复过程是必不可少的。令人惊讶的是，很多软件组织在这方面都没有给予必要的重视，因而也给组织的发展留下了严重的隐患，一旦灾难发生，后果不堪设想。

在建立好存储库以后，需要做的工作就是确定将哪些工件置于库中。根据实际需要，组织可能会决定只将正式文档、模型文件、源代码、发布版本等文件放入库中，而对于临时文档、编译时产生的中间文件等，则不将它们放入库中。我们把放入库中的文件称之为配置项（Configuration Item）。

2、控制并且审计（Audit）对于工件的修改

在标识相关的工件并将它们置于存储库中以后，我们需要建立对于这些工件的修改控制机制以及审计机制。

库里的工件不是谁想修改就可以修改的。控制机制必须保证只有拿到授权的人员才能对相关工件进行修改，而审计机制则保证修改的动作被完整地记录，也就是说，谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方（Who、When、Why、What）。审计机制通常通过“检出/检入”（Check out/Check in）模式得到实现。在这种模式下，工件一旦入库，读写权限就变成只读（read only），如果要对该工件进行修改，则需要通过“检出”这个步骤；在修改结束以后，如果希望将修改的成果入库，则需要通过“检入”这个步骤。在经过一次“检出/检入”步骤以后，会形成该工件新的版本，因此也有人把上边的过程称之为“版本控制”（Version Control）。在版本控制过程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可以自动地记录审计工作所需的四个“W”（Who、When、Why、What）。

3、设立并管理基线

通过审计机制我们可以保存一个工件完整的变更历史；但是一个项目通常是由成百上千个工件构成的，每个工件在变更过程中都会形成一系列的版本，如何确认系统在某个时刻分别由哪些工件的哪些版本构成？这就需要引入一个概念：配置（Configuration）。对于软件系统来说，在开发过程中某个时刻存储库中所有工件的一个“快照”（snapshot），就形成一个“配置”。对于一些重要时刻的系统配置，我们可以使用基线（Baseline）来进行标志。

IEEE对于基线的定义是：已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变

简单地说，基线就是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于这个标准进行，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对它进行的变更都将记录为一个差值，直到建成下一个基线。

建立基线的主要原因是：重现能力、可追踪性和报告能力。

重现能力是指返回并重新生成软件系统给定发布版本的能力。可追踪性建立项目各种类型工件（需求、设计、实现、测试等）之间的横行依赖关系，其目的在于确保设计满足需求、代码实施

设计以及使用正确代码编译生成可执行文件。报告能力来源于一个基线内容同另一个基线内容的比较，基线比较有助于程序调试并生成发布说明（Release notes）。

建立基线有以下几个好处：

(1)基线为开发工件提供了一个定点和快照。新项目可以从基线提供的定点之中建立。

(2)当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。

(3)可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现被报告的错误。在开发过程中，需要定期建立基线以确保团队开发人员的工作保持同步，通常，在项目生命周期中的里程碑处定期建立基线。

4、记录并跟踪变更请求

以上我们谈论的都是对于工件的变更活动的实施，下面我们要谈到的是软件配置管理的另一个方面：对于变更请求的管理。这是变更活动的源头。

著名的软件大师Brooks曾经谈到导致软件开发困难的一个原因就是软件的可变性。大家都知道，各种要素，如市场的变化、技术的进步、客户对于项目认识的深入等等，都可能导致软件开发过程中的变更请求的提出，而且承认这种变更请求的合理性也已经是工业界的共识。

但是，如果缺乏对于变更请求的有效的管理能力，纷至沓来的变更就会成为开发团队的噩梦。缺乏有效的变更请求管理会导致以下一些问题：

（1）软件产品质量低下，对一些缺陷的修正被遗漏；

（2）项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的能力；

（3）开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一边、而工作在一般优先级任务上的情况。

变更请求管理的复杂程度与变更的具体类型有关。简单地说，变更请求管理会涉及到变更请求的提交、变更请求的复审、变更任务分配、变更结果的验证等一系列活动。通常，变更请求管理的流程是：由请求者提交变更请求，变更控制委员会（Change Control Board，CCB）召开CCB复审会议对变更请求进行复审，以确定该请求是否为有效请求。如果是，则基于项目团队所确定的优先级、时间表、资源、变更难度、风险、严重性以及其他相关标准，判定对该变更的修改程序，并分配实施变更任务的人力资源和时间资源；变更任务实施人员负责实施该变更；实施结束以后提交验证人员，由验证人员负责对变更结果进行验证，如果变更成功则通知相关人员，否则由变更实施人员返工。

典型的变更请求管理如需求变更管理、缺陷追踪等。实施有效的变更请求管理有以下好处：

（1）提高软件产品质量；

（2）提高开发团队沟通效率；

（3）帮助项目管理人员对产品状态进行客观的评估。

关于变更请求管理的详细过程以及相关准则PMT将在相关报告中阐述。

5、维护稳定、一致的工作空间

在我们把相关工件纳入集中的存储库、大家也都遵照“检出/检入”的工作模式对工件进行修改以后，下一步的工作就是要为每位开发人员设定“私有”的工作区，或者叫做工作空间。

工作空间通常以特定的基线为基础创建，要求能够做到为指定的任务方便地取出正确的工作版本建立私有工作空间；开发人员根据项目要求在自己的私有空间中对工件进行修改和测试活动，而与其他开发人员相对保持隔离，也就是说，自己的修改活动不会受到他人的影响，也不会影响到其他开发人员。但是，在保持隔离的同时，又应该提供相应的机制，当开发人员希望共享工作成果的时候，能够很方便地实现共享。

开发人员日常的开发工作都是在工作空间里进行的，因此，稳定性应该是工作空间首要的特性，只有高度稳定的工作空间才能保证开发人员的工作效率。

第四篇：项目配置管理心得体会

项目配置管理心得体会：

1、配置管理的定义：配置管理是标识和控制配置项，以维护其完整性、可追溯性以及正确性的学科

2、配置管理的过程：

（1）配置项识别。

（2）配置项标识。

（3）配置库创建。

（4）基线计划。

（5）备份计划。

（6）配置库管理（权限管理、基线管理、配置项审计、版本管理）

3、有效实施配置管理后的解决问题：

（1）开发人员未经授权修改代码或文档。

（2）人员流动造成企业的软件核心技术泄密。

（3）找不到某个文件的历史版本。

（4）无法重现历史版本。

（5）无法重新编译某个历史版本，使维护工作十分困难。

（6）“合版本”时，开发冻结，造成进度延误。

（7）软件系统复杂，编译速度慢，造成进度延误。

（8）因一些特性无法按期完成而影响整个项目的进度而导致项目失败。

（9）已修复的bug在新版本中出现。

（10）配置管理制度难于实施。

（11）分处异地的开发团队难于协调，可能会造成重复工作，并导致系统集成困难。

4、在实施配置管理过程中遇见的问题：

（1）配置管理制度难于实施。解决办法：在项目立项时，对项目组成员进行配置管

理制度理解培训，让大家都意识到配置管理在整个项目中重要位置。

（2）已修复的bug在新版本中出现。解决办法：有效的控制配置管理过程中每一

阶段的变更修改，并记录相关信息。如：

 谁进行的修改？

 修改了什么？

 什么时候进行的修改？

 为什么要进行修改？

 当前发布包含哪些新功能?

 当前发布对已有功能进行了那些增强?

 当前发布修复了哪些BUG?

第五篇：规范软件开发过程——软件配置管理实践

规范软件开发过程——软件配置管理实践

2010-05-19 来源：网络

随着软件系统的规模、复杂度日益上升，软件开发过程管理已经成为保证软件系统开发效率、质量、成本的关键性因素。作为软件开发过程中质量保障的重要组成部分，行之有效的软件配置管理（以下简称SCM，Software Configuration Management）能够显著提高软件开发组织的自身能力、提高软件开发过程的完整性，以及降低软件开发的风险。

软件配置管理的概念

ISO 9000、CMM、ISO/IEC 12207、IEEE 729-1983对SCM的定义有不同的描述。ISO9000定义SCM为“一个管理学科，它对配置项的开发和支持生命周期给予技术上和管理上的指导。配置管理取决于项目的规模、复杂程度和风险大小”。

CMM2将SCM定义为一个关键过程域KPA，是“贯穿于整个软件过程中的保护性活动，它被设计来（1）标识变化，（2）控制变化，（3）保证变化被适当的发现（4）向其他可能有兴趣的人员报告变化。”。SCM包括了配置项识别、工作空间管理、版本控制、变更控制、状态报告、配置审计等活动，其中以版本控制最为核心和关键。

数据集中工程软件配置管理策略

1、数据集中工程项目背景

中国建设银行数据集中工程的目标是通过建立总行级的数据中心，向全行38个一级分行、20000多个网点提供完整的核心金融服务。其核心应用系统DCC-CCBS包括主机、前置、前端三大部分。主机应用部分部署在总行级数据中心，前置应用部分部署在数据中心前置通信网关、各一级分行业务大前置，前端部分部署在网点。

DCC-CCBS项目的SCM需要实现开发、发布、部署的全过程软件配置管理。开发过程SCM的核心是系统源码版本管理；发布过程的SCM核心是系统目标码版本管理；部署过程以确保系统目标码版本在数据中心、一级分行、网点和外系统的正确部署为首要目标。

2、开发过程软件配置管理

系统源码版本除系统源程序、参数外，还包括需求规格说明书、系统总体架构设计说明书、主机/前置/前端系统结构设计说明书、各子系统的详细设计说明书、各子系统的对外接口规范、业务操作手册、系统使用手册、系统安装维护手册等文档。根据配置项的不同属性，经过评审，形成需求基线、设计基线和源代码基线等不同的基线。开发过程SCM按照子系统的性质，分为主机、前置、前端三部分独立管理。

DCC-CCBS项目总体组负责整个需求和变更的控制。通过审批的需求按照功能分布分解为主机、前置、前端的子需求，再由各部门分别管理和实现。环境及版本控制小组负责向各部门提出形成“系统基线”的要求，以同步主机、前置、前端的源码版本。

3、发布过程软件配置管理

发布过程的系统目标码版本包括系统目标码（执行码）、系统参数及相关文档等。按照用途，系统目标码版本可分为测试版和正式版。以前置平台为例，发布过程SCM的主要活动包括：构建环境管理，保证编译环境的纯净性和正确性；

构建过程管理，保证构建过程的自动化操作，及其正确性和完整性；

版本编号管理，统一版本命名规则，确保目标码版本号的唯一性和可追踪性；

目标码版本生成管理，从各版本管理工具系统收集、整理、打包相应的目标码、参数和文档，形成完整的或部分（补丁）的目标码版本；

配置状态检查，检查目标码版本包中内容的正确性、完整性和一致性；

4、部署过程软件配置管理

部署过程SCM的主要任务是：建立安全、可靠和迅速的传输流程和传输渠道；建立目标码版本记录和追踪机制、版本运行时刻检查机制和版本恢复机制；确保正确的版本、按照正确的渠道、在规定时间递交到正确的用户并生效。

在DCC-CCBS生产环境中，软件开发中心将通过数据中心版本管理系统发布各单位所需的目标码版本，各单位在版本管理系统和数据传输通道的支持下，实现版本/补丁的主动分发、查询、下载和生效。

软件配置管理实施经验

1、树立正确的企业配置管理意识

SCM是一门管理学科。归根结底，其关键是“管理”，然后才是“软件配置”。项目级SCM能否成功实施，与企业的软件配置管理目标、策略、能力、组织和资源息息相关。

2、提高全员的配置管理素质

SCM是规则和流程的集合，需要依靠流程中所有部门和人员共同的支持和努力。任何环节上的疏忽和懈怠，都将直影响SCM的实施效果。

3、采用合适的工具

功能强大的或昂贵的工具未必是合适的工具。往往20%的功能即可解决80％的配置管理问题。目前比较流行的版本管理工具包括CVS、PVCS、ClearCase、Harvest、VSS、Endeavor等。在选择具体工具时，往往需要考虑以下因素：（1）工具将要使用的范围；（2）工具自身的功能、稳定性、扩展行，以及对环境的要求；（3）工具使用的复杂度；（4）工具与其他流程和工具的集成度和交互性；（5）工具的投资和维护费用。

4、及时的检查和梳理

大系统开发过程中，配置管理往往采用分步离散管理方式，因此保证整个系统配置管理的完整性成为一件精密细致的工作，需要投入大量人力及时修订基线，防微杜渐，避免混乱，以满足对配置管理正确性、完整性和及时性的要求。

5、系统化思考、分步实施、持续改进

SCM不是一项孤立的管理活动。企业的战略目标、管理能力、文化背景、组织结构，项目的规模、性质、技术、人员等都是影响SCM决策的重要因素。因此需要在项目乃至企业的整体环境中系统的考虑SCM的实施策略和方法。

通过分阶段实施量化的、渐进的配置管理目标，可以避免由于引入复杂管理流程所造成的混乱，有利于方便灵活地优化配置管理流程。同时，阶段性目标的实现将有助于整个团队提高士气、增强信心，并逐步提高开发队伍的配置管理素质。