软件配置管理指南_V1.0
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
外部审计：是指客户CMO及QA对项目的所有配置管理活动否和要求相一致的配置审计。外部审计结果作为项目验收报告的输入，用于后续合作评估。
0
补丁版本号
包含对客户或测试组发现和报告的一个或多个问题的解决。此版本只发布给报告问题的客户或测试组。解决一次问题发布一个补丁版本给报告问题的客户或测试组。补丁也可能只是一种优化（而不是解决客户发现的问题）。
所有上述数字都是阿拉伯数字，并且单调递增。
为清楚起见，下列关键词可以作为软件版本标识的前缀：
1、建立项目配置库
2、维护组织级配置库
3、提供配置管理培训
4、执行组织级配置审计
CMO
配置管理员
Configuration Management Operator
1、识别、标识配置项
2、管理配置库访问权限
3、制定配置管理计划
4、维护配置项变更记录
5、建立基线
6、配置状态报告
7、版本发布
CCB
变更控制委员会
Change Control Board
1、评估和批准对基线的变更
2、评估和批准变更申请
QA
质量保证
QualityAssurance
1、实施配置审计
5.配置管理简介
5.1
配置管理是通过标识配置项，变更控制，配置状态跟踪，配置审计来建立和维护工作产品的精确配置，保证工作产品一致稳定。
5.2
5.2.1
配置管理中最基本的元素是配置项，它是被唯一标识的实体。
5.3
5.3.1
配置标识是对配置管理的前提和基础。
配置标识包括了配置项的选择、划分以及功能物理属性进行描述的过程。
配置项是逻辑上组成软件系统的各组成部分。比如一个软件产品包括数个程序模块，每个程序模块及其相关文档和支撑数据就是软件的配置项。它们可以作为一个配置项，也可以根据类型划分为几个配置项。这个过程就是配置项的选择与划分。
如版本规则不明确，则应采用本版本规则，但必须保证版本号与客户方版本号的对应关系。
1)版本命名
文档的版本标识形式为以下的十进制标识符：
xx.yy
其中xx起始为“1”，yy起始为“0”。
所有数字均是阿拉伯数字，并且单调递增。如果发生了重大的修改，xx递增；如果只有小修改，递增yy。
配置项未经过评审时，版本标注不得早于v1.0。
3)事件驱动发布内容：配置库及权限变更情况
5.8
对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。
配置审计的物理审计是由QA来做，检查配置项的一致性，完整性，规范性。
配置审计分为内部审计和外部审计。
内部审计：是指项目组内部人员（CMO、项目PM、QA）对项目的配置项完整性、正确性,一致性和可跟踪性的基线审计，包括例行审计、每个版本发布前的质量审计及阶段点审计；
表格4发布版本标识
数字
起始
发布类型
典型描述
Xx
1
主版本号
增加了一个大的特性－可能导致与原先版本不兼容。
Yy
0
次版本号
增加了一个小的特性－保持与原先版本兼容。
Zz
0
维护版本号
可以包含一些更改，并且包含自上一次版本发布以后所有的补丁。一般地，这个版本要根据保证和/或支持/维护协议主动提交给所有的用户。
Pp
例如：银行项目_back_20130810_fully
增量备份
命名规则是：项目名称+“_”+ back +“_”+“YYYY/MM/DD”+ hourly
例如：银行项目_back_20130810_hourly
5.4
配置控制包括配置项在完成基线化后所产生的变更的评估、批准、驳回以及实现过程。
5.4.1
需求基线
该阶段尾所有文档通过评审后打基线，包含立项基线所有配置项及：SDV测试方案、SDV测试用例，只需对01.CI目录打基线即可。
命名规则是：项目名称+“_”+“RD”+“_”+“Baseline”
设计基线
在实现阶段结束以后打基线。除包含“立项基线”与“需求基线”所有包含的配置项以外增加源代码、单元测试计划及用例，系统测试计划及用例。
配置项通过评审后，版本可升为V1.0版，达成V1.0版的配置项纳入配置库，正式受控。配置项纳入配置库时，应在修订记录中注明版本号。
2)发布版本标识
一个发布软件由一系列配置项组成，由这些配置项共同构成一个广义的配置项－－版本。对于版本的标识建议采用如下的形式。如客户有该项要求，则按客户要求操作。
软件版本以xx.yy.zz.pp的形式标识，其中xx、yy、zz、pp的意义如下：
由供应商提供的源代码，并接受供应商的维护
工具
支持软件开发、建立、维护的工具管理，比如语言开发工具，编译工具，测试工具，配置管理工具等
用户文档
包括用户手册，安装指南等
运行环境
包含系统运行环境的相关内容，比如系统运行平台，环境设置要求等
5.3.1.2
软件配置项一般可分为两大类：文档与代码。
对于这两种类型，其配置项划分方法不同：
AR
Allocated Requirements
分配需求
4.角色和职责
表格2角色和职责
缩略语
中文名
英文名
职责
PM
项目经理
Project Manager
1、协助CMO识别配置项
2、申请建立配置库
3、审查配置库变更
组织级CMO
组织级配置管理员
OrganizationalConfiguration Management Operator
分类名
描述
合同类文档
建议书、LOI（用户意向书）、用户需求、SOW (工作任务书)、合同
计划类文档
包括各类项目相关计划，比如项目过程手册、项目计划，配置管理计划等
工程类文档
包括需求规格文档、测试计划（含测试用例）、设计文档、需求跟踪矩阵等
程序代码
所有开发的源代码，包括各类支持数据，二进制文件
第三方程序代码
配置管理指南
修订历史
版本号
版本发布日期
作者
审核者
批准者
受影响的部分和变更总结
1.目的
为了指导和帮助XX公司项目的配置管理工作，特制定本指南。
2.范围
本过程文件适用于所有的软件开发及测试项目。
读者为项目组中负责配置管理活动的人员。
3.术语和缩写语
表格1术语和缩略语
缩略语
英文全名
中文解释
CMP
Configuration Management plan
5.3.2.3
如在某个阶段中，需要对某个模块单独进行基线化操作，此时基线以下述标签规则建立。
标签命名规范：
BaseLine_版本号_[子系统名称/模块名称]_阶段
例如：
BaseLine _V100R002C02L00106_ CHG_SDV
5.3.3
整体备份
命名规则是：项目名称+“_”+ back +“_”+“YYYY/MM/DD”+fully
凡是纳入配置管理范畴的工作产出都是配置项（CI）。
配置项主要有两大类：
1)属于产品组成部分的工作产出；
2)项目管理和机构支撑过程产生的文档。
配置项，指一个产品在生命周期各个阶段所产生的各种形式和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项。（要和过程中配置项的定义一）
配置管理计划
CI
Configuration Item
配置项
CCB
Change Control Board
变更控制委员会
CSA
Configuration Status Accounting
配置状态发布
OR
Offering Requirements
产品包需求
DR
Design Requirements
设计需求
配置项在大小，复杂程度和类型上划分非常广泛，可以从整个的系统（包括硬件，软件和文件）到一个单一的模块。通常我们的项目计划，需求规格书，设计文档，编码，测试用例等都是配置项。配置项选择可参考本文“配置项标识”章节。
5.2.2
基线是一组配置项集合的稳定版本，是进一步开发的基础。基线保证了后续开发活动所需工作产品及支持文档数据的稳定性和一致性。基线的变更要遵循变更控制的流程。
1)文档
一般将一篇文档可以划分为一个配置项。根据需求一类文档也可作为一个配置项。
2)代码
对于单板软件、模块、开源软件、外购软件或需要单独管理的软件代码可设置为一个配置项。如果没有特别管理需求，所有组成一个Build的代码也可作为一个配置项。
5.3.1.3
每个配置项都必需被唯一地标识，这个唯一的标识被用于与其它配置项进行区分，跟踪和报告该配置项的状态。一般地，每个配置项被赋予一个标识符。
1)文档命名规则
项目名称名称+文档名称+文档版本。中间使用“_”下划线连接。
格式：项目名称_文档名称_文档版本
例如：
中信CRM零售管理项目_详细设计_V1.0.xls
如客户方有其他要求，则按客户要求操作。
2)工具命名规则
工具名称+空格+版本号
例如：
Subversion 1.6.17
5.3.1.4
版本命名必须与客户下发的工作任务书所要求的版本命名保持一致。
5.4.2.2
配置项自提交审核开始，即处于受控状态。
例如：
1)一个正在进行审核的设计文档。
2)一个已通过审核的配置管理计划。
5.4.2.3
配置项被纳入基线范围，并且此基线已经建立，则称此配置项已基线化。
5.5
1.版本转测试由CMO负责。
2.每个版本转测试时CMO都必须检查确保交付件的完整性，对代码配置库打标签并对版本回收修改权限。
维护版本2.1.1.0
补丁版本2.1.1.1
内部版本2.1.1.1
5.3.2
5.3.2.1
标签命名采用以下规则：
Label _版本号_标签名
标签注释规范如下：
【标签人】：描述实际修改该问题的人员信息（格式：中文姓名）
【标签说明】：详细说明标签的内容。
5.3.2.2
1)瀑布模式的项目中，CMO必须在需求分析结束、code&UT结束、ST结束、SDV结束、验收结束时进行基线化操作。
在立项结束时候打基线，包含的配置项有：工作任务书、分配需求、客户提供物、方案建议书、方案选择表、项目估算表、项目计划、WBS、过程裁剪表、需求设计说明书、项目需求表，只需对01.CI目录打基线即可。
命名规则是：项目名称+“_”+“Init”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)
配置状态跟踪是对配置库的状态，软件的更新或变更的过程进行记录、监视并通报给项目组和相关成员的活动。
1.责任人：CMO
2.发布对象：项目组所有人员
3.发布周期：例行发布或事件驱动发布
4.发布形式：邮件
5.发布内容：
1)月度例行发布内容：版本发布情况
2)阶段点发布内容：文档归档情况、基线建立情况、变更情况
3.转测试交付件必须包括：基线化的需求、设计、规格、产品配套资料、文档等相关文档
5.6
1.版本验收通过后，由CMO交付版本。
2.每个版本交付验收时CMO都必须对照工作任务书检查确保交付件的完整性，对代码配置库打标签，并对版本回收修改权限。
3.版本交付件必须包括工作任务书的交付件清单所有交付件。
5.7
每个基线都必须有被唯一的标识。基线内容包括文档和代码。
到达阶段点时，CMO检查该阶段配置项的完整性，并在阶段点评审通过5个工作日内建立基线。
表格5阶段基线
项目类型
项目阶段
基线名称
瀑布
需求分析
需求设计基线
CODE&UT结束
开发基线
ST结束
测试基线
SDV结束
验收基线
验收结束
产品基线
标签命名采用以下规则
立项基线
在配置管理系统（SVN）中，基线是一组特定版本的配置项副本拷贝，凡纳入此基线范围的配置项，称为此配置项已基线化。
以下是建立/修改基线注意事项：
1)通过正式的评审过程建立。
2)基线变更要执行变更流程。
3)基线的变更由CCB裁决。
4)基线是进一步开发和修改的基准。
5.2.3
版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。版本以版本号进行标识。
在项目开始时，需根据项目的情况确定CCB成员，建议组成人员为、PM、、QA、CMO。PM为CCB负责人，PM根据变更请求的情况事件驱动地召集CCB会议。CCB也可以批量处理更改请求或采用定期的方式进行处理。这些活动都应该在配置管理计划中体现。
5.4.2
5.4.2.1
当配置项处于创建之初未纳入基线之前，项目组成员可以修改。此时配置项是草稿状态。
பைடு நூலகம்5.3.1.1
软件配置项包括但不限于：
1)用户需求
2)SOW (工作任务书)
3)估算记录
4)项目计划
5)配置管理计划
6)需求规格
7)功能规格
8)产品规格
9)设计规格
10)需求跟踪矩阵
11)用户手册
12)测试计划
13)测试方案
14)测试用例
15)代码
16)测试工具
17)脚本
配置项可以分成以下类型：
表格3配置项分类表
命名规则是：项目名称+“_”+“Design”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)
验收&产品基线
在整个项目开发结束以后打的基线，包含CI目录下的所有配置项。
命名规则是：项目名称+“_”+“Final”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)
0
补丁版本号
包含对客户或测试组发现和报告的一个或多个问题的解决。此版本只发布给报告问题的客户或测试组。解决一次问题发布一个补丁版本给报告问题的客户或测试组。补丁也可能只是一种优化（而不是解决客户发现的问题）。
所有上述数字都是阿拉伯数字，并且单调递增。
为清楚起见，下列关键词可以作为软件版本标识的前缀：
1、建立项目配置库
2、维护组织级配置库
3、提供配置管理培训
4、执行组织级配置审计
CMO
配置管理员
Configuration Management Operator
1、识别、标识配置项
2、管理配置库访问权限
3、制定配置管理计划
4、维护配置项变更记录
5、建立基线
6、配置状态报告
7、版本发布
CCB
变更控制委员会
Change Control Board
1、评估和批准对基线的变更
2、评估和批准变更申请
QA
质量保证
QualityAssurance
1、实施配置审计
5.配置管理简介
5.1
配置管理是通过标识配置项，变更控制，配置状态跟踪，配置审计来建立和维护工作产品的精确配置，保证工作产品一致稳定。
5.2
5.2.1
配置管理中最基本的元素是配置项，它是被唯一标识的实体。
5.3
5.3.1
配置标识是对配置管理的前提和基础。
配置标识包括了配置项的选择、划分以及功能物理属性进行描述的过程。
配置项是逻辑上组成软件系统的各组成部分。比如一个软件产品包括数个程序模块，每个程序模块及其相关文档和支撑数据就是软件的配置项。它们可以作为一个配置项，也可以根据类型划分为几个配置项。这个过程就是配置项的选择与划分。
如版本规则不明确，则应采用本版本规则，但必须保证版本号与客户方版本号的对应关系。
1)版本命名
文档的版本标识形式为以下的十进制标识符：
xx.yy
其中xx起始为“1”，yy起始为“0”。
所有数字均是阿拉伯数字，并且单调递增。如果发生了重大的修改，xx递增；如果只有小修改，递增yy。
配置项未经过评审时，版本标注不得早于v1.0。
3)事件驱动发布内容：配置库及权限变更情况
5.8
对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。
配置审计的物理审计是由QA来做，检查配置项的一致性，完整性，规范性。
配置审计分为内部审计和外部审计。
内部审计：是指项目组内部人员（CMO、项目PM、QA）对项目的配置项完整性、正确性,一致性和可跟踪性的基线审计，包括例行审计、每个版本发布前的质量审计及阶段点审计；
表格4发布版本标识
数字
起始
发布类型
典型描述
Xx
1
主版本号
增加了一个大的特性－可能导致与原先版本不兼容。
Yy
0
次版本号
增加了一个小的特性－保持与原先版本兼容。
Zz
0
维护版本号
可以包含一些更改，并且包含自上一次版本发布以后所有的补丁。一般地，这个版本要根据保证和/或支持/维护协议主动提交给所有的用户。
Pp
例如：银行项目_back_20130810_fully
增量备份
命名规则是：项目名称+“_”+ back +“_”+“YYYY/MM/DD”+ hourly
例如：银行项目_back_20130810_hourly
5.4
配置控制包括配置项在完成基线化后所产生的变更的评估、批准、驳回以及实现过程。
5.4.1
需求基线
该阶段尾所有文档通过评审后打基线，包含立项基线所有配置项及：SDV测试方案、SDV测试用例，只需对01.CI目录打基线即可。
命名规则是：项目名称+“_”+“RD”+“_”+“Baseline”
设计基线
在实现阶段结束以后打基线。除包含“立项基线”与“需求基线”所有包含的配置项以外增加源代码、单元测试计划及用例，系统测试计划及用例。
配置项通过评审后，版本可升为V1.0版，达成V1.0版的配置项纳入配置库，正式受控。配置项纳入配置库时，应在修订记录中注明版本号。
2)发布版本标识
一个发布软件由一系列配置项组成，由这些配置项共同构成一个广义的配置项－－版本。对于版本的标识建议采用如下的形式。如客户有该项要求，则按客户要求操作。
软件版本以xx.yy.zz.pp的形式标识，其中xx、yy、zz、pp的意义如下：
由供应商提供的源代码，并接受供应商的维护
工具
支持软件开发、建立、维护的工具管理，比如语言开发工具，编译工具，测试工具，配置管理工具等
用户文档
包括用户手册，安装指南等
运行环境
包含系统运行环境的相关内容，比如系统运行平台，环境设置要求等
5.3.1.2
软件配置项一般可分为两大类：文档与代码。
对于这两种类型，其配置项划分方法不同：
AR
Allocated Requirements
分配需求
4.角色和职责
表格2角色和职责
缩略语
中文名
英文名
职责
PM
项目经理
Project Manager
1、协助CMO识别配置项
2、申请建立配置库
3、审查配置库变更
组织级CMO
组织级配置管理员
OrganizationalConfiguration Management Operator
分类名
描述
合同类文档
建议书、LOI（用户意向书）、用户需求、SOW (工作任务书)、合同
计划类文档
包括各类项目相关计划，比如项目过程手册、项目计划，配置管理计划等
工程类文档
包括需求规格文档、测试计划（含测试用例）、设计文档、需求跟踪矩阵等
程序代码
所有开发的源代码，包括各类支持数据，二进制文件
第三方程序代码
配置管理指南
修订历史
版本号
版本发布日期
作者
审核者
批准者
受影响的部分和变更总结
1.目的
为了指导和帮助XX公司项目的配置管理工作，特制定本指南。
2.范围
本过程文件适用于所有的软件开发及测试项目。
读者为项目组中负责配置管理活动的人员。
3.术语和缩写语
表格1术语和缩略语
缩略语
英文全名
中文解释
CMP
Configuration Management plan
5.3.2.3
如在某个阶段中，需要对某个模块单独进行基线化操作，此时基线以下述标签规则建立。
标签命名规范：
BaseLine_版本号_[子系统名称/模块名称]_阶段
例如：
BaseLine _V100R002C02L00106_ CHG_SDV
5.3.3
整体备份
命名规则是：项目名称+“_”+ back +“_”+“YYYY/MM/DD”+fully
凡是纳入配置管理范畴的工作产出都是配置项（CI）。
配置项主要有两大类：
1)属于产品组成部分的工作产出；
2)项目管理和机构支撑过程产生的文档。
配置项，指一个产品在生命周期各个阶段所产生的各种形式和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项。（要和过程中配置项的定义一）
配置管理计划
CI
Configuration Item
配置项
CCB
Change Control Board
变更控制委员会
CSA
Configuration Status Accounting
配置状态发布
OR
Offering Requirements
产品包需求
DR
Design Requirements
设计需求
配置项在大小，复杂程度和类型上划分非常广泛，可以从整个的系统（包括硬件，软件和文件）到一个单一的模块。通常我们的项目计划，需求规格书，设计文档，编码，测试用例等都是配置项。配置项选择可参考本文“配置项标识”章节。
5.2.2
基线是一组配置项集合的稳定版本，是进一步开发的基础。基线保证了后续开发活动所需工作产品及支持文档数据的稳定性和一致性。基线的变更要遵循变更控制的流程。
1)文档
一般将一篇文档可以划分为一个配置项。根据需求一类文档也可作为一个配置项。
2)代码
对于单板软件、模块、开源软件、外购软件或需要单独管理的软件代码可设置为一个配置项。如果没有特别管理需求，所有组成一个Build的代码也可作为一个配置项。
5.3.1.3
每个配置项都必需被唯一地标识，这个唯一的标识被用于与其它配置项进行区分，跟踪和报告该配置项的状态。一般地，每个配置项被赋予一个标识符。
1)文档命名规则
项目名称名称+文档名称+文档版本。中间使用“_”下划线连接。
格式：项目名称_文档名称_文档版本
例如：
中信CRM零售管理项目_详细设计_V1.0.xls
如客户方有其他要求，则按客户要求操作。
2)工具命名规则
工具名称+空格+版本号
例如：
Subversion 1.6.17
5.3.1.4
版本命名必须与客户下发的工作任务书所要求的版本命名保持一致。
5.4.2.2
配置项自提交审核开始，即处于受控状态。
例如：
1)一个正在进行审核的设计文档。
2)一个已通过审核的配置管理计划。
5.4.2.3
配置项被纳入基线范围，并且此基线已经建立，则称此配置项已基线化。
5.5
1.版本转测试由CMO负责。
2.每个版本转测试时CMO都必须检查确保交付件的完整性，对代码配置库打标签并对版本回收修改权限。
维护版本2.1.1.0
补丁版本2.1.1.1
内部版本2.1.1.1
5.3.2
5.3.2.1
标签命名采用以下规则：
Label _版本号_标签名
标签注释规范如下：
【标签人】：描述实际修改该问题的人员信息（格式：中文姓名）
【标签说明】：详细说明标签的内容。
5.3.2.2
1)瀑布模式的项目中，CMO必须在需求分析结束、code&UT结束、ST结束、SDV结束、验收结束时进行基线化操作。
在立项结束时候打基线，包含的配置项有：工作任务书、分配需求、客户提供物、方案建议书、方案选择表、项目估算表、项目计划、WBS、过程裁剪表、需求设计说明书、项目需求表，只需对01.CI目录打基线即可。
命名规则是：项目名称+“_”+“Init”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)
配置状态跟踪是对配置库的状态，软件的更新或变更的过程进行记录、监视并通报给项目组和相关成员的活动。
1.责任人：CMO
2.发布对象：项目组所有人员
3.发布周期：例行发布或事件驱动发布
4.发布形式：邮件
5.发布内容：
1)月度例行发布内容：版本发布情况
2)阶段点发布内容：文档归档情况、基线建立情况、变更情况
3.转测试交付件必须包括：基线化的需求、设计、规格、产品配套资料、文档等相关文档
5.6
1.版本验收通过后，由CMO交付版本。
2.每个版本交付验收时CMO都必须对照工作任务书检查确保交付件的完整性，对代码配置库打标签，并对版本回收修改权限。
3.版本交付件必须包括工作任务书的交付件清单所有交付件。
5.7
每个基线都必须有被唯一的标识。基线内容包括文档和代码。
到达阶段点时，CMO检查该阶段配置项的完整性，并在阶段点评审通过5个工作日内建立基线。
表格5阶段基线
项目类型
项目阶段
基线名称
瀑布
需求分析
需求设计基线
CODE&UT结束
开发基线
ST结束
测试基线
SDV结束
验收基线
验收结束
产品基线
标签命名采用以下规则
立项基线
在配置管理系统（SVN）中，基线是一组特定版本的配置项副本拷贝，凡纳入此基线范围的配置项，称为此配置项已基线化。
以下是建立/修改基线注意事项：
1)通过正式的评审过程建立。
2)基线变更要执行变更流程。
3)基线的变更由CCB裁决。
4)基线是进一步开发和修改的基准。
5.2.3
版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。版本以版本号进行标识。
在项目开始时，需根据项目的情况确定CCB成员，建议组成人员为、PM、、QA、CMO。PM为CCB负责人，PM根据变更请求的情况事件驱动地召集CCB会议。CCB也可以批量处理更改请求或采用定期的方式进行处理。这些活动都应该在配置管理计划中体现。
5.4.2
5.4.2.1
当配置项处于创建之初未纳入基线之前，项目组成员可以修改。此时配置项是草稿状态。
பைடு நூலகம்5.3.1.1
软件配置项包括但不限于：
1)用户需求
2)SOW (工作任务书)
3)估算记录
4)项目计划
5)配置管理计划
6)需求规格
7)功能规格
8)产品规格
9)设计规格
10)需求跟踪矩阵
11)用户手册
12)测试计划
13)测试方案
14)测试用例
15)代码
16)测试工具
17)脚本
配置项可以分成以下类型：
表格3配置项分类表
命名规则是：项目名称+“_”+“Design”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)
验收&产品基线
在整个项目开发结束以后打的基线，包含CI目录下的所有配置项。
命名规则是：项目名称+“_”+“Final”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)