配置管理流程

配置管理流程

1　概要

1.1　内容

规范配置管理活动，确保配置项正确地惟一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中创建和维护项目产品的完整性和可追溯性。

1.2　适用范围

对于不一样类别的软件项目，配置管理的流程不一样，可在本流程的基础上进行裁减。

1.3　术语和缩略语

1.3.1　软件配置管理（Software Configuration Management，SCM）

软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能获得精确的不一样版本的产品配置。

1.3.2　配置（Configuration）

配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性。所以配置包括了即将受控的全部产品特性，其内容及相关文档、软件版本、变动文档、软件运行的支持数据，以及其余一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的配置包括更多的内容并具备易变性。

1.3.3　配置项（Configuration Item，CI）

凡是归入配置管理范畴的工做成果统称为配置项（Configuration Item, CI），配置项逻辑上组成软件系统的各组成部分，通常是能够单独进行设计、实施和测试的。一个纯软件的CIs一般也称之为软件配置项（Computer Software Configuration Items，CSCIs）。

配置项主要有两大类：

1) 属于产品组成部分的工做成果，例如需求文档、设计文档、源代码、测试用例等；
2) 项目管理和机构支撑过程产生的文档。这些文档虽然不是产品的组成部分，可是值得保存。

每一个配置项的主要属性有：名称、标识符、文件状态、版本、做者、日期等。全部配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。

1.3.4　基线（Baseline）

在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不一样时间点上经过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每个基线都是其下一步开发的出发点和参考点。基线肯定了元素（配置项）的一个版本，且只肯定一个版本。通常状况下，基线通常在指定的里程碑（Milestone）处建立，并与项目中的里程碑保持同步。每一个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何人随意修改，对其的修改将严格按照变动控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增长和修改的基线内容造成下一个基线。

基线的主要属性有：名称、标识符、版本、日期等。一般将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。

创建基线的好处：

1) 重现性：及时返回并从新生成软件系统给定发布版的能力，或者是在项目中的早些时候从新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队提供一种取消变动的方法。

2) 可追踪性：创建项目工件之间的先后继承关系。目的是确保设计知足要求、代码实施设计以及用正确代码编译可执行文件。

3) 版本隔离：基线为开发工件提供了一个定点和快照，新项目能够从基线提供的定点之中创建。做为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变动进行隔离。

2　相关人权责

2.1　项目经理（Project Manager，PM）

责任：

1) 与CCB协商肯定项目起始基线和开发里程碑；
2) 接受配置管理计划，并按相关规定贯彻执行；
3) 接受配置控制委员会的报告。

权利：

1) 提出配置管理计划的修改要求；
2) 提出管理管理的建议和要求。

2.2　配置控制委员会（Configuration Control Board，CCB）

责任：

1) 制定和修改项目的配置管理策略；

权利：

1) 批准、发布配置管理计划；
2) 创建、更改基线的设置，审核变动申请；
3) 根据配置管理员的报告决定相应的对策。

2.3　配置管理员（Configuration Management Officer，CMO）

责任：

1) 编制配置管理计划；
2) 执行配置项管理方案；
3) 执行版本控制和变动控制方案；
4) 编制配置状态报告；

权利：

向CCB汇报有关配置管理流程中的不符合状况。

2.4　程序库管理员（Program Librarian，PL）

责任：

1) 配置库的创建和权限分配；
2) 配置管理工具的平常管理与维护；
3) 配置库的平常操做和维护；

权利：

1) 各配置项的管理与维护；
2) 对开发人员进行相关的培训。

2.5　开发人员（Developer）

责任：

1） 根据肯定的配置管理计划和相关规定，提交配置项和基线；
2） 负责软件集成和版本生成。

权利：

按照软件配置管理工具的使用模型来完成开发任务。

2.6　测试人员（Tester）

责任：

根据配置管理计划和相关规定，提交测试配置项和测试基线；

权利：

负责软件变动的测试验证。

