1、基于 CMM 和 CMMI 的配置管理（一）1 配置管理内容的逻辑关系在 CMM 和 CMMI 中，将配置管理的目的定义为“建立和维护产品的完整性 ”，这个目标没有提到对项目管理的支持，也就是说，它定义的配置管理的目标比当前业界对配置管理的认识有些缩小。但是，仔细分析可以发现“建立和维护产品的完整性” 是其他配置管理目标的基础。下面就从这个目标出发进行分析。逻辑关系见下图：配置完整性（对标准的理解）1. 产品完整性：就是项目提交的工作成果是“产品集合完整、子产品的正确”的2. 产品集合完整：产品包含的子产品（配置项）是完整的3. 子产品的正确：子产品（配置项）达到了需求要求，满足标准、规程的要
2、求逻辑关系分析1. “基线管理”支持“产品集合完整”，明确产品的“ 子产品”（配置项）集合，并进行管理和控制2. “配置项管理”，提供了了对子产品（配置项）的控制管理，支持“ 子产品的正确”3. “变更管理”，同时支持“产品集合完整、子产品的正确”，用于控制子产品（配置项）和产品（基线）的变更4. “配置标示”，建立对配置项（子产品）的识别、命名，支持“ 配置项管理”5. “版本控制”，控制配置项（子产品）生命历程，保留配置项（子产品）演进历史6. “过程管理”，就是对配置项、基线的建立、变更的状态标示、过程控制，保证产品（或子产品）按照规定的流程进行了操作；例如“配置项”进入“基线”的过程包
3、括：配置项标示、产品验证、进入配置、配置审计等7. “配置计划 ”、“配置库管理”、“ 配置审计”、“配置报告” 等是整个配置管理得支持系统。提供了配置管理“可视性”和监督管理2 配置和配置项在配置管理中，“配置”和“配置项” 是重要的概念，“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置” 包括了即将受控的所有产品特性，其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的“配置” 包括更多的内容并具有易变性。受控软件经常被划分为各类配置项（Configuraion items, CIs），这类
4、划分是进行软件配置管理的基础和前提，CIs 是逻辑上组成软件系统的各组成部分。比如一个软件产品包括几个程序模块，每个程序模块及其相关文档和支撑数据可能被命名为一个 CI。一个系统包括的 CIs 的数目是一个与设计密切相关的问题。一个纯软件的 CI 通常也称之为软件配置项（CSCI）。现在所有的配置管理工具均提供对配置项的管理工具，包括(Check in 和 Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比较繁琐，一般推荐使用配置管理工具，减少事务性工作。3 基线在配置管理系统中，基线就是一个 CI 或一组 CIs 在其生命周期的不同时间点上通过正式评审而进入正式受控的一
5、种状态，而这个过程被称为“基线化” 。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基线” ，通过建立这样一个基线，受控的系统需求成为进一步软件开发的出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进行功能评审的基础。每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程。基线具有
6、以下属性：通过正式的评审过程建立基线存在于基线库中，对基线的变更接受更高权限的控制基线是进一步开发和修改的基准和出发点进入基线前，不对变化进行管理或者较少管理进入基线后，对变化进行有效管理，而且这个基线作为后继续工作的基础不会变化的东西不要纳入基线变化对其他没有影响的可以不纳入基线建立基线的好处：重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。可追踪性：建立项目工件之间的前后继承关系。目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。版本隔离：基线为开发工件提供了一
7、个定点和快照，新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。4 基线、配置、配置项的关系基线的组成，以及配置项和配置的关系如下图：基线管理的步骤：1、在开发前确定基线的“ 配置”2、基线批准前，根据“配置”检查配置项是否齐备3、对各个配置项，确认其版本的正确性4、对每个配置项建立基线标志，例如上图为：测试基线=（配置项 A=1，配置项 B=1，配置项 C=1）alpha 版=（配置项 A=2，配置项 B=1，配置项 C=1）beta 版=（配置项 A=3，配置项 B=3，配置项 C=2）产品基线=（配置项 A=4，配置项 B
8、=4，配置项 C=4）5、基线变更管理6、基线的各类报告和审计信息针对某个具体得项目，可以根据基线的内容，建立一个基线信息的跟踪表，例如如下：注：被色块覆盖的表示，此配置项属于对应列的基线注：在色块的栏目填写对应配置项的版本号5 变更管理在有效标示了配置并进行了管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就要依赖有下的变更管理。缺乏有效的变更请求管理会导致的问题：软件产品质量低下，对一些缺陷的修正被遗漏项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的能力开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一边、
9、而工作在一般优先级任务上的情况可能错误使用和引用已经变更的产品，引起开发工作混乱变更管理的流程：（获得）提出变更请求；由 CCB 审核并决定是否批准；为（被接受）修改请求分配人员，提取 SCI，进行修改；提交修改后的 SCI，并测试（或者评审）；重建软件的适当版本；复审（审计）所有 SCI 的变化；发布新版本。 为了更好的指导变更范围的影响分析，可以通过两种表格来帮助发现受到变更影响的内容，一种是需求跟踪表，一种是配置项依赖关系表，分别如下：6 配置库管理在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，必须规划好工作空间的管理。主要的手段是设置配置库
10、（即文件夹设置），和设置版本的分支，来实现对配置项权限管理。书签设置版本分支基本上要为每个配置项从建立开始就划分成 3 个不同的分支：私有分支、集成分支、公共（主干）分支。让它们分别对应 3 类工作空间。私有分支：私有分支对应的是开发人员的私有开发空间。开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素。集成分支：集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得。即各开发人员必须将私有工作空间中的开发成果归并（Merge）
11、到该分支后才能进入下一个开发活动。所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的管理工作由系统集成员及相关指定人员负责。 公共（主干）分支：公共分支对应的是整个软件开发组织的公共空间。各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人员开放只读权限。该分支的管理工作由系统集成员负责。 上面定义的 3 类工作空间（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更
12、发生时，应及时做好基线的推进。配置库的设置决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，它适用于通用的应用软件开发组织。这样的组织一般产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。而按任务建立相应的配置库则适用于专业软件的研发组织。在这样的组织内，使用的开发工具种类繁多，开
13、发模式以线性发展为主，所以就没有必要把配置项严格的分类存储，人为增加目录的复杂性。因此，笔者认为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵活。配置库的日常工作配置库的日常工作是一些事务性的工作，主要保证配置库的安全性，包括：对配置库的定期备份清除无用的文件和版本检测并改进配置库的性能等7 配置报告配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过 CASE 工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。配置状态报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。为了说明项目状态对变更的情况也
14、应当进行报告。有时，对配置库的情况也进行说明，例如备份次数，磁盘占用空间等等。只要是关心的信息，均可作为状态报告的内容。这些信息进行有效记录，往往可以作为项目度量的重要数据来源。8 配置审计配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由 SQA 人员单独执行。 审计机制保证修改的动作被完整地记录，也就是说，记录了谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方。 在版本控制过程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可以自动地记
15、录审计工作所需的四个“W” （Who、When、Why、What）。 同时配置审计工作应当可以说明如下信息。 配置审计应当说明的信息：1. 变更要求被完成，并且对附加的修改已经执行了2. 采用了正确的正式验证手段3. 遵循了标准的要求4. 变更的 4W 信息被完整记录，并和相关配置项关联 9 项目实施指南一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。一个项目设立之初项目经理首先需要制定整个项目的计划，它是项目研发工作的基础。在有了总体研发计划之后，软件配置管理的
16、活动就可以展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火”的行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功的重要保证。在“开发阶段和维护阶段 ”，软件配置管理活动主要分为三个层面，这三个层面是彼此之间既独立又互相联系的有机的整体。（1） 主要由配置人员完成的管理和维护工作；（2） 由系统集成员和开发人员具体执行软件配置管理策略；（3） 变更流程。 软件阶段 活 动 活动说明计划阶段制定软件 一个项目设立之初，项目经理首先需要制定整个项目的计划计
17、划确定配置策略 配置管理委员会（CCB）根据项目的开发计划确定各个里程碑和开发策略制定配置计划 配置人员根据 CCB 的规划，制定详细的配置管理计划，交 CCB 审核批准配置计划 CCB 通过配置管理计划后交项目经理批准，发布实施确定初始基线 CCB 设定研发活动的初始基线配置库管理配置人员根据软件配置管理规划设立配置库和工作空间，为执行软件配置管理做好准备；并定期进行备份和清理工作授权开发 开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作集成 系统集成员按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进管理基线 CCB 根据项目的进展情况，并适时的
18、建立基线，批准基线变更，保证开发和维护工作有序的进行。开发阶段和维护阶段产品发布 系统集成员进行产品集成，由 CCB 批准，进行发布配置会议 CCB 定期举行例会，根据成员所掌握的情况、配置人员的报告和开发人员的请求，对配置管理计划作出修改，并向项目经理负责。配置报告和审计配置人员定期向项目经理和 CCB 提交审计报告，并在配置管理例会中报告项目在软件过程中可能存在的问题和改进方案其 他变更管理 事件触发执行，由 CCB 批准、项目组执行，并执行审计10 配置管理部署模型基本过程 序号 阶段 活动 备注1 获得相应管理权1.1 建立相应负责团队1.2 获得授权和资源 可召开启动会2 评估配置管
19、理现状2.1 绘制和评估当前过程的控制图 可采用 CMM 标准2.2 了解员工对配置管理的态度2.3 了解组织的配置管理技术水平2.4 了解领导期望2.5 编制并评审评估报告 获得“现状信息”3 配置工具选择3.1 编制、评审评估评分表3.2 评估配置工具和供货商3.3 收集其他用户的使用经验4 配置过程定义 制定配置管理过程草案4.1 利用“现状信息”和收集的经验4.2 制定新的过程4.3 评审新过程，并建立新的过程基线5 试点5.1 选定试点项目5.2 确定试点负责小组5.3 定义试点成功标准和进度5.4 试点项目人员培训5.5 试点改进 同时对草案进行改进5.6 试点总结/推广 完成正式
20、过程的发布6 全面实施6.1 组建相应部门和团队6.2 制定各个项目的实施计划6.3 配置管理知识、过程、工具的培训6.4 帮助各个项目向新过程迁移6.5 日常监督、抽查、沟通7 结束 总结、奖励相应操作文件 对应过程：2.2 了解员工对配置管理的态度建立一个 CHECKLIST，来进行调研，如下 序号 调查内容 调查结果1 原来是否有过类似尝试，成功或者失败了2 是否有由于配置管理不好造成的痛苦经历3 对建立配置管理过程是否支持4 是否觉得配置管理过程会压抑创造性5 是否觉得配置管理过程太繁琐6 对配置管理是否有不合理的期望7 是否有些急功近利8 是否对实施配置管理工具感兴趣9 个人英雄主义
21、和分工协作那个是主流对应过程：2.3 了解组织的配置管理技术水平建立一个 CHECKLIST，来进行调研，如下 序号 调查内容 调查结果1 是否已经有了配置管理过程，运作时间2 是否使用了配置管理工具，使用时间3 是否接受了配置管理的专门培训，培训时间4 对配置管理过程的认识程度5 对配置管理工具的使用程度6 企业员工的基本素质和学习能力对应过程：3.2 评估配置工具供应商建立一个 CHECKLIST，来进行调研，如下 序号 调查内容 调查结果1 工具可以解决当前问题，满足当前需求吗？2 产品的市场地位3 产品价格4 与现有环境的兼容程度5 运行能力（峰值情况、成熟性、稳定性）6 是否支持未来
22、需求7 是否具备：工作空间管理8 是否具备：版本控制9 是否具备：配置报告10 是否具备：过程支持11 是否具备：安全和保护12 是否具备：工具集成13 是否具备：构造支持14 是否具备：图形界面15 是否具备：自定义支持16 是否具备：发行管理17 是否具备： WEB 支持对应过程：3.2 评估配置工具供应商建立一个 CHECKLIST，来进行调研，如下 序号 调查内容 调查结果1 配置管理服务从业时间2 成功案例数量和质量3 培训、技术支持队伍4 提供的培训和指导，以及其他服务5 近期关于配置服务的商誉、资产、销售额6 地理位置、服务及时性对应过程：4.2 制定新的过程 1. 配置管理过程
23、至少应当包括的内容：配置标示、配置控制、报告、审计 2. 在考虑工具纳入配置过程中应当考虑下表内容 序号 考虑内容1 从配置过程中分解出那些是事务性、那些是创造性的工作2 考虑事务性工作的繁重程度和精度要求程度，理出一个“自动化优先级”3 根据过程，确定工具可以运用的地方4 根据“自动化优先级”选择那些工具功能进行自动化5 考虑使用工具功能自动化的前提和结果 6 划分出“自动化”和“人工”的接口，并清晰描述7 调整过程要素，适应工具，从而形成一个纳入了工具的配置管理过程8 考虑这个过程的适用性和效益对应过程：6.1 组建相应部门和团队负责配置管理部署和实施的团队必须包括 序号 团队成员 职责和要求1 组长 负责管理小组，并负责配置管理的部署和实施2 技术人员 负责考虑将要和配置工具集成的各类工具之间的接口3 配置专家 配置工具精通、配置管理理论知识熟悉4 过程专家 负责过程建模和主要的过程分析工作5 配置管理人员 负责评审新过程，并提供原来配置管理的经验6 项目经理 负责评审新过程，并提供配置管理适应于项目的参考对应过程：6.2 制定各个项目的实施计划计划应当包括的内容： 序号 计划内容1 目标和完成标准2 投资和收益分析3 阶段划分和进度安排4 资源投入安排5 人员分工和组织6 风险管理
