本文选自《软件工程指全程建模实现》第二版书稿内容，与上一篇不同，本段文字为全新撰写整理自blog中配置管理方面的内容，因为书稿目前还没有完成，为了表示对朋友们的歉意，现发布部分内容给大家分享。
注：因为无法上传图片，因此本文中没有书中配套的图片。
1.1.1 引言
我们在网络上能够搜索到的关于配置管理工具的文档资料介绍的内容大体如下：
什么是配置管理？
有哪些配置管理工具？
配置管理工具之间的比拼。
如何选择配置管理工具。
配置管理计划如何制定执行。
等等。
在上面这些专题中提到的都是配置管理工具独立使用或者如何解决配置管理相关的内容。
而本节不是为了介绍配置管理工具的一般性使用方法或者上述内容，本文的目的主要在于配置管理工具和常规文档以及建模工具甚至开发编码工具之间的配合问题，如何通过这个来验证配置管理工具中的信息的真实性，如何防治软件开发中的弄虚作假问题。
1.1.2 配置管理工具的使用方法
起因
问题产生：
在 2001 年笔者参加的 CMM 的最终评审中，印度过来的主任评估师要求分析设计组人员在对话结束后提供一份设计变更的请求资料和设计变更的结果，我们当场承诺了下来。
设计变更我们的确做过，但因为当时是一个小的工具产品的开发，设计变更只有为数不多的几次，因为整个开发周期也只有三个月时间的小项目。而在这几次变更中，我们采用的是会谈商议的方式，并没有邮件发送作为标记或者其他变更文档，于是我们对主任评估师说，我们用了 lotus notes 这个内部 OA 系统发送了内部变更申请的邮件和批复邮件，主任评估师就让我们打印出来相关的邮件内容供他审核。
问题解决：
我们离开对话现场后，用了 15 分钟时间就做了两封邮件出来（因为有个哥们本人就是 notes 高手），连标定时间和日期都做的完全符合“实际 ” 情况应该发生的那样。于是，这唯一的一个弱点就通过了主任评估师的审核，我们分析设计组全部达标。
这样的一个案例的问题同样在很多公司里面上演过，在很多评审过程中发生过，只是类型略有差异，造假的内容各有不同而已。
那么这样的问题该如何解决，这个问题就分为两个层面的观点：
一个方面是作为非开发者，也就是你如何避免被欺骗？不管你是作为企业的管理者，还是所谓的主任评估师 /ISO 预审员或者相关角色，甚至是招标审核方，或者是客户 / 用户方，你都需要知道技术人员做的是什么，里面是不是真的？
另一方面就是对于技术人员来说，如何有效地利用配置管理工具，让企业的管理者知道自己没有在浪费时间，如何让客户 / 用户知道自己的辛苦，知道自己中间曾经走过多少条路才找到了这样一条快捷的道路来实现了用户所需要的功能——很多时候代码的多次重构，都是从一个个绕圈的路上寻找更快捷到达目的地的过程，中间这些绕圈的路子是不可避免的，但是，非开发人员只能看到你的结果，他们一般都看不到中间的过程和艰辛。所以，国内才有大量的倒卖 / 盗卖代码，甚至一个超大规模的复杂系统（在国外开价可以过千万的系统）居然开价只有几十万甚至几万乃至几千块钱的现象出现。
解决办法
针对这种现象，我们作为技术人员一方面要客观地体现我们的技术和研发过程经历的艰难和过程，另一方面更要务实的做事。所有阅读本书的读者都可以看到本书有一个与众不同的修订历史记录，这个历史记录记录了笔者本人从开始撰写各个独立的文章到后面的合并以及第一次的正式出版，后来又进行了新的文章的撰写以及这些撰写完成的文字再次与整本书的融合过程。这个修订历史列表同样应用于 2002 年底中国电信 MSS 系统规范文档中，下面截取部分该文档的修订历史列表做为例子：
图表 8 ‑ 14 中国电信 MSS 系统规范文档的修订列表起始部分
中间的部分就省略了，同时遮盖了部分设计人员姓名的内容，其他内容保留，以提供本文档的真实可靠性的信息供读者查阅。
图表 8 ‑ 15 中国电信 MSS 系统规范文档的修订列表结束部分
在开发过程中，我们可以把文档中这些修订说明部分的内容复制到配置管理工具的 comment 里面，两者对应就可以形成全部文档的可靠性验证了。
在审核的时候，审核人员可以查阅文档的修订记录中关键条目的说明是否与配置管理工具中该文档的 comment 内容一致，如果配置管理工具中的版本数量过少，或者 comment 内容对应的修订时间与文档中的修订时间不同，那就可以认定该文档造假。如果当年印度那位头发全白的主任评估师去打开配置库，进行这样的验证性查找，或者委托他的助手进行这样的工作，那当时的这个问题就会被发现出来。
对于技术人员来说，这样一份文档放在任何级别的审核人员面前，他首先不能否认你的工作过程所付出的劳动，在这个基础上，任何人都会因此而动心，至少对你的劳动增加了一份同情之感。在中国电信集团的那次终审中，所有参加评审的领导发表意见时候的第一句话都会说，可以看到四川设计院在进行集团这个项目的工作中付出了很多的劳动，很辛苦，云云。
另外，这部分内容对应于可度量绩效管理模型中开发工作绩效的内容，在那里对应的配置库中的绩效计算基础数据就是从这里通过这样的方法可以获取到的。
其他问题
有人说文档的修订说明必须和配置库的 comment 一一对应么？
答：
不需要一一对应，但是，凡是配置库中有的 comment 都应该出现在文档的修订说明中，也就是说，配置库中的版本数量应该少于或者远远少于文档的实际修订次数。
这是因为，从配置库中取出来的文档可能修订半天后才会进行一次提交，才会形成一条 comment 内容，另外，技术人员也有可能把文档带回家或者去和客户商谈等非开发现场进行文档的修订，这个时候，文档的修订次数就会增加，每次增加都应该增加一条修订说明，而不是等提交到配置库的时候才产生一条修订说明。
如果两者数量完全一样，那这里面也肯定有猫腻存在，应该怀疑该文档内容和修订内容的真实性了。
有人还会问，那代码或者其他的怎么操作？
答：
对于代码和 uml
模型的修订过程，我们也可以在代码的上面形成版本号的形式，因为代码的开发很少离开工作现场，所以，我们可以做到每一次的修订都与配置库关联进行，填写对应的 comment 内容。
另外，代码和模型文件的修订内容可以很具体，一般一次任务可以进行如下说明：
首先， check out 的时候写明本次任务的内容在 comment 内；
其次，未完成任务的提交里面要在 comment 内写明本次提交的修订内容，同时标注任务未完成；
最后，完成后的提交，要在 comment 内写明本次任务修订的内容全部完成，或者那些内容因为什么样的变更而暂时不考虑完成。
这样基本上就完全完成了对代码的全面配置管理工作。
1.1.3 结论
配置管理工具是软件工程活动的核心工具之一，其重要性是每一个参加过实际项目开发的人都能体会到的。但是，如何用好配置管理工具则是大多数技术人员都很迷惑的事情。本节建议的方法不会浪费较多的时间，毕竟每次工作时间结束都可以顺手用几秒钟完成这样一段文字，而更多的就是复制和粘贴，不会增加更多的工作量，却可以获得相当好的效果。