软件配置管理（一）
曾经看过一套CMMI过程文件：配置管理规范要求，凡是经过评审的工作产品均需受控管理；而评审工作指南则要求，凡是要纳入受控库的工作产品均需通过评审。漂亮，逻辑完美。问题是读者依然不清楚究竟哪些文件要评审或者入库。云里雾里的感觉，看着就让人很烦躁，更别说遵照执行了。体系落不了地，很多原因与此类似吧。
配置管理的内容很多，我准备分两部分来讲。第一部分介绍基本概念，第二部分介绍配置管理中的主要活动流程。
一、配置管理项
配置管理通过管理不断演化和完善的软件产品，确保开发者在 软件生命周期 中的各个阶段都能得到精确的产品配置。 配置管理的对象就是配置管理项，不仅包括了合同规定的最终交付产品，也包括软件开发的中间过程产品，例如文档、工具等。注意：软件“单元/模块/配置项/系统”中的“配置项”是软件结构层面的概念，与此处的“配置管理项”含义是不同的。
从配置管理的目的就可以看出：原则上，只要会影响产品配置的工作产品都应该进行配置管理，都属于配置管理项（以下简称“配置项”）。配置项识别可参照如下原则，注意此处的“工作产品”除了包括项目组生产的，也包括工具软件、开源代码、第三方库、过程标准、参考资料等。
- 会发生变化的工作产品；
- 作为其他工作产品依据的工作产品；
- 被其他工作产品使用或依赖的工作产品；
- 属于交付物、采购品的工作产品。
由于大多数配置管理库也充当了文件服务器，因此尽管很多中间过程产品（如项目月报、会议纪要等）不符合上述原则，通常也会在开发库进行统一管理。
二、配置管理库
针对不同的配置项或同一配置项的不同状态，应该采取不同的控制策略。例如对于软件需求规格说明，草稿状态时想怎么变都没问题；当评审通过后，变更就应履行审批程序了；而如果作为交付物都已交付用户了，那么变更可能还需征求用户意见了。
根据控制策略的不同，建立不同的配置管理库（以下简称“配置库”），例如开发库、受控库和产品库。
- 开发库：开发库由项目组成员自行管理，可以是一个物理独立的存储库，也可以只存在于逻辑层面，而实际就是开发人员的本地目录（建议有一个独立的开发库，因为除了会进入受控库的配置项之外，还有很多文件是值得集中管理的）。开发库的权限控制可以比较宽松，例如授予项目组所有成员拥有全部权限（新建/删除/读写），或者仅禁止删除，再或者也可以根据目录授权（注意这是一个危险的复杂源头）。
- 受控库：受控库用于存放需要严格控制版本的配置项，可以是评审通过的文件、提交测试的代码等。项目的阶段或里程碑工作成果通常都应该受控管理，因为它们会作为下一阶段工作的输入和依据，必须严格控制版本。因此在项目进度计划制定完成后，项目的受控配置项清单包括各配置项的计划受控时间、入库负责人等，就都可以确定了。受控库的操作通常由项目配置管理员负责，其他项目组成员只有读权限，对于受控配置项的变更和出入库需要履行审批程序，批准后由项目配置管理员操作。
- 产品库：产品库用于存放交付客户的产品。对于产品库的使用建议是“交付了就存、只存交付的”。有的组织规定产品库只用于存放最终交付的产品，而在实际研发过程中，出于临时应急或者提前试用的原因或考虑，项目可能会交付多次。由于都不属于最终交付，产品库就只会在最后项目结束时保存一个版本，对中间交付的版本都没有给予足够的重视。而实际在项目后期调试过程中，保持客户现场版本与内部版本的一致性是很重要的，甚至于出差前后的版本都可能存在差异。因此建议“交付了就存”（多做些版本控制工作是值得的，起码可以提升团队的掌控感）。另外，与交付产品对应的，还有许多不要求交付的中间过程成果，这些成果或在开发库或在受控库，不建议与交付产品配套着再放到产品库一份，避免因重复而导致库间的不一致性问题。因此建议“只存交付的”。产品库与受控库类似，除组织级配置管理员外，其他项目组成员只有读权限，出入库需要申请更高级别负责人的批准。
不同配置库的主要区别在于不同的控制策略，而控制策略不同的根本原因在于保存的配置项的状态不同。 下图展示了三库对应保存的配置项。
一般开发库、受控库和产品库中的配置项都是向后包含的，但这并不意味着只有开发库就够了。例如软件需求规格，开发库中应该是尚未评审的草稿版本，即使后期保存了评审通过的版本，也仍然不能作为工作的正式依据，针对软件需求规格的变更更是必须从受控库中申请出库；再比如三库可能都有软件使用手册，但如果要提交用户，需要从产品库申请出库。至于非配置项，也可以保存在开发库中，但是通常不会纳入配置状态报告和审计的范围。
三、基线
基线是一个特殊的配置项，将一组受控配置项作为一个整体进行统一命名和管理，是项目工作产品在项目生命周期某个时间点上的一个定点和快照。
我们可以在项目研制过程中的多个时间点建立基线，在CMMI以及GJB3206A中，都定义了三种最基本的基线：功能基线、分配基线和产品基线。
在《工作分解结构WBS》中，我们曾经介绍过，项目应该参考组织的WBS模板制定进度计划。在进度计划的基础上，就能确定项目的配置项、受控配置项、基线以及基线所包含的受控配置项。当然组织也可以基于WBS模板给出受控配置项和基线的最低要求。例如下图就是与瀑布模型WBS模板对应的一个项目标准受控配置项清单。
请大家理解前文介绍的配置项、配置库以及基线的概念（尤其是加粗部分）。前面已经用两张图展示了配置项与配置库、配置项与基线的关系，下图重点展示配置库和基线的关系，下右图相对更贴近现实一些。重点说明两点：
- 只在受控库建立基线。根据基线的定义，大家应该可以理解，开发库打基线没有意义（都还没有受控），产品库打基线没有必要（产品库中的每个版本都已经是状态明确的产品配置）；
- 用一个比较形象但不很准确的说法，配置库和基线都是配置项的集合，配置库是配置项的横向分布，而基线是配置项的纵向分布。
当然，究竟建立几种配置库、对应几条基线、又对应哪些配置项，这些都可以根据管理需要确定，本文给出的都是相对易于理解的建议。
四、CCB
CCB的全称是“Configuration Control Board”（配置控制委员会），还有一种说法是“Change Control Board”（变更控制委员会）。CMMI-V1.2中是这样描述的：“Configuration control boards are also known as change control boards ”。GB/T 20158中称作 “变更授权机构”。虽然说法不同，但概念和作用都是一致的。
CCB的主要职责是审批受控配置项以及基线的建立和变更。简单说就是在受控库/产品库入库申请、基线发布申请、变更申请上签字。下面重点说明几点。
- CCB不负责开发库配置项的入库和变更审批，项目组可以根据需要制定简单规则，也可以完全无须审批；
- CCB可以不负责受控库/产品库的出库审批；
- 可以根据配置项、基线、变更的不同重要程度对CCB分级（下图是两种分级示例）；
- CCB应该由项目利益相关方的主要负责人组成，包括客户代表、主管项目的高管、部门负责人、项目负责人、商务/开发/测试/质量/配置管理等环节负责人等。不同组织的项目管理和决策模式不同，应根据实际情况确定CCB人员。另外不同级别的CCB人员范围也不同；
- CCB的审批过程应该是一个集体决策过程，CCB的领导者主要职责是组织和主持决策会议。可以充分利用项目例会开展决策活动。
五、配置项和基线标识
标识就是编号，用于唯一命名每个配置项/基线及其不同版本。下面是一种参考的标识规则以及实例。
- 文档代号及序号可以理解为文档两级分类，可以用“TP”标识测试计划，用序号区分不同阶段的测试计划；也可以用“UM”标识使用手册，用序号区分不同类型的手册；当然也可以用“RS”标识需求规格，而序号在当前阶段只有1个；
- 配置项/模块代号：如果包括多个软件配置项，则每个配置项都应标识；如果只有1个配置项，则可以省略配置项/模块代号；
- 文档版本号：采用大、小版本两段制。初始编制完成时为0.0；首次评审通过时为1.0；发生变更时递增小版本；发生重大变更时递增大版本，小版本归零；文档评审通过后，文档作者针对评审问题进行修改并通过验证，升级文档版本，提交入受控库申请（文档修改、问题验证过程可能需要多人参与，应充分利用开发库，避免可能的版本问题）；
- 代码版本号：采用大、小、受控版本三段制。首次入受控库提交测试时为0.0.1；每次消缺、完善后入受控库时递增受控版本；首次发布时为1.0.0；再次发布时递增小版本，受控版本归零；发布重大变更时递增大版本，小版本、受控版本归零；在工作中可能会遇到下述情况，开发提交了1.0.3版本，经测试回归后认为满足发布条件，接下来应发布基线、入产品库，但受控库里的版本是1.0.3，怎么改成1.1.0呢？此时有两个办法：一是正常履行变更程序，出库修改版本并验证后再入库；二是由开发人员协助受控库配置管理员，直接在受控库修改版本号。第二种方法更简单但因缺少正式的验证过程而存在风险，因此应在过程文件中明确工作流程及要求，各项目编写具体的版本修改指南并通过评审批准；
- 基线版本号：采用大、小版本两段制。首次发布时为1.0；发生变更时递增小版本；发生重大变更时递增大版本，小版本归零；
- 除了文档、代码外，其他配置项类型也应该制定标识规则，例如：项目编号_TOOL_工具名称_版本号等。组织应制定配置项和基线标识规则，明确项目编号、文档代号、基线类型代号以及版本号的编号规则；
- 注意：很多组织已经通过了ISO9000认证，配置项标识规则应与ISO9000中相关的技术文件控制程序保持共通性，两个体系对同一份文件的编号规则应保持一致。
六、配置库目录
配置库的参考目录见下图，开发库目录由项目组根据需要确定，受控库目录应该与前文提到的项目受控配置项清单保持一致，产品库目录应与产品基线对应。开发库由项目组自行建立，受控库和产品库分别由项目级和组织级配置管理员建立。
好了，本文暂告一段落，下文介绍配置管理的主要活动流程。
看看一个组织的配置管理过程文件，就能看出来他们到底管没管。很多过程文件仅仅保证了“逻辑合理”而已，实际根本无法指导具体工作，更别提连逻辑都矛盾或不完整的那部分了。
想想如果我有一个十来个人的小团队，如何保证并行开发的效率，如何把团队的工作成果管理起来。本文所有概念都能用得上，配置项就是我认为要管起来的工作成果；配置库可能是服务器上的“备份”文件夹；基线是因为有里程碑意义，所以我会单独刻张盘；CCB就是以我为中心的高管团队（打比方而已）。别人家的管理方法100%不适合你，学习的目的是理解并根据需要调整，项目管理没有“拿来主义”。
