大家好。
      在配置管理理论中讲到，配置管理的目的是：建立和维护在整个软件生命周期中工作成果的完整性、一致性和可追踪性。那么各位对“完整性、一致性、可追踪性”的理解是怎样的呢？请发表自己的看法。

为了简化理解，我假设一个项目有三个输出的工作产品a、b、c（即配置项），它们特定版本的组合形成我们最终交付的产品。

－完整性：a、b、c从输出了第一版本之后，CM要保证三者每个版本以及版本信息的都有存档；

－一致性：假设最终交付产品的版本是v1.0，它对应的a、b、c的版本分别是v1.1、v2.3、v1.0，那CM就需要保证这样特定版本的组合关系不要乱套了，也就是说若a的版本是v1.0的话，对于最终交付产品的版本是v1.0来说就是不一致了

－可追溯性：a在开发过程中会历经版本的变迁，从v1.0到v1.1是有什么样的变化（如功能增强、缺陷修复），需要记录下来，以便特定版本的回溯

以上是个人理解，欢迎赐教！

同意rocky_rup,他的说明很形象

为了做到"完整性、一致性、可追踪性",我们有相应的配置工作的开展来保证.

比如
1.配置审计:  包括物理审计和功能审计.

2.变更控制:控制每个变更,尤其是对于一致性方面,任何一个配置项变更,相应的受影响的配置项都需要相应变更.

3.版本控制:记录每个版本的变更,便于跟踪.

qingqing版主的第三点，版本控制，例如，对于一个设计文档进行变更，版本号是怎么定的，因为，我们cq中，版本号是变更提交者提的，他们经常乱填写，对于我们跟踪版本其实是困难的。我可能根本很难对应此变更所产生的版本，开发人员也没有去查看我打标签的习惯。很苦恼

叽叽喳喳,你好!

对于你说的问题。
我的想法是，不管我们用什么工具来管理文档、代码等。
变更和版本号的管理都需要制定规范来保证。

对于变更，比如基线变更，首先设计文档可以建立基线，然后变更流程需要规定，
从变更申请、评审、基线变更、变更验证、基线升级和变更报告等一系列的操作约定。

对于版本号，也不能随便填写，应该有对配置项的版本号的约定。

在工具的基础上，需要通过流程等一起来保证。

以上意见你可以参考。

完整性：库的概念：文档库、代码库做到可追溯
一致性：基线的概念：重要里程碑的基线控制，版本递交保证各个阶段基线的一致性
可追踪性：每个阶段的配置审计，配置项的记录，变更的控制

引用:

原帖由 叽叽喳喳 于 2006-12-30 11:55 发表
qingqing版主的第三点，版本控制，例如，对于一个设计文档进行变更，版本号是怎么定的，因为，我们cq中，版本号是变更提交者提的，他们经常乱填写，对于我们跟踪版本其实是困难的。我可能根本很难对应此变更所产 ...

版本号的命名就是配置管理中的标示的一种，不能乱填，必须制定标准。像在机械产品中就有各种编码规则，如隶属码，分类码等

[ 本帖最后由 dellxps 于 2007-1-8 23:03 编辑 ]

文档和代码，以及发布版本的一致性，也应该属于一致性的定义