3、配置基线

　　（1）基线是软件生存期各开发阶段末尾的特定点，也称为里程碑。在这些特定点上，阶段工作已结束，并且已经取得了正式的阶段产品。

　　建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被割开，从而更加有利于检验和肯定阶段工作的成果。同时也有利于变更控制。有了基线的规定后，就可以禁止跨越里程碑去修改另一开发阶段“已冻结”的工作成果。

　　作为阶段的正式产品，基线应该是稳定的，设计基线的规格说明应该是通过评审的。

　　（2）如果把软件看作是系统的一个组成部分，以下三种基线是最受人们关注的：

　　①功能基线：是指在系统分析和软件定义阶段结束时，经过正式评审和批准的系统设计规格说明中对被开发软件系统的规格说明：或是协议书或合同中所规定的对被开发软件系统的规格说明：或是项目任务书中所规定的对待开发软件系统的规格说明。

　　②分配基线：指在软件需求分析阶段结束时，经正式评审和批准的软件需求规格说明。

　　③产品基线：指软件组装与系统测试阶段结束时，经正式评审和批准的有关所开发的软件产品的全部配置项的规格说明。

　　4、变更请求与变更控制

　　（1）利用配置库实现变更控制

　　一般情况下，处于开发状态中的软件配置项尚未稳定下来，并未受到配置管理的控制，开发人员的变更也并未受到限制。但当开发人员认为工作已告完成，可供其它配置项使用时，它就开始趋于稳定。把它交出评审，就开始进入评审状态，若通过评审作为基线将准许进入配置库（实施check-in），开始“冻结”，此时开发人员不允许对其任意修改，因为它已处于受控状态。通过评审表明，它确已达到质量要求，但若未能通过评审，则将其回归到工作状态，重新进行调整。我们可以通过图4看到上述配置项状态变化的过程。

　　处于受控状态下的配置项，原则上不允许修改，但这不是绝对的，如果由于多种原因需要变更，就需要提出“变更请求”。在得到批准的情况下，允许配置项从库中检出（实施check-out），待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。此过程即为库管理。当然完全可以借助于工具实现库管理。

　　（2）变更请求

　　变更请求是实施变更控制的起始一步，也是必不可少的一步。最为常见的变更理由可能是清除缺陷、适应运行平台的变更，或是软件扩展提出的要求，例如增加功能、提高性能等。

　　四、配置审核

　　1、什么是配置审核

　　配置审核的任务是验证配置项对配置标识的一致性。软件开发的实践表明，尽管对配置项做了标识，实践了变更控制和版本控制，但如果不做检查或验证，仍然会出现混乱。这种验证包括：

　　对配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象。

　　配置标识的准则是否得到了遵循。