配置管理可能是我所有工作中最缺失的一项了，作为甲方公司的IT，不知道识别配置项，不知道应该具体到哪些细节，也缺乏变更实施后的跟踪，有时候真觉得做项目真够糊里糊涂的了。今天交流的主题希望能够解决这些问题，起码让我在以后的项目管理中能找到方向。总结如下：

在CMMI和IEEE关于配置管理的正式定义是：软件配置管理是软件工程中的一项规程，包括相关工具和应用技术（过程或方法），公司用它来管理软件资产变更。配置管理，主要目的是进行工作产品管理，其中包括各类文档、代码、版本、纪要、bug等等。

这八点做好了，就是一个合格的配置管理过程

 1、组织的知识和过程财富流失

2、不能及时了解项目的进展状况

3、缺乏实现并行开发的手段

4、软件复用率低下

5、无法开展规范化的测试工作

6、对软件版本的发布缺乏有效的管理

7、缺乏历史数据的积累，没有软件开发的历史数据

8、无法有效的管理和跟踪变更

要强调的是，要制定好配置管理计划才能有效开展配置管理

文档代码记录、版本控制以并行开发或回退、变更管理是重中之重

通常看核心的这三点即可

 1、没有文档记录、代码记录，我们无法衡量结果是否有效

  2、版本控制以并行开发或回退

 3、变更管理

 配置计划参考：

 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

 在项目的实施过程中，将配置库分为受控配置库和非受控配置库两种。

受控配置库

在本项目开发实施的整个过程中，根据不同阶段的配置管理划分11个受控配置目录，只有配置管理员拥有增加和修改的权限，其它用户只有只读的权限。受控配置库的目录为：

00初始配置

01启动

02需求分析

03设计

04编码

05测试

06安装

07总结

08变更

09项目管理

10环境配置

 非受控配置目录

在本项目开发过程中，设立了非受控配置目录。设立非受控配置目录的目的是为了统一管理和存放开发过程中产生的临时文档和过程性文档，没有格式及命名上的严格要求，使项目组成员在思考、设计时不受太多的限制和约束，能够更有效地发挥个人能力，符合以人为本的原则。

在项目初期，设立了以下三个目录：

目录名称         用途及说明

个人工作区     用于保存项目成员自己编写的文档，每个项目成员都有自己独立的工作目录

小组工作区     用于保存小组成员写作编写的文档，每个小组都有自己独立的工作目录

文档提交区     作为非受控配置库和受控配置库之间的缓冲，用于提交已经定稿的文档和代码，在评审通过后，再由配置管理员取出并提交到受控配置库中

配置管理工具

 ClearCase 支持常见的平台

Firefly  软件本身基于Java开发，可在Windows、Linux、Solaris、HP-UX、AIX等常见平台上使用，平台之间的移植也非常方便

CVS 支持几乎所有的操作系统

PVCS 软件本身基于Java开发，能够支持常见的平台

VSS 仅支持Windows操作系统

ClearCase是IBM的，非常细致庞大的工具，我们在用。 Firefly是国内的一家公司

VSS是基本免费的工具， CVS、SVN等工具也非常好用

SVN是近两年的工具，他是CVS等工具的简化和融合工具

ClearCase 服务器采用多进程机制，使用自带多版本文件系统MVFS，对性能有较大负面影响。做为一款企业级、全面的开发配置管理工具，适用于大型开发团队

Firefly服务器采用了多线程的应用服务器，性能表现优秀，做为一款企业级、全面的开发配置管理，能适用于50人到上千人的团队

CVS较高的运行性能，适用于各种级别的开发团队

PVCS服务器采用文件系统共享方式，对CPU、内存及网络要求较高，性能一般，仅适用于中小型项目团队，不适合于企业级应用

VSS相对功能单一、简陋，适用于几个人的小型团队，在数据量不大的情况下，性能可以接受

 以上是这篇文章的分析，非常到位 http://z.xiaoi.com/r?space.itpub.net%2F%3Fuid-12639375-action-viewspace-itemid-156983

通过交流，老谷建议：作为甲方，对配置管理不需要太多控制，阶段点监察他们的库足够了。

个人认为在本公司，对于软硬件环境的配置项做好记录，这些方面相对固定。配置管理员可兼职，负责文档方面和代码方面的存档更新。文档方面，所有过程文档均做好记录，做好版本控制，特别是变更后的文档的更新，这方面工作基本都流于形式，我们的文档似乎都是一成不变的，即使做了变更，有变更申请和分析文档，却很少更新详细方案设计书，也很少对项目进度表作出更新。代码方面，当Release版本发布开始，每次的发布均保留在服务器上的某处，供应商无权更新，只有当变更批准，测试完成后才能发布，并记录新的版本号、执行人等关键信息，而且要跟踪变更后的运行状况。不仅要做记录，而且在里程碑节点时，需要做审核，是否记录完全，是否跟踪变更执行情况。也需要适当检查乙方的配置库，是否有完备的配置库。

至于配置工具，暂时先不考虑，毕竟管理得不需要太细。