--软件配置管理基础--
文章出处：51testing / 作者：不详 /
SCM的定义
软件配置管理（Software Configuration Management，SCM），是软件工业化开发和工程化管理的基本手段；是为减少软件开发中出现的混乱，使得软件开发过程有序化，可管理的现实、可靠的手段；是为保证软件配置项的完整性和正确性，在整个软件生命周期内应用配置管理的过程。通常包括配置标识、配置控制、配置状态记实、配置评价、软件发行管理和交付等。
SCM是一种按规则实施的管理软件开发和维护过程以及其软件产品的方法。
SCM是一套用于在开发和维护的各个阶段管理各种程序中间产品的规则 。
SCM的基本术语
1.配置控制委员会（Configuration Control Board，简称CCB）
是指由技术和管理专家组成的，对配置及其管理具有决策权限和职责的小组。
配置控制委员会由相关的管理和技术人员组成，实施软件技术状态控制。
可根据组织和任务建立多级CCB管理，上级CCB负责协调下级各部门CCB的关系，各级CCB将负责不同规模、不同领域、不同阶段、不同程度软件配置控制。
2.软件配置项(software configuration item，SCI)
定义：为了配置管理的目的而作为一个基本的独立单位来看待的软件成分，通常为软件配置中的一个元素。
包括：源代码、目标码、数据库；文档测试用例软件工具、可复用软件、外购软件、用户提供的软件等。
在多数的软件配置管理系统中，最基本的软件配置项是以磁盘文件的形式存放和管理的。
下面是构件的定义：
构件是一个特定的、可文档化的工作产品（文件）集，其中，这些工作产品是在生存周期过程中产生的或使用的。
一个工作产品可以被定义为:
一个由软件开发项目的功能、活动或任务所产生的任任意有形的（软件）项。
工作产品包括管理计划、测试计划、需求规约、设计文档、代码、会议记录、备忘录、进度和预算等。
一个构件可以是一个工作产品或是一组相关的工作产品，在配置管理活动中，这些工作产品被当作是一个单一实体。
下面的工作产品均可作为被管理的构件：
.管理计划（项目、进度、预算、质量保证、测试、SCMP等）；
.需求文档和测试文档；
.用户、维护文档和手册；
.测试文档、测试驱动器和测试数据；
.支撑软件（包括编译器和操作系统）；
.数据字典和各种引用；
.源代码，包括外部得到的、可用的代码；
.可执行程序，包括外部获取的构件；
.链图和构造过程的其它产品；
.产品发布说明，例如版本描述文档；
.创建和运行产品所使用的数据库；
.接口控制文档，在一个系统工程的配置管理（CM）系统中可能不对这类构件进行单独维护；
.任何支持产品开发和运行的项，其中有些项只有可运行的形式。
构件的结构：
它是一个带有目录结构的文件集。
3.软件配置（software configuration，简称SC）
软件配置是指若干个软件配置项在不同时期的组合、结构与关系定义，同时定义了由这些配置项所组成的更大的配置（模块、子系统、系统）。
是软件生存周期各阶段产生的各种形式和各个版本的文档、程序、数据及环境的集合。
理解配置的定义：
在项目开发中的系统、子系统是由一定的软件配置项（构件）通过相应的结构（层次组织结构、通信结构等）组织起来的。
系统引用“配置”实现对相关软件项的组织，完成系统的构造。
配置从“系统结构”的角度来看待项目里的资源，来定义一个系统的建模。
通过配置，用户可以定义系统或子系统，利用配置也可以分层地描述一个复杂的软件系统。
4.项目
项目的定义:
项目是相对于一个独立的待开发的系统的所有被管理资源的存储结构。
一个项目（或子项目）就是一个独立开发的软件系统（或子系统）。
一个项目可以含有一个或多个子项目，以及一个或多个配置项（构件）。
项目可以由实际项目中专门负责项目分解或者概念的组织来定义。项目和子项目的组织完全由项目人员自己设计。
项目的结构：
项目可以包含子项目，并可以多层嵌套，嵌套的层次不限。
同时项目可以包含配置项（构件），并且配置项（构件）与子项目之间的关系可以是并列关系。
5.工作区
指开发人员在其本地工作站上用来存放自己的工作产品的地方（一般为本地机器上的一个磁盘目录）。
这里的开发人员特指要执行“检入”、“检出”等操作的工作人员。
6.软件开发库
在软件生存周期的某个阶段期间，存放与该阶段软件开发工作有关的软件配置项、软件配置及其相关信息的配置库。
通常该类库是部署在软件开发任务的研发部门或者小组的。
7.软件受控库
软件受控库是指软件生存周期某一阶段结束时，存放作为阶段产品而释放的、与软件开发工作有关的软件配置及其相关信息的软件配置库。
软件受控库是一个受控的软件配置项的集合，以便于软件开发、运行及维护。
8.软件产品库
软件产品库是指在软件生成周期的组装与系统测试阶段结束后，存放最终产品而后交付给用户运行或在现场安装的软件配置及其相关信息的更高一级的软件受控库。
9.基线
基线是配置演化过程中的状态标识，是配置在某一时刻的快照，反映了它所描述的系统或者其组成部分在某一时刻的状态；可以将配置的基线理解为配置的版本，是配置演化的里程碑，即软件生命周期内的阶段里程碑。
如何理解基线：
基线是一个或多个构件的集合，所包含的构件版本的内容和状态已通过技术上的复审，并在生存周期的某一步骤被接受。
利用配置来定义基线的组成结构，而通过选取配置中每个构件的合适版本来组成基线。
所以基线是配置的相应组成构件某一时刻状态的快照，反应系统组成某一时刻的状态；一个配置中每条基线是反映系统的不同状态，不同版本，反映配置演化的里程碑，即软件开发过程的阶段里程碑。
基线的组成结构和配置一致，但是基线在此结构的基础上定义了所包含的每一个构件的版本或子配置的子基线。
基线的分类:
基线分为“普通基线”和“受控基线”两大类。
普通基线：通常由项目小组内部控制，不受CCB控制就可以实施变更的基线。
通常，普通基线是项目组内部为了更好地控制进度，在两个受控基线（里程碑）之间划分的一些更细的基线（里程碑）。
受控基线：必须通过CCB的参与和审批才能实施变更的基线，即需要通过变更管理的流程才能改变的基线。
此外，还有产品基线：作为产品发布的基线。
基线管理的相关规定：
一般情况下，在开发库中，我们所创建的基线通常为普通基线。一旦我们要通过实施严格“变更管理”来控制某条基线时，我们就把这条基线定义为“受控基线”。
在受控库中，配置和构件都是受控的，导出和提交的时间由严格的变更流程来控制。
10.基线提升
是指由下级配置库向上级配置库提交已经经过评审确认的基线的过程。
11.基线变更
从某条基线状态为达到下一条基线状态所要进行的变更。
12.配置项变更
指软件配置项为了达到某个状态而进行的变更，可能由项目开发计划的预定任务、消除缺陷或增强请求等引起的。
13.角色
角色是系统访问权限的一个集合。
定义一个角色时，涉及到两方面因素，
一是该角色能够访问的资源，二是该角色在这些资源上的操作权限。
也就是说，角色确定了拥有该角色的用户对哪些资源具有哪些操作权限。
在实际项目工作中，可以针对每一个项目内的不同岗位来定义在这个项目中的不同角色，通过将角色与用户关联可确定该用户对库资源的访问权限。
即在定义好角色之后，再将角色授予用户或用户组，让这些用户来承担这个岗位的工作。
用户组是一组相关的系统用户，可通过用户组的方式一次性给多个用户赋予同一个角色，方便管理。
