1、论项目的配置管理摘要 某企业是以是一家集研究、开发、生产、销售于一体的现代生活用纸企业；旗下拥有两个异地生产基地，全国各地有 30 个销售办事处；随着业务的不断扩大，原有手工操作工作效率低下、业务流程不规范，造成管理上存在很多隐患，无法实现企业的精细化管理；为了实现这个目标，企业于 2007 年 3 月与某软件供应商签订了 ERP 系统项目合作协议，整个项目于 2008 年 12 月通过了总体的验收。本文结合我的工作经历，简要叙述项目的基本情况和对配置管理的认识，以及配置管理的六个过程。详细阐述了项目中所遇到的配置管理问题，以及解决这些问题所采用的方法和技术；并分析采用这些措施所取得的效果；最
2、后提出一些改进措施。 正文 某企业是以是一家集研究、开发、生产、销售于一体的现代生活用纸企业；旗下拥有两个异地生产基地，全国各地有 30 个销售办事处；随着业务的不断扩大，原有手工操作内部信息交流不顺畅、不能有效共享资源、工作效率低下、业务流程不规范，造成管理上存在很多隐患，无法实现企业的精细化管理；为了实现这个目标，企业于 2007 年 3 月与某软件供应商签订了 ERP 系统项目合作协议，实施信息化管理，提升核心竞争力。系统整体模块有：销售管理、采购管理、库存管理、物流管理、生产管理、财务管理、基础数据管理、权限管理模块。在这个项目过程中我主要担任的工作是：完成项目的需求分析、系统实施和项
3、目的日常管理的工作。日常管理方面的工作包括：项目过程中所有文档和配置的管理。在项目开发过程中，需要处理的配置管理问题是有：没有规范的配置管理流程、没有使用配置管理工具等等； 配置管理在项目管理中具有重要的地位和作用，是软件生命周期的重要控制过程；配置管理是通过技术及行政手段对产品及期开发过程和生命周期进行控制、规范的一系列措施和过程。配置管理过程是对来断演化、完善过程中的软件产品的管理过程，最终目标是实现软件产品完整性、一致性、可控性，使软件产品最大程度与用户需求相吻合。 配置管理包括六个基本过程：配置管理计划、配置标识和建立基线、变更管理、版本管理、配置审核、配置状态报告。配置管理计划是配置
4、管理员制定配置管理所需的各项计划，如：配置项计划、基线计划、交付计划、备份计划等；配置标识和建立基线是识别配置项并创建基线；变更管理是跟踪并采取措施保证变更在受控状态下进行，防止配置项被随意修改而导致混乱等现象，并且可以快速准确地找到配置项的任何版本；配置审核是验证配置项对配置标识的一致性，防止向用户提供不合格的产品；配置状态报告是有效地记录和报告配置项所需的信息，目的是及时、准确地给出软件配置项的当前状况，供相关人员了解，以加强配置管理工作。配置管理过程主要采用了 VSS工具对其进行管理。 由于本企业整体的信息化基础比较薄弱，并且用户分散在异地，因此对用户的变更申请要做好控制，如何保证驻地实
5、施与总部实施配置项和版本一致性，确保项目成果与用户需求相吻合，对我们来说是一个挑战。在项目配置控制上，我们采取以下措施来解决配置管理中经常出现的问题： 1、 定义配置项标识，做好版本管理 为了统一实施过程是的文档，我制定了文档的命名规则；如标识号由“项目代号”、“配置项分类号”和“版本号“构成，如：S1A1001，其中 S1为项目代号、A1O 配置项分类号、001 为版本号；文件修改后按命名规范修改相应的版本号，这样当需要查找历史资料时，可以抽取不同的版本，也可以对比不同版本的内容，追踪文件的变迁过程。 在项目实施过程中，出现过几次不同用户对同一个问题而提出不同描述的变更请求，因为版本管理做得
6、好，每涉及的变更请求都可以抽查不同时期的文档和源程序的不同版本，这样避免了变更混乱的现象，也方便了后期的维护工作。 2、 启动变更控制委员会，规范变更管理流程 配置管理的一个重要内容就是对变更加以控制，使变更对成本、工期和质量的影响降到最小，变更必需是有序的、可控的，在本项目的变更控制中，我启用了变更控制委员会（CCB），包括双方项目负责人、用户代表、配置管理员，由 CCB 对提出的变更实施决策。变更管理和主要任务包括分析变更，即根据成本效益和涉及到的技术等因素判断变更实施的必要性，确定是否实施变更；记录变更信息，并追踪变更信息；确保变更在受控的条件下进行。 为了明确变更需求和便于管理，我要求
7、所有的变更申请都必需以书面的形式提交到项目组，再通过控制委员会确定是否变更，以更好的控制项目实施进度、并保证了项目的质量。接到变更请求后，我先根据变更需求从系统的可行性、增加的工作量是否对项目进度造成影响等因素考虑是否需要招开项目委员会会议讨论确定，如果变更需求比较小，不涉及系统内核变动或流程与关键业务处理的，就把变更需求直接交给软件公司项目经理，项目经理确认后则交给系统工程师处理，否则则通知委员会成员招开会议讨论并确定，会后，以书面形式将评审结果发给需求变更负责人与软件公司变更处理负责人，对于经评审批准的变更，我会根据变更影响的程度，适当调整项目进度，同时以书面形式下达变更通知，进行变更的实
8、施，并要求做好变更记录，以提高项目实施的工作效率。 在项目实施过程中，物料信息只有一种计量单位，但现实使用过程中是不止一种计量单位的，比如：螺丝钉这一物资，采购时是按单位盒来采购，入库时也是按盒，但是领用时是按只来领用，虽然可以通过单位换算出来，但存在的误差还是到不到财务的要求；所以财务提出需要改为多种计量单位。经过 CCB 审核后，执行这变更请求，并以书面形式通知各相关人员，配置管理员做好变更记录。 3、 利用配置状态报告，记录和跟踪配置项的改变 变更大多来自于用户需求，但也有来自系统本身的设计问题，变更申请可能被通过，也可能被拒绝。对于每一个变更申请单都要记录下来，通过 CCB 审核的，要
9、登记变更的实施情况及实施后的效果，没有通过审核的，也要记录被拒绝的原因，以防日后再提出。这些信息都要记录在配置状态报告中，便于开发人员之间的沟通，也方便了开发人员和用户的沟通，避免可能出现的不一致和冲突。 比如，物料计量单位，我们把它改为多计量单位后，仓库入库时要输入不同计量单位所对应的数量，这样增加了他们的工作量，他们认为只要输入一种计量单位的数量，然后通过单位换算出来就行了，于是他们对此又提出了变更请求；CCB 最终没有通过这次变更请求，我通过配置状态报告，给申请人看了上次变更申请单的处理资料，向他解释不能通过的原因，得到了他的理解。项目于 2008 年 12 月顺利通过验收，按期完成，得
10、到用户的认可。在处理项目实施过程的变更中，配置管理起到了较好的作用。 配置管理过程中我们采用了 VSS 工具对整个过程进行管理，该工具功能强大、易学易用，使得版本管理和变更管理等相关配置管理都做得比较好；但是我们的流程和文档格式的规范性还有待于提高；在今后的配置管理过程中，对变更过程的评估一定要仔细，可以采用正式的技术评审和软件配置审核方法，正确理解用户的需求,以免后期工作反复。比如物料计量单位，刚开始我们也是认为没有必要这样做，只要里面设置单位换算就行了，没想到它的精度对不同的业务部门需求不一样而达不到要求，如果当初和用户沟通细心一点，这个问题就会提前解决。 我认为要做好配置管理首先要有统一
11、思想和理念，然后是方法，最后是工具。因为我们这次项目特殊性是用户分散在异地，所以我们把配置文档共享到服务器上并设置好使用权限，让异地实施人员方便的查找配置信息。我们严格遵循配置管理的理念，按照变更管理和流程来执行变更管理。论软件项目的配置管理【摘要】 我于 2005 年 1 月至 2006 年 1 月参加了某个知名饮料集团公司的企业信息系统的开发工作，该大型集团的业务主要涉及到奶制品的进销存。本人在项目中负责系统分析，设计和部分测试与系统实施的工作，本文从配置管理工具的选择、配置管理流程制定、配置管理库结构的确定，以及作为配置管理工作的推动者如何推动这项工作等方面仔细描述。本人参与了该项目的系
12、统分析、设计、测试和实施工作，实现了该系统的库存管理、供应链管理、销售管理和 OA 等子系统。通过该项目的配置管理和实施，应该说，这次我们对项目的配置管理实施是非常成功的，在整个开发过程中，基本没有出现因为配置管理的问题导致的对开发进度的延误。当然，在开发过程中也发生了由于需求变化导致基线变更引起开发进度的延迟，不过这不应该算作是配置管理的失误，因为作为配置管理来说，只能尽量保证基线变更不会导致项目失控。【正文】 2005 年年初，我参加了某个知名饮料集团公司的企业信息系统的开发工作，该大型集团的业务主要涉及到奶制品的进销存，该项目的工作量大约是 12 人年，项目周期约为 1 年。大部分（90
13、%以上）的开发工作在前 6 个月内完成，后期的工作主要由维护人员进行系统维护和调整。在 6 个月的开发时间中，前 4 个月由开发人员在公司进行开发，根据用户的需求完成设计，确定系统架构并实现整个框架，部分明确的功能以及公用模块也在这段时间内完成；后 2 个月的时间部分开发人员在现场，部分开发人员在公司共同完成后期的开发工作。整个项目采用的开发语言是 C+、Java、ASP，涉及的平台包括Solaris 和 Windows，采用的开发工具包括 Visual Studio 和 Solaris 上的CC。此外，整个项目还使用了一些第三方的平台，如 IBM 的 MQ 等。除用户需求之外，公司还对项目组
14、提出了代码复用方面的要求，开发人员在开发过程中必须注意代码的可重用性。 在项目正式启动之后，配置管理工作就可以开始了。配置管理工作开始的第一步就是一份配置管理计划。我认为需要在配置管理计划中明确的内容包括：1、 配置管理软硬件资源； 2、 配置库结构； 3、 人员、角色以及配置管理规范； 4、 基线计划； 5、 配置库备份计划； 配置管理环境包括软硬件环境。具体的资源需求应该根据项目实际情况来确定，一般需要考虑的包括：网络环境、配置管理服务器的处理能力、空间需求，配置管理软件的选择等。配置管理环境的确定需要综合考虑各个方面的因素，包括我们采用的开发工具，开发方式，开发人员对配置管理工具的熟悉程
15、度等，其中，开发人员对配置管理工具的认可和熟悉程度常常直接决定配置管理能否正常进行，如果选择了需要开发人员花费比较大的精力去熟悉的配置管理软件，我们就必须花费大量时间来进行培训；同时，配置管理软件和开发工具的集成程度也是一个必须考虑的因素，根据我们的经验，选择一个和开发环境集成紧密的配置管理工具至少可以减少 20%花费在 Check In/Check Out 和配置管理人员保持配置库完整上的工作量。根据我们项目的实际情况，我们有如下一些考虑： 根据历史经验，一个类似项目的配置库大小约为 3G，考虑到备份等操作对空间的需求，至少应该为配置管理库保留 10G 以上的空间。为了保证配置管理库的安全，
16、除了相应的备份计划之外，还可以采用了 RAID 01 的方式为配置数据库提供更好的可用性保证；考虑到在项目的后期有部分开发人员会在现场进行开发，因此在网络条件上需要提供对远程访问方式的支持；配置管理服务器的选择和配置管理软件的选择相关，考虑到目前公司有一台闲置的PC 服务器，最好能充分利用这台服务器；配置管理软件必须可以以某种方式支持远程访问，而且由于我们的开发平台涉及 Solaris 和 Windows，配置管理软件要能够支持这两种平台；考虑到开发工具方面，配置管理工具要求能和我们选择的开发工具进行很好的集成；项目组的开发人员缺乏使用配置管理工具的经验，有将约 30%的开发人员使用过 VSS
17、 配置管理工具，但仅限于最基础的使用，对 VSS 的 Label 等功能没有概念；结合以上的情况，我们首先考虑配置工具的选择。 从开发人员具有的配置管理工具使用经验和配置管理工具使用的难易度方面来说，VSS 是最好的选择，在现有的基础上只需要对开发人员进行简单培训；考虑到和开发工具的集成，VSS 也是一个不错的选择。因为 VSS 简单易用，在大多数人眼里，VSS 似乎都只是一个玩具，难登大雅之堂，最多能管管自己的代码，要用团队开发中，那似乎是不可能的。刚接触 VSS 时，我也是抱着差不多的想法，觉得要用 VSS 作为一个较大的项目的配置管理工具完全不可能，但随着对 VSS 研究的深入，加上在工
18、作中也使用了其它一些配置管理工具，如 CVS、ClearCase、CCC harvest 等工具，反过来比较，反而觉得 VSS 有它独到的地方。不过本项目还要求对远程接入方式的支持，以及对 Solaris 平台的支持，VSS 肯定是不能满足要求的（VSS 通过 VPN 方式应该是可以实现对远程访问的支持，但 VSS 的完全共享方式实在是不敢在 Internet 上使用）。除 VSS 外，可以选择的配置管理工具还有 CCC Harvest、ClearCase、CVS 等，但 Harvest 和 ClearCase 使用起来比较复杂，需要一个专门的配置库管理员负责技术支持，还需要对开发人员进行较多
19、的培训，另外，Harvest 和ClearCase 价格不菲；CVS 在 Unix 下使用方便，而且是免费的，但其文本方式的操作界面对于习惯在 Windows 平台上开发的开发人员来说使用非常不习惯（CVS 也有 windows 下的 GUI 版本，但经过我们的试用，在操作习惯上和我们目前开发人员习惯的方式很不相同，较难被接受）。 经过在 MSDN 和Internet 上查找，终于找到了一个 VSS 的增强软件 SOS（Source Offsite），它基于 VSS 的数据库，可以支持通过 TCP/IP 方式访问和操作 VSS 库，在Windows、Slolaris 和 Linux 上都提供了
20、客户端，并且通过传输数据的压缩和加密方式，使得文件操作的速度大大加快并增强了系统的安全性。事实证明，VSSSOS 的组合在我们的整个项目过程中起到了关键的支持作用。我们使用的 SOS 是 3.53 的 Standard 版本。 确定了配置管理工具后，我们使用公司购置的一台 Compaq PC Server 作为配置管理的硬件环境，VSS 对硬件配置要求不高；作为一个工作组级别的配置管理工具，在我们的项目中，安装 VSS 的配置服务器是一台 P4 2.2G/512M RAM/30G4 Disk 的 HP PC 服务器，这样的条件下 VSS 运行已经足够稳定和快速，相比起 CC 和 CCC har
21、vest 的要求，这部分的投资是很小的；如果再考虑到 CC 和 CCC 都运行在 Unix 平台上需要的维护费用，当然是 VSS 更加划算了。最终确定的方案是安装该服务器安装 Windows 2000 Server 操作系统，为了保证配置数据的安全性，我们采用 RAID 01 方式，总的可用空间在 50G 左右；另外为了备份的需要，还为服务器配置了一个 CDR 刻录机。 对于网络环境的选择，因为公司已有现成的 100M 局域网，通过一个交换机和路由器连接至 Internet，有一个公网的静态 IP；配置管理服务器是内网的一台机器，具有一个内网 IP。为了满足远程访问的需要，我们通过在路由器上设
22、置端口映射，将 SOS 需要使用的端口映射到配置管理服务器上（缺省情况下，SOS 使用 8888 和 8890 两个端口）。网络拓扑图如下： 在公司的开发人员通过局域网使用 VSS 访问和操作配置库，在现场的开发人员通过 Internet 接入对配置库进行访问和操作。 我制订了配置库维护和备份计划 ，配置库的维护的备份需要专职的配置库管理员来负责。在整个项目中我们采用的配置库维护策略是根据 Microsoft 的Best Practice 白皮书建议，包括以下要点： 1、 保持配置数据库的大小不超过 5G；Microsoft 建议，配置库的大小在35G 比较合适，太大的数据库会极大影响 VSS
23、 的效率；减小配置库大小的 2、 每周进行 VSS 数据库的分析（Analysis），发现问题及时修正；VSS 提供了 Analysis 和 Fix 工具，由于不合理的 Delete 等操作，VSS 数据库有可能会出现一些 Interrupt Data 之类的问题，通过定期的每周的分析工作，可以极大减少数据库出现问题的风险； 3、 每日进行配置库的增量备份，每周进行数据库的完全备份；VSS 库的备份可以通过 VSS 自己的 Archive 功能或者是操作系统的 Backup 程序来进行。VSS 的 Archive 功能对 VSS 中的文件数据进行压缩并保留 VSS 的所有状态，但只能对 VSS
24、 库进行完全备份，不能实现增量备份功能。Windows2000 Server提供的 Backup 实用程序可以对文件进行备份，由于 VSS 库就是以文件形势存在的，因此针对 VSS 的 data 目录进行备份也可以完全达到备份的目的，使用系统备份工具的好处是可以实现增量备份。 我们在实际中使用的系统的备份工具，每周五生成的完全备份采用刻录光盘的方式保存，每天的增量备份数据存放在文件服务器上进行备份。 配置项的命名包括两个方面的内容： 1、配置项标识：在我们的项目中，一般使用“项目名_配置类别_配置项特殊标识”来命名。配置项命名中的“配置项特殊标识”根据配置类别的不同而不同。比如，对“设计文档”
25、，如果细分的话，可以分为“概要设计”和“详细设计”；对“代码”，可以按照模块来命名配置项。 2、配置项版本命名：配置项版本命名是针对配置项的版本进行命名，在我们的项目中，配置项版本通过对 Project 的 Label 操作来实现，配置项版本的命名需要能清楚标识配置项的状态。一般说来，配置库至少包括个人工作区、受控库、发布区三个部分，在我们的项目中，所有的配置项都保存在一个 VSS库中，对这三个部分的划分是通过逻辑划分方式进行的，具体来说，就是通过配置项版本命名来划分的。因此，我们配置项的版本命名规定如下： a) 基线版本：按照基线的状态，我们这个项目中的基线有两个方面：一是作为里程碑的基线；
26、另一个是模块的阶段性成果基线（对工作产品而言），由模块的负责人确定。 里程碑基线对我们的项目来说，采用的是迭代的开发过程，以一个迭代过程为例，分为需求、概要设计、详细设计、代码实现、单元测试、集成测试、系统测试七个阶段，每个阶段都需要产生里程碑。对每个里程碑都有明确的标识标明当前状态。 阶段性成果基线阶段性成果主要体现在代码过程中，比如代码进行到一个阶段，开发组长认为代码的这个状态可以保留，就可以确定为一个代码基线。这种基线一般不需要通过评审等正式手段来确定，但也必须有相应的验证手段；比如在我们的项目中，在代码阶段，确定代码基线的责任人是开发组长，但开发组长必须保证代码基线符合一定的条件。 b
27、) 其他版本：除基线版本外，有时候还需要在开发和维护过程中确定其他版本。例如，产品在测试过程中不断的问题修复过程中，可能会有多种反复，此时需要将每次修改的内容作为一个版本。 关于版本，还有另一个需要注意的问题。一般来说，按照模块来划分，每个模块有自己的版本演进比较合理。首先，一个模块一般是由一个或两个开发人员完成的；其次，一个模块的功能会比较单一且独立，在版本的演化过程中便于控制，也不会和其他模块产生过于复杂的关系。而产品的版本则需要由各个模块的不同版本组成，这个纵横的关系需要很好地管理，我们的做法是在 VSS 库上用 Label 来标识，同时维护一张描述产品版本和模块版本关系的矩阵图便于追踪
28、。 在确定了配置项之后，就可以确定配置库的目录结构了。配置库的目录结构直接关系到配置管理的工作量和使用的方便性，所以需要根据自己的需要确定一个合理的结构。 在确定配置管理库目录结构的时候，我们曾经考虑过两种产品目录结构的方式：一种是按照模块划分，在模块下再划分诸如设计文档、代码等目录；另一种方式是按照产品类型划分，例如首先是文档、代码，然后在其下按照模块划分。 这两种方式都有自己的优点，最终我们还是选择了前一种划分方式，一方面是考虑便于进行权限的分配，另一方面是考虑到便于将同一模块的所有内容组织起来进行版本的管理。 角色是配置管理流程的执行者和参与者，定义明确的角色有利于实现明确的授权和明晰的
29、流程，虽然在实际中可能多个角色由一个人担任，但还是应该保留角色的定义。 我们所说的配置项变更流程主要是针对配置项发生变化的控制，在我们的项目中分为两个部分，首先是对配置项新建、检入（CheckIn）和检出（CheckOut）的规定；其次是对入库的文件类型和大小的规定：新建、检入、检出及破坏 1、 新建：即 Add，除特殊情况外，一般不规定由谁来新建（只要有权限即可），但尽量指定每个 project 只有一人负责新建。 2、 检入：即 check in，检入频率规定如下： i. 在代码编写前，至少每周一次 ii. 代码编写阶段，至少每天一次 iii. 测试阶段以后，根据代码、文档的变动，只要当天
30、有变动就要检入一次。iv. 为配合检查、备份工作，需在检查备份周期前全部 check in (不保持check out)并退出登录。详见“检查及备份”部分 3、 检出：即 check out。原则上只对要修改的文档方可检出。 4、 破坏（Destroy）：一般情况不可以破坏文件、目录。 5、 如果是误操作，则可在一天内提交管理员处 6、 如果超过一天，则需要由项目经理同意，且管理员破坏前要备份。 7、 各阶段环境职责 配置项发布是指配置项进行到一定的阶段（例如，里程碑阶段），需要对外发布时的规则。在我们的项目中，配置项发布是通过标签，即 LABEL，来实现的。 基线确立与变更 ，基线的确定在上
31、一部分中已经说到过，我们的项目基线分为两类，一类是作为里程碑和其他工作依赖的基线（例如需求文档、设计文档等），另一类是开发过程中有必要保留的一种状态（例如代码过程中某个模块的一个有保留价值的 snapshot）。对这两种不同的基线，其影响的范围不同，确立和变更方式也不一样。 我们项目的基线变更控制委员会由客户代表、产品经理、项目经理以及技术经理组成，对发布的里程碑类基线的变更必须由变更控制委员会确认并由 QA进行变更记录，所有被变更影响的配置项都需要重新同步后再次发布；而对于仅仅作为工作状态保留的基线，一般只需要建立基线的小组确认更改并在QA 进行记录即可。 通过该项目的配置管理和实施，应该说
32、，这次我们对项目的配置管理实施是非常成功的，在整个开发过程中，基本没有出现因为配置管理的问题导致的对开发进度的延误。当然，在开发过程中也发生了由于需求变化导致基线变更引起开发进度的延迟，不过这不应该算作是配置管理的失误，因为作为配置管理来说，只能尽量保证基线变更不会导致项目失控。选择一个合适的配置管理工具绝对是必要的，我们在前面用了一章多的篇幅介绍我们使用的配置管理工具及其方案，事实证明，我们选择的配置管理工具对我们项目管理实施的效果是决定性的。 在配置管理实施的初期，及时的指导起的作用是巨大的，甚至可以说是成功的主要因素；对不熟悉配置管理的开发工程师来说，配置管理工作容易在一开始就让他们产生厌烦情绪，一点点使用上的不方便就会导致开发人员对配置管理的怨言，这个时候，及时的指导就显得非常重要了，我们在配置管理实施过程中，准备了VSS 操作手册、SOS 简明操作手册、配置管理操作指导书等手册，进行了三次的培训，并在实施过程中随时解决开发人员在使用配置管理工具中的问题。而且，在实施初期，我们以奖励为主，在一个月的时间内没有将配置管理工作作为考核内容。 在配置管理基本走上正规后，每周的配置状态检查是我们对配置管理执行效果的检查，一旦发现问题，会作为 QA 问题报告发出并要求限期改正。 如果没有这个检查制度，配置管理工作很难持续受控。
