软件配置管理过程及其关键活动

《软件配置管理过程及其关键活动》由会员分享，可在线阅读，更多相关《软件配置管理过程及其关键活动（5页珍藏版）》请在金锄头文库上搜索。

1、软件配置管理过程及其关键活动软件配置管理过程及其关键活动PMT 陈越随着软件产业的崛起，软件工程技术正吸引着越来越多关注的目光。特别是以 CMM 为代表的先进 的软件工程理念在国内也正日益受到业界广泛的重视。 软件配置管理（Software Configuration Management，SCM）作为 CMM 2 级的一个关键域（Key Practice Area，KPA），在整个软件的开发活动中占有很重要的位置。正如 Pressman 所说的： “软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计来（1）标识变化，（2）控制 变化，（3）保证变化被适当的发现，以及（4）向其他可能有兴

2、趣的人员报告变化。” 所以， 我们必须为软件配置管理活动设计一个能够融合于现有的软件开发流程的管理过程，甚至直接以 这个软件配置管理过程为框架，来再造组织的软件开发流程。 本文参照了 CMM 2 级中软件配置管理的相关的要求，充分考虑了在 CASE 工具的辅助下实现自动 的软件配置管理的可能性，描述了在一个比较理想的软件研发组织中软件配置管理的流程及其关 键活动。一一 角色职责角色职责对于任何一个管理流程来说，保证该流程正常运转的前提条件就是要有明确的角色、职责和权限 的定义。特别是在引入了软件配置管理的工具之后，比较理想的状态就是：组织内的所有人员按 照不同的角色的要求、根据系统赋予的权限来

3、执行相应的动作。因此，在本文所介绍的这个软件 配置管理过程中主要涉及下列的角色和分工：项目经理（项目经理（ProjectProject ManagerManager，PMPM）：）：项目经理是整个软件研发活动的负责人，他根据软件配置控制委员会的建议批准配置管理的各项 活动并控制它们的进程。其具体职责为以下几项： 制定和修改项目的组织结构和配置管理策略； 批准、发布配置管理计划； 决定项目起始基线和开发里程碑； 接受并审阅配置控制委员会的报告。配置控制委员会（配置控制委员会（ConfigurationConfiguration ControlControl BoardBoard，CCBCCB）：

4、）：负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。其具体职责为以 下几项： 定制开发子系统； 定制访问控制； 制定常用策略； 建立、更改基线的设置，审核变更申请； 根据配置管理员的报告决定相应的对策。配置管理员（配置管理员（ConfigurationConfiguration ManagementManagement OfficerOfficer，CMOCMO）：）： 根据配置管理计划执行各项管理任务，定期向 CCB 提交报告，告，并列席 CCB 的例会。其具体职 责为以下几项： 件配置管理工具的日常管理与维护； 提交配置管理计划； 各配置项的管理与维护； 执行版本控制

5、和变更控制方案； 完成配置审计并提交报告； 对开发人员进行相关的培训； 识别软件开发过程中存在的问题并拟就解决方案。 系统集成员（System Integration Officer，SIO）： 系统集成员负责生成和管理项目的内部和外部发布版本，其具体职责为以下几项：集成修改； 构建系统； 完成对版本的日常维护； 建立外部发布版本。开发人员（开发人员（DeveloperDeveloper，DEVDEV）：）：开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定，按照软件配置管理工具的 使用模型来完成开发任务。二过程描述二过程描述一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段

6、和维护阶段。然而从软件配置 管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和 维护”阶段。项目计划阶段：项目计划阶段：一个项目设立之初 PM 首先需要制定整个项目的计划，它是项目研发工作的基础。在有了总体研 发计划之后，软件配置管理的活动就可以展开了，因为如果不在项目开始之初制定软件配置管理 计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项 目开发状况的混乱并注定软件配置管理活动成为一种“救火”的行为。所以及时制定一份软件配 置管理计划在一定程度上是项目成功的重要保证。 在软件配置管理计划的制定过程中，它的主要流程应该是这

7、样的：CCB 根据项目的开发计划确定各个里程碑和开发策略； CMO 根据 CCB 的规划，制定详细的配置管理计划，交 CCB 审核； CCB 通过配置管理计划后交项目经理批准，发布实施。项目开发维护阶段：项目开发维护阶段：这一阶段时项目研发的主要阶段。在这一阶段中，软件配置管理活动主要分为三个层面：（1） 主要由 CMO 完成的管理和维护工作；（2）由 SIO 和 DEV 具体执行软件配置管理策略；（3）变更 流程。这三个层面是彼此之间既独立又互相联系的有机的整体。 在这个软件配置管理过程中，它的核心流程应该是这样的：（1）CCB 设定研发活动的初始基线； （2）CMO 根据软件配置管理规划设

8、立配置库和工作空间，为执行软件配置管理就阿做好准备； （3）开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作； （4）SIO 按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进；（5） CCB 根据项目的进展情况，审核各种变更请求，并适时的划定新的基线，保证开发和维护工作有 序的进行。 这个流程就是如此循环往复，直到项目的结束。当然，在上述的核心过程之外，还涉及其他一些 相关的活动和操作流程，下面按不同的角色分工予以列出： 各开发人员按照项目经理发布的开发策略或模型进行工作； SIO 负责将各分项目的工作成果归并至集成分支，供测试或发布； SIO 可