2.7　软件质量保证员（Software Quality Assurance，SQA）

责任：

负责配置审核并提交报告。

权利：

对配置审核中发现的不符合项，要求相关责任人进行纠正。

3　实施细则

3.1　CCB的成立

3.1.1　项目在设计发注后，由项目经理负责组织成立CCB。

3.1.2　CCB成员组成

CCB成员人数通常为奇数，人数在3～7人范围内。CCB成员通常包括：

1) 项目经理PM；
2) 配置管理员CMO；
3) SQA；
4) 测试人员Tester；
5) 顾客表明；
6) 主要开发人员等。

3.1.3　CCB的决策机制

寻求CCB成员的一致意见。若不能达成一致，可采起由顾客表明作出决策；或采起少数服从多数的原则，由CCB成员投票肯定，投票超过半数即为经过。

3.2　肯定配置策略

3.2.1　配置策略肯定的时机

CCB成立后，由CCB组织会议根据项目的开发计划肯定各个里程碑和开发策略，CMO负责整理肯定的项目基线和配置项列表，并在编制《配置管理计划》时列明，按约定的时机收集配置项和创建初始基线。

3.2.2　配置项的范围

1) 技术文档（Documents）：项目开发计划、需求分析报告、软件设计书、质量保证计划、概要设计书、详细设计书、测试文档、技术报告、用户手册、总结报告等；
2) 程序（Program）：阶段产品、计算机程序、源程序、释放产品等；
3) 工具（Tools）：自动设计工具、开发工具、测试工具、维护工具等；

4) 交互文档（Communications）：与客户或项目组内交互产生文档，如会谈记录、E-mail、会议纪要、MSN记录等。

3.3　制定配置管理计划

3.3.1　《配置管理计划》的编制

一般状况下，由CMO在设计发注后，开始编制《配置管理计划》；若有特殊须要，根据合同或项目要求，由CMO在某一项目或项目的某一阶段开始前制定《配置管理计划》。

3.3.2　《配置管理计划》的内容

《配置管理计划》应包括如下方面的内容：

1) 该项目对配置管理的要求；
2) 实施配置管理的责任人、组织及其职责；
3) 须要开展的配置管理活动及其进度安排；
4) 采用的方法和工具等。

3.3.3　《配置管理计划》的由CCB负责审批。

3.4　配置项标识规则

3.4.1　配置项标识要求

1) 合同有明确标识和追踪要求时，由开发人员按合同要求进行标识，以保证知足合同追踪要求。
2) 在开发过程当中项目组人员提交的配置项，由项目组人员按照本节相关部分标识规则进行标识。
3) 项目组人员将要标识或已标识的配置项提交给CMO归入配置库统一管理，并填写《配置状态报告》。

3.4.2　配置项标识方式

3.4.2.1　标识项

配置项标识属性包括：名称、编号、文件状态、版本、做者、日期等。本文标识规则对名称、编号、文件状态和版本进行了描述和规定。

3.4.2.2　名称

文件名称的标识按文档模板中统一名称为准。

a) 编号

文档编号格式为 CC_XXX_***_$$$_###，其中 CC表示公司，XXX是项目的三位英文字母缩写表示， ***_$$$表示文档类别，###表示文档顺序号。同时对应每一个内容都有固定的一个索引文件CC_XXX_**_$$$_index，目的是为了为本类别下的文件创建一个概要说明列表，保证快速对文档进行识别和检索。

3.4.2.3　文件状态

文件状态分为“草稿”、“正式发布”和“修改中”三种。

修改处于“草稿”状态的配置项不算是“变动”，无需CCB的批准，修改者按照版本控制规则执行便可。

当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据配置变动控制的规则执行。

3.4.2.4　文档版本控制

对于计划性文档、技术文档和用户文档，其版本按修改的前后顺序肯定。新生成的文档第一次发行为初版，修改后第二次发行为第二版，以此类推。

3.4.2.5　发行版本控制

