软考.项目配置管理CM(Configuration Management)

配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。

在GB/T 11457- -2006中， 将“配置管理”正式定义为:“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”

配置管理包括6个主要活动:

------制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付-----

如何进行配置管理计划
配置控制任务主要有两个:①涉及程序的状态转移管理  ②涉及必须被实现的变更申请的管理

1. 配置项

        GB/T 11457—2006（软件工程术语）对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”配置项的例子有：交付的软件产品和数据，用于创建或支持软件产品的支持工具，供应商提供的软件和客户提供的设备/软件，各类文档，源代码，可执行代码，测试用例，运行软件所需的各种数据等。

        在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。  例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

      所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。

典型的配置项有哪些：
需求规格、设计文档、源代码、测试计划、测试脚本、测试规程、测试数据、项目使用的标准(例如编码规范和设计规范)、验收计划、CM计划和项目计划之类的文档、用户手册之类的用户文档、培训材料文档、合同文档(包括支持工具，如编译器或内部使用的工具)、质量记录(评审记录、测试记录)和CM记录(发布记录、状态跟踪记录)。

2. 配置项状态

配置项的状态可分为“草稿”“正式”和“修改”

 3. 配置项的版本号

(1)处于“草稿”状态的配置项的版本号格式为0.YZ, YZ的数字范围为01~99。随着草稿的修正，YZ 的取值应递增。YZ的初值和增幅由用户自己把握。.

(2)处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1~9。Y为次版本号，取值范围为0~9。

配置项第一次成为“正式”文件时，版本号为1.0。

如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0，1.1，.。当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。

(3) 处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，- -般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。参见上述规则(2)。

4. 基线

     基线通常对应于开发过程中的里程碑(Milestone)， 一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线( Release)，内部开发使用的基线一般称为构造基线( Build)。

        基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段性产品。

        建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。

        作为阶段工作的正式产品，基线应该是稳定的，如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿，就不能作为基线，不能被冻结。
        如果把软件看作是系统的一个组成部分，以下3种基线最受人们关注的：功能基线、分配基线、产品基线。

        （1）分配基线（指派基线）：指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。

        （2）功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。

        （3）产品基线：指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。

        另外，交付给外部顾客的基线一般称为发行基线，内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。

        提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。

5. 配置库--三库配置管理概念

所谓“三库”是指“开发库”、“受控库”以及“产品库”。

• 开发库主要使用对象为产品开发人员。开发库中主要存储和管理产品源代码、需求规格说明、软件设计说明、单元测试资料等，以此构成一系列开发基线。
• 受控库主要使用对象为产品测试人员。测试库中主要存储和管理由研发人员提交的软件程序、版本说明，以及由测试人员编制的测试方案、测试用例、版本测试报告、BUG分析列表等以此构成一系列测试基线。
• 产品库主要使用对象为产品管理人员、产品生产人员。产品库主要存储和管理正式发布的产品版本及其配套资料，以此构成产品基线。产品库是企业最核心的资产，同时也是对接外部市场的唯一出口。

6. 配置控制委员会(Configuration Control Board, CCB),

      负责对配置变更做出评估、审批以及监督已批准变更的实施。
        CCB建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。小的项目CCB可以只有一个人，甚至只是兼职人员。  通常，CCB不只是控制配置变更，而是负有更多的配置管理任务，例如:配置管理计划审批、基线设立审批、产品发布审批等。

7. 配置管理关键活动

1.配置项(Software Configuration Item，SCI) 识别

“软件过程的输出信息可以分为三个主要类别: (1) 计算机程序(源代码和可执行程序)(2)程序的文档(针对技术开发者和用户)，(3)数据(包含在程序内部或外部)。

建立基线控制-打lable
IEEE对基线的定义是这样的:“已经正式通过复审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。”我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类，例如:基线配置项可能包括所有的设计文档和源程序等;非基线配置项可能包括项目的各类计划和报告等。

2.工作空间管理
在引入了软件配置管理工具之后，所有开发人员都会被要求把工作成果存放到由软件配置管理工具所管理的配置库中去，或是直接工作在软件配置管理工具提供的环境之下。
- -般来说，比较理想的情况是把整个配置库视为一个统-的工作空间，然后再根据需要把它划分为个人(私有)、团队(集成)和全组(公共)这三类工作空间(分支)，从而支持并行开发的需求。
每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作空间上，例如:对于私有开发空间而言，开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支.上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素，而集成分支对应的是开发团队的公共空间，该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限，它的管理工作由SIO负责;至于公共工作空间，则是用于统-存放各个开发团队的阶段性工作成果，它提供全组统- -的标准版本，并作为整个组织的Knowledge Base。

3.版本控制
版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯- -性。 Improvement, SPI) 活动的进行。

4.变更控制
在对SCI的描述中，我们引入了基线的概念。从IEEE对于基线的定义中我们可以发现，基线是和变更控制紧密相连的。也就是说在对各个SCI做出了识别，并且利用工具对它们进行了版本管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就成为了软件配置管理的另-重要任务。因此，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制。
在本文的前面的部分中，已经把SCI分为 基线配置项和非基线配置项两大类，所以这里所涉及的变更控制的对象主要指配置库中的各基线配置项。

变更管理的一般流程是:

A) 提出变更请求;
B)由CCB审核并决定是否批准;
C) (被接受) 修改请求分配人员为，提取SCI， 进行修改;
D)复审变化;
E)提交修改后的SCI;
F)建立测试基线并测试;
G)重建软件的适当版本;
H)复审(审计)所有SCI的变化;
|)发布新版本。

5.配置状态报告

配置状态报告应根据报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。同时也能从中根据开发人员对配置项的操作记录来对开发团队的工作关系作一定的分析。
配置状态报告应该包括下列主要内容:
(1)每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。
(2)每个变更申请的状态和已批准的修改的实施状态。
(3)每个基线的当前和过去版本的状态以及各版本的比较。
(4)其他配置管理过程活动的记录。
 

6. 配置审计

配置审计(Configuration Audit)也称配置审核或配置评阶，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一-致性 和完整性。

配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求一-不允许出现任何混乱现象，例如:

• 防止向用户提交不适合的产品，如交付了用户手册的不正确版本。
• 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。找出各配置项间不匹配或不相容的现象。
• 确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。确认记录和文档保持着可追溯性。

1)功能配置审计(Functional Configuration Audit)
  审计配置项的一致性(配置项的实际功效是否与其需求一致)，具体验证以下几个方面。

• 配置项的开发已圆满完成。
• 配置项已达到配置标识中规定的性能和功能特征。---功能和性能
• 配置项的操作和支持文档已完成并且是符合要求的。

2)物理配置审计(Physical Configuration Audit)
   审计配置项的完整性( 配置项的物理存在是否与预期一致)，具体验证如下几个方面。

• 要交付的配置项是否存在。
• 配置项中是否包含了所有必需的项目。.