软件配置管理

软件配置管理1、简介软件配置管理，贯穿于整个软件生命周期，它为软件研发提供了一套管理办法和活动原则。软件配置管理无论是对于软件企业管理人员还是研发人员都有着重要的意义。软件配置管理可以提炼为三个方面的内容：VersionControl-版本控制ChangeControl-变更控制ProcessSupport-过程支持关键活动包括：配置项、工作空间管理、版本控制、变更控制、状态报告、配置审计等。2、软件配置管理技术软件配置管理是一组活动,是设计用来标识变更的工作产品、建立它们之间的关系、定义管理这些工作产品不同版本、控制变更以及审计和报告所发生的变更。每一个涉及到软件工程过程的人员均在某种程度上和SCM相关联。一般情况下需要专门的SCM小组或专门的技术人员来管理和支持。下面通过依次介绍配置管理过程中的主要活动来描述配置管理过程。2.1识别配置项在项目开发过程中，程序、数据和文档都可以作为配置管理的对象，下面以图的形式来列举可能的配置项，如图2-1所示，由图可以看出配置项之间是组合关系或者相互关系。图2-1可能的配置项2.2基于配置项版本控制版本控制是将规程和工具相结合来管理在软件工程过程中所创建的配置对象的不同版本，通过“属性元组”等其它技术来控制完整版本中的“变体”，采用不同的工具不同的技术，版本控制的机制会有一些不同。2.3变更控制变更在软件开发过程中是不可避免的，但过于频繁的变更也会对项目的开发产生负面的影响，如影响项目的进度、浪费人力物力，因此需要对变更进行控制。变更控制可以依照如下的步骤来进行：（1）提交变更请求；（2）审核变更请求；（3）分配和确定任务；（4）提取变更项；（5）执行变更；（6）审核变更；（7）更新配置管理库。整个变更控制的产物主要是变更请求单、变更报告单、工程变更单或变更确认单等。2.4配置审计配置审计一般包括两种，一种是正式的技术评审，另一种是软件配置审计。在正式的技术评审中，将关注已经被修改的配置项的正确性，配置项的评估配置项，以确定它与其他一致性、遗漏及潜在的副作用。正式评审应该针对于所有的变更。而另外一种软件配置审计，是来评估正式评审中没有考虑的那些特征，可以考虑如下方面：（1）工程变更单（ECO）中的相关内容是否已经完成；（2）是否已经进行了正式的技术评审；（3）变更过程中是否遵循了软件工程标准；（4）在对配置项修改的同时，是否有相关的详细注释（comments）；（5）在配置管理工具中是否标注了变更后的配置项状态；（6）所有与该配置项相关的配置项是否进行了相应的更新。2.5发布配置状态报告配置状态报告（ConfigurationStateReport,CSR）是SCM的一个任务，它在中大型项目中扮演着重要的角色，内容可以包括：修改了什么、谁修改的、修改是什么时候发生的以及修改有什么影响，一般情况下，是在一个配置项被赋上新的或已经修改的标识时，或者一个变更被批准时，或者产生配置审计结果时产生配置状态报告。还可以将CSR放于一个联机数据库中，使得开发者、维护者和管理者可以通过关键词等方式去访问。2.6发布管理当项目进行到一定的阶段，可能需要发布一个稳定的或相对比较稳定的版本，这个时候就需要首先制定发布实施计划，然后生成发布准备报告，最后发布完成生成发布报告。3、软件配置管理工具RationalClearCase介绍3.1VOBVOB（VersionedObjectBase），即版本对象库，这是SCM系统的核心，用来存储文件、目录和元数据的永久数据存储池。它能够管理任何表示为文件或目录的对象。它支持的特征包括：（1）可扩展的。ClearCaseVOB中的元素可以从成百上千的文件演变成成千上万的文件和目录，当VOB变得很大时，一个VOB中的文件和目录可以在多个VOB间移动。一个VOB可以被分成多个VOB，多个VOB也可以相互连接。（2）容错性。ClearCaseVOB使用内部数据库，不需要进行额外的数据库管理。（3）分布式。ClearCaseVOB可以分布在网络的不同服务器上，对于最终用户是透明的。（4）可复制。这里的复制是指在不同地理位置上进行完全的复制并保持相互间的同步更新。ClearCaseVOB可以在两点或多点进行复制。可复制是异地分布开发的关键。ClearCase有两种VOB，一种是标准VOB，另一种是项目VOB（projectVOB，简称PVOB），PVOB中包含与项目环境相关的对象。简言之，VOB存储和组织的对象组成了正在开发的系统，而PVOB存储的对象则用来组织和管理正在开发的项目。3.2配置规格（configspec）定义在一个视图中可以看到哪些元素的哪些版本。对于使用UCM模型的项目，ClearCase自动生成配置规格。对于不使用UCM的项目，可以使用默认配置规格，或手工生成配置规格，还可以使用脚本生成配置规格。3.3工作空间在ClearCase中，工作空间被称为“视图（view）”，视图的主要目的是为开发者提供一组稳定的、一致的软件内容，在视图中可以进行变更和执行单元测试。视图依据一组配置规格定义从VOB内所有可用版本中选择文件和目录的合适版本。ClearCase提供了两种视图，快照视图（snapshot）和动态视图(dynamic)。快照视图将文件的拷贝从VOB中下载到视图中，使用一个数据库跟踪下载到本地工作目录中的版本，可以使用配置规格中的load语句来限制哪些元素从VOB拷贝到快照视图中。动态视图通过一个称为“多版本的文件系统（MultiversionedFileSystem，简称MVFS）的虚拟文件系统提供对于元素版本的存取操作，不用将元素拷贝到本地目录中，这个虚拟文件系统直接指向VOB中的元素。当在MVFS文件系统中使用编辑器的工具访问文件时，MVFS会中断文件打开命令，判断用户在什么视图中工作，再判断选择文件的哪个版本正确，然后打开文件的那个版本。动态视图是ClearCase所特有的。3.4项目管理：项目、工作流和活动由于软件开发活动的规模和复杂性，项目管理需要自动化和工具来协助组织和管理大型软件项目。ClearCaseUCM拥有辅助管理和组织软件项目的对象和自动化功能，包括：项目、工作流和活动。项目管理研究所（PMI）学院如下定义项目：在有限资源条件下，人们用于规划、执行和控制活动而付出的努力。项目是为了创建“一个”产品或者服务而付出的“临时性”的努力。“临时性”的含义是每个项目都有明确的开始时间和结束时间。“一个”的含义是该产品或者服务在某些方面与其他的产品或者服务有明确的不同之处。在组织机构的各个层次都在进行着各种项目。项目中可能牵涉一个人或者是成百上千的人。项目可能只花费不足100个小时，也许会耗费超过100000000个小时。项目可能涉及一个机构的一个部门，也可能是跨越组织机构边界的合资或合作伙伴。项目通常是贯彻机构业务策略的要件。ClearCaseUCM中的项目代表一组独立的个人协作生成新的基线，这个基线由一个系统的一个或多个构件组成。使用ClearCase项目，其属性定义了项目范围和工作的对象以及策略，策略包括：项目分配工作的策略，工作空间（工作流和视图）的策略，还有项目成员执行哪些活动的策略。一个工作流为其关联的一个或多个视图定义了工作配置，它包括为创建视图自动生成配置规格所需要的信息。每个项目有一个集成流（integrationstream）和多个开发流（developmentstream）。工作流主要有两个作用：（1）配置与工作流相关联的视图。他们配置视图来选择正确的文件版本，在工作流中从事项目工作。（2）工作流物理地存储开发人员工作在视图中的活动。活动用于跟踪完成一项开发任务的工作。它包括一个文本标题，标题描述了任务和变更集，标题还标识了这个活动中所创建或者修改的所有版本。活动对象的主要任务就是跟踪变更集和结果。3.5版本对象：元素、分支和版本在ClearCase中，元素（element）就是置于版本控制下的文件和目录。每个元素记录了它所代表的文件或目录的版本。这些元素版本被组织成不同的分支，分支就是版本的序列。3.6构件管理：构件和基线将被一起开发、集成、基线和发布的文件和目录聚集在一起就形成了构件，构件通过一个根目录来定义。构件的一个版本就是一个基线。构件基线标识了构件中包含的每个元素的零或一个版本。每个基线有一个用户定义质量和晋升级别。一个公司可以使用ClearCase定义不同的测试水平并标识基线，表示每个基线已通过的测试水平。3.7过程：标签、属性、超链、触发器标签（Label）是一个标签类型的一个实例，并被关联到一个元素的一个版本上。标签类型是一个冠名的标记符，用来标识一组相容的元素版本。在UCM里不需要自己创建和生成标签。属性类型由一对数据/值构成，能够把属性（Attribute）实例关联到几乎所有的ClearCase对象上。超链（Hyperlink）定义对象间的关系。触发器（Trigger）是用户定义的事件，当某些ClearCase操作发生时被激活。触发器有两种不同的类型：事前触发和事后触发。事前触发的触发器在ClearCase事件发生前被激活，可以取消触发的事件，它的典型应用是强制制度；事后触发在ClearCase事件发生后被激活，它的典型应用是通知。4组织和职责4.1配置管理组（CM）配置管理组由配置经理和专职配置管理员组成，配置经理可以由技术经理或其他人员担任。配置经理要熟悉机构的配置和变更管理流程，并且要熟悉所采用的SCM工具。在开发人员开始工作之前，配置管理员一定要确立SCM环境，这有两个关键步骤：建立硬件环境和建立开发环境。配置管理员协同系统管理员评估和分配硬件资源，然后还要在服务器端和客户端安装ClearCase，接下来就可以建立开发环境了。配置管理员要和系统架构师一起确定实施模型、创建存储池、创建产品的目录结构、创建初始的版本化元素。总结后可以列出配置经理的主要工作职能包括以下几点：（1）负责识别项目配置项，形成项目配置项基线计划；（2）负责确定项目配置项标识规定；（3）归并集成；（4）构建系统；（5）申请基线变更；（6）建立发布版本。配置管理员的主要工作职能包括以下几点：（1）制定与维护项目的配置管理计划；（2）建立与维护项目配置管理库；（3）为项目组成员进行配置管理工具与配置库的培训；（4）对已提交的配置项进行配置审计，并建立相应的基线；（5）按照配置管理过程、标准、计划等执行配置管理活动，执行基线与其他配置项的变更控制流程。4.2变更控制委员会（CCB）项目组设立变更控制委员会CCB，成员一般由项目经理（PM）、技术经理（TM）、质量保证经理、配置经理组成，在处理具体配置项变更时，根据具体情况，CCB成员会做相应的变动。本项目的CCB成员包括：A、B、C、D、E和F。CCB成员的主要职能为以下几点：（1）判断变更申请的级别和有效性，并反馈给配置管理员；（2）对变更后的配置项审核，将审核结果填写至变更单中；（3）对评审变更的影响范围、工作量等负责；（4）对变更申请做出裁决；（5）跟踪变更状态，验证变更并负责；4.3组评审委员会（GRB）项目组设立变更控制委员会GRB，成员一般由项目经理、技术经理、质量保证经理、配置经理组成。GRB成员在整个开发过程中，对整个开发的产出物进行评审，具体包括：（1）制定访问控制和开发策略；（2）审核配置管理计划；评审并批准基线的建立；（3）评审在开发阶段所有的产出物；（4）审核发布版本。5、项目命名规定为了管理的规范化，对项目中所使用的标识的命名作出如下规定：（1）技术文档标识规定：CRM24-文档类型名称（2）质量记录标识规定：CRM24-文档类型名称–序号（3）代码标识规定：项目启动阶段，由项目经理或技术经理负责提供，GRB审核。（4）会议记要：CRM24-文档类型名称–开会日期（5）项目周报：CRM24-文档类型名称–提交日期（6）技术讨论记录：CRM24-文档类型名称–讨论日期6、项目软件配置管理活动6.1识别项目中的配置项项目中可以纳入配置管理库