基线的概念对于大多数做技术状态管理或配置管理的组织来说，并不陌生。基线就是一组状态已经固化的配置项。通常我们的一个软件项目至少会建立3条基线：功能基线、分配基线、产品基线；我们都知道基线不能随意变更，变更必须要得到批准。但是，这样的理解和这样的做法就是%正确的吗？
也许这样对于基线的理解有些片面。虽然我们做了不少工作，但是并没有抓住基线控制的核心。基线要控制的软件产品，其核心就是软件代码。所以基线控制做得好不好，就应该以代码控制得好不好来评价。
这样的话，问题就来了。通常的做法，我们只建立功能基线、分配基线和产品基线这3条基线，那么代码只能纳入产品基线。而在产品基线建立的时候，已经是软件项目即将结束的时候，这样的话，基线控制对于开发过程中代码的变更控制还能有什么帮助？虽然通过配置项的变更控制，代码的版本变更也能控制起来，但是，这种控制通常都是把代码打包成一个整体的控制，而这样对于代码控制是不够的。
从代码控制的角度来说，基线包括项目的所有代码。在实现阶段需要包括的内容有：?每个模块当前的层次，包括源代码和目标代码。?每个测试用例的当前层次，包括源代码和目标代码。?所使用的每个组装器、编译器、编辑器或其他工具的当前层次。?任何专门测试或操作数据的当前层次。?所有宏、库和文件的当前层次。?任何安装和操作程序的当前层次。如果项目涉及操作系统或控制程序变更，还需要保持计算机系统配置及其变更层次的数据。
要做好基线控制，至少要做好两件事：一个是基线控制，另一个就是配置管理记录。
基线控制
基线是一组状态固化的配置项，所以基线是不应该轻易变动的。如果必须要变更基线，那么基线一定要经过适当的批准。通常的做法是基线的变更要经过CCB（变更控制委员会）的批准，而CCB的组成通常是覆盖软件开发的主要利益相关方的，这样的决策才最符合所有利益相关方的利益。基线控制的另外一个要点是，当发生基线变更时，代码必须要通过回归测试，才能纳入配置管理。这样，基线的内容才是可信的，基线才是真正的控制起来。
配置管理记录
配置管理的一项任务是当软件出现BUG时，能够回复到正确的历史版本，并且能够找到导致BUG发生的原因。所以，不仅要对主要的工作产品做好历史版本控制，还要对变更的过程有影响的那些因素进行详细记录。这些记录包括以下3个方面：
变更申请记录
在变更申请当中，应记录这些内容：变更来源、变更描述、变更方法、变更次序、变更进度、变更影响等信息等。
2.变更报告
在变更报告当中，应记录这些内容：变更的代码、变更的文档、变更原因、已进行的测试和结果等。
3.问题报告
在问题报告当中，应记录这些内容：环境条件、软硬件配置、变更的代码、测试用例、操作环境等。
参考文献：《软件过程管理》
赞赏
人赞赏
怎样治疗白癜风白癜风医疗的饮食禁忌