控制：通过建立配置管理过程和规程，SCM实施对CIs的控制，以在升级的生命周期中维护配置变化的可跟踪性。在每个阶段/里程碑增长的配置，确保要包括新增的通过验证的代码和维护已知偏差的可跟踪性。在我们组织中，CM在产品生命周期中定期更新CSA数据库，这种做法提供了项目在各个指定时间点的快照。这意味着要同时查询当前和已归档的项目时，增量发布的历史数据可以描述出发现缺陷的阶段和改正缺陷的阶段等信息。

    图2是我们数据库内一个变更请求单（简称SCR）的例子。在这个过程中对将来需使用的数据进行了度量。在每个里程碑时跟踪进度，比如最后的同行评审完成时间、CCB批准的时间，还包括评审SCR耗费的人时，同行评审花费的时间，行动项个数与优先级，源代码行以及内存的变化等。

    偏差在不同的测试阶段被发现。当偏差被发现时，发现缺陷的工程师负责将其输入数据库。当偏差成为配置项后，数据库给它分配一个跟踪编号。SCM跟踪问题直到其被改正或确定不是问题。图3是一份偏差状态报告的样例。

    图二：变更请求

    图三：偏差报告

    审计：在软件增量开发的构建过程中，SCM要进行配置审计，以确保产品的完整性和与规程的一致性。此外，作为独立的实体，SCM团队还在产品的生命周期中负责质量保证的工作，维护过程的连续性和可跟踪性。我们的CM过程包括审计和质量检查，保证在软件代码开发的同时，相关规格的及时更新。

    例如，当一个变更请求被评审，意见被记录，责任人已按同行评审的意见再次修订后就会进行审计，我们的同行评审过程要求对文档进行审计，保证责任人完成所有批准的变更。如果审计没有通过，将会重复变更的步骤。

    我们得到的一个教训是这样的：当发布新的软件系统前时，客户又提出新的系统升级需求。客户的需求往往是模糊、不确定的，而且没有标识出所有的配置项，额外的硬件修订需求也没有识别出，直到我们开始升级软件时才发现。在项目的晚期才识别、纠正和实施发现的偏差，会影响软件的发布周期。为避免此类问题重演，我们采取了纠正行动，对配置管理过程进行裁剪，增加对文档进行预评审的过程。修订后的过程将此类问题减少90％。而且CCB能基于更好的产品进行评审，对项目的费用和进度估算也更准确。