软件配置管理 对软件成果的有效保护 林 锐 博士上 海 漫 索 计 算 机 科 技 有 限 公 司Page 2目录1. 什么是软件配置管理 2. 为什么需要配置管理3. 人的问题4. 软件配置管理规范：概念与流程 5. 软件配置管理规范：配置管理计划 6. 软件配置管理规范：版本控制规则 7. 软件配置管理规范：变更控制规则 8. 软件配置管理规范：配置库操作 9. 软件配置管理规范：配置审计 10. 常用配置管理工具参考书：软件工程与项目管理解析，林锐 著，电子工业出版社，2003Page 31. 什么是软件配置管理 1.1 忏悔录曾经有一个很好的配置管理工具在我面前，我没有理睬，直到版本混乱的时候才后悔莫及， 工作中最大的痛苦莫过于此，如果上天再给我一次机会的话，我向对它说三个字：我要你。如果 非得加一个期限的话，我希望是一辈子。 1.2 概念u不要和“计算机零配件组装”搞混淆。u软件配置管理（Software Configuration Management, SCM）是指通过执行版本控制、变更控制 等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对 工作成果的一种有效保护。 u配置管理与任何一位项目成员都有关系，因为每个人都会产生工作成果。配置管理是否有成效取 决于三个要素：人、规范、工具 Page 41. 什么是软件配置管理 1.3 配置管理的商业理念 u企业的商业需求决定了配置管理的力度，我们不必追求完美无缺的配置管理，而是让开发团队恰 好够用就行，并将为配置管理所付出的代价控制在预算之内。 u富有成效的配置管理的特征： 任何项目成员都要对其工作成果进行配置管理，应当养成良好的习惯。不必付出过多的精 力，最低要求是保证重要工作成果不发生混乱。 配置管理规范应当清晰明了，便于执行，不必在细节方面要求太多，不给项目人员添加过 多的负担，不使人厌烦。 选择配置管理工具应当综合考虑价格、易用性和功能因素，而不是购买最先进的工具。令 人满意的工具通常是价格低廉、简便易用、功能恰好够用。 uCMM/CMMI对配置管理过程域论述得十分清楚详细，假设完全按照CMM/CMMI的要求执行的 话，你可以得到100分（满分）的配置管理成绩。出于商业利益考虑，我不向往100分的成绩，因为代价太高了。我更愿意付出前者的30左 右代价获取6070分（及格）的成绩，这样最划算。70100分的配置管理成绩对于大部分商业软件而言没有多少意义，那属于锦上添花，如果 我们没有足够的精力的话，那么就以最低的代价达到及格分数就行了。 Page 52. 为什么需要软件配置管理 2.1 如果没有软件配置管理，将有什么坏处？u最大的麻烦是工作成果被覆盖。如果不采用配置管理软件来保存工作成果的历史版本的话，人们 在同一个文件上修改内容，保存之后，那么新的内容覆盖了老的内容。多数情况下新的内容比老的内容好，覆盖了也没关系。但是总有不少意外，例如程序员修 改了老程序员之后，突然发现新程序是错误的，而老程序却是对的，可是老程序被新程序 覆盖了，再也无法恢复。怎么办呢？还能怎么办，只好重新写老程序再覆盖新程序呗，可是过一阵子又发现新程序 也又可取之处，这时却无法恢复新程序了，只好重新写新程序再覆盖老程序，如果你经 常碰到这样的事情，你会发疯的。为了避免成果被覆盖，很多人采用最原始的手工管理版本的方式，例如给文件加后缀“-01” 、“-02”以表示版本。天长日久，工作目录下就会有一堆带数字后缀的文件，而且你自己也 忘记了数字后缀代表什么内容，管理起来非常麻烦。 我在读大学的时候，我自己以及周围的人都不知道软件配置管理，所以大家都有上述经历 。幸好在学校里的人时间不值钱，工作成果也不值钱，可以穷折腾。但是在企业里工作， 我们可不能不懂软件配置管理，否则就贻误工作浪费金钱了。 Page 62. 为什么需要软件配置管理 2.2 使用软件配置管理，将有什么好处？u最直接的好处是工作成果的所有版本都被保留着，不会丢失也不会被覆盖，你不会气得发疯了。 如今硬盘的存储空间价格低廉，用于保存历史版本的存储空间的成本可以忽略不计。如果 你保存了工作成果的100个历史版本，哪怕99版本都是“垃圾”，只有一个版本里有“黄金”， 那也值了。所以你尽管放心保存历史版本好了，累的是计算机又不是你，你怕什么。 u间接的好处是，项目的所有工作成果被完整地保留下来，这是企业的知识财富，可以被人们很好 地分享利用。而且减少了人员辞职造成的损失，企业老板可以放心很多了。因为如果没有配置管理的话，人走了，即使他把成果刻录成光盘交给接收者，别人也搞不 清楚那些成果的演化过程。 u我在事业部推广CMM的时候，有一天事业部总经理郑重其事地找我商谈，说某个产品线的经理 要“跳楼N次”，请大家帮忙“解救”。因为他把更新北京客户的软件安装到天津客户那里，却把更 新天津客户的软件安装到其他客户那里，现在他自己也搞不清除发生了多少错乱！如果跳楼一次 能够消除一个错乱的话，那么他要跳楼N次。这是典型的版本错乱问题，只有良好的配置管理才可以解救这位产品经理。 Page 73. 人的问题 3.1 事在人为 u配置管理的方法是成熟的，而且相应的软件工具也是成熟的，基本上不存在看不懂、不会用的问 题。配置管理的执行效果如何，完全应了中国的一句老话“事在人为”啊。 妨碍配置管理的主要问 题是人们“嫌麻烦”（还有侥幸心理）。 u在没有出乱子的情况下，执行版本控制看起来有些麻烦。每次修改工作成果的时候，总是先check out，然后再修改，最后还要check in，多了前后两步。其实check out和check in两步操作只需花费几秒钟，而且不费脑子，凭良心说根本没有添加 麻烦，仅仅是个人感觉不爽快而已。然而不执行版本控制的话，万一发生工作成果被覆盖 或丢失等问题，那么麻烦就大了。 很多老百姓有闯红灯的不良习惯，本来只要等十来秒钟就可以安稳上路的，可就是感觉麻 烦，就急着要闯红灯。人们平时不知浪费多少时间，你又何必节约这十几秒钟呢。在没有 发行交通事故的时候，你闯红灯后有一股赚了的快感，万一你运气不好躺在医院里，就后 悔莫及了。所以不要嫌配置管理麻烦，这点小麻烦是为了避免你遇到大麻烦。 u侥幸心理导致人们麻痹大意。我也有这个毛病，我非常清楚版本控制的重要性，也能熟练使用配 置管理软件，可是我常常把一个文件check out出来后，修改了一两周后才check in进去。我只敢对个人文件的配置管理存在侥幸心理，我从来不敢轻视软件产品的配置管理。因为 前者出乱子的代价比较小，我承受得起，后者出乱子我可承受不起。（例如Future 软件的 配置管理）。 Page 84. 软件配置管理规范：概念与流程 4.1 配置项 u软件研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被妥 善地保管起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很 麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。u凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI）。配置项主要有两大 类：属于产品组成部分的工作成果，例如源代码、需求文档、设计文档、测试用例等等。在管理过程中产生的文档例如各种计划、监控报告等等，这些文档虽然不是产品的组成部 分，但是值得保存。 u每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保 存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。4.2 基线 u基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置 项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。u基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个 基线。基线的主要属性有：名称、标识符、版本、日期等。u通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。 Page 94. 软件配置管理规范：概念与流程 4.3 角色 u为了提高配置管理的效率和安全性，项目应当设有配置管理员这个角色。配置管理员的主要工作 是为项目制定配置管理计划，创建和维护配置库等。 u对于大型的项目，鉴于配置管理的重要性和复杂性，机构应当设立配置控制委员会（ Configuration Control Board，CCB）。CCB是个虚拟小组，对配置管理各项活动拥有决策权（ 例如审批计划，审批变更请求等）。对于配置管理而言，CCB是决策者，而配置管理员是执行者 。u对于普通的小型软件项目而言，CCB这个概念难以落实，我们就不要玩虚的了，让项目经理或者 配置管理员做决定就行了。 4.4 流程 Page 105. 软件配置管理规范：配置管理计划 u配置管理员根据本项目的特征，起草配置管理计划，由CCB负责人（通常是项目经理）审批。u配置管理计划的主要内容： 1. 人员与职责 2. 软件硬件资源 3. 配置项计划 4. 基线计划 5. 配置库备份计划 6. 版本控制规则 7. 变更控制规则 8. 审批 u模板见word文档Page 116. 软件配置管理规范：版本控制规则 6.1 概念 u版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并 且可以快速准确地查找到配置项的任何版本。所有项目成员都必须遵照版本控制规程操作配置库。u配置项的状态有三种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”（Changing）。u配置项状态变迁： 配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“正式发布” 。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项 修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。 Page 126. 软件配置管理规范：版本控制规则 6.2 版本号 u（1）处于“草稿”状态的配置项的版本号格式为：0.YZ YZ数字范围为01-99。随着草稿的不断完善，“YZ”的取值应递增。“YZ”的初值和增幅由用户自己把握。 u（2）处于“正式发布”状态的配置项的版本号格式为：X.Y X为主版本号，取值范围为1-9。Y为次版本号，取值范围为1-9。 配置项第一次“正式发布”时，版本号为1.0。 如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升 级幅度比较大时，才允许增大X值。 u（3）处于“正在修改”状态的配置项的版本号格式为：X.YZ 配置项正在修改时，一般只增大Z值，X.Y值保持不变。 当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。参见规则 （2）。 Page 137. 软件配置管理规范：变更控制 u变更控制的目的是防止配置项被随意修改而导致混乱。为了提高效率，对于处于“草稿状态”的配置项，不必进行变更控制，因为它们本来就是草 稿，本来就是要被不断地修改的。当配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被“冻结”）时 ，如果要修改配置项的话，那么按照变更控制规则执行。 u步骤：第一步 变更申请。变更申请人向CCB提交变更申请，重点说明“变更内容”和“变更原因”。第二步 审批变更申请。CCB负责人（或项目经理）审批该申请，分析此变更对项目造成的 影响。如果同意变更的话，则转向第三步，否则终止。 第三步 安排变更任务。CCB指定变更执行人，安排他们的任务。CCB需要和变更执行人就 变更内容达成共识。 第四步 执行变更任务。变更执行人根据CCB安排的任务，修改配置项。CCB监督变更任务 的执行，如检查变更内容是否正确、是否按时完成工作等。第五步 对更改