工程型软件项目的配置管理实例
前言
软件配置管理作为贯穿软件开发过程始终的一项工作，其重要性不言而喻。51cmm上已有众多关于配置管理介绍、配置管理计划、配置管理工作开展心得一类的文章，这些文章从概念和实施上介绍了配置管理工作的内容，但美中不足的是仍嫌抽象，那些想要依葫芦画瓢的兄弟姐妹们在试图将这些理论应用到自己项目的配置管理中的时候，会发现仍然是无从下手（我也曾是这些感觉无从下手的人中的一个）。因此，本文拟从另外一个角度，以本人最近实际操作的一个项目的配置管理工作谈起，从配置管理工具的选择、配置管理流程制定、配置管理库结构的确定，以及作为配置管理工作的推动者如何推动这项工作等方面仔细描述一下本人的做法，希望这几篇文章能给那些水深火热中的兄弟姐妹们一点帮助。
这里有两点需要特别说明：
1、本文描述的内容是以一个项目的配置管理为主线，对组织级的配置管理和配置管理策略没有进行详细讨论；
2、本文用来做示例的项目是一个“工程型”的项目，所谓的“工程型”是和“产品型”对应的，这样的项目需要公司的开发人员和现场的开发人员进行协作开发，一般而言，在公司的开发人员完成大部分的功能，现场的开发人员根据用户需求，对软件进行修改（这部分的工作量一般会较大，在一个16人年的项目中，这部分的工作可能会占到三分之一以上的工作量）。
配置管理工作概述
配置管理工作的工作范围，在51cmm的很多文章中都有描述，具体可以参考河清专栏的《基于CMM和CMMI 的配置管理》和陈越的《软件配置管理实施体会》。在这里不作详细的描述。
本文涉及的项目背景
本文用来示例的项目是某省电信的一个项目，该项目的工作量大约是16人年，项目周期约为1年。大部分（90%以上）的开发工作在前8个月内完成，后期的工作主要由维护人员进行系统维护和调整。在8个月的开发时间中，前5个月由开发人员在公司进行开发，根据用户的需求完成设计，确定系统架构并实现整个框架，部分明确的功能以及公用模块也在这段时间内完成；后3个月的时间部分开发人员在现场，部分开发人员在公司共同完成后期的开发工作。
整个项目采用的开发语言是C++、Java、ASP，涉及的平台包括Solaris和Windows，采用的开发工具包括Visual Studio和Solaris上的CC。此外，整个项目还使用了一些第三方的平台，如IBM的MQ等。
除用户需求之外，公司还对项目组提出了代码复用方面的要求，开发人员在开发过程中必须注意代码的可重用性。
配置管理前期准备工作
在项目正式启动之后，配置管理工作就可以开始了。配置管理工作开始的第一步就是一份配置管理计划。51cmm上已有不少配置管理计划的模板，大家可以参考。
一般而言，需要在配置管理计划中明确的内容包括：
1、配置管理软硬件资源；
2、配置库结构；
3、人员、角色以及配置管理规范；
4、基线计划；
5、配置库备份计划；
在下文中，我们将围绕这些内容进行详细描述。
配置管理环境
配置管理环境包括软硬件环境。具体的资源需求应该根据项目实际情况来确定，一般需要考虑的包括：网络环境、配置管理服务器的处理能力、空间需求，配置管理软件的选择等。配置管理环境的确定需要综合考虑各个方面的因素，包括我们采用的开发工具，开发方式，开发人员对配置管理工具的熟悉程度等，其中，开发人员对配置管理工具的认可和熟悉程度常常直接决定配置管理能否正常进行，如果选择了需要开发人员花
费比较大的精力去熟悉的配置管理软件，我们就必须花费大量时间来进行培训；同时，配置管理软件和开发工具的集成程度也是一个必须考虑的因素，根据我们的经验，选择一个和开发环境集成紧密的配置管理工具至少可以减少20%花费在Check In/Check Out和配置管理人员保持配置库完整上的工作量。
根据我们项目的实际情况，我们有如下一些考虑：
根据历史经验，一个类似项目的配置库大小约为3G，考虑到备份等操作对空间的需求，至少应该为配置管理库保留10G以上的空间。为了保证配置管理库的安全，除了相应的备份计划之外，还可以采用了RAID 0＋1的方式为配置数据库提供更好的可用性保证；
考虑到在项目的后期有部分开发人员会在现场进行开发，因此在网络条件上需要提供对远程访问方式的支持；
配置管理服务器的选择和配置管理软件的选择相关，考虑到目前公司有一台闲置的PC服务器，最好能充分利用这台服务器；
配置管理软件必须可以以某种方式支持远程访问，而且由于我们的开发平台涉及Solaris和Windows，配置管理软件要能够支持这两种平台；考虑到开发工具方面，配置管理工具要求能和我们选择的开发工具进行很好的集成；
项目组的开发人员缺乏使用配置管理工具的经验，有将约30%的开发人员使用过VSS配置管理工具，但仅限于最基础的使用，对VSS的Label等功能没有概念；结合以上的情况，我们首先考虑配置工具的选择。
配置管理工具的选择软硬件环境的选择
确定了配置管理工具后，我们使用公司购置的一台Compaq PC Server作为配置管理的硬件环境，该服务器配置如下：
CPU：1CPU，P4 2.0G
内存：512M DDR
硬盘空间：30G×4
网卡：HP G bit网卡一张
最终确定的方案是安装该服务器安装Windows 2000 Server操作系统，为了保证配置数据的安全性，我们采用RAID 0＋1方式，总的可用空间在50G左右；另外为了备份的需要，还为服务器配置了一个CDR刻录机。网络环境的选择
公司已有现成的100M局域网，通过一个交换机和路由器连接至Internet，有一个公网的静态IP；配置管理服务器是内网的一台机器，具有一个内网IP。为了满足远程访问的需要，我们通过在路由器上设置端口映射，将SOS需要使用的端口映射到配置管理服务器上（缺省情况下，SOS使用8888和8890两个端口）。
网络拓扑图如下：
在公司的开发人员通过局域网使用VSS访问和操作配置库，在现场的开发人员通过Internet接入对配置库进
行访问和操作。
配置库维护和备份计划
配置库的维护的备份需要专职的配置库管理员来负责。在整个项目中我们采用的配置库维护策略是根据Microsoft的Best Practice白皮书建议，包括以下要点：
1、保持配置数据库的大小不超过5G；Microsoft建议，配置库的大小在3－5G比较合适，太大的数据库会极大影响VSS的效率；减小配置库大小的
2、每周进行VSS数据库的分析（Analysis），发现问题及时修正；VSS提供了Analysis和Fix工具，由于不合理的Delete等操作，VSS数据库有可能会出现一些Interrupt Data之类的问题，通过定期的每周的分析工作，可以极大减少数据库出现问题的风险；
3、每日进行配置库的增量备份，每周进行数据库的完全备份；VSS库的备份可以通过VSS自己的Archive 功能或者是操作系统的Backup程序来进行。VSS的Archive功能对VSS中的文件数据进行压缩并保留VSS 的所有状态，但只能对VSS库进行完全备份，不能实现增量备份功能。Windows2000 Server提供的Backup 实用程序可以对文件进行备份，由于VSS库就是以文件形势存在的，因此针对VSS的data目录进行备份也可以完全达到备份的目的，使用系统备份工具的好处是可以实现增量备份。我们在实际中使用的系统的备份工具，每周五生成的完全备份采用刻录光盘的方式保存，每天的增量备份数据存放在文件服务器上进行备份。【小结】在本章中，我们描述了工程型项目配置管理的一些概念，着重介绍了配置管理的环境，包括配置管理工具的选择等。在配置工具选择方面，我们采用VSS＋SOS的组合方案，第二章中，我们将重点介绍VSS 和SOS工具的使用，并在介绍配置管理规范中结合配置管理工具讲解具体的操作
配置管理双枪将VSS＋SOS
说起VSS，接触过的人应该不少。尤其是用用VC和VB做开发的人，绝大多数人应该都接触过和使用过VSS。VSS小巧精干，和VS开发工具集成极为紧密，就算不使用专门的配置服务器，直接在自己的开发用机上安装一个VSS，也能在代码管理方面方便不少。SOS在上一章中已经做了介绍，这一章将详细介绍之。
VSS概念
也许正因为VSS简单易用，在大多数人眼里，VSS似乎都只是一个玩具，难登大雅之堂，最多能管管自己的代码，要用团队开发中，那似乎是不可能的。刚接触VSS时，我也是抱着差不多的想法，觉得要用VSS作为一个较大的项目的配置管理工具完全不可能，但随着对VSS研究的深入，加上在工作中也使用了其它一些配置管理工具，如CVS、ClearCase、CCC harvest等工具，反过来比较，反而觉得VSS有它独到的地方。关于VSS和其他配置工具的比较，在google上搜索的话应该能找到一大堆，我这里给出几个对我来说印象最深刻的VSS的优势：
1、VSS操作使用简单；要在配置管理工具中评选“最平易近人奖”，那一定非VSS莫属。VSS中包含了配置管理需要的全部操作，但应用起来却非常简单，首先是全部操作都可以通过GUI完成，如Check In/Check Out 操作、Get Latest等基本操作；Label、Share、Branch、Merge等高级操作；其次是VSS和开发环境集成紧密，在开发环境的IDE中就可以方便地完成操作；
2、VSS对硬件配置要求不高；作为一个工作组级别的配置管理工具，在我们的项目中，安装VSS的配置服务器是一台P4 2.2G/512M RAM/30G×4 Disk的HP PC服务器，这样的条件下VSS运行已经足够稳定和快速，相比起CC和CCC harvest的要求，这部分的投资是很小的；如果再考虑到CC和CCC都运行在Unix平台上需要的维护费用，当然是VSS更加划算了；
3、VSS几乎是免费的；只要购买了VS开发工具，就能免费使用VSS；
4、VSS备份/恢复非常简单；只需要通过拷贝——覆盖就能完成VSS的备份/恢复工作，你说简不简单？：）
5、有良好的可扩展性；通过VSS的自动化接口（Automation），可以自己写程序来完成对VSS库的访问，也正是基于这点，目前市面上已有一些VSS的扩展工具出现，我们在本章要讲的就是其中之一——Sourcegear 的SOS。
说了这么多优点，当然不是说VSS就只有优点，和其他的配置管理软件比起来，VSS也有一些不足之处：主要表现在以下几点：
1、缺乏对Unix的支持（没有Unix上的客户端或者服务器，这是微软的一贯作风）；
2、不支持远程访问方式（只能通过第三方的扩展工具实现）；
3、支持的配置数据库大小建议不超过5G SOS（SourceOffSite）软件介绍
接下来，我们重点介绍SOS软件，包括软件的安装、配置和使用。
SOS软件的安装
SOS软件分为服务端和客户端两个部分，客户端运行在配置管理服务器上，客户端运行在需要访问配置库的客户机上。以下以SOS 3.5.3标准版的SOS为例，说明该软件的安装、配置和使用。
服务端的安装和设置
SOS可以从Sourcegear的网站上下载试用，免费版本可以试用30天，允许10个用户，目前最新版本是4.0。不过为了解决SOS中的中文问题，建议大家从华军软件园中找到中文SOS进行安装（所谓的中文SOS是国内的高手修改了SOS 3.53程序使其支持中文）。
上图是中文SOS安装时的安装界面，选择安装目录等，一路Next，很容易就安装完成了。安装完成后，系统在“开始”菜单中生成了中文SOS的相关菜单项目。
下图是安装完成中文SOS之后生成的菜单：
安装完成后，需要对SOS进行设置。选择中文SOS菜单的“服务器管理”进入设置界面：
“System Info”页面显示的是SOS的概要信息；
“General Setting”页包含了重要的设置信息，选中“use unsecure port”表示允许使用非加密模式进行数据传输，端口号在后面的编辑框中设置；选中“use secure port”表示允许使用加密模式进行数据传输，端口号在后面的编辑框设置。“Version 2.0 Compatibility”用来选择加密模式，一般选择128bit模式即可。在“Logging”选项中，选择日志的记录方式；最后的“Idle Connections”，如果选中的话，在指定时间内没有数据传输的话，连接就会自动断开。
“Serial Number”页面用来管理SOS的license。通过Add…按钮可以增加新的Serial Number。SOS中可以添加多个Serial Number。
“Databases”页面用来添加SOS管理的VSS数据库。点击Add…按钮可以添加数据库，添加对话框的上一个框填入VSS库的ini文件所在路径，下一个是数据库的别名，可以任意设置。SOS可以同时管理多个数据库。
1”
“User Keys”页面用来生成客户端访问控制的Key文件：
使用“Add Key…”按钮可以弹出“Add User Key”的对话框。该对话框的第一个输入框要求输入要增加的用户在VSS中对应的用户名；第二个输入框要求输入SOS服务器的IP地址，例如“202.100.68.88”，在局域网中可以设置为“192.168.1.1”；（注意，如果配置管理服务器同时具有局域网和广域网的IP地址，并且用户需要从局域网和广域网都可以访问SOS，则对同一个用户需要两个不同的Key文件。在我们的实际工作中，我们只使用SOS进行Internet上的访问，在局域网内还是使用VSS，因此没有这个问题）。下面的Expiration要求输入用户的过期有效时间期限，选择“Key Never Expired”允许用户永不过期。
输入完相应信息后，点击“OK”确认生成用户Key文件。生成的用户Key文件保存在SOS安装目录下，文件名为[用户名].iky，注意保留此文件，SOS客户端在启动时需要首先导入一个key文件。
“Web Project”页面用于设置Web Project的发布路径：
在第一个编辑框中填入该工程在VSS中的路径，例如“$/WebProject1/test”，在下面的编辑框中输入发布的路径，例如“d:\temp”。发布路径也可以是在其他机器上的网络路径。
“Debug”页面是两个调试级别的选项：
这两个选项的具体含义在SOS的Manual中也没有明确提到，我们在实际运用中也没有发现该选项的具体作用，建议不选取。
“Excluded File Types”页面设置不允许添加到VSS库中的文件类型：
添加的条目是文件后缀，具有在列表中的后缀的文件都不能被添加到VSS库中。
“Pin Support”页面用于设置是否允许PIN操作：
如果允许“PIN”操作，还需要指定ss.exe文件所在的目录。
设置完成后，需要重新启动SOS服务端，具体方法是在“服务”中启动相应服务：启动服务完成后，服务端的安装设置就已经完成了，接下来我们介绍SOS客户端的安装和使用。
SOS客户端的安装和使用
SOS的客户端分为Windows版本、Solaris版本和Linux版本。Windows版本的安装非常简单，直接执行安装程序就可以顺利安装。Solaris版本的SOS客户端以tar形式发布，首先在Solaris上安装GTK和GLIB，然后展开安装程序到任意目录即可。对Linux版本的SOS客户端，也需要首先安装GTK和GLIB，然后展开相应tar包到任意目录即可。
Solaris、Linux和Windows版本的SOS客户端运行界面都非常类似，下面以Windows版本为例说明其使用。第一次运行SOS客户端时，系统会弹出一个对话框要求输入服务器和端口号。这时用“Cancel”按钮取消，选择菜单项的“Tools”——“Import Encryption Key…”，导入服务端生成的Key文件：
导入完成后，选择菜单项的“File”——“Connect to Server…”，输入服务器IP地址和端口，如果连接成功，系统会给出可以连接的数据库列表，可以从列表中选择合适的数据库进行连接访问。
连接成功后，显示的主界面和VSS的基本一致，SOS的操作方式和VSS的也一样，具体可以参见VSS的文档。
下图是SOS的主界面：
当然，SOS在操作上也有一些和VSS不同的地方，下面列出这些不同点：
1、缺省设置下，SOS中每次登录不会主动刷新工程树和文件列表，需要用工具条上的刷新按钮进行刷新；
2、SOS的“Search”功能较VSS弱，只能查找Check Out的文件；
3、SOS的Option设置项目很多，大部分都是SOS增加的为适应远程连接的设置项：
【小结】本章介绍了VSS、SOS的使用，重点是SOS的安装和使用方法。SOS在使用上其实还有很多小技巧，在此不能一一列举，在sourcegear的网站上都能找到相关的资料。在下一章中，我们将结合配置管理工具介绍配置管理规范的内容。
配置管理规范
配置管理规范
对于一个一般的项目来说，配置管理规范的内容至少需要包括以下的内容：
1、配置项及其命名规则；
2、配置库文件目录结构；
3、角色和权限定义；
4、配置项变更流程；
5、配置项发布；
6、基线定义和基线变更。
配置项及其命名规则
对我们的项目来说，配置项需要包括以下的内容：
1、项目管理过程文档；
a) 项目任务书；
b) 项目计划；
c) 项目周报；
d) 个人日报和周报；
e) 项目会议纪要；
f) 培训记录和培训文档；
2、QA过程文档；
a) QA不符合报告；
b) QA周报；
c) 评审记录；
3、工作产品
a) 需求文档；
b) 设计文档；
c) 代码；
d) 测试文档；
e) 软件说明书和手册；
4、项目中使用的第三方产品
上文中用红色部分标识的是容易遗漏的配置项，尤其是第4个（项目中使用的第三方产品），实际上，一个工程型的项目会大量使用第三方的软件（例如，我们的产品中就使用了IBM的MQSeries、Oracle、一些第三方的开发控件），对这些产品的管理至少可以解决三个方面的问题：
1、版本配合的问题：大部分的第三方软件在升级之后，并不能实现二进制层面上的兼容，需要对原有的代码重新编译；甚至有的第三方软件在升级之后，API层面上的兼容性都做不到；因此，在工程实施的过程中，版本的配合问题是一个需要关注的问题；
2、发布的完整性问题：一般来说，比较大型的第三方软件在发布过程中都不会有遗漏，但对一些小的第三方软件来说，比如我们使用的许多perl的CPan模块，如果在开发过程中没有有意识的进行管理的话，很容易就会发生遗漏；
3、在某些特殊条件下由于第三方软件的变化引起的基线变更：这种情况极少会发生，但在我们以前的项目中，确实还遇见过。一般是因为原来选型时使用的第三方软件不能满足要求，只能通过更换新的第三方软件，这就补课避免地需要变更基线（例如需求文档、设计文档等）；将第三方软件纳入配置管理的范畴可以更方便地管理基线的变更。
关于第三方软件产品配置项的管理还有一点需要说明：由于第三方软件有可能会比较大，而且相对我们的项目来说，是很少会发生变更的（一般在一个项目过程中，不会采用不同的配置项的命名可以便于查找相关配置项。配置项的命名包括两个方面的内容：
1、配置项标识：在我们的项目中，一般使用“项目名_配置类别_配置项特殊标识”来命名。下表列出了
配置项命名中的“配置项特殊标识”根据配置类别的不同而不同。比如，对“设计文档”，如果细分的话，可以分为“概要设计”和“详细设计”；对“代码”，可以按照模块来命名配置项。
2、配置项版本命名：配置项版本命名是针对配置项的版本进行命名，在我们的项目中，配置项版本通过对Project的Label操作来实现，配置项版本的命名需要能清楚标识配置项的状态。一般说来，配置库至少包括个人工作区、受控库、发布区三个部分，在我们的项目中，所有的配置项都保存在一个VSS库中，对这三个部分的划分是通过逻辑划分方式进行的，具体来说，就是通过配置项版本命名来划分的。因此，我们配置项的版本命名规定如下：
a) 基线版本：按照基线的状态，我们这个项目中的基线有两个方面：一是作为里程碑的基线；另一个是模块的阶段性成果基线（对工作产品而言），由模块的负责人确定。
里程碑基线――对我们的项目来说，采用的是迭代的开发过程，以一个迭代过程为例，分为需求、概要设计、详细设计、代码实现、单元测试、集成测试、系统测试七个阶段，每个阶段都需要产生里程碑。对每个里程碑都有明确的标识标明当前状态。
阶段性成果基线――阶段性成果主要体现在代码过程中，比如代码进行到一个阶段，开发组长认为代码的这个状态可以保留，就可以确定为一个代码基线。这种基线一般不需要通过评审等正式手段来确定，但也必须有相应的验证手段；比如在我们的项目中，在代码阶段，确定代码基线的责任人是开发组长，但开发组长必须保证代码基线符合一定的条件。
b) 其他版本：除基线版本外，有时候还需要在开发和维护过程中确定其他版本。例如，产品在测试过程中不断的问题修复过程中，可能会有多种反复，此时需要将每次修改的内容作为一个版本。
关于版本，还有另一个需要注意的问题。一般来说，按照模块来划分，每个模块有自己的版本演进比较合理。首先，一个模块一般是由一个或两个开发人员完成的；其次，一个模块的功能会比较单一且独立，在版本的演化过程中便于控制，也不会和其他模块产生过于复杂的关系。而产品的版本则需要由各个模块的不同版本组成，这个纵横的关系需要很好地管理，我们的做法是在VSS库上用Label来标识，同时维护一张描述产品版本和模块版本关系的矩阵图便于追踪。
配置库目录结构
在确定了配置项之后，就可以确定配置库的目录结构了。配置库的目录结构直接关系到配置管理的工作量和使用的方便性，所以需要根据自己的需要确定一个合理的结构。
在确定配置管理库目录结构的时候，我们曾经考虑过两种产品目录结构的方式：一种是按照模块划分，在模块下再划分诸如设计文档、代码等目录；另一种方式是按照产品类型划分，例如首先是文档、代码，然后在其下按照模块划分。这两种方式都有自己的优点，最终我们还是选择了前一种划分方式，一方面是考虑便于进行权限的分配，另一方面是考虑到便于将同一模块的所有内容组织起来进行版本的管理。
从这里的配置库结构中可以看到，我们在最上层将配置项分为管理类和产品类：管理类中的项目管理部分基本是按照初始－计划－执行－收尾四个阶段来划分。在项目产品类别中，我们按照需求－设计－实现－测试四个阶段划分目录，在实现阶段，为每个模块划分了代码、详细设计、概要设计和单元测试四个目录，需要说明的是，在第三层中有一个HLD的目录，在模块下同样有一个HLD的目录，在我们的实际工作中，第三层的HLD目录用来存放系统级别的概要设计文档，而模块下的HLD目录用来存放模块级别的概要设计文档。当然，这里的配置库结构仅仅起到了示范作用，在实际使用中，可以根据自己的需要修改。例如，在Module 的级别上可以增加一个SubSystem的层，便于在产品集成时更加方便。
角色定义及权限分配
角色是配置管理流程的执行者和参与者，定义明确的角色有利于实现明确的授权和明晰的流程，虽然在实际中可能多个角色由一个人担任，但还是应该保留角色的定义。
下面是该项目中我们的角色定义：
配置管理员
整个配置管理库由配置管理员管理。配置管理员负责分配和修改其他成员的权限，要维护所有目录和配置项。
开发经理
开发经理在本项目中负责主导完成需求分析和系统总体设计，对项目的总体进度负责。开发经理拥有对管理类文档的读取权限，可以对项目类文档进行读写操作；
开发组长
开发组长对本小组的工作负有组织和管理任务，同时开发组长也需要承担一定的开发任务。开发组长对管理类文档有读取权限，对本组负责的模块有读取权限，对自己负责的模块有读写的权限；
开发工程师
开发工程师完成具体的开发任务，对自己负责的模块目录有读写权限，对管理类文档有读取权限；
测试组长
测试组长负责组织测试，给出测试计划和测试方案，并核定测试报告。测试组长对所有目录都有读取权限，对测试目录有读写权限；
测试工程师
测试工程师负责完成测试工作，包括测试用例开发和测试执行，测试报告编写。测试工程师对自己负责的模块有读取权限，对测试用例目录有读写权限。
QA工程师
QA工程师拥有对所有目录的读取权限，拥有对QA类文档目录的读写权限。
〔说明〕除配置管理员外，其他所有成员都没有Destroy目录和文件的权限，这是为了防止误删除操作带来不可挽回的损失。如果需要对目录进行Destroy操作，必须由配置管理员进行。
【小结】在本章中，我们介绍了配置管理规范的配置项及其命名、配置库的目录结构以及配置管理的角色权限分配。在下一章中，我们将介绍完配置管理规范的其他内容并给出配置管理实施过程中的一些心得体会。
配置项的变更与发布
配置项变更流程
我们所说的配置项变更流程主要是针对配置项发生变化的控制，在我们的项目中分为两个部分，首先是对配置项新建、检入（CheckIn）和检出（CheckOut）的规定；其次是对入库的文件类型和大小的规定：新建、检入、检出及破坏
1、新建：即Add，除特殊情况外，一般不规定由谁来新建（只要有权限即可），但尽量指定每个project 只有一人负责新建。
2、检入：即check in，检入频率规定如下：
i. 在代码编写前，至少每周一次
ii. 代码编写阶段，至少每天一次
iii. 测试阶段以后，根据代码、文档的变动，只要当天有变动就要检入一次。
iv. 为配合检查、备份工作，需在检查备份周期前全部check in (不保持check out)并退出登录。详见“检查及备份”部分
3、检出：即check out。原则上只对要修改的文档方可检出。
4、破坏（Destroy）：一般情况不可以破坏文件、目录。
5、如果是误操作，则可在一天内提交管理员处
6、如果超过一天，则需要由项目经理同意，且管理员破坏前要备份。
关于VSS库内存放文件类型及大小的规定
1、文件名及目录规定：以英文名字命名
2、文件大小规定：最大不超过20M
3、允许类型：
4、表2.1中提至的文档类
5、代码及脚本类及为配合编译需要的类库等
6、以下类型不允许存放在VSS库中：
7、备份数据
8、安装程序、打包程序（zip\rar）
9、超过20M以上的非代码类及开发文档类文件
10、对于特殊情况或不确定情况，需向配置管理人员咨询后再加入
11、对于不允许存放类型的配置类文件，可与配置管理员联络，随件附《说明清单》，以文件型式保存于服务器。
配置项发布
配置项发布是指配置项进行到一定的阶段（例如，里程碑阶段），需要对外发布时的规则。在我们的项
基线确立与变更
基线的确定在上一部分中已经说到过，我们的项目基线分为两类，一类是作为里程碑和其他工作依赖的基线（例如需求文档、设计文档等），另一类是开发过程中有必要保留的一种状态（例如代码过程中某个模块的一个有保留价值的snapshot）。对这两种不同的基线，其影响的范围不同，确立和变更方式也不一样。
我们项目的基线变更控制委员会由客户代表、产品经理、项目经理以及技术经理组成，对发布的里程碑类基线的变更必须由变更控制委员会确认并由QA进行变更记录，所有被变更影响的配置项都需要重新同步后再次发布；而对于仅仅作为工作状态保留的基线，一般只需要建立基线的小组确认更改并在QA进行记录即可。
检查与备份
1、检查：
根据VSS白皮书建议，要定期检查数据的正确性。故VSS库管理员应每周检查一次，流程如下：
a) 开发人员于每周五下午5:30前check in（(不保持check out)）并退出登录
b) VSS库管理人员用analyze工具检查VSS数据库，操作如下：
在dos命令行中输入：analyze –f –d –c –v4 c:\vss\data
其中“c:\vss\data”为vss库的数据目录
2、备份：
a) 每天增量备份，通过windowsNT以上自带的备份工具进行增量备份，备份以硬盘存放即可。
b) 每周全备份：每周检查完毕之后，对VSS数据库进行全备份，建议以光盘介质备份。
配置管理实施后记
应该说，这次我们对项目的配置管理实施是非常成功的，在整个开发过程中，基本没有出现因为配置管理的问题导致的对开发进度的延误。当然，在开发过程中也发生了由于需求变化导致基线变更引起开发进度的延迟，不过这不应该算作是配置管理的失误，因为作为配置管理来说，只能尽量保证基线变更不会导致项目失控。
总结我们这次的配置管理实施工作，除了这几篇文章中讲到的需要注意的问题外，我觉得有一些应该算做是决定实施成败的关键因素：
1、一个好的执行人员是成功的关键；
一个好的执行人员的重要性怎么强调都不过分。所谓的一个好的执行人员应该具备这样的素质：
a) 对配置管理工作有较为深刻的理解；
b) 对使用的配置管理工具运用熟练；
c) 具有好的沟通能力，能和开发组长、开发人员以及其他干系人沟通；
d) 有好的执行力，对流程的执行能起到监督和推动作用；
e) 耐心细致，很多时候，细节决定了成败；
2、好的工具能起到事半功倍的效果；
选择一个合适的配置管理工具绝对是必要的，我们在前面用了一章多的篇幅介绍我们使用的配置管理工具及其方案，事实证明，我们选择的配置管理工具对我们项目管理实施的效果是决定性的。
3、在配置管理实施的初期，及时的指导起的作用是巨大的，甚至可以说是成功的主要因素；
对不熟悉配置管理的开发工程师来说，配置管理工作容易在一开始就让他们产生厌烦情绪，一点点使用上的不方便就会导致开发人员对配置管理的怨言，这个时候，及时的指导就显得非常重要了，我们在配置管理实施过程中，准备了《VSS操作手册》、《SOS简明操作手册》、《配置管理操作指导书》等手册，进行了三次的培训，并在实施过程中随时解决开发人员在使用配置管理工具中的问题。而且，在实施初期，我们以奖励为主，在一个月的时间内没有将配置管理工作作为考核内容。
4、每周的配置状态检查非常重要；
在配置管理基本走上正规后，每周的配置状态检查是我们对配置管理执行效果的检查，一旦发现问题，会作为QA问题报告发出并要求限期改正。如果没有这个检查制度，配置管理工作很难持续受控。
〔后记〕
《工程型软件项目配置管理实例》这几篇文章是我们在项目的配置管理实施过程中的一些体会，和其他配置管理文章不同的是，这里我们给出的都是马上就可以应用的实践步骤。当然，每个公司的环境各有不同，同样的实践不可能在每个地方都能产生一样的效果，只是希望这一系列文章能给大家一些启发。
时间仓促，文章中有些地方可能还有未能表达清楚的地方，欢迎大家和我探讨。
软件配置管理计划 案卷号 日期 ,项目名称, 软件配置管理计划 作者: 完成日期: 签收人: 签收日期: 修改情况记录: 版本号修改批准人修改人安装日期签收人 目录 1 引 言 ..................................................................... ........ 1 1.1 目的..................................................................... 1 1. 2 定义和缩写 词 ............................................................. 1 1.3 参考资 料 ................................................................. 1 2 管 理 ..................................................................... ........ 1 2.1 机
构..................................................................... 1 2. 2 任务..................................................................... 2 2. 3 职责..................................................................... 2 2.4 接口控 制 (2) 2.5 实现..................................................................... 2 2.6 适用的标准、条例和约 定 (3) 2.6.1 指明 (3) 2.6.2 内容................................................................. 3 3 软件配置管理活 动 (4) 3.1 配置标 识 (4) 3.1.1 基线 (4) 3.1.2 代码、文 档 ........................................................... 4 3.2 配置控制 .................................................................
中国核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国核电集团所有，未经许可，不得以任何方式外传。
修改记录页
目录 (一)基本信息 (4) (二)角色与职责 (4) (三)配置管理资源 (5) (四)权限分配 (5) (五)配置项计划 (6) (六)配置库基线 (7) (七)配置库备份计划 (8) (八)配置库状态报告 (8) (九)配置审核 (9) (十)审批意见 (9)
配置管理计划(一)基本信息 项目名称： 项目代号： 立项时间： 预计主要项目阶段有： 配置项目命名规则依据： (二)角色与职责
(三)配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理，并提供更新、检索和历史版本的恢复。 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。 （2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑存、外存、CPU等）。 预计建库申请日期： 预计建库日期： 预计工作库需空间： (四)权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。
(五)配置项计划 填写上面表格过程中，需要对照成果物列表逐项填写。
中国广东核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国广东核电集团有限公司所有，未经许可，不得以任何方式外传。
修改记录页
目录 (一)基本信息错误!未定义书签。 (二)角色与职责错误!未定义书签。 (三)配置管理资源错误!未定义书签。 (四)权限分配错误!未定义书签。 (五)配置项计划错误!未定义书签。 (六)配置库基线错误!未定义书签。 (七)配置库备份计划错误!未定义书签。 (八)配置库状态报告错误!未定义书签。 (九)配置审核错误!未定义书签。 (十)审批意见错误!未定义书签。
配置管理计划 基本信息 项目名称： 项目代号： 立项时间： 预计主要项目阶段有： 配置项目命名规则依据： 角色与职责 配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理，并提供更新、检索和历史版本的恢复。 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。
（2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑内存、外存、CPU等）。 预计建库申请日期： 预计建库日期： 预计工作库需空间： 权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域帐号的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。
软件配置管理计划示例 作者：赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理
2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2．3 职责 在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B．软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C．项目的专职配置管理人员检查在作配置更改时的质量保证措施； D．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；
从项目管理角度看软件配置管理 项目的目地是为了创造一项产品或服务，因此，产品本身的生产工艺必然会成为项目管理过程的核心内容。无论在哪一种软件工程方法中，软件配置管理都是一项不可或缺的重要管理内容，特别是对于服务企业内部的信息技术部门来说，从产品生命周期出发，同时支持服务产品和软件产品，同时负责开发与运行，其管理复杂度很高，要想理顺各项工作的内部关系、理清各项工作之间的配合关系，都离不开配置管理这个基本手段，它是许多管理工作的“落地”部分。其实，配置管理并不是一个时髦的概念，在许多传统行业（例如制造业）中早已有之，软件行业只是在软件工程方法中继续延用了这一概念，它是一流软件开发企业所必备的基础设施。 在项目管理中，配置管理是一种重要的管理手段。在PMI的PMBOK中对于配置管理系统是这样描述的： 由此可见，配置管理是一个非常宽泛的概念，项目中只要是需要进行管理的任何特性，都可以纳入配置管理。配置管理不只是操作层面的问题，更是管理理念、管理方法的问题，是一个系统。 项目范围管理需要配置管理来落实 在项目范围管理中，需要识别和控制项目的交付成果，要描述交付物应有的各种特性。这些交付物及其特性，就是配置管理中的配置项。从项目管理的角度，WBS只需要分解到可管理（Manageable）的程度，而配置管理则要求分解到终可操作的程度，管理的粒度更为精细。因此，良好的配置管理机制，是项目范围管理得到终落实的保证。 在许多软件开发项目中，项目范围管理涉及三个方面：业务需求、技术结构、投产服务。编写哪些程序模块，实现哪些功能，部署到哪些地点，这其实
都是项目范围管理所要关注的内容，在配置管理中对应了产品的物理属性和功能属性以及服务的属性，都可以通过配置管理来识别、记录和跟踪。只有做好软件配置管理，才能真正把项目的范围管理做实。 业务需求决定了软件产品的功能特性，对软件产品的配置管理，首先就是对业务需求的管理。在业务需求中，要求软件产品所提供的各种功能和特性，包括界面风格、操作方式、处理流程、业务规则、数据逻辑等，也都是软件产品的配置项，这种对业务需求的分解、管理的过程，就是对业务需求中的配置项的管理过程。当项目中业务需求发生变更时，其实就是对这些配置项的变更管理。因此，在软件工程过程中，配置管理是需求管理的基本手段，通过科学、严谨的配置管理方法，对业务需求进行识别、分解、跟踪、控制，直接决定了对业务需求的管理能力。许多公司目前在需求管理方面还处于粗放型的管理，虽然基本能够满足项目管理的需要，但对于软件工程过程来说，管理粒度还比较粗，而且缺乏明确的配置项的定义，缺少有效的跟踪控制手段，还需要更精细的管理。 技术结构是软件产品的物理属性，软件产品的配置管理，也是对软件内部技术结构的管理。从技术方案到软件产品、再到产品内部结构，这也是项目范围不断分解、细化的过程。为了实现业务需求、满足产品外部特征的要求，软件产品应如何设计其内部结构，划分内部模块、定义模块接口、确定有多少个程序等等，产品分解到后，每一个程序都作为一个单独的配置项进行管理，在开发过程中对于程序的修改都纳入配置管理，跟踪程序变化过程。这种对软件产品从技术角度的不断分解和定义，就是基于技术结构的配置项管理，是与软件结构设计相对应的，配置项的划分是否合理，使用起来是否灵活、方便，哪些可以成为公共组件（Component），其实反映的都是软件设计的思想。在有的软件企业中，配置管理不只是程序员的操作工具，它已经成为工程技术管理的
卷号DEPLOY 卷内编号DEPLOY005 密级组内 HD20090917SR005 通用型行政审批服务协同管理平台 配置管理计划 1.2 项目承担部门：java第四组 撰写人（签名）：区允文 完成日期：2010年8月4日 本文档使用部门：■主管领导■项目组 □客户（市场）□维护人员□用户 评审负责人（签名）：江威龙 评审日期：2010/8/4
目录 1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4 1.4参考资料4 1.5概述4 2.项目配置4 2.1组织结构4 2.2职责和接口5 2.3工具、环境和基础设施5 3.配置管理活动6
3.1配置库6 3.1.1配置库架构6 3.1.2权限分配7 3.1.3配置库层次及开发活动说明：8 3.2配置标识9 3.2.1标识方法9 3.2.2项目基线10 3.3配置项11 3.4配置和变更控制11 3.4.1变更请求的处理和审批11 3.4.2变更控制委员会 (CCB)11 3.4.3变更过程中的活动11 3.4.4变更过程中的变更请求状态12 3.4.5保存变更历史记录13 3.4.6变更请求中受影响配置项的变更13 3.5配置状态统计14 3.5.1项目介质存储和发布进程14 3.5.2报告和审计14 4.里程碑15 5.培训和资源15 6.分包商和厂商软件控制15 7.附录15
配置管理计划 1.简介 1.1目的 为了使项目相关的各种资源便于查看，修改，不至于凌乱；为了让各个开发人员方便高效地协同合作；为了项目的版本便于管理，作出此配置管理计划。 1.2范围 项目进行中所得出的所有工件都要遵守此计划，包括文档以及源代码，以及硬件。 1.3定义、首字母缩写词和缩略语 CM：配置管理。 CCB：变更控制委员会。 CI：配置项。包含文档、程序。 Baseline：基线。 CR：变更请求。 PCA：物理审计。 FCA：功能审计。 1.4参考资料 《华南农业大学软件学院实训讲义》 《华南农业大学项目阶段评审工件》 1.5概述 此文档对项目开发过程中的配置方面作出约束，开发以及变更都要按照要求来做。 2.项目配置 2.1组织结构
软件项目配置管理计划案例 本案例选自《软件项目管理案例教程》（韩万江，机械工业出版社）一书，项目案例为《校务通管理系统》，该项目的配置管理计划如下： 1. 引言 包括目的、缩写词和参考资料，具体内容略。 2．组织及职责 配置管理的角色和职责见表1。 表1：配置管理角色职责表 3.配置管理环境 由于本项目属于中小型项目，工期也不很长，而且项目组人员对Visual SourceSafe也比较熟悉，所以采用Visual SourceSafe作为配置管理工具。 3.1配置库目录结构
3.2用户及权限 4．配置管理活动 4.1 配置项标志 4.1.1 命名规范 本项目配置项命名规范由5个字段组成，从左到右依次为：公司、项目、类型、编号和版本号，如图1所示。这些字段用一横线（-）分隔。
图1：配置项命名规范 4.1.2 主要配置项 QTD-School –RM –SRS-v1.0 公司：3个字符 项目：最长10个字符 类型：最长5个字符 编号：最长8位数字/字符 版本号：V m.n
4.1.3 项目基线 在Visual SourceSafe中基线由LABLE标志，字母必须为大写。基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。 表5 4.1.4 配置项的版本管理 配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支：主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。 这四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。 对配置项的版本管理在不同分支具有不同的策略： （1）主干分支 系统默认自动建立的物理分支——主干分支（/main）,基线均以LABLE方式出现在主干分支上。 （2）私有分支 如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不与管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。 （3）小组分支 如果出现小组共同开发一配置项，该分支可视为项目组内部分组的私有空间，存放代码开发过程中的版本分支，由项目组内部控制。
第6章软件项目配置管理（习题） 一、选择题 1.在项目进行过程中，2个项目成员使用不同版本的设计说明书，这时项目经理 首先应该检查（B ） A.信息管理系统 B.配置管理系统 C.CPI D.SPI 2.变更控制主要关注的是（B ） A.阻止变更 B.标识变更，提出变更，管理变更 C.管理SCCB D.客户的想法 3.为了更好的管理变更，需要定义项目基线，关于基线的描述，正确的是（B ） A.不可以变化的 B.可以变化，但是必须通过基线变更控制流程处理 C.所有的项目必须定义基线 D.基线发生变更时，必须修改需求 4.项目的基线发生变更应该经过（D）授权执行的 A.项目管理者 B.质量保证人员 C.配置管理人员 D.SCCB 5.变更控制系统必须包括下列所有的内容，除了（B） A.文档说明 B.成功的谈判 C.跟踪系统 D.授权核准审批机构 二、判断题 1.软件配置管理的目的是建立和维护整个生存期中软件项目产品的完整性和可追 朔性。（√） 2.软件配置项是变更控制系统中的决策系统。（×） 3.统计被批准的配置项是一种配置审计。（√） 4.在进行配置管理过程中，一定要采用高档的配置管理工具。（×） 5.基线产品是不能修改的。（×） 三、简答题 1.什么是软件配置管理？它有什么作用？ 2.软件配置项包括哪些内容，这些内容应该包括哪些相关信息？ 3.什么是基线？它在配置管理中有什么作用？为什么要建立基线？ 4.说出软件项目各阶段的基线，这些基线的建立产生过程以及它们在软件开发中的 作用。
5.基线管理的两个基本功能是什么？ 6.简述软件配置管理的组织以及相关人员的职责。 7.简述软件配置管理的功能。 8.举出常见的配置管理的工具软件，并比较其优劣。 9.配置状态报告的内容是什么？随着项目的进行配置状态报告的内容有哪些变 化？ 10.配置审核的概念和种类是什么？ 11.配置管理计划包括哪些内容？ 12.基于构件的软件配置管理与其他的配置管理形式有哪些异同点？ 13.仅当每个与会者都在事先作了准备时，正式的技术复审才能取得预期的效果。如 果你是复审小组的组长，你怎样发现事先没做准备的与会者？你打算采取什么措施来促使大家事先做准备？ 14.若你是一个小项目的主管，你将为此工程设置哪些基线，又如何控制它们？
您现在的位置：需求工程多媒体教学系统>> 教学资料>> 正文 软件项目配置管理范例. 一. 概述 1.1 目的和范围 本文档描述NewSkyCRM软件开发项目的软件配置管理计划，该计划向NewSkyCRM软件开发项目组以及相关受SCM活动影响的组和个人提供相应的说明和活动指南，使某某软件开发中心SCM方针能够在NewSkyCRM软件开发项目的SCM活动中得到贯彻。 本计划适用于NewSkyCRM软件开发项目的整个生命周期。 1.2 软件配置管理计划维护 本计划由NewSkyCRM项目经理和软件配置管理经理共同制订。如果计划中的SCM活动在实施中出现偏离，由软件配置管理经理按照《变更控制规程》及时维护。 1.3 参考资料 《电信NewSkyCRM产品软件开发计划书》，Version 1.3.0， NS.TEL-NewSkyCRM-CRM-RM-03； 《电信NewSkyCRM产品系统功能说明书》，Version 1.1.1， NS.TEL-NewSkyCRM-CRM-RM-02； 某某软件开发中心《软件配置管理过程》，Version 1.1，NS-PROC-SCM-001； 某某软件开发中心《软件配置管理计划规程》，Version 1.0， NS-PROC-SCM-002。 二. 角色与职责 2.1 软件配置管理代表
软件配置管理代表的职责是遵循某某软件开发中心《软件配置管理过程》及有关规程等文档进行软件配置管理活动。 表1软件配置人员表 2.2 配置控制委员会 NewSkyCRM软件开发项目配置控制委员会的职责是管理本项目内软件基线 的变更等操作和配置项/单元标识的审定。主席主持配置控制委员会的活动。 表2配置控制委员会 2.3 项目经理 NewSkyCRM软件项目经理必须履行某某软件开发中心《软件配置管理过程》及有关规程等文档中指定的有关项目经理的职责。 2.4 项目开发组 NewSkyCRM软件项目开发组必须履行某某软件开发中心《软件配置管理过程》及有关规程等文档中指定的有关项目开发组的职责。 表3项目组成员表
软件配置管理计划(SCMP) 说明 《软件配置管理计划》(SCMP)说明在项目中如何实现配置管理。 软件配置管理计划的正本格式如下： 1引言 本章应分成以下几条。 1.1标识 本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。 1.2系统概述 本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。 1.3文档概述 本条应概括本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。 1.4组织和职责 描述软件配置管理(SCM)负责人和软件配置控制委员会(SCCB)的组成以及他们在项目中的职责和权限；说明与项目配置管理相关的人员，如项目经理、部门SCM组长的职责；描述以上人员之间的关系。 为了能够清晰的表述，可选用图表的方式进行说明。 1.5资源 描述项目配置管理活动所需的各种资源，包括人员、培训、工具、设备、设施等等。其中人员是指人力成本，它是根据项目开发计划中的总工时计算得出的。 2引用文件 本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章还应标识不能通过正常的供货渠道获得的所有文档的来源。 3管理 描述负责软件配置管理的机构、任务、职责及其有关的接口控制。 3.1机构 描述在各阶段中负责软件配置管理的机构。描述的内容如下： a.描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构； b.说明项目和子项目与其他有关项目之间的关系； c.指出在软件生存周期各阶段中的软件开发或维护机构与配置控制委员会的相互关系。 3.2任务 描述在软件生存周期各阶段中的配置管理任务以及要进行的评审和检查工作，并指出各个阶段的阶段产品应存放在哪一类软件库中(软件开发库、软件受控库或软件产品库)。 3.3职责 描述与软件配置管理有关的各类机构或成员的职责，并指出这些机构或成员相互之间的关系： a.指出负责各项软件配置管理任务(如配置标识、配置控制、配置状态记录以及配置的评审与检查)的机构的职责； b.指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系； c.说明由本计划第3.2条指明的生存周期各阶段的评审、检查和审批过程中的用户职
XXX项目配置管理计划 xxxxxxxxxxxxxxx公司20xx 年xx月xx 日
文档编号：XXXXXXXX-XXX-XXX 版本号：1.00 项目名称:XXXX项目 文档名称: 版本修改内容描述修改人日期备注1.0 第一版xxx 2014.6.3 1.01修正了……xxx 2014.6.3 批准人：日期：审核人：日期： 公司名称：xxxxxxxxxxxxxxxxxx有限公司 地址：xxxxxxxxxxxxxxxxxxxxxxxxx 电话：010-xxxxxxxx 网址：https://www.doczj.com/doc/7517327902.html, 邮箱：mengsuran@https://www.doczj.com/doc/7517327902.html,
目录 1. 引言 (1) 1.1 目的 (1) 1.2 术语定义 (1) 1.2.1软件配置管理 (1) 1.2.2 配置管理 (1) 1.2.3 配置项 (1) 1.2.4 基线 (1) 1.2.5 变更控制 (2) 1.2.6 配置审计 (2) 1.3 参考资料 (2) 2. 软件配置 (3) 2.1 软件配置环境 (3) 2.1.1服务器软件环境 (3) 2.1.2 硬件环境 (3) 2.1.3 配置管理客户端 (3) 2.2 软件配置项 (3) 2.2.1 受控配置项 (3) 2.2.2 非受控配置项 (4) 2.3 配置管理员 (4) 2.3.1 设立的必要性 (4) 2.3.2 主要职责 (4) 3. 软件配置管理计划 (4) 3.1 建立示例配置库 (4) 3.2 配置标识管理 (6) 3.2.1文档 (6) 3.2.2 程序 (6) 3.2.3 基线 (6) 3.3 配置库控制 (6) 3.3.1 .权限控制 (6) 3.3.2 配置库控制 (6) 3.3.3 建立软件库 (6) 3.3.4软件配置更改 (7) 3.3.5配置文件清单的维护 (7) 3.4 配置的检查和评审 (7) 3.5 配置库的备份 (8) 3.6 配置管理计划的修订 (9) 3.7 配置管理计划附属文档 (9) 4. 里程碑 (10)
软件配置管理计划示例 计划名国势通多媒体网络传输加速系统软件配置管理计划 项目名国势通多媒体网络传输加速系统软件 项目委托单位代表签名年月日 项目承办单位北京麦秸创想科技有限责任公司 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的国势通多媒体网络传输加速系统软件规定各种必要的配置管理条款，以保证所交付的国势通多媒体网络传输加速系统软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料
◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆国势通多媒体网络传输加速系统软件质量保证计划 2 管理 2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务
. 软件项目管理计划 Version 1.2专业资料word . Revision 专业资料word . 录目 1. 简介1 项目概述1.1 1.2 项目交付产品1 SPMP 的演化1.3 1 参考资料1.4 1 1.5
术语与缩写1 1 2. 项目组织 1 2.1 过程模型2. 2 组织结构1 2. 3 组织接口1 2.4 项目职责2 2 管理过程3. 3 3.1 管理目标和优先级3.2 假设、依赖关系和限制3 风险管理3.3 3 监督和控制机制3.4 3 3.5 人员计划3 3 4. 技术过程 4 方法、工具和技术4.1 软件文档4.2 4 用户文档4.3 4 4.4 项目支持功能4 4 工作包、进度表和预算5. 4 工作包5.1 依赖关系5.2 4 资源需求5.3 4 预算和资源分配5.4 4 5.5 进度表4 6. 其他索引 6.1 4 6.2 附录 4 专业资料word . 1. 简介 1.1 项目概述 说明：简要综述项目的目标、发布的产品、主要工作活动、主要工作制品、关键里程碑、所需资源、进［度和预算等。必要的情况下，还应描述该项目与其他项目的关系。］ 1.2 项目交付产品
说明：列出主要的可交付产品、交付日期、交付地点和满足项目协议条款所需的质量。］［的演化SPMP1.3 说明：描述如何以及由谁负责维护本文档，应指明更新内容的传播方式以及在变更控制下更新文档版本[ 的机制。］ 1.4 参考资料 说明：提供项目计划中所引用的所有文档和其他信息资源的完整清单，包括标题、报告编号、日期、作[ 者以及发布机构。］ 1.5 术语与缩写 说明：定义SPMP 所应用的全部术语和缩写词。］［ 2. 项目组织 2.1 过程模型 说明：描述该项目所使用的软件过程模型，或者是所遵循的组织标准模型。过程模型需要指明［里程碑的时间、基线、评审、工作制品、项目交付产品、结束标志等。］ 2.2 组织结构 说明：描述项目的内部组织结构，可以参考如下的层次结构图形式。］［专业资料word .
机电管理系统性能测试系统 配置管理计划
这里填写公司名称 文档编号：XXXXXXXX-XXX-XXX 版本号：1.00 产品名称:机电管理系统性能测试系统 文档名称:配置管理计划 这里填写公司地址、联系方式等
目录 1. 引言 (1) 1.1 目的 (1) 1.2 术语定义 (1) 1.3 参考资料 (1) 2. 软件配置 (2) 2.1 软件配置环境 (2) 2.2 软件配置项 (2) 2.3 配置管理员 (3) 3. 软件配置管理计划 (4) 3.1 建立示例配置库 (4) 3.2 配置标识管理 (6) 3.3 配置库控制 (7) 3.4 配置的检查和评审 (8) 3.5 配置库的备份 (9) 3.6 配置管理计划的修订 (9) 3.7 配置管理计划附属文档 (9) 4. 里程碑 (11) 附录1 文档命名规定 (12) 1、受控配置库文件命名规则 (12) 2、非受控配置库文件命名规则 (12) 3、提交文档文件命名规则 (12) 附录2文档编码规范 (13) 附录3 帐号及权限管理 (14) 附录4 配置库使用规定 (16) 文档修改记录 (17)
1. 引言 1.1 目的 本文档目的在于机电管理系统性能测试系统进行软件配置管理，提高软件质量，降低软件开发成本。 本文档内容主要参考研发中心相关的ISO程序和制度文档，并在这基础上整理成适合本项目的软件配置管理，为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。 1.2 术语定义 软件配置管理：简称SCM（Software Configuration Management的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。 基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。 配置管理员：项目组中负责配置管理工作的角色，该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。 配置标识：（Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识别。 配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。 1.3 参考资料 《研发中心配置管理制度》 《产品的标识与可追溯性程序》 《开发手册》
配置管理计划配置管理计划的案例 配置管理计划来自：://.chinaspis. 作者：林锐电子工业出版社出版发行 { 项目名称 } 配置管理计划文状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改文标识： pany-Project-CM-PLAN 当前版本： X.Y 作者： 完成日期： Year-Month-Day 版本历史版本/状态作者参与者起止日期备注 目录 1.人员及职责 2.配置管理软硬资源 3.配置项计划 4.基线计划 5.配置库备份计划 附录：本计划审批意见 1.人员及职责 提示： （1）根据《项目计划》中的角色分配，确定配置管理员，CCB（配置控制委员会）成员。
（2）CCB的人数根据项目规模而定。一般地，项目经理是CCB的负责人。 角色人员职责、工作范围 配置管理员 （1）制定《配置管理计划》 （2）创建和维护配置库 CCB负责人 （1）审批《配置管理计划》 （2）审批重大的变更 CCB成员例如：审批某些配置项或基线的变更… 2.用于配置管理的软硬资源 提示： （1）配置管理员确定本项目的配置管理软。例如采用Microsoft公司的Visual SourceSafe或者Rationa公司的l ClearCase。 （2）配置管理员根据所采用的配置管理软，确定计算机资源（考虑内存、外存、CPU等）。 配置管理软硬资源说明配置管理软名称公司，软版本等计算机名称内存、外存、CPU等3.配置项计划 提示：配置管理员标识配置项，估计每个配置项的正式发布时间。标识符的参考格式为Project-Type…Type-Number。例如：类型主要配置项标识符预计正式发表时间计划 《项目计划》
<项目名称> 配置管理计划 版本 <1.0> [注：以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应 该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=正文）。]
修订版历史
目录 1.简介 1.1目的 1.2范围 1.3定义、首字母缩写词和缩略语 1.4参考资料 1.5概述 2.软件配置管理 2.1组织、职责和接口 2.2工具、环境和基础设施 3.配置管理活动 3.1配置标识 3.1.1标识方法 3.1.2项目基线 3.2配置和变更控制 3.2.1变更请求的处理和审批 3.2.2变更控制委员会 (CCB) 3.3配置状态统计 3.3.1项目介质存储和发布进程 3.3.2报告和审核 4.里程碑 5.培训和资源 6.分包商和厂商软件控制
配置管理计划 1.简介 [配置管理计划的简介应提供整个文档的概述。它应包括此配置管理计划的目的、范 围、定义、首字母缩写词、缩略语、参考资料和概述。] 1.1目的 [阐明此配置管理计划的目的。] 1.2范围 [简要说明此配置管理计划的范围：它的相关模型，以及受到此文档影响的任何其他事物。] 1.3定义、首字母缩写词和缩略语 [本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。这些信息可以通过引用项目词汇表来提供。] 1.4参考资料 [本小节应完整地列出此配置管理计划中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和发布组织。列出可从中获取这些引用的来源。这 些信息可以通过引用附录或其他文档来提供。] 1.5概述 [本小节应说明此配置管理计划中其他部分所包含的内容，并解释文档的组织方式。] 2.软件配置管理 2.1组织、职责和接口 [说明谁将负责执行 CM 工作流程中所述的各种配置管理 (CM) 活动。] 2.2工具、环境和基础设施 [说明在整个项目过程或产品生命周期中为实现 CM 功能而使用的计算环境和软件工 具。 说明对整个项目过程或产品生命周期中生成的配置项进行版本控制时所需的工具和过 程。 建立 CM 环境时所涉及的问题有： ?产品数据量的预期大小 ?产品团队的分配 ?服务器和客户机的实际位置] 3.配置管理活动 3.1配置标识 3.1.1标识方法 [说明项目工件或产品工件的命名、标记和编号方法。标识方案中需包括硬件、系统软件、市售 (COTS) 产品以及产品目录结构中所列的所有应用程序开发工件，例如计划、模型、构件、测试软件、结果与数据、可执行文件等。] 3.1.2项目基线 [基线提供一项正式标准，随后的工作都基于此标准，并且只有经过授权后才能对此标准进行变更。
项目配置管理计划模板 【项目名称】 项目配置管理计划模板 日期： 版本号：
文件变更记录 *A–增加M–修订D–删除 变更 日期变更类型 修改人摘要备注 版本号（A*M*D）
目录 项目配置管理计划 (1) 文件变更记录 (2) 目录 (3) 1. 概述 (4) 编写目的 (4) 参考资料 (4) 2. 配置管理约定 (4) 3. 配置项/单元列表 (6) 4. 软件配置列表 (8) 5. 配置管理活动策划列表 (8)
1.概述 1.1 编写目的 指导项目的配置管理活动。 1.2 参考资料 《项目主计划》 《项目自定义过程说明》 2.配置管理约定 1)项目组所有成员的工作产品都要放入配置库，本项目配置库的目录如下：
项目配置管理计划模板 图 2.1项目配置库目录 2)使用的配置管理工具： 服务器端：SVN1.8 客户端：TortoiseSVN-1.8.4.24972-win32-svn-1.8.5 3)权限分配 表 2.1项目配置库权限分配表 目录PM RAE SE PG TE QA CE \01-项目管理库\01-售前rw rw r r r r rw \01-项目管理库\02-项目 rw r r r r r rw 策划 Page 5/9
项目配置管理计划模板 \01-项目管理库\03-项目 rw r r r r rw rw 监控 \01-项目管理库\04-项目 rw r r r r r rw 结项 \01-项目管理库\05-风险 rw r r r r rw rw 库 \02-开发工程库\01-需求r rw r r r r rw \02-开发工程库\02-设计r r rw r r R rw \02-开发工程库\03-编码r r r rw r r rw \02-开发工程库\04-测试r r r r rw r rw \02-开发工程库\05-发布rw r r r r r rw \02-开发工程库\06-验收rw r r r r rw rw \02-开发工程库\07-维护r r r rw rw r rw \02-开发工程库\08-个人 rw rw rw rw rw rw rw 使用 \03-支持\01-配置管理r r r r r r rw \03-支持\02-质量保证管 r r r r r rw rw 理 \03-支持\03-培训记录rw r r r r r rw \03-支持\04-决策分析rw r r r r r rw \04-基线库r r r r r r rw \05-参考资料rw rw rw rw rw rw rw \06-其他rw rw rw rw rw rw rw 3.配置项/单元列表 表3.1配置项/单元列表 过程阶段编配置项/单元计划提交计划基线 负责人备注（基线名称）号名称时间时间 启动 1 项目立项报告
软件配置管理计划 SANY GROUP system office room 【SANYUA16H-
软件配置管理计划示例 计划名国势通多媒体网络传输加速系统软件配置管理计划 项目名国势通多媒体网络传输加速系统软件 项目委托单位代表签名年月日 项目承办单位北京麦秸创想科技有限责任公司 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的国势通多媒体网络传输加速系统软件规定各种必要的配置管理条款，以保证所交付的国势通多媒体网络传输加速系统软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义
本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆国势通多媒体网络传输加速系统软件质量保证计划 2 管理 2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务
软件项目管理习题题目 第一章绪论 1．列举你在执行IT相关任务时曾碰到的问题。试把这些问题按频率和影响大小分别排序。对每一个问题，考虑是否可以通过某种方法降低发生的可能性。 2．软件工程的三个目标是什么，以什么衡量是否达到目标？ 3．软件工程活动包括哪些？那些活动需要有最终用户的参与？每个过程需要有怎样的文档产出？ 4．设计包括哪两个阶段，具体任务，干系人有什么区别？ 5．软件工程的原则有哪些？ 6．你能说出哪些软件工程模型，他们各自有什么有缺点,适用于怎样的系统？ 7．有人说“线性模型已经过时了，有着诸多缺点，不需要再了解它。”你怎么看待这种说法？线性模型和其他模型的关系是怎样的？ 8．在下列哪一个阶段项目发起人对项目的范围、质量、时间和成本有最大的影响力，为什么？ 9．项目的定义是什么，有什么特点，请给出三个是项目的例子，并给出三个不是项目的例子。 10．软件项目与一般的项目的区别在什么地方 11．判断以下活动中哪些是项目，哪些不是项目，并请说明理由。（1）升级某政府部门的办公自动化系统（2）打字员打印文件（3）报考软件学院软件工程硕士研究生（4）购买家用轿车（5）每天骑车上班 12．项目生命周期包括哪些阶段？哪个阶段具有最大的不确定性？各个阶段的活动主要有哪些？ 13．项目管理的六要素有哪些？相互之间是什么关系。TQC又指什么？ 14．怎样衡量项目是否成功？ 15．项目管理分哪几大知识体系，它们之间什么关系？ 16．在选择职员时，应该考虑哪些因素？ 17．管理者是否应该和小组中更多的普通员工交朋友，并和他们打成一片？ 18．如果项目快结束时，忽然有一个很重要的，但非常耗时的变更，你作为项目经历应该怎么做 19．为什么说时间和人员不能交换？试说明其原因。 20．你能列出那些人际关系的矛盾？试阐述可能的解决方法。 第二章需求管理 1．软件需求的定义是什么，分别从用户角度，开发者角度，相关文档角度给以阐述 2．描述软件需求要做的五项主要事情指什么。 3．软件需求过程与那些过程相关，是怎样的关系？