里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。基线（Baseli
e）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（即变更控制）。基线通常对应于开发过程中的里程碑（Milesto
e），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。
812软件代码管理的一般规则
软件代码管理的特征：开发人员可能在一天之内多次更新代码，可能对整个目录进行checkoutchecki
操作，文件数量多，对实时性要求比较高。软件代码的版本结构可能比较复杂（例如产生分支），对代码管理工具的功能要求比较高。一般地只有开发人员可以checkoutchecki
代码，非开发人员不必（也不该）
f4
第8章IDP支持过程
访问代码库。开发人员应当采用专业配置管理工具来管理所有的软件代码，常见配置管理工具有CVS、SourceSafe、ClearCase等。软件代码管理的一般规则如下：先请配管理员在配管理工具中创建对应的代码库，其目录结构与开发环境的目录结构保持一致。配管理员为每个项目成员分配代码库的操作权限。一般地，项目成员拥有AddChecki
Checkout等权限，但是不能拥有“删除”权限。具体操作视所采用的配管理工具而定。项目成员根据自己的权限操作代码，例如AddChecki
Checkout等，项目组成员要保证代码及时Checki
（建议时间间隔不能超过1天，最好能够每日Build所有代码）。如果要修改已经发布了的代码，必须遵循“申请－审批－执行”的变更管理流程。在开发进度压力比较大的情况下，为了提高工作效率，允许省略“变更控制报告”，但是至少要得到项目经理的口头批准，并告知受影响的相关人员。有关责任人定期备份代码库。
813文档管理的一般规则
文档管理的特征：文档的主要用途是交流，交流越充分则文档的价值就越高。所以除了开发人员，不少相关人员（例如领导、市场人员等）都可能访问文档库。人们一般不会频繁地修改文档，文档的版本结构很简单（一般不会产生版本分支），对管理工具的功能要求不高。人们并不局限在办公室里使用文档，可能出差在外地、也可能在家里使用文档。一般地，企业领导和市场人员基本上不会使用CVS、SourceSafe、ClearCase查看文档（对他们而言这些工具都太复杂了），使用Wer