最终完成的软件版本用三位符号表示：“s.x.y”。各符号位的含义以下：

1) “y”为第二次版本号，表示纠正错误时的版本升级，用一位数字表示：“1~9”，对上一次产品或项目中的缺陷作修正，第二次版本号增长；

2) “x”为第一次版本号，表示增长功能时的版本升级，用一位数字表示：“0~9”。与上一产品或项目相比，功能进行了小量的增长或修正时，第一次版本号增长，第二次版本号为零，第二版本号为零时能够省略不写；

3) “s”为主版本号。对产品做重大调整，或与已发行的上一产品相比，在功能与性能上有较大改善时主版本号增长；产品或项目概念全新，第一次完成，版本号为1.0。

3.4.2.6　基线版本标识

内部基线，如计划基线、设计基线等，在版本号前加Build，如Build 1.0；

发行产品基线在版本号前加Release，如Release 2.0。

3.5　配置库管理

3.5.1　配置库（Repository）的分类

配置库分为两类：

1) 文档库（Document Library）：由CMO负责管理，主要使用eSM系统管理除程序之外的文档资料（包括图片等）；
2) 程序库（Program Library）：由PL负责管理，主要使用CVS版本工具对程序代码进行管理。

3.5.2　配置库的创建

1) CCB成立以后，PL便可着手组织创建配置库。全部项目应创建配置库，以便管理各配置项。
2) 文档库空间由eSM系统建立，PL仅建立基线文档库，仅PL能够对其操做。
3) 程序库主要经过设置版本的分支，来实现对配置项权限管理，基本上要为每一个配置项从创建开始就划分红3个不一样的分支（如图1）：

图1　配置库空间分配和版本迁移策略

1) 私有分支（Private Branch）：私有分支对应的是开发人员的私有开发空间。开发人员根据任务分工得到对相应配置项的操做许可以后，他即在本身的私有开发分支上工做，他的全部工做成果体现为在该配置项的私有分支上的版本的推动，除该开发人员外，其余人员均无权操做该私有空间中的元素。

2) 集成分支（Integration Branch）：集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支得到。即各开发人员必须将私有工做空间中的开发成果归并（Merge）到该分支后才能进入下一个开发活动。全部涉及多人协调的开发工做（如集成测试等）都必须工做在这一空间中。该开发团队拥有对该集成分支的读写权限，而其余成员只有只读权限。该分支的管理工做由PL及相关指定人员负责。

3) 公共分支（Common Branch）：公共分支对应的是整个软件开发组织的公共空间。各个开发小组在现阶段的任务完成后，将能够发布的版本归并到该分支上，未来须要查阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人员开放只读权限。该分支的管理工做由PL负责。

上述定义的3类分支以及文档库由CMO统一管理，根据各开发阶段的实际状况定制相应的版本选取规则，来保证开发活动的正常运做。在变动发生时，应及时作好基线的推动。

3.5.3　分配权限

PL为每一个项目成员分配配置库操做权限。通常地，项目成员拥有Add、 Checkin/Checkout、Download等权限，可是不能拥有“删除”权限。PL的权限最高。

3.5.4　配置库的操做与管理

1) 开发人员根据得到的受权的资源进行项目的研发工做，操做配置库，例如Add、Checkin/Checkout、Download等。
2) PL根据配置管理计划建立与维护基线，“冻结”配置项，控制变动。
3) 配置库的检出

当发生变动且变动评审经过后，或者发现Bug且Bug评审经过后，由PL将Common Branch中CIs检出至开发人员的Private Branch上，供开发人员进行变动。

4) 配置库的检入

当变动实施结束或Bug修正和测试结束，并经过配置审核后，由PL将变动后的CIs检入到Common Branch。

5) PL按期清除配置库里的垃圾文件。
6) PL按期备份配置库。

3.6　配置项和基线管理

3.6.1　CMO根据配置管理计划，对配置项和基线进行分阶段管理。

3.6.2　项目启动

