软件配置管理规范
日期
1999/07/8修订记录修订版本1.00初稿完成。
描述作者审核批准
拟制：审核：批准：部门：部门：部门：日期：日期：日期：
目 录
1、规范概述. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2、定义与缩写词. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3、软件配置管理的目的. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4、适用范围 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
5、SCM 概述. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6、SCM 人员组织与职责. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7、配置管理计划. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8、配置标识. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9、基线建立. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10、配置库系统. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11、接口管理. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12、 配置控制. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2213 、发布（建立）管理. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14、 配置状态发布. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
15、 配置评审与验证. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
16、子合同管理. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
17、培训. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
18、参考文献. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31附录1：SEI-CMM 对SCM 实施情况的检查表. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32附录2：《软件配置管理计划（模板）》. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
软件配置管理规范
1、规范概述
《软件配置管理规范》（以下亦称“规范”）定义了公司对软件配置管理的一般要求，描述了相关的功能、组织、人员及职责，相关流程和操作方法，软件配置管理与软件开发流程各阶段的关系等。每个项目都应该根据规范和《配置管理计划（模板）》制订相应的《配置管理计划》，以指导项目具体的配置管理活动。
下图显示了规范在软件配置管理中的作用方式。
2、定义与缩写词
在本规范中，使用了以下定义和缩写词：
SCM ：
CM:
SCMP:
CCB:
SCCB:
CI ：
CSCI:
FCA:
PCA:
SQA ：软件配置管理（Software Configuration Management）配置管理（Configuration ）, 可能泛指对软件、硬件、和固件的配置管理，根据上下文也可能同SCM 软件配置管理计划(Software Configuration Management Plan)配置控制小组（Configuration Control Board）软件配置控制小组（Software Configuration Control Board）配置项（Configuration Item）软件配置项（Computer Software Configuration Item）功能配置评审（Functional Configuration Audit）物理配置评审（Physical Configuration Audit）软件质量保证 (Software Quality Assurance)
CR:
CMO:
CSA:
VDD:
DM:
SEPG:
BASELINE:变更申请（Change Requist）配置管理员（Configuration Manage Officer）配置状态发布（Configuration Status Accounting）版本描述文档 (Version Description Document)数据管理（Data management）软件工程过程组（Software Engineering Process Group）基线
3、软件配置管理的目的
软件配置管理的目的是在软件产品的整个生命周期中建立并维护软件产品的完整性和一致性。
SCM 是SEI-CMM Level2 指定的6个关键过程域（KPAs ）之一，正确实施的SCM 是对软件开发活动进行质量控制的一个关键过程。SCM 包括在不同时间点上标识软件的配置，系统地控制对配置的更改、并维护在整个软件生存周期中配置的完整性和可跟踪性。软件产品相关文档、资料、数据的残缺与不一致，软件代码当前实现状态不清晰，不同个人对软件的更改冲突等是软件产品开发过程普遍存在的现象，其结果是各类软件故障或造成软件可维护性、可继承性较差，而这些正是SCM 试图解决的问题。
对正在开发或维护的软件的各类更改是不可避免的，同时也是导致各类软件项目延期、超出预算的一个重要原因，对更改控制的失效往往是导致各类软件错误的主要来源，正确实施的SCM 是帮助项目经理管理和控制这些变更的最有效手段。
4、适用范围
本规范适用与公司所有软件或软件相关类项目，规范的作用方式见第一章所述。
本规范适用于项目经理，他们必须对项目的SCM 活动进行计划和监控；适用于SCM 专职人员（SCM 经理，配置管理员等），他们在软件生命周期内具体操作实施SCM 活动；适用于软件开发人员、软件测试人员、SQA 人员，他们将接受SCM 的较大影响。
本规范同时是一部SCM 的辅导性文件，它描述了SCM 的各类概念和定义，实施过程，与软件开发过程各阶段的关系，组织、接口，相关的工具，各类报表的建议模式等。
规范对公司软件开发项目在配置管理方面的总要求是：
1) 向SCM 活动提供足够的资源
2) 任命一个专门小组负责协调和实施SCM 活动-SCM 小组
3) 对SCM 小组人员进行SCM 目的、流程、方法方面的培训，保证他们有能力完成SCM 活
动
4) 对软件人员和其他受影响的组织和个人进行SCM 目的、流程、方法方面的培训，保证他们有能力完成SCM 活动
5) 建立一个小组对项目软件基线进行授权管理-SCCB
6) 对配置管理活动进行规划
7) 按照成文的流程制订SCM 计划，并按此计划实施SCM 活动
8) 对软件产品进行标识、控制、保证可用
9) 按照一个成文的流程记录并发布各配置项的状态
10) 按照一个成文的流程对变更进行初始化、记录、评估、审批、和跟踪
11) 建立接口控制协议
12) 建立配置库系统管理软件基线
13) 按照成文的流程对软件基线进行评审
14) 按照成文的流程对基线的变更进行控制
15) 把基线的内容和状态通知到受影响的组织和个人
16) 按照成文的流程从软件基线库中建立产品并发布
17) 对SCM 活动的执行状态、基线状态，项目趋势制订相应的报告表格并定期发布的相关的组织和个人
18) 度量SCM 活动的执行情况
19) 高层领导定期对SCM 执行情况进行检查
20) 项目经理对SCM 执行情况进行定期和不定期检查
21) SCM小组对软件基线进行定期评审以保证其与规格文档的一致性
22) SQA组织对SCM 执行情况进行检查
5、SCM 概述
5.1 功能概述
软件配置管理是通过在软件生命周期的不同的时间点上对软件配置进行标识并对这些被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。
为了达到上述定义的目的，SCM 要完成四方面的功能：
y 配置标识：标识组成软件产品的各组成部分并定义其属性，制定基线计划。
y 配置控制：控制对配置项的修改。
y 配置状态发布：向受影响的组织和个人报告更改申请的处理过程，通过的更改及他们的实现情况等。
y 配置的评审：确认受控软件配置项满足需求并就绪。
接受SCM 过程控制的软件受控配置项应包括一切可能对软件产品的完整性和一致性造成影响的组成要素，比如项目文档、产品文档、代码、支撑数据、项目编译建立环境、项目运行环境等，所有这些可以由同一套SCM 过程统一管理。
5.2 重要术语
5.2.1 配置与配置项
在本规范中，“配置”和“配置项”是重要的概念，“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的“配置”包括更多的内容并具有易变性。
受控软件经常被划分为各类配置项（Configuraion items, CIs），这类划分是进行软件配置管理的基础和前提，CIs 是逻辑上组成软件系统的各组成部分。比如一个软件产品包括几个程序模块，每个 程序模块及其相关文档和支撑数据可能被命名为一个CI 。一个系统包括的CIs 的数目是一个与设计密切相关的问题，关于怎样将一个软件系统划分为不同的CIs 将在以下有关章节中阐述，注意如果一个产品同时包括硬件和软件部分，一般一个CI 也同时包括软件和硬件部分，一个纯软件的CI 通常也称之为软件配置项（CSCI ）。本规范的CI 一般指CSCI ，软硬件的配置管理有一些相通的地方，但因为软件更易于修改，所以软件配置管理是一个更应该系统化的过程。
5.2.2 基线与基线管理
各CIs 随软件开发活动的进展，会有越来越多的部件进入受控状态。一般地，软件开发过程从概念演绎和需求分析开始，然后是设计，各CSCIs 的编码或写作，集成测试，最后是用户手册的编写等。软件配置管理包括了在软件生命周期的时间分散点上对各CIs 进行标识并对对他们的修改进行控制的过程。在一个开发阶段结束或一组功能开发完成后，要对相应的CIs 进行基线化并形成各类基线。在配置管理系统中，基线就是一个CI 或一组CIs 在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。
每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程，因此基线具有以下属性：
y 通过正式的评审过程建立
y 基线存在于基线库中，对基线的变更接受更高权限的控制
y 基线是进一步开发和修改的基准和出发点。
一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进行功能评审的基础。
5.2.3 版本
版本（版本号）是表示一个CI 具有一组定义的功能的一种标识。随着功能的增加，修改或删除，CI 被赋予不同的版本号。一般在配置标识方案中给出版本标记方法。
5.3 组织与职责概述
一些组织和角色将对SCM 的实施起重要作用。必需有一个全职人员具体操作SCM 过程，包括建立详细的SCM 流程，保证所有变更申请以正确的方式处理，报告配置项的状态，控制各基线的内容等，这个角色就是配置管理员(CMO)，任命专职的CMO 是成功实施SCM 的重要活动之一。
对各基线内容的存储和管理依赖一个称之为配置库的专门数据库系统来完成。配置库中应管理各基线组成部分的正式拷贝，它包括所有基线化的内容，有变更必要时实施check-out 操作，变更完成后实施check-in 操作，配置库由CMO 管理并接受SCM 经理的领导。一些自动化的SCM 工具可以简化版本管理员的操作。
决定一个变更请求是否可接受通常由配置控制组(CCB)负责完成，CCB 一般是由项目经理担任组长，因为他可以调配各种资源，CCB 的其他成员可根据他们对费用控制和各类变更评估的能力等来选定，CCB 的一般运做方式是由组长收到小组其他成员的建议后统一决定对变更的取舍，CCB 流程由CMO 具体操作，他负责接受变更申请及相关分析评估并提交CCB ，记录CCB 的裁决，返回提交者和具体实现者。
5.4 过程概述
SCM 要求有明确的过程指导对基线的建立和控制，防止对各CSCIs 的随意修改，并定期发布基线内容的状态，对某种配置是否包含了其所有必要内容以及这些是否达到了相关的功能和物理的要求进行正式的评审，因此，SCM 包括了四个基本过程：
y配置标识
y配置控制
y配置状态发布
y配置评审
配置标识是软件生命周期里选择定义各类CIs ，建立各类基线、描述相关软件配置项及其文档的过程。首先，软件被分组成一系列软件配置项，一旦各CSCIs 和他们各自应包含的内容被选定，再制定一套对这些进行命名的框架方案，包括对代码、数据、文档进行命名和编号的一整套方案，最后，是对这些CSCIs 的功能、性能和物理特性生成描述文档。
配置控制是对配置项的变更申请进行初始化、评估、协调、实现，包括将通过和实现的变更加入到基线中的更改控制过程。更改控制确保各类变更被正式地初始化、分类、评估、批准/或不批准，获批准的变更请求锝到正确的实现、记录和验证。
配置状态发布是跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报。
配置评审是是验证一个可发布的软件基线是否包含了它应包括的所有内容，这些内容是否已进行功能的和物理的验证的过程。通常包括两类评审，功能配置评审（FCA) 和物理配置评审(PCA)，FCA 确认软件已通过测试并满足基线规定的需求说明，即确保配置的正确性，PCA 确认将发布的软件包含了所有必需的组成部分，包括代码、文档、数据等，确保配置的完整性。
6、SCM 人员组织与职责
6.1 组织CHART 图
可以参考项目计划以CHART 图的方式明确SCM 相关组织及其接口关系。
6.2 项目经理（产品经理）
项目经理对整个项目的进度和结果负责。在SCM 过程中，项目经理的职责定义如下：
y 制定相关项目计划
y 任命SCM 组织和人员，比如SCM 经理，CMO 和各级CCBs
y 帮助制定并评审软件配置管理计划（SCMP ）
y 监督SCM 活动的实施
y 参与各类评审活动
6.3 SCM经理
SCM 经理对SCM 活动的正确实施和结果负责，对于较小的项目，SCM 经理可由项目经理兼任。SCM
经理的职责定义如下：
y 负责制定项目SCMP ，包括流程和相关表格的制订，组织对SCMP 的评审
y 负责对SCMP 的修订，组织相关的评审
y 组织建立各类软件基线
y 指导和监督SCM 活动，对SCM 的执行结果负责
y 参与各类评审活动
y 指导CMO 和CCB 的工作
y 组织相关的技术培训
6.4 配置管理员（CMO ）
y 管理配置库，管理基线库
y 作为CCB 的执行秘书，操作CCB 工作流程y 配置状态记录与发布
6.5 SCM小组
SCM 小组由SCM 经理，CMO ，系统分析等人员组成。小组职责：
y 建立并管理软件基线库
y 起草、维护、发布项目SCMP ， 标准，流程y 对CIs 进行分解和标识y 管理对基线库的操作y 更新基线库y 监督规范的执行情况y 整理和发布SCM 报告
6.6 CCB
CCB 即变更控制小组，由以下各类人员组成：
y 项目经理或SCM 经理兼任组长y CMO （执行秘书）y 系统分析员y 高级程序员y 成本工程师y SQA人员
y 及其他对项目费用和项目总体设计起关键作用的动态人员
CCB 职责：
y 授权对CIs 进行选择，分类，标识y 授权建立各类基线
y 代表各类组织和个人对变更申请进行评估y 授权从基线中的建立产品并发布
CCB 具体运做变更控制流程，对各类更改进行评估，批准或否定各类变更申请（CRs ），
变更控制流程在以下章节详述。
注意CCB 不可以投票的方式决定CRs 的获准与否，CCB 成员从不同的角度对CRs 对项目的影
响进行评估，这里的原则是：
y 提交人必需对CR 进行初步的评估
y CMO对CR 进行预审，防止重复的和不完整的CR 被提交到CCB y CCB各成员对从各方面对CR 提供足够的评估意见
y 由项目经理或接受授权的配置经理根据评估意见对CRs 的获准与否进行最后的裁决，这样
可以保证项目朝着一个既定的目标不断推进。
如有必要，可以设立不同级别的CCB ，他们具有不同的授权，对不同层次的变更申请进行
控制，在这种情况下，项目组可以在配置管理计划中以树状结构说明其从属结构，并在计划中明确说明他们的授权范围。6.7 SEPG小组
SEPG 小组负责监督项目的软件工程规范化程度，对于较小的项目，可以共享公司级的
SEPG 组织，SEPG 对项目的SCM 活动的规范化程度进行监控制和指导，并可协助组织提供相关的业务技能培训，指导使用统一的IT 工具等。6.8 SQA 组织
SQA 组织应以专职的形式进行工作。
SQA 依照有关SQA 规范对项目的SCM 活动的开展情况进行监督，并直接向高层主管汇报。
6.9 软件开发工程师
在SCM 过程的控制之下进行软件开发，文档写作等工作，参与部分单元测试工作，接受各
种SCM 控制。6.10 软件测试工程师
进行系统集成测试，在必要的时候对各类实现的软件变更进行回归测试。
7、配置管理计划
7.1 意义
SCM 的目的是在软件产品的整个生命周期建立和维护产品的完整性。按IEEE 的观点，
SCM 包括两个步骤：计划和实施。制定SCMP 是实现SCM 的第一步，也是重要的一步，SCMP 指导整个项目的SCM 活动，使整个项目的SCM 活动有章可循，否则，SCM 活动将是时间驱动式的，从而可能给整个项目的进度、费用控制和产品的完整性造成危害。
因为每个项目的具体情况不同，项目的大小不同，项目的进度安排不同，重新开发的比重
不同，有些比重较大，有些只是某方面的功能增强，有些可能只是一个系统集成的项目，涉及较
多的子合同管理等，因此没有一个通用的SCMP 模式可以适应于所有的项目，项目SCMP 参照SCMP 模板和配置管理规范，按照规定的流程结合项目实际进行制定，评审，和维护，这是CMM 模型对配置管理的基本要求的之一。
7.2 形式
按照《软件配置管理计划（模板）》的格式、本规范及相应的项目计划制订软件配置管理
计划（SCMP ），可针对项目具体情况对模板进行适当的裁减，但SCM 的四个基本内容即配置标识别、配置控制、配置状态发布和配置评审的内容要阐述清楚。
项目SCMP 将包含的具体的SCM 活动，怎样开展这些活动，相应的组织、人员、职责、流
程，相应的时间安排，相应的资源需求，相应的培训计划等。7.3 配置管理计划与流程
SCMP 应包括开展SCM 活动的各种详细流程（比如变更控制流程），为使SCMP 的维护变得
方便，建议流程以附录或文档交叉参考的方式提供，这样，计划将重点放在“做什么”，流程将重点放在“怎么做”。7.4 制定与评审方法7.4.1 参考有关标准和指南
作为编写SCMP 的第一步，请先参考或复习一遍相关的标准和指南，包括SEI-CMM, NASA,
IEEE ，DoD 的有关标准及本规范，还可以参考一个类似项目的SCMP 的例子。7.4.2 裁减SCMP 模板
可以通过对《软件配置管理计划（模板）》进行适当的增删得到你自己的模板，这是你下
一步工作的出发点。7.4.3 搜集素材
参照已经确定的模板，你应该可以确定你应该准备哪些素材来对模板进行展开，比如你需
要制定哪些流程，怎样的标识方案，输出哪些状态报告等。参照整个项目计划和测试计划，与相关的人员和组织进行讨论，逐步细化每一项内容。7.4.4 递归
完成了上一步的工作，与模板进行比较，检查是否所有方面的内容都有了足够的材料和内
容，如果不是这样，继续对有关方面的内容进行准备。7.4.5 收集意见
SCM 将涉及很多组织和个人，制订SCMP 的目的之一就是要建立他们之间的一种通信共同
语言和承诺，征得他们对SCMP 的理解和认同是至关重要的，所以可以将按以上步骤制订得到的SCMP 以草案的方式发给他们，征求他们的改进意见，对SCMP 进行优化，然后提交评审。7.4.6 制定评审流程
7.5 维护与控制
随着项目的进展，要对SCMP 进行不断维护工作，注意SCMP 属于受控的CI 之一，因此对
SCMP 的更改按CCB 规定的变更处理流程进行。
8、配置标识
配置标识是对软件配置进行管理的前提和基础。配置标识包括了软件配置项的选择、命名
和描述的过程。选择涉及将软件分解成配置项，命名涉及对代码和文档开发出一套命名和编码的框架方案，描述涉及对配置项特性进行文档化描述的过程。
8.1、建立分类
一般地，先建立CIs 的分类（这些可看作高层的CIs ），建议一个软件系统以以下方式进行
CIs 分类，在配置库中以目录的方式体现，每个目录要有一个CI . LST说明文件，说明此这组CIs 的公共特性、CIs 清单及描述，及与其他分类的关系。
分类名计划软件需求文档设计文档程序代码第三方程序代码
测试工具用户文档目标代码运行环境安装盘
目录名Plan SRD SDD Source VendorSrc Test Tools UD OBJ Platform Install
描述
包括各类项目相关计划，比如项目计划，配置管理计划，SQA 计划，测试计划等需求管理数据库，包括各类需求规格，需求分析报告，需求更改记录等
包括各类过程设计文档，比如概要设计文档，详细设计文档，接口协议文档等所有开发的源代码，包括各类支持数据，
二进制文件
由供应商提供的源代码，并接受供应商的维护
包括测试代码，测试用例设计，测试报告，问题更改单等
支持软件开发、建立、维护的工具管理，比如语言开发工具，编译和建立工具，测试工具，配置管理工具等包括用户手册，安装指南等包括目标代码，可执行代码等
包含系统运行环境的相关内容，比如系统运行平台，环境设置要求等
包含安装到运行平台上的软件系统，安装说明，发布说明，运行环境要求
CI.LST 文件格式：
公共特性：描述该类CIs 的分类公共特性，在系统中的位置等CI 1-n:
CI 标识版本号
责任人，联系电话功能列表
功能1功能2...... 功能n
CI 关联
说明与该CI 有关的其他CI 及其关联关系
修改记录
序号变更日期
变更部分（节号，表格号，附录号等）变更类型（A ：增加变更描述CR 编号
也可将CI 特性部分与每个CI 分别写成VDD 文档。
8.2 CSCIs 选择
接下来要把软件系统通常分解成一系列CSCIs ，这些CSCIs 将被独立写作、开发和测试，然
后在系统集成时将他们组合在一起，对SCM 系统而言，这些CSCIs 是分离的受管理的实体。
CSCIs 的划分与系统设计密切相关，也可能由相关项目合同来确定。一个通用的原则是，
一个CSCI 是一个可以独立设计、实现和测试的功能实体或独立模块。CSCI 划分也可采用的分层的方法，比如整个需求文档可以作为一个CSCI ，各个需求单元可以看作其从属CSCIs ，对于复杂的系统，可以用配置树的方式表示CSCIs 的层次划分。
对代码进行CSCI 分解的其他一些可参考的规则包括：
M ：修改
D ：删除）
y 一组对整体性能至关重要、或涉及较大风险，或对系统安全有重大影响的软件。y 一组具有高度复杂性，涉及新技术，或对性能有严格要求的软件
y 一组涉及较多于其他软件的接口，特别是与第三方软件模块接口较多的软件y 一组可能修改可能较多的软件y 一组涉及特定功能或应用的软件y 一组将安装在异质平台上的软件y 一组计划重用的软件
y 尽量减少同级CIs 之间的偶合性，CIs 之间的接口定义尽量简单y 通常，在产品描述清楚和接口清晰的前提下，CIs 越少越好。
8.3 命名约定
每个软件部件都必需被唯一地标识，这个唯一的标识被用于跟踪和报告该CSCI 的状态。一
般地，每个CSCI 被赋予一个CSCI 标识符（ID ）。
SCMP 应制定完整的CI 命名约定，包括对文档、代码、数据、CRs 、基线等的命名方案等。以下是建议的一般形式：
y 文档
使用“产品缩写-文档类型-内部编号-版本号”的方式命名：产品缩写：由4位字母或数字组成，一般遵循公司的统一命名文档类型：由3-4位字母组成，一般使用国际惯例的英文缩写
内部编号：由项目经理和SCM 经理制定的用于对同类文档进行分类的项目内4位编码，必
要时可以对位域进行定义
版本号： 由项目经理和SCM 经理制定的用于标识文档更新状态的版本号，当使用SCM 工具
进行版本标识时，此部分可以在归档时加入。
文档类型如下：
SCMP ：软件配置管理计划SDD SDP SPP SPS SRS STD STP STR
：软件详细设计文档：软件开发计划：软件测试方案：软件产品规格：软件需求规格：软件概要设计文档：软件测试计划：软件测试报告
SQAP ：SQA 计划
y 代码
使用“产品名-部件名-模块名”的方式进行命名。
产品缩写：由4位字母或数字组成，一般遵循公司的统一命名部件名、模块名：根据软件设计文档对软件结构的划分选择缩写名。
y CRs
结合变更管理软件（ClearQuest ，Notes 等）制定对每一个CR 的标识方案，保证每一个CR 有一个唯一的索引ID
y 基线
由基线类型和版本号标识。基线的建立和类型详见第9章。
8.4 版本号
项目组要制订对CSCIs 和基线的统一的版本号命名惯例，一般以“主版本. 子版本”的形式
表示，对于支持版本号数据类型定义的SCM 工具（比如ClearCase) ，由SCM 小组定义统一的版本号数据类型在项目内统一使用。8.5 CSCIs 与SCMP 维护
配置标识是后续配置管理的基础，也是配置管理的重要内容，但在项目的初期，制订详细
的配置标识方案可能因为系统设计原因出现困难，这时可以先制订关于配置标识的指导性原则，随着项目的进展，再完善详细的标识方案，同时更新配置管理计划。
9、基线建立
基线建立属于配置标识的范畴，这里单独描述，并描述其与软件生命周期的关系。
9.1 基线的种类
以瀑布模型为例，在这个典型的软件生命周期中，将涉及以下软件基线：需求基线：Software Requirements Baseline分配基线：Software Allocated Baseline设计基线：Software Design Baseline代码基线：Software Code Baseline产品基线：Software Product Baseline
接受基线：Software Accepted (AS-BUILD) Baseline
注意，本章只是从配置管理的角度对各阶段的活动进行概述，详细的软件开发活动参见相
关软件开发流程文件。9.1.1 产品概念与初始阶段
在产品概念与初始阶段，将进行软件产品的概念分析，形成相应的产品概念，接着进行相
关的可行性分析，如果这些获得通过，则制定并评审相应的项目计划，任命SCM 经理和CMO ，CMO 开始制定相关的初步的配置管理计划并提交评审，输出初始需求基线 （Initial Acquirer'sBaseline ）并通过评审，包括以下方面的内容：
y 可行性分析报告与立项报告 y项目计划y SCMP草案y 系统需求
y 如果有供应商，则供应商的相关项目计划应加入到此基线中，这些计划同时接受供应商
的维护
9.1.2 需求分析阶段
在需求分析阶段，将根据系统需求，形成软件需求，根据软件需求制定初步的测试计划
（Test Plan)，以决定如何对相关需求进行测试，要进行相关的风险分析，并建立风险控制策略，细化相关的标准、方法、流程、并且要将这些文档化，制定详细的配置管理计划（SCMP ），建立SCM 组织，任命SCM 人员，并在SCMP 中明确他们的职责，详细的SCMP 完成后，作为配置项加入配置库进入受控状态。
输出软件需求基线（ Software Requirement Baseline）并通过评审，包括以下方面的内容：
y 软件需求规格y 接口需求规格y 软件开发计划y SQA计划
y SCMP
SRB 是以后进一步开发活动的出发点，对此基线的变更要通过CCB 要求的正式流程进行。
9.1.3 概要设计阶段
在概要设计阶段，对软件产品进行概要设计，包括确定软件的整体框架，确定主要的软件
模块，分配软件需求到各软件模块等。
输出：软件分配基线 (Software Allocated Baseline)并通过评审，包括以下方面的内容：
y 概要设计文档y 需求分配文档y 软件建立计划(build)y 软件测试计划 (high level)y 更新的上一基线的内容
SAB 是以后进一步开发活动的出发点，对此基线的变更要通过CCB 要求的正式流程进行
9.1.4 详细设计阶段
在软件详细设计阶段，将扩展概要设计到单元级(unit level)，完成接口控制文档，修订测试
计划，评估各种约束条件，落实测试人员和资源等。
输出软件设计基线（Software Design Baseline）并通过评审，包括以下方面的内容：
y《软件详细设计》，软件详细设计定义了各CSCIs ，并细化到模块级，以及模块间接口，
使得进一步的编码和测试可以进行。
y 软件支持数据y 用户界面
y 更新的上一基线的内容
SAB 是以后进一步开发活动的出发点，对此基线的变更要通过CCB 要求的正式流程进行
9.1.5 软件实现阶段
在软件实现阶段，主要完成编码、单元测试和相关的代码描述文档。
输出软件代码基线（Software Code Baseline）并通过评审，包括以下方面内容：
y 软件代码（代码首次进入基线库）y 代码描述文档y 用户手册y 系统集成测试计划y 软件支持数据y 更新的上一基线的内容
SCB 是以后进一步开发活动 的出发点，对此基线的变更要通过CCB 要求的正式流程进行另外，SCB 具有如下特点，即他们是内部基线，并是分步完成的，因此可以有多个代码基
线。
9.1.6 系统集成与测试阶段
在系统集成与测试阶段，主要完成系统集成，集成测试，包括进行功能和性能测试，并进
行交付准备，FCA （配置功能评审）和PCA （配置物理评审）也在这个阶段完成。
输出软件产品基线 （Software Product (or Integrated) Baseline）并通过评审，包括以下方面的内容：
y 测试后的代码y 所有文档的最后版本y 更新的上一基线的内容
9.1.7 软件发布阶段
在软件发布阶段，执行正式的软件发布流程，如有必要，将进行产品功能演示，并正式提
交软件产品给用户，产品进入用户配置管理系统。
输出产品接受基线 （Software Accepted (AS-BUILD) Baseline）并通过评审，包含更新的软
件产品基线内容。9.1.8 软件维护阶段
在软件维护阶段，主要进行bug fix，功能增强和版本升级等工作，输出新的产品基线。需要注意的是：
y 一切变更按CCB 要求的正式流程进行
y 如果必要（重大需求变化等），迭代部分或整个软件开发周期阶段
9.2 基线的动态演变
配置管理的关键活动就是管理变更过程，跟踪各类变更的实现情况，确保软件配置在其生
命周期的任一时间点上都是清晰明确的。这包括明确定义各基线的内容并跟踪对基线的所有变更，这条原则适用于所有类型的基线。
一个新的升级或发布形成一个新的基线，要检查评审基线的所有内容以保证其与前一基线
的一致性，同时该基线被赋予新的类型或版本号，下图显示了基线的动态演变过程。
9.3 基线的建立和评审流程
以下说明一个基线的建立和评审流程。
10、配置库系统
10.1 统一工具和使用规范
配置库系统是实现配置管理的辅助自动化工具，它提供对配置项的增量式存贮和对各类流
程（比如变更控制流程，配置状态发布）的支持。项目应根据其规模和配置管理的复杂程度使用
专门的配置管理系统建立配置库系统。公司将统一配置管理工具的选型，并将制订相应的工具使用规范，项目组使用指定的配置管理工具并遵循相应的规范建立和使用配置库系统。10.2 库结构设置
为了体现对配置项的分层控制，在逻辑上，将配置库分为三类：开发库，基线库，产品
库，对应于IEEE 建议的动态库，受控库，和静态库。
y 基线库：包含通过评审的各类基线，各类CRs, 及变更统计数据。
y 开发库：程序员的工作空间，始于某一基线，为某一目的的阶段开发服务，最终通过正
式的评审过程归并到某一基线，回归到基线库。
y 产品库：保存各基线的静态拷贝，基线库进入发布阶段形成产品库，可以在产品数据库
中形成相应的拷贝。
10.3 权限设置
SCM 经理应对各类配置项和配置库针对不同的用户设立不同的权限，以下是一些一般的规
则：
y 原则上，开发人员对开发库操作有权，管理员对基线库操作有权，产品库的维护属于公
司行为。
y 将用户分组，在工具支持的情况下对操作类型进行分组，以分组的的形式进行权限管
理。
y 对各类CSCIs ，严格控制写（
check-in ）权限，只有CSCIs 的作者才拥有写权限。y 只有CMO 才拥有对基线库的操作权限（check-in/check-out)，开发人员的操作只限于开发
库。
y 于CSCIs 无关的人员操作无权。
y 必要时，将权限设置制作成如下的权限设置表格，以方便管理。
10.4 工具实现
对CRs, 变更数据的管理使用SCM 工具的变更管理工具实现。
用SCM 工具的分枝和归并功能实现基线库、开发库和产品库的分离：版本树主干作为基线
库，在进行功能增强和错误、缺陷修改时建立相应的版本分支做为开发库，修改完成后归并到基线库中。
11、接口管理
接口管理的目的是保证产品各软件、硬件组成部分间的协调性和互用性。对各类接口协议
进行控制，是软件配置管理中最重要的任务之一。
在软件需求基线制定阶段，应分析接口需求，确定接口协议文档和对文档的撰写、修改管
理规范。软件接口协议有以下几类：
yyyy
用户界面：指子系统与用户、维护人员、设计人员间的操作约定系统间接口：软件系统间的通信协议、数据包格式、数据定义等约定系统内部接口：系统内部各子系统的各种连接约定标准程序接口：指软件系统与标准子程序库间调用约定
接口管理要求：
yyy
确定接口说明文档，作为CSCI 进行管理，确保文档的完整和一致性性对已交付的接口说明文档进行修改必须按确定流程进行接口修改必须按确定流程及时发布到受影响的相关组织
12、 配置控制
配置控制是系统控制对基线化的代码、文档、支撑数据的修改的过程，包括评估，协调，
审批，跟踪实现的过程。变更控制过程保证变更被正式地初始化，分类，评估，批准或否定，归档，实现，测试，并最终实现与一个基线的集成。
变更可以分为两类，功能增强（优化）和错误修改，功能增强类变更主要来自开发人员和
设计人员，错误修改可能来自测试和用户、市场部门，两类修改都要接受配置控制过程的控制，但评审的侧重点可以有所不同。
一个正式的变更控制过程确保只有被正式批准的变更才可以被实现并添加到一个基线化的
代码或文档中去，它包括以下这些步骤：
y 变更申请初始化y 分类y 变更评估y 分派y 实现y 验证y 基线变更
以下具体描述：
12.1 变更申请初始化
对代码或文档的变更申请可能来自不同的来源。一个(CR)可能来自一个潜在的用户，系统
分析员，测试人员，或软件供应商。每一个项目都应该建立起一套CR 提交表格，这里有一些一般的形式可以参考，实际的CR 表格形式必需与SCMP 计划保持一致，有些变更管理工具也提供一些一般的电子表格形式，每一个项目还应该任命一个专门人员（比如配置管理经理或CMO) 来受理CR ，包括赋予CR 一个唯一的跟踪编号和分类号，并实际执行变更流程。
CMO 接受CR, 检查其清晰度和完整性，如果CMO 认为该CR 不够完整，他可以将它返回给
提交者，错误还有可能被重复报告，这些也应由CMO 予以屏蔽，然后，CMO 赋予该CR 一个唯一的跟踪编号，并在变更管理库中形成相应的记录信息。
12.2 分类
变更申请按照其潜在的影响和所要求的审批权限进行分类。
Level I ： 对系统级需求，外部接口，系统成本和系统开发进度产生重大影响的CRs 。Level II： 对内部接口，内部功能分配或模块级费用和进度产生影响的CRs 。Level III： 只对CSCI 内部设计和功能分配产生影响的CRs 。
对I, II类CRs ，通常需项目经理以上的人员进行审批，对III 类CRs ，可在CSCI 管理级获得审
批。
变更申请地分类可以由提交者建议，然后CMO 或CCB 对CR 的影响进行复审并给出最终地
分类编号。12.3 变更评估
配置控制过程的一个重要方面是它支持对变更申请进行充分的分析评估，这涉及它对系统
性能，接口，可用性，成本，进度，合同的影响程度，还应对它对软件产品的安全性，可靠性，可维护性，可移植性及效率的影响程度的评估。项目CMO 将CR 分派到CCB 进行这类评估。在有些情况下，CR 在被分析前先经过某些小组进行预审，这可以节省一些不大可能被通过的CR 的评估开销。
评估将产生一个报告，其中包括对变更的描述，受影响的CSCIs 及相关文档，以及所要求
的资源情况等。这个报告成为CR 的一部分。评估完成后，CR 返回CMO 。
变更评估检查表：序号[**************]
项目规模期限复杂性资源影响费用影响测试需求
风险外部影响资源需求项目影响替代方案实现状态
说明
更改范围的大小更改完成的时间要求实现的复杂程度
对CPU, 内存，网络等的资源影响
对项目和产品费用的影响
对测试的要求程度
相关的风险分析，比如是否涉及到关键模块
和技术
对用户，市场策略的影响
对项目资源，比如人员技能、软硬件资源的
需求
对项目当前和后续工作的影响
有无更好的替代方案该更改是否已经进行等
12.4 变更分派
将CR 分配到基线化的CIs 的工作由CCB 完成，CCB 根据CR 分析报告评估一个CR 的必要性和
代价，CCB 可能批准，不批准或推迟一个CR ，也可能返回提交者要求补充更多的信息或分析。
获准的CR 发回CMO 执行下一步的流程，被拒绝的CR 连同CCB 的拒绝原因一起发回提交
者，需要进一步分析的CRs 连同CCB 的问题清单被返回分析小组或提交者，被推迟的CRs 先归档，在适当的时间进行处理。
如果不需更高一层的CCB 进行审批，CMO 就将被批准的CRs 发到相应的开发团队或CI 负责
人，否则CR 包被发送到更高一级的CCB 进行进一步的审批。
CMO 做为CCB 的执行秘书，负责记录当前CR 的状态并发布相应的简报，这些信息同时被
归档。12.5 变更实现
获得通过的CRs 可以直接作为变更授权表，或由CMO 据此准备更改任务单，有时还包括制
定对相应代码和文档的修改指导文件。
开发组要安排实施变更的必要资源，他们必须从配置库获得将被变更的CIs 的正式拷贝。对
代码的修改涉及设计，编码，测试，验证的过程，并且要对可能受影响的文档进行更新，一旦更改完成并通过了单元测试，并对相关文档进行了更新，所有这些被赋予新的版本号并返回到配置库置于受控状态。12.6 验证
对于已完成并进行了单元测试的更改，还必需进行CSCI 级的测试，这往往需要重新运行测
试计划中的相关测试用例或开发新的测试用例并添加到测试计划中去，回归测试用例也需重新进行以防止更改引入新的错误，一旦这些完成，开发组将测试报告提交回配置库，更改的配置项被编号为新的基线版本。
CR 实现和测试完成后，CMO 将对这个过程进行记录并在更改跟踪数据库中存档。
12.7 基线变更控制
变更控制在代码和数据修改完成并测试，以及相应的文档得到相应的更新后才要完成。为
了减少版本数和软件部件的发布频率，对软件的变更常常被分组为不同的发布版本，每个发布版本包括了经过测试的代码和文档并以一个基线的形式出现，详见基线一章。
12.8 软件变更申请CR （问题报告）单
以下描述一个CR 可能包含的各要素，一个项目可以根据具体的情况进行适当的裁剪。
项目名
SCR NUM
提交者提交日期项目名称CIs 版本
项目描述
SCR 编号，由SCM 工具自动生成或由CMO 赋
予，作为该CR 的跟踪编号提交者姓名
该CR 的初始提交日期该CR 涉及的项目名称该CR 涉及的软件或文档名
涉及的CIs 的版本号，可能包括基线版本号，CI 的主、子版本号
CR 类型有三种CR 类型：1-开发类2-问题类3-功能增强类
或按12.2 的分类进行分类并给出分类描述
简要描述对问题的简要描述，因为可能在有关列表中进行显示，此项以不超过30个字对问题进行提示性描述
详细描述重要程度
CCB 意见CCB 级别提交至
要求完成日期解决方案描述影响的软件模块I&T意见及日期SCM 意见及日期实际完成人及日期
归档人及归档编号（SCA Reference No）SQA 意见及日期
对问题的详细描述
重要程度（优先级）分为5级：1-最重要 （Critical ）
2-很重要（Very Important）3-重要（Important ）4-一般（Inconvenient ）5-不重要（Interesting ）配置控制组处理意见配置控制组的权限级别处理人
对此CR 的解决方案的简要描述代码检查与测试部门意见与签署日期
给出配置状态报告单编号
软件质量保证小组签署意见和日期
12.9 CCB的组成与职能
一个项目要详细定义其CCB 的组成人员和相应人员的具体职责，他们是变更控制流程的具
体操作者，根据评估的CR 的类型，CCB 可以临时召集其他相关人员参加评审。12.10 变更处理流程
13 、发布（建立）管理
项目组要制定成文的产品发布（建立）流程保证发布软件包的正确性和完整性。发布分为两类，内部发布和市场发布，内部发布是项目阶段性需求，公司组织间的建立发
布过程，外部发布面向市场和用户。两类发布均应接受发布管理流程的控制。13.1 发布（建立）流程
13.2 版本描述文档（VDD ）
发布软件包中的版本描述的内容如下表所示：
序号123
项目
建立编号专用申明包装说明
456
功能说明用户注意事项
bug list
789
修正软件包组成安装说明
1011
公司名称发布日期
内容
提供建立编号，比如：Build xxxx
如果本次建立是专为某个用户或某一类用户，在这里给出特别说明。
描述软件包的介质类型，数目及每一个介质中包含的软件内容列表，每一项文件的性质和在软件包中的作用。如果包括多各介质（比如磁盘，Zip 文件），要分别列表说明。
如果本次发布中包含了从前版本中没有的功能，要予以列表简要描述。
列出在安装和使用中要求用户要特别注意的事项，比如硬件限制、操作方式的改变等。
列出已知的在本次发布中的软件缺陷，尚未改正的错误和有关约束，这样可以让用户详细了解本次发布的状态，并避免他们重复提交问题报告，同时阐述相应的责任声明。
列出本次发布中已经解决的问题报告
列出软件包的逻辑组成，可以细致到文件级，这样可以方便用户对软件包的备份维护。
说明安装中要注意的事项，特别是安装说明书付印后的变更事项，主要强调在每一步安装过程用户要准备的必要信息数据。
写明公司的名称，地址，联系电话，Email 地址，服务热线等。
说明本次建立的操作时间
13.3 介质标签
如果发布以磁盘或磁带等介质发布，在介质标签上要至少包含以下内容：
序号123456项目介质类型介质序号内容建立号VDD 公司名称
说明
使用介质类型
比如五张盘的第一张：1/5说明包含的软件内容同VDD
说明VDD 的文件名或文件编号
写明公司的名称，地址，联系电话，Email 地址，服务热线等。
14、 配置状态发布
14.1 CSA的内容
配置状态发布（CSA ）的目的是在软件的生命周期内记录并跟踪演变中软件的状态，并将
这些通知到受影响的组织和个人。它提供对基线化的需求、代码、支撑数据、和相关文档的可溯性。它记录基线的具体内容以及相应的演变记录。它记录对一个基线的所有变更，无论他们是错误更改或者是功能性能增强的结果。
从第一个规格说明基线化（比如软件需求规格）开始配置状态发布功能即开始运做并贯穿
软件整个生命周期，这些统计信息是下一步进行功能配置评审和物理配置评审的重要资料，配置状态统计给出每一个发布的内容列表。
CSA 的内容包括：
y 一个通过评审的标识并描述配置项功能和物理特性的文档列表y 提交的变更申请的状态y 通过的变更申请的实现状态y 所有配置项的功能和物理特性y SCM的执行状况
14.2 CSA流程
14.3 CSA报告
存在两类CSA 报告，阶段性报告和基于事件驱动的报告，下表列出了一个项目可能输出的
CSA 报告及其内容描述。
编号[1**********]112
报告类型规格更改报告软件更改报告CIs 列表
合同变更报告CR 状态报告
问题报告状态报告变更实现状态建立记录报告维护记录评审报告项目趋势报告
描述
当前版本，相应更改（提交和批准的）列出所有CIs 的所有组成部分的清单跟踪所有合同条款的变更
y跟踪所有变更请求的状态，从提交到
完成
y跟踪所有问题报告的处理状态，从建
立到处理结束
y报告已实现的变更申请的实现状态
包括建立中涉及的所有配置项的说明对每一个CI 的维护记录
记录整个评审过程的完整报告
以图形表示的单位时间提交的CRs 数
目
y以图形表示的单位时间处理的CRs 数
目
y单位时间内完成的评审次数等
配置管理工具支持对配置状态的记录、统计和发布功能，CMO 可以对工具进行订制输出上
述有关表格并进行发布。
15、 配置评审与验证
配置评审和验证是确保基线化的配置项已通过测试证明他们已经满足其功能要求并包含所
有可提交的组成部分的过程。配置验证的主要手段，是在每次软件系统的发布前安排评审，即要有正式的产品发布流程。配置验证使CSCIs 与相应规格说明保持一致。功能配置评审（FCA ）验证软件与相应的需求说明保持一致，物理配置评审（PCA ）验证将发布的软件部件确实存在并包含所有应包含的组成部分，比如正确版本的源程序和目标代码，文档，和安装手册等。
每个基线在确定之前都要进行配置评审 和验证。
15.1 功能配置评审 FCA
功能配置评审验证CSCIs 的实际执行效果是否和基线化的设计文档保持一致。这包括了对
测试方法、测试流程、测试报告、以及工程和设计文档的评审，实际上，在一个高层的系统集成完成之前，不可能对一个CSCI 进行完全的验证，因此FCA 要在CSCI 的生命周期的各个阶段特别是基线建立时分别进行。FCA 将产生正式的评审报告，这些评估报告将作为提交给用户的评审文档的一部分。
15.2 物理配置评审 PCA
物理配置评审是对提交建立（build ）的软件部件是否满足基线化的VDD 文档保持一致的正
式检查。PCA 要确保相关的修改是否已经正确的包含到相应的软件部件中，以及所有的组成部分，软件、数据、和文档是否完整等。PCA 将产生正式的报告记录评审结果并同FCA 报告一样作为用户评审资料的一部分。
15.3 对配置管理执行过程的外部评审
在软件开发过程中还包含了其他一些对SCM 过程的评审，这些包括SQA 组织对SCM 流程是
否被正确有效的执行所进行的检查评审，CMO 和配置库管理员负责组织相应的记录和报告提交给SQA 人员并回答相关的问题，具体细节参照相关SQA 规范。
16、子合同管理
如果项目涉及软件承包子合同，要在配置管理计划中说明对承包商的配置管理的方法，包
括：
y 要求承包商制定并维护一个符合本规范要求的配置管理计划。y 协调项目配置管理与承包商配置管理计划的一致性。y 要求承包商任命专职的配置管理人员负责实施配置管理。y 要求承包商提交定期和不定期的配置管理状态报告。y 对承包商提交的交付产品进行验证。
有关子合同管理的进一步细节请参考公司《软件子合同管理规范》。
17、培训
培训是执行配置管理活动的重要内容，也是SEI-CMM 对配置管理的明确要求，培训至少包
括：
y 对SCM 小组进行有关SCM 规范、策略、流程、方法论、工具等方面的培训。
y 对与该项目有关的组织和个人进行有关SCM 规范、策略、流程、方法论、工具等方面的
培训。
18、参考文献
IEEE STD 828 STD 1042CMM SEI-93-TR-25CMM SPF
NASA SCM GUIDELINERATIONAL RUP
SEI SCM PLAN: THE BEGINNING TO YOUR CM SOLUTIONDoD MIL-STD-498DoD MIL-DTD-973
IMPLEMENTING CONFIGURATION MANAGEMENT 2ND EDITION SEI PRESS
1：SEI-CMM 对SCM 实施情况的检查表
附录
关键实践与子过程I. 承诺执行
1、项目遵循一个公司级的SCM 规范a. 每个项目的SCM 活动都被精确定义b. SCM贯穿了整个项目的生命周期
c. SCM覆盖了外部、内部软件，以及项目工具d. 项目建立了相应的配置管理库系统e. 软件基线和SCM 活动有定期的评审II. 执行能力
1、成立了管理项目基线的委员会SCCB a. 授权建立软件基线和标识软件配置项
b. 能代表项目经理和受影响的组织对软件变更的意见c. 评审和授权对软件基线的变更d. 授权从软件基线库系统建立产品
2、项目建立了协调和实施SCM 的小组(比如SCM 小组）a. 建立管理软件基线库
b. 制订、维护、发布软件配置管理计划、标准和流程c. 标识配置项
d. 管理对配置库的存取e. 更新软件基线
f. 从软件基线库系统建立产品g. 记录SCM 活动
h. 产生并发布SCM 报告
3、为SCM 提供了足够的资源
a. 任命了SCM 经理专门对SCM 负责b. 提供了相应的支持SCM 活动的工具
4、对SCM 小组进行了SCM 的目的、流程、方法的培训5、对软件工程组和其他受影响的小组进行了如何开展SCM 活动的培训III. 活动执行
1、每个项目都按照流程制订了SCM 计划a. 与项目计划平行制订了配置管理计划b. 配置管理计划接受了受影响组织的评审c. 配置管理计划是受管理的
2、文档化的通过评审的配置管理计划被用作指导SCM 的基础，它包括
a. 将进行的SCM 活动、时间表、相应职责和资源
b. 由软件工程组和其他受影响的小组在SCM 方面的需求和活动
3、建立了配置库系统管理基线，此系统a. 支持对SCM 的多级控制b. 支持对配置项的存取
是否原因