9、向 CCB 提出设立基线的要求，经批准后由 CMO 执行； CMO 定期向项目经理和 CCB 提交审计报告，并在 CCB 例会中报告项目在软件过程中可能存在的问 题和改进方案； 在基线生效后，一切对基线和基线之前的开发成果的变更必须经 CCB 的批准； CCB 定期举行例会，根据成员所掌握的情况、CMO 的报告和开发人员的请求，对配置管理计划作 出修改，并向项目经理负责。 综上所述，配置管理的工作流程如图 1 所示：三三. . 关键活动关键活动 1 1配置项（配置项（SoftwareSoftware ConfigurationConfiguration ItemItem，SCISCI）识别）识

10、别Pressman 对于 SCI 给出了一个比较简单的定义：“软件过程的输出信息可以分为三个主要类别： （1）计算机程序（源代码和可执行程序），（2）描述计算机程序的文档（针对技术开发者和用 户），以及（3）数据（包含在程序内部或外部）。这些项包含了所有在软件过程中产生的信息， 总称为软件配置项。” 由此可见，配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。 软件配置项分类软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况下 来控制变化，软件配置管理引入了“基线（Base Line）”这一概念。IEEE 对基线的定义是这样 的：“已经正式通过复审核批准的某规

11、约或产品，它因此可作为进一步开发的基础，并且只能通 过正式的变化控制过程改变。” 所以，根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非 基线配置项两类，例如：基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包 括项目的各类计划和报告等。 配置项的标识和控制配置项的标识和控制所有配置项都都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分） 记录对象的标识信息。在引入软件配置管理工具进行管理后，这些配置项都应以一定的目录结构 保存在配置库中。 所有配置项的操作权限应由 CMO 严格管理，基本原则是：基线配置项向软件开发人员开放读取得

12、 权限；非基线配置项向 PM、CCB 及相关人员开放。2 2工作空间管理工作空间管理在引入了软件配置管理工具之后，所有开发人员都会被要求把工作成果存放到由软件配置管理工 具所管理的配置库中去，或是直接工作在软件配置管理工具提供的环境之下。所以为了让每个开 发人员和各个开发团队能更好的分工合作，同时又互不干扰，对工作空间的管理和维护也成为了 软件配置管理的一个重要的活动。 一般来说，比较理想的情况是把整个配置库视为一个统一的工作空间，然后再根据需要把它划分 为个人（私有）、团队（集成）和全组（公共）这三类工作空间（分支），从而更好的支持将来 可能出现的并行开发的需求。 每个开发人员按照任务的要求

13、，在不同的开发阶段，工作在不同的工作空间上，例如：对于私有 开发空间而言，开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开 发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员 外，其他人员均无权操作该私有空间中的元素；而集成分支对应的是开发团队的公共空间，该开 发团队拥有对该集成分支的读写权限，而其他成员只有只读权限，它的管理工作由 SIO 负责；至 于公共工作空间，则是用于统一存放各个开发团队的阶段性工作成果，它提供全组统一的标准版 本，并作为整个组织的 Knowledge Base。 当然，由于选用的软件配置管理工具的不同，在对于工作

14、空间的配置和维护的实现上有比较大的 差异，但对于 CMO 来说，这些工作是他的重要职责，他必须根据各开发阶段的实际情况来配置工 作空间并定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基 线的推进。3 3版本控制版本控制版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保 证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统 自动记录的版本信息以外，为了配合软件开发流程的各个阶段，我们还需要定义、收集一些元数 据（Metadata）来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。 当

15、然如果选用的工具支持的话，这些辅助数据将能直接统计出过程数据，从而方便我们软件过程 改进（Software Process Improvement，SPI）活动的进行。 对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来 说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变 更控制的流程来进行操作。4 4变更控制变更控制在对 SCI 的描述中，我们引入了基线的概念。从 IEEE 对于基线的定义中我们可以发现，基线是 和变更控制紧密相连的。也就是说在对各个 SCI 做出了识别，并且利用工具对它们进行了版本管 理之后，如何保证它们在

16、复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅 速的恢复到任一历史状态就成为了软件配置管理的另一重要任务。因此，变更控制就是通过结合 人的规程和自动化工具，以提供一个变化控制的机制。 在本文的前面的部分中，已经把 SCI 分为基线配置项和非基线配置项两大类，所以这里所涉及的 变更控制的对象主要指配置库中的各基线配置项。 变更管理的一般流程是： A) （获得）提出变更请求； B) 由 CCB 审核并决定是否批准； C) （被接受）修改请求分配人员为，提取 SCI，进行修改； D) 复审变化； E) 提交修改后的 SCI； F) 建立测试基线并测试； G) 重建软件的适当版本； H) 复审（审计）所有 SCI 的变化；I) 发布新版本。 在这样的流程中，CMO 通过软件配置管理工具来进行访问控制和同步控制，而这两种控制则是建 立在前文所描述的版本控制和分支策略的基础上的。 5 5状态报告状态报告 配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况。这 样的报告应该是定期进行，并尽量通过