配置项包括需求说明、订单及其评审结果等；项目发注后应封锁该子项目，创建发注基线。

3.6.3　需求分析

系统调研后开发人员进行系统分析，并整理需求分析报告。需求分析报告经过评审并需取得客户的肯定。在需求分析报告取得客户的确认后，封锁该子项目，创建需求基线。如需升版则必须经过评审并获得客户的确认。

3.6.4　项目计划

需求分析完成后便可制定项目的开发计划，包括项目整体进度说明、进度跟踪、计划修改、配置管理计划、质量保证计划、测试计划等。项目开发计划评审经过后，封锁该子项目，创建项目计划基线。

3.6.5　系统设计

系统设计可分为概要设计、详细设计和数据库设计等部分。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审经过后，创建设计基线。

3.6.6　编码

编码按功能模块分子项目，即每一个模块计做一个配置项。代码基线分别在单元测试结束后创建Alpha版，Alpha测试后创建Beta版，在集成测试时创建Merge后版。

3.6.7　测试

各测试阶段应提供测试计划、测试用例、测试结果和测试分析报告，项目启动后应提供项目测试计划书，项目验收结束后应提交项目测试总结报告等。配置时应说明测试的版本与编码版本的对应关系。各阶段测试（如单元测试、集成测试）完成后创建测试基线。

3.6.8　交付与验收

在交付前配置审核完成后创建产品基线，产品基线包含程序以及有关文档配置项，包括交付施工文档、工具等。

3.6.9　项目总结

项目总结应通过部门内部评审，包括项目质量报告、测试报告等。

3.6.10　相关资料与培训

相关资料与培训也应做为配置项归入配置管理，此部分包括：

1) 相关法律、法规；
2) 必须遵守或项目组约定的技术规范；
3) 与客户或项目组内部重要的交互信息记录，如Question Sheet、会议记录、会谈记录、e-mail和MSN记录；
4) 必要的业务或技术培训等。

3.7　配置变动控制

3.7.1　变动的分类

软件及其相关文档的变动按照变动的影响范围进行分类：

1) A级：变动会影响系统级需求、外部接口、产品价格或者交付期；这类变动必须通过CCB审核并有客户批准和确认。
2) B级：变动会影响配置项间的功能接口、组件级成本或者项目Schedule；这类变动必须由CCB或上级管理部门的批准和承认。
3) C级：变动会影响配置项内部功能的设计和分配；这类变动能够由配置项的管理人员负责批准。

图2 变动控制流程

3.7.2　变动请求的提出

1) 由发起者（客户、最终用户或开发部门）肯定变动，填写《变动请求/评审单》，描述变动缘由和变动内容，并提交给CMO。
2) CMO对填写的申请表是否清晰、明确和完整性进行审查，若CMO发现变动不明确或不完整，应返回申请表给发起者。CMO对经过审查的变动申请分配变动ID，以便跟踪和记录变动信息。

3.7.3　变动评估

1) CMO将《变动请求/评审单》发送给项目经理（或者其余受权人员），由项目经理负责对变动进行评估。
2) 变动控制的一个重要环节就是变动评估，变动评估要分析每一个变动对系统功能、接口、成本、进度以及约定需求的影响，同时还要分析对软件安全性、可靠性、可维护性、可移植性和性能的影响。
3) 变动评估产生的文档应描述若实施变动必须变动的配置项、文档和资源；变动评估文档在完成变动评估后发送给CMO。
4) CMO收到评估后的《变动请求/评审单》后，更新变动记录，并安排CCB会议日程。

3.7.4　变动审核

