软件配置管理过程及其关键活动 [引]
|
文章出处：《共创软件》 作者：PMT 陈越 发布时间：2005-11-10
|
|
| |
|
|
随着软件产业的崛起，软件工程技术正吸引着越来越多关注的目光。特别是以CMM为代表的先进的软件工程理念在国内也正日益受到业界广泛的重视。 软件配置管理（Software Configuration Management，SCM）作为CMM 2级的一个关键域（Key Practice Area，KPA），在整个软件的开发活动中占有很重要的位置。正如Pressman所说的：“软件配置管理是贯穿于整个软件过程中的保护性活动，它被设 计来（1）标识变化，（2）控制变化，（3）保证变化被适当的发现，以及（4）向其他可能有兴趣的人员报告变化。” 所以，我们必须为软件配置管理活动设计一个能够融合于现有的软件开发流程的管理过程，甚至直接以这个软件配置管理过程为框架，来再造组织的软件开发流程。 本文参照了CMM 2级中软件配置管理的相关的要求，充分考虑了在CASE工具的辅助下实现自动的软件配置管理的可能性，描述了在一个比较理想的软件研发组织中软件配置管理的流程及其关键活动。 一． 角色职责 对于任何一个管理流程来说，保证该流程正常运转的前提条件就是要有明确的角色、职责和权限的定义。特别是在引入了软件配置管理的工具之后，比较理想的状态 就是：组织内的所有人员按照不同的角色的要求、根据系统赋予的权限来执行相应的动作。因此，在本文所介绍的这个软件配置管理过程中主要涉及下列的角色和分 工： 项目经理（Project Manager，PM）： 项目经理是整个软件研发活动的负责人，他根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。其具体职责为以下几项： 制定和修改项目的组织结构和配置管理策略； 批准、发布配置管理计划； 决定项目起始基线和开发里程碑； 接受并审阅配置控制委员会的报告。 配置控制委员会（Configuration Control Board，CCB）： 负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。其具体职责为以下几项： 定制开发子系统； 定制访问控制； 制定常用策略； 建立、更改基线的设置，审核变更申请； 根据配置管理员的报告决定相应的对策。 配置管理员（Configuration Management Officer，CMO）： 根据配置管理计划执行各项管理任务，定期向CCB提交报告，告，并列席CCB的例会。其具体职责为以下几项： 件配置管理工具的日常管理与维护； 提交配置管理计划； 各配置项的管理与维护； 执行版本控制和变更控制方案； 完成配置审计并提交报告； 对开发人员进行相关的培训； 识别软件开发过程中存在的问题并拟就解决方案。 系统集成员（System Integration Officer，SIO）： 系统集成员负责生成和管理项目的内部和外部发布版本，其具体职责为以下几项： 集成修改； 构建系统； 完成对版本的日常维护； 建立外部发布版本。 开发人员（Developer，DEV）： 开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定，按照软件配置管理工具的使用模型来完成开发任务。 二．过程描述 一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。 项目计划阶段： 一个项目设立之初PM首先需要制定整个项目的计划，它是项目研发工作的基础。在有了总体研发计划之后，软件配置管理的活动就可以展开了，因为如果不在项目 开始之初制定软件配置管理计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件配置管理活 动成为一种“救火”的行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功的重要保证。 在软件配置管理计划的制定过程中，它的主要流程应该是这样的： CCB根据项目的开发计划确定各个里程碑和开发策略； CMO根据CCB的规划，制定详细的配置管理计划，交CCB审核； CCB通过配置管理计划后交项目经理批准，发布实施。 项目开发维护阶段： 这一阶段时项目研发的主要阶段。在这一阶段中，软件配置管理活动主要分为三个层面：（1）主要由CMO完成的管理和维护工作；（2）由SIO和DEV具体执行软件配置管理策略；（3）变更流程。这三个层面是彼此之间既独立又互相联系的有机的整体。 在这个软件配置管理过程中，它的核心流程应该是这样的：（1）CCB设定研发活动的初始基线；（2）CMO根据软件配置管理规划设立配置库和工作空间，为 执行软件配置管理就阿做好准备；（3）开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作；（4）SIO按照项目的进度集成组 内开发人员的工作成果，并构建系统，推进版本的演进；（5）CCB根据项目的进展情况，审核各种变更请求，并适时的划定新的基线，保证开发和维护工作有序 的进行。 这个流程就是如此循环往复，直到项目的结束。当然，在上述的核心过程之外，还涉及其他一些相关的活动和操作流程，下面按不同的角色分工予以列出： 各开发人员按照项目经理发布的开发策略或模型进行工作； SIO负责将各分项目的工作成果归并至集成分支，供测试或发布； SIO可向CCB提出设立基线的要求，经批准后由CMO执行； CMO定期向项目经理和CCB提交审计报告，并在CCB例会中报告项目在软件过程中可能存在的问题和改进方案； 在基线生效后，一切对基线和基线之前的开发成果的变更必须经CCB的批准； CCB定期举行例会，根据成员所掌握的情况、CMO的报告和开发人员的请求，对配置管理计划作出修改，并向项目经理负责。
三. 关键活动 1．配置项（Software Configuration Item，SCI）识别 Pressman对于SCI给出了一个比较简单的定义：“软件过程的输出信息可以分为三个主要类别：（1）计算机程序（源代码和可执行程序），（2）描述 计算机程序的文档（针对技术开发者和用户），以及（3）数据（包含在程序内部或外部）。这些项包含了所有在软件过程中产生的信息，总称为软件配置项。” 由此可见，配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。 软件配置项分类软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线（Base Line）”这一概念。IEEE对基线的定义是这样的：“已经正式通过复审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化 控制过程改变。” 所以，根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类，例如：基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。 配置项的标识和控制 所有配置项都都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分）记录对象的标识信息。在引入软件配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中。 所有配置项的操作权限应由CMO严格管理，基本原则是：基线配置项向软件开发人员开放读取得权限；非基线配置项向PM、CCB及相关人员开放。 2．工作空间管理 在引入了软件配置管理工具之后，所有开发人员都会被要求把工作成果存放到由软件配置管理工具所管理的配置库中去，或是直接工作在软件配置管理工具提供的环 境之下。所以为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，对工作空间的管理和维护也成为了软件配置管理的一个重要的活动。 一般来说，比较理想的情况是把整个配置库视为一个统一的工作空间，然后再根据需要把它划分为个人（私有）、团队（集成）和全组（公共）这三类工作空间（分支），从而更好的支持将来可能出现的并行开发的需求。 每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作空间上，例如：对于私有开发空间而言，开发人员根据任务分工获得对相应配置项的操作许可 之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的 元素；而集成分支对应的是开发团队的公共空间，该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限，它的管理工作由SIO负责；至于公共工作 空间，则是用于统一存放各个开发团队的阶段性工作成果，它提供全组统一的标准版本，并作为整个组织的Knowledge Base。 当然，由于选用的软件配置管理工具的不同，在对于工作空间的配置和维护的实现上有比较大的差异，但对于CMO来说，这些工作是他的重要职责，他必须根据各 开发阶段的实际情况来配置工作空间并定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。 3．版本控制 版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型 自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段，我们还需要定义、收集一些元数据（Metadata）来记录版本的辅 助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然如果选用的工具支持的话，这些辅助数据将能直接统计出过程数据，从而方便我们软件过程改进 （Software Process Improvement，SPI）活动的进行。 对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。 4．变更控制 在对SCI的描述中，我们引入了基线的概念。从IEEE对于基线的定义中我们可以发现，基线是和变更控制紧密相连的。也就是说在对各个SCI做出了识别， 并且利用工具对它们进行了版本管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就成为了 软件配置管理的另一重要任务。因此，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制。 在本文的前面的部分中，已经把SCI分为基线配置项和非基线配置项两大类，所以这里所涉及的变更控制的对象主要指配置库中的各基线配置项。 变更管理的一般流程是： A) （获得）提出变更请求； B) 由CCB审核并决定是否批准； C) （被接受）修改请求分配人员为，提取SCI，进行修改； D) 复审变化； E) 提交修改后的SCI； F) 建立测试基线并测试； G) 重建软件的适当版本； H) 复审（审计）所有SCI的变化； I) 发布新版本。 在这样的流程中，CMO通过软件配置管理工具来进行访问控制和同步控制，而这两种控制则是建立在前文所描述的版本控制和分支策略的基础上的。 5．状态报告 配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。 配置状态报告应根据报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。同时也能从中根据开发人员对配置项的操作记录来对开发团队的工作关系作一定的分析。 配置状态报告应该包括下列主要内容： A) 配置库结构和相关说明； B) 开发起始基线的构成； C) 当前基线位置及状态； D) 各基线配置项集成分支的情况； E) 各私有开发分支类型的分布情况； F) 关键元素的版本演进记录； G) 其它应予报告的事项。 6．配置审计 配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。 总之，软件配置管理的对象是软件研发活动中的全部开发资产。所有这一切都应作为配置项纳入管理计划统一进行管理，从而能够保证及时的对所有软件开发资源进 行维护和集成。因此，软件配置管理的主要任务也就归结为以下几条：（1）制定项目的配置计划；（2）对配置项进行标识；（3）对配置项进行版本控制； （4）对配置项进行变更控制；（5）定期进行配置审计；（6）向相关人员报告配置的状态。 在此，我想特别指出的是：由于软件配置管理覆盖了整个软件的开发过程，因此它是改进我们的软件过程、提高过程能力成熟度的理想的切入点。希望本文所描述的 这个软件配置管理的角色分配和工作流程能在实践中不断地得到完善，从而使我们的软件开发活动能够更加有序、高效的进行！ |
|
