IT公司软件配置管理讲义.ppt

配置项状态变迁： 配置项刚建立时其状态为“草稿”。 配置项通过评审（或审批）后，其状态变为“正式发布”。 此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。 当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。 版本号 （1）处于“草稿”状态的配置项的版本号格式为：0.YZ YZ数字范围为01-99。 随着草稿的不断完善，“YZ”的取值应递增。 “YZ”的初值和增幅由用户自己把握。 （2）处于“正式发布”状态的配置项的版本号格式为：X.Y X为主版本号，取值范围为1-9。Y为次版本号，取值范围为1-9。 配置项第一次“正式发布”时，版本号为1.0 如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。 （3）处于“正在修改”状态的配置项的版本号格式为：X.YZ 配置项正在修改时，一般只增大Z值，X.Y值保持不变。 当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。参见规则（2）。 版本控制的好处 使混乱的开发状态变得有序！ SCM 的主要技术——版本控制 变更控制的目的是防止配置项被随意修改而导致混乱。 为了提高效率，对于处于“草稿状态”的配置项，不必进行变更控制，因为它们本来就是草稿，本来就是要被不断地修改的。 变更控制 当配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被“冻结”）时，如果要修改配置项的话，那么按照变更控制规则执行。 步骤： 第一步 变更申请。变更申请人向CCB提交变更申请，重点说明“变更内容”和“变更原因”。 第二步 审批变更申请。CCB负责人（或项目经理）审批该申请，分析此变更对项目造成的影响。如果同意变更的话，则转向第三步，否则终止。 第三步 安排变更任务。 CCB指定变更执行人，安排他们的任务。CCB需要和变更执行人就变更内容达成共识。 第四步 执行变更任务。 变更执行人根据CCB安排的任务，修改配置项。CCB监督变更任务的执行，如检查变更内容是否正确、是否按时完成工作等。 第五步 对更改后的配置项重新进行技术评审（或审批）。 第六步 结束变更。 当所有变更后的配置项都通过了技术评审或领导审批，这些配置项的状态从“正在修改”变迁为“正式发布”，本次变更结束。 在实际操作中，审批变更申请并非总是“客观公正”的，人们并不在乎变更申请是否合理，关键看是谁提出变更申请。官儿越大的人提出的变更申请总是优先处理的。 配置库操作 所有人员都依照配置管理规范和计划来操作配置库。 配置管理员的主要操作有： 创建配置库，并且至少创建配置库的所有第一级目录。 为每个项目成员分配操作权限。一般地，项目成员拥有Add, Check in, Check out, Download等权限，但是不要轻易拥有“删除”权限。 配置管理员的权限最高。具体操作视所采用的配置管理软件而定。 根据“基线计划”创建与维护基线，“冻结”配置项，控制变更。 定期清除配置库里的垃圾文件。 定期备份配置库。 其他项目成员根据自己的权限操作配置库里的工作成果， 例如 ： Add, Check in, Check out, Download等。 在没有出乱子的情况下，执行版本控制看起来有些麻烦。 每次修改工作成果的时候，总是先check out，然后再修改，最后还要check in，多了前后两步。 其实check out和check in两步操作只需花费几秒钟，而且不费脑子，凭良心说根本没有添加麻烦，仅仅是个人感觉不爽快而已。 然而不执行版本控制的话，万一发生工作成果被覆盖或丢失等问题，那么麻烦就大了。 配置项 软件研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被妥善地保管起来，以便查阅和修改。 如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。 毫无疑问，人们应当将文件分门别类、有条理地保存起来。 凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI）。 软件配置项(Software Configuration Items，SCI) 配置项主要有两大类： 属于产品组成部分的工作成果，例如源代码、需求文档、设计文档、测试用例等等 在管理过程中产生的文档例如各种计划、监控报告等等，这些文档虽然不是产品的组成部分，但是值得保存。 标识软件配置项 软件配置项分为基本对象和复合对象: 基本对象：分析\设计\编码\测试时所建立的”文档单元”,如,需求规格说明中的一节、一个模块的源代