1) CCB对提交的变动申请进行审核，并根据变动评估肯定变动的影响级别；CCB审核可能的结果有三种：接受变动；拒绝变动；延期变动。CCB也可能须要更多的变动分析的信息。
2) CCB批准的变动，由CMO将变动项目发送到指定的开发人员（Assigner）进行下一步的实施变动工做；对于拒绝的变动，由CMO将CCB拒绝变动的缘由发送给发起者，并保存《变动请求/评审单》，更新变动记录，关闭变动活动；须要进一步分析的，由CMO将变动项目随同CCB的Question Sheet发送给评估分析人员；对于延期的变动，由CMO对变动的相关文档进行归档，以便在适当时机提交CCB审核。
3) CMO负责整理CCB会议记录，填写《变动请求/评审单》中相应审核项；更新变动记录，若是是接受变动，还需将要变动的CIs状态改成“修改中”；将变动文档分发给相关人员。

3.7.5　变动实施

1) 变动被批准后，PL负责将要变动的CIs以及相关文档迁移至变动负责人的Private Branch上，由变动负责人开始实施变动，并详细记录变动的内容；项目管理部门要对变动的实施进行跟踪。
2) 对于代码变动，必须修改设计、代码、测试以及变动正确性的验证。并且与变动相关的文档必须修订，以反映变动。当变动以及测试完成后，进行Merge。
3) 对于开发计划、配置管理计划发生变动的，项目组人员要按照变动过的开发计划、配置管理计划提交配置项。

3.7.6　变动确认

1) 变动后的程序Merge后必需通过测试组进行回归测试，以确保变动没有引入新的Bug。不会引发程序变动的文档（如计划文档）的变动不需通过测试。

2) 经过Merge后测试后，SQA需对变动进行审核，审核的范围通常涉及如下方面：

• 1) 测试记录；
• 2) 变动请求；
• 3) 配置项的检入及检出；
• 4) 文件的命名；
• 5) 版本的编号。

3) SQA审核后，开发人员才能生成新的版本，由PL更新到基线库中。
4) PL应从新标识全部被影响的配置项及版本。
5) A级和B级的变动项也可能直到下次系统发行版本时才生成。
6) 生成新版本后，CMO负责收集全部变动信息归档，修改变动CIs状态为“正式发布”，关闭变动，并将变动报告发送给发起者。

3.8　配置状态报告

3.8.1　配置状态报告的目的

记录和报告整个软件生命周期演化状态。

3.8.2　配置状态报告记录的内容

配置状态报告记录的内容包括：

• 软件和文档的标识；
• 目前状态；
• 基线演化状态；
• 变动状态；
• 版本交付信息等。

3.8.3　配置状态报告的生成

配置管理报告自第一个基线建立时创建，由配置管理系统生成，及时反映当前配置状态。

3.9　配置审核

3.9.1　配置审核的类别

配置审核分为：

1) 功能配置审核（Functional Configuration Audit，FCA）：审核软件功能是否与需求一致，并符合基线文档要求；一般要审查测试方法、流程、报告和设计文档等。
2) 物理配置审核（Physical Configuration Audit，PCA）：审核要交付的组成项是否存在，是否包含全部必需的项目，如正确版本的源代码、资源、文档、安装说明等等。

3.9.2　配置审核执行的时机

一般选择如下几种状况由SQA负责实施配置审核：

1) 软件产品交付或是软件产品正式发行前；
2) 软件开发的阶段工做结束后；
3) 在产品维护工做中，按期地进行。

3.9.3　不符合项的处理

对配置审核中发现的不符合现象，SQA进行记录，并填写《不符合项报告》，交由责任部门限期进行纠正，SQA负责纠正措施的验证。全部的不符合项报告均关闭后，才能发布新版本。

3.10　发行管理

3.10.1　经过配置审核后，由项目经理负责生产新版本，并由PL检入产品库中，并按照5.4节配置标识规则进行版本标识。

3.10.2　交付管理

这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。交付出去的配置项必须有据可查，避免发生混乱。流程以下：

1) “索取人”向CCB提出交付申请。2) CCB审批该申请。若是该申请不合法（合理），则拒绝交付配置项。若是赞成交付，CCB应给出详细的交付清单。3) PL依据CCB的批示，从配置库中提取配置项交付给“索取人”。4) “索取人”验收后签字。