而软件配置管理中也类似，需要记录谁“借”出了什么文件，什么时候“还”的。在这一“借”一“还”的过程中，程序员修改了它，而软件配置管理记录下了这些修改。那么，为什么要记录呢?
因为软件资产与图书资产不同，软件资产在不断变化，不断演进。项目初始的时候，可能只有一份简单的项目计划，而项目结束时，已是可以交付给用户的产品。如果缩小视野，单就某个源代码文件来看，也会看到，通常它会在项目的某个时刻，被某个程序员创建第一个版本，然后，可能有不同的程序员，不断修改它，产生新的版本。软件配置管理关心：是不是这个文件的各个历史版本应该被记录，以便今后翻阅?是不是各次修改的修改者、修改的原因应该被记录，以便将来可以理解当时的情形，理解为什么做出这样的改动?更扣人心弦的是，当两个人同时想要修改一个文件的时候，可能会导致其中一个人的改动丢失，也就是常说的版本覆盖。那么，是让他们一个改完了另一个再改呢，还是让他们同时改，在将来合并?等等。
所以说，软件配置管理是关于不断演进的软件资产的管理。
为什么称作配置管理?
机器由零部件组成。例如，汽车一般由底盘、发动机、车身和电器设备四大部分组成。其中，汽车底盘一般包括传动系、转向系、制动系和行驶系。传动系主要由离合器、变速器、传动轴和减速器等部件组成。再往下，基本就是零件了.
机器由正确型号的零部件配置而成。每个零件都有型号、编号。零件组成的部件也有。一直到整个机器，一辆汽车。要保证制造出来的机器是正确的，就要保证选取了所有正确型号的零部件。那么，容易想到，应该有某种列表或文档，标明各零部件型号和组成关系，也就是说，标明配置信息。而当配置有变动的时候，要更新这样的列表或文档。并且，这种变动不能随随便便，是否应该先让总工程师批准?是否应该做相应的测试?这些都属于对配置的管理。
从软件配置管理的视角看，软件也是这么配置起来的。往小了说，各个源代码文件的正确版本配置在一起，编译产生了正确的可运行程序。往大了说，若干软件组件的特定版本，配置构成了特定的软件产品。而有些软件组件，可能参与了不止一个软件产品的配置构成。而当某个软件组件参与不止一个软件产品的配置构成的时候，可能是这个软件组件的同一个版本，也可能是不同版本。看，问题有多复杂!不管理怎么行!
软件配置管理，与对机械系统的配置的管理相比，是有一些自己的特点的。主要有两点：第一，软件更容易发生变化，向前演进。一个程序员，修改一个Bug，可能5分钟就搞定了，于是，5分钟前与5分钟后，已经是不同的版本了。更何况，不止一个程序员在工作。如此快速的、众多的变化，如果靠一个书记员手工记录相关信息，那恐怕比较累。所以需要某种自动化的工具，提供这方面的支持。
文章来源于领测软件测试网 https://www.ltesting.net/
