CMMI3级软件过程 第17章 配置管理
(完整版)CMMI3过程体系文档清单
分类
过程域(PA)
过程
规程
模板
过程管 理过程
项目管 理类过
程
工程开 发类过
程
OPD、OPF
OT PP
PMC、IPM、RSKM PMC、IPM、RSKM PMC、IPM、RSKM
RD PP TS、PI
软件过程改进过程
组织培训过程
项目立项过程 项目策划过程
项目跟踪过程
84—82
检查单
配置服务器/CMM目录下文件配置清单
84—83
检查单
配置服务器/CMM目录下文件配置清单
84—84
84—76
检查单
配置服务器/CMM目录下文件配置清单
84—77
检查单
配置服务器/CMM目录下文件配置清单
84—78
检查单
配置服务器/CMM目录下文件配置清单
84—79
检查单
配置服务器/CMM目录下文件配置清单
84—80
检查单
配置服务器/CMM目录下文件配置清单
84—81
检查单
配置服务器/CMM目录下文件配置清单
配置服务器/CMM目录下文件配置清单
过程
规程
模板
指南
规范
84—39
分类
过程域(PA)
配置服务器/CMM目录下文件配置清单
过程
规程
模板
指南
规范
84—40
分类
过程域(PA)
配置服务器/CMM目录下文件配置清单
过程
规程
模板
指南
规范
84—41
分类
过程域(PA)
配置服务器/CMM目录下文件配置清单
CMMI3访谈问题及答案--配置管理
配置管理访谈1. 可否请你描述一下：你是如何确定你的项目的配置项的访问控制的？我们在项目启动时，会编写项目配置管理计划，明确配置项以及相应的责任人，并设立每个配置项的访问权限，比如：项目计划的修改权只有计划的责任人拥有。
再次，对于配置项，我们实施变更控制：对于基线化了的配置项，配置管理员会锁定，如果有人要修改，要提交变更申请，得到CCB授权同意后，配置管理员才会将配置项的修改权限放给变更申请人。
2. 可否请你描述一下：在你的项目中是如何发起变更请求，如何审核变更请求，如何报告变更状况的(如何记录的)？对于基线化了的配置项，我们如果要修改，需要提交变更请求，即起草变更请求表；对于变更请求，项目CCB会进行影响分析，在变更请求表中填写影响范围、工作量等信息，同时会做出是否同意变更的决定，如果决定变更，会制定修改方案，安排相关人员明确影响范围，实施变更；变更实施完成，要提交CCB验证，验证通过后，变更请求才被关闭；3. 可否请你描述一下：怎样计划配置审计的(怎样制定配置审计计划)？配置审计计划一般参考项目配置管理计划制定审计计划，从功能审计和物理审计方面考虑具体审计时机。
功能审计，比如我们项目一般会在配置系统建立结束时作一次审计，以检查配置系统能够满足本项目的实施需要，配置项管理方法是否正确，是否完整；再则，我们根据基线建立计划以及阶段结束时间制订物理审计和功能审计的时机，以确保所有的配置项如在 CM 计划中期望的那样放在配置管理系统(也称配置库)下，确保团队有一个机制来知道给定配置管理项的最新状态，确保配置管理项的状态与基线信息一致，识别团队的配置管理培训需求等4. 可否请你描述一下：怎样审核和授权软件基线的变更的？软件基线的变更需要获得CCB的审核和授权5. 可否请你描述一下：CCB由哪些人员组成？就由项目经理，配置管理员、技术骨干组成。
CCB主任一般由项目经理担当。
6. 可否请你描述一下：在你的项目中，那些工作产品进行配置管理？为什么？（或者问题方式可能是：配置项是如何识别的？）根据组织级定义的配置管理过程，所有工作产品都实施配置管理，包括来自客户的各种资料，要交付给客户的成果物，项目计划等。
CMMI 配置管理
CMMI之配置管理2008-01-11 作者：张瑾来源：希赛网在笔者进行CMMI咨询时，当问及软件技术人员什么是”配置管理”的时候，很多人的回答就是“版本管理”，而且很多人都会说出各种各样的版本管理工具，例如：VSS、TFS、CVS或SVN等等。
但这样的回答是不正确、不全面的。
版本管理只是软件配置管理的一个小的部分，在CMMI中配置管理分为“配置项和基线的管理”、“变更控制管理”和“基线的完整性”三个部分。
凡是提到软件“配置管理”（Configuration Management），我会先给它下个定义：“它是软件工程的核心部分，是CMMI中最基础的PA”。
为什么它会如此重要呢？首先配置管理的工作就是确保软件项目时时保持条理清晰，随时想要任何工作产品都可以迅速找到，并且工作产品的内容不会出错，这也就是大家常讲的可回溯性、完整性和正确性；其次软件配置管理活动始终贯穿整个软件项目的生命周期。
因此说软件配置管理是最基础、最核心的管理工作一点都不夸张。
(一) 软件配置项在CMMI的“配置管理”过程域CM中SP1.1首先提到的就是“配置项”的概念，在大家开展配置管理工作前应该先识别哪些是本项目的配置项。
“配置项”就是配置管理的对象，简单来讲它符合以下任意一个特点：1、它会被两个或两个以上的项目成员共同使用。
2、它会随着项目的开展而发生变化。
3、对项目重要的工作产品。
4、一些工作产品之间的关系非常紧密，一个变化其他的就会受到影响。
通过以上定义大家会发现项目中的很多东西都属于配置项，例如：各种需求文档、设计文档等都会经常变更；程序的代码是大家共享的，而且代码文件之间又有较高的相互依赖性。
那大家也许会发现还有一些工作产品不符合以上定义，例如：各种周报、会议记录等。
这些也是配置项吗？很显然，它们不符合以上特点，那么这些工作产品就不属于配置项的范围，但有时在进行CMMI实施时，项目组也往往会将其一并进行管理。
既然配置项是“配置管理”的基础，那么大家还需要给每一个配置项起一个唯一标识，这样才能够做到清晰不混淆。
cmmi3流程
cmmi3流程CMMI3流程CMMI（Capability Maturity Model Integration）是一种软件开发过程的评估与改进模型，通过帮助组织改进其软件开发过程，以实现更高的质量和效率。
CMMI3是CMMI模型的一个级别，代表了相对成熟的软件开发过程。
CMMI3流程是指在实施CMMI3级别的软件开发过程中所需遵循的一系列流程和步骤。
下面将详细介绍CMMI3流程的主要内容。
1. 需求管理流程需求管理是软件开发过程中的重要环节，CMMI3要求对需求进行全面的管理和跟踪。
首先，需求应该明确、完整，并且能够准确地反映用户的期望。
其次，需求应该进行适当的分析和评审，以确保其可行性和一致性。
最后，需求应该进行有效的变更控制，以应对需求变更带来的影响。
2. 项目计划与控制流程项目计划与控制是确保软件开发项目按时交付和达到预期质量的关键。
CMMI3要求制定详细的项目计划，包括工作分解结构、里程碑和资源分配等。
同时，项目的进度和成本应该进行有效的监控和控制，及时发现和解决问题，确保项目按计划进行。
3. 配置管理流程配置管理是管理软件开发过程中各种配置项的重要环节。
CMMI3要求对软件配置项进行标识、控制和追踪。
配置项应该按照规定的标准进行版本控制，并且对配置项的变更应该进行适当的评审和批准。
同时，配置项的状态和版本应该进行有效的记录和报告。
4. 产品质量保证流程产品质量保证是确保软件开发过程中交付的产品符合质量要求的关键。
CMMI3要求建立有效的质量管理体系，包括质量策划、质量评审和质量度量等。
同时，应该对软件开发过程中的各个环节进行质量控制，及时发现和纠正问题，以提高产品的质量。
5. 测试管理流程测试是确保软件开发过程中交付的产品符合功能和性能要求的关键环节。
CMMI3要求进行全面的测试计划和测试用例的编写。
测试应该覆盖各个功能模块和场景，并且应该进行有效的测试执行和问题管理。
同时，测试过程中的结果应该进行准确的记录和报告。
CMMI3级18个过程域
CMMI3级18个过程域CMMI（Capability Maturity Model Integration）是一种用于评价和改进组织的软件工程能力的模型。
CMMI模型将软件工程能力分为不同的级别，目前最高级别是CMMI级别5、在CMMI模型中，共有18个过程域，每个过程域都包含一组过程目标和过程实践。
下面将介绍CMMI级别3中的18个过程域，并对每个过程域进行详细解析。
1. 要求开发（Requirements Development）：该过程域涉及确定、分析和记录系统和软件需求的活动。
它包括需求的获取、管理、分析和验证。
2. 要求管理（Requirements Management）：该过程域涉及组织和控制项目的需求。
它包括需求的识别、跟踪、控制和变更管理。
3. 项目计划和监控（Project Planning and Monitoring）：该过程域涉及制定和维护项目计划，并监控项目活动的执行。
它包括识别和规划项目活动、建立项目计划、监控项目进展和基于此进行调整。
4. 项目监控和控制（Project Monitoring and Control）：该过程域涉及监控和控制项目执行过程中的工作和活动。
它包括收集和分析项目绩效数据、对比实际和计划绩效，对项目进展进行控制。
5. 供应商协议管理（Supplier Agreement Management）：该过程域涉及与供应商达成协议，并管理和监控供应商的活动。
它包括选择供应商、与供应商协商、管理和控制供应商的交付和绩效。
6. 产品集成（Product Integration）：该过程域涉及对各个组成部分进行整合，形成最终产品。
它包括定义和实施产品集成策略、执行产品集成和验证集成后的产品。
7. 风险管理（Risk Management）：该过程域涉及识别、评估和控制项目和产品的风险。
它包括制定风险管理计划、识别和评估风险、并采取相应的风险缓解措施。
8. 决策分析和解决方案评估（Decision Analysis and Resolution）：该过程域涉及通过分析和评估不同的解决方案，制定决策。
CMMI 3培训_配置管理课件
配置项的出入库
变更的控制
配置验收、软件审计、构 造和发布
变更请求/问题报告 记录
配置相关表格
配置项状态的统计 结束
PPT学习交流
6
选择配置工具
公司目前将采用微软的Visual SourceSafe作为配 置管理工具，以后可以考虑采用其他的更为适用的 工具来作为企业级的的配置管理工具；
预先定义了项目的配置库的结构，作为每个项 目在进行配置计划时的基础。
18
Q&A
PPT学习交流
19
入库时间 项目策划结束 项目策划结束 项目策划结束 项目策划结束 项目策划结束 需求阶段 需求阶段 需求阶段 设计阶段 设计阶段 设计阶段 测试策划结束 测试前 测试完成 试运行 试运行
提交人 项目组 项目组 项目组 SCM组 SQA组 项目组 项目组 项目组 项目组 项目组 项目组 测试组 测试组 测试组 项目组 项目组
PPT学习交流
14
配置验收，基线审计、构造和发布
• 配置管理员对配置项的完整性进行审计
• 检查基线的完整性和准确性，对于生成产品的基线是否存在遗漏； • 基线的变更是否已完成； • 基线变更所涉及到的其他配置项是否已作了修改； • 基线中的各个配置项与SCM基线内容报告是否一致，是否存在遗漏。 • 审计报告的提交
每周 每周 测试阶段 项目结束 定期 事件驱动 评审结束 评审结束 评审结束 评审结束 事件驱动 编码阶段 编码阶段 编码阶段 项目启动 项目结束
项目组 项目组 测试组 项目组 项目组 项目组 SQA小组 SQA小组 SQA小组 SQA小组 项目组 项目组 项目组 项目组 项目组 项目组
PPT学习交流
• 确定SCM库备份的工具、时间、周期等；
CMMI 3级软件过程改进方法与规范-前言
C M M I3级软件过程改进方法与规范S i m p l i f i e d P a r a l l e l P r o c e s s，S P P内容提要软件过程改进是目前IT 企业研发管理的重点与难点。
为了提高软件过程能力，企业首先要研制软件过程规范，这是有一定难度并且费时费力的工作。
本书论述的是一套通用的CMMI 3级软件过程改进方法与规范，称为“精简并行过程”（SPP）。
SPP 2.0共有19个关键过程域，分为项目管理过程、技术开发过程和支撑过程三大类：✧项目管理过程有7个关键过程域，分别为立项管理、结项管理、项目计划、项目跟踪、风险管理、外包管理和需求管理。
✧技术开发过程有8个关键过程域，分别为需求开发、技术预研、系统设计、实现与测试、系统测试、用户验收、产品维护和技术评审。
✧支撑过程有4个关键过程域，分别为配置管理、质量保证、采购管理和培训管理。
SPP 2.0文档总数约500余页，包含了众多的过程规范和模板。
采用SPP，用户可以在最短的时间内建立适合于本企业的软件过程规范，大大降低用户研制规范的代价和风险。
本书的主要读者对象是IT企业的研发主管、项目经理和软件开发人员，以及即将到企业工作的高校毕业生。
前言一、背景介绍在国内，绝大多数大中型IT企业几乎都面临着“研发管理混乱”的难题。
“研发管理混乱”必将导致“产品质量低下”、“进度延误”、“费用超支”等问题。
IT企业谋求发展，研发管理必须规范化，这是大中型IT企业的迫切需求。
软件过程改进（Software Process Improvement, SPI）是目前国内大中型IT企业研发管理的重点与难点。
CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。
CMM是由美国卡内基-梅隆大学（Carnegie-Mellon）软件工程研究所（Software Engineering Institute, SEI）研制的，其发展简史如下：✧CMM 1.0于1991年制定。
CMMI中配置管理
现在所有的配置管理工具均提供对配置项的管理工具，包括(Check in 和Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比 较繁琐，一般推荐使用配置管理工具，减少事务性工作。
基线
在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间 点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基 线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了 元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一 般在指定的里程碑处创建，并与项目中的里程碑保持同步。
配置审计 配置审计的主要作用是作为变更控制的补充手段，来确保某 一变更需求已被切实实现。在某些情况下，它被作为正式的 技术复审的一部分，但当软件配置管理是一个正式的活动时， 该活动由SQA人员单独执行。 审计机制保证修改的动作被完 整地记录，也就是说，记录了谁修改了这个工件，什么时候 做的修改，为什么原因做出这个改动，以及修改了哪些地方。 在版本控制过程中，如果利用一些配置管理工具（或者版本 控制工具）的支持，则可以自动地记录审计工作所需的四个 “W”（Who、When、Why、What）。 同时配置审计工作 应当可以说明如下信息。
变更管理的流程： 1.（获得）提出变更请求； 2.由CCB审核并决定是否批准； 3.为（被接受）修改请求分配人员，提取SCI，进行修改； 4.提交修改后的SCI，并测试（或者评审）； 5.重建软件的适当版本； 6.复审（审计）所有SCI的变化； 7.发布新版本。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第17章配置管理配置管理(Configuration Management,CM)的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性，配置管理是对工作成果的一种有效保护。
☆制定配置管理计划[SPP-PROC-CM-PLANNING]。
☆配置库管理[SPP－PROC－CM-LIB]。
☆配置项版本控制[SPP-PROC－CM－VERSION]。
☆配置项变更控制[SPP－PROC－CM－CHANGE]。
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身情况（如商业目标、研发实力等）适当地修改规范，然后推广使用。
17.1 介绍项目研发和管理过程中会产生许许多多地工作成果。
例如文档、程序和数据等，它们都应当背保存起来，以便查阅和修改。
如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。
毫无疑问，人们应当将文件分类、有条理地保存起来。
凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI），配置项主要有两大类：●属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。
●项目管理和机构支撑过程域产生的文档。
这些文档虽然不是产品的组成部分，但是是值得保存。
每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。
所有配置项都被保存再配置库里，确保不会混淆、丢失。
配置项及其历史记录反映了软件的演化过程。
基线(BaseLine)由一组配置组成，这些配置项构成了一个相对稳定的逻辑实体。
基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。
基线通常对应开发过程中的里程碑(Milestone),一个产品可以有多个基线，也可以只有一个基线。
基线的主要属性有：名称、标识符、版本、日期等。
通常将交付给用户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。
所有的项目成员都要使用配置管理软件来保护自己的工作成果。
机构应当采用统一的配置管理软件，常见的配置管理软件有Microsoft的Visual SourceSafe和Rational的ClearCase 等。
为提高配置管理的效率和安全性，结构应当有专门的配置管理员（角色）。
配置管理员为每个项目制定《配置管理计划》，创建和维护配置库。
鉴于配置管理的重要性和复杂性，机构还应当设立配置控制委员会（Configuration Control Board，CBB）。
CBB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。
对于配置管理管理而言，CBB是决策者，而配置管理员是执行者。
如果机构的各个项目的配置管理拥有决策权。
如果机构的各个项目相对独立，那么每个项目可以设立各自的CBB。
CBB的决策采用“少数服从多数”的原则。
配置管理的流程如图17－1所示。
图17－1 配置管理流程图1.制定配置管理计划配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。
CBB审批该计划。
2.配置库管理配置管理员为项目创建配置库，并给每个项目成员根据自己的权限操作配置库。
配置管理员定期维护配置库，例如清除垃圾文件、备份配置库等。
3.版本控制在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。
对配置项的任何修改都将产生新的版本。
由于我们不能保证新的版本一定比捞的版本“号”，所以不能抛弃老的版本。
版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆现象，并且可以快速准确地查找到配置项地任何版本。
配置项地状态有3种：“草稿”、“正式发布”、和“正在修改”，本规程制定了配置项状态变迁与版本号地规则。
4.变更控制在项目开发过程中，配置项发生变更几乎是不可避免的。
变更控制的目的就是为了防止配置项被随意的修改而导致混乱。
修改处于“草稿”状态的配置项不算是“变更”，无CBB的批准，修改者按照版本控制规则执行即可。
当配置的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请－审批－执行变更－再评审－结束”的规则执行。
5.配置审计为了保证所有人员（包括项目成员、配置管理员和CBB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。
审计配置是一种“过程质量检查”活动，是质量保证人员的工作职责之一。
请参考质量保证规范SPP-PROC-QA,此处不再论述。
配置管理过程域产生的主要文档有：☆《配置管理计划》，模板见[SPP－TEMP－CM－PLAN]。
☆《配置库管理报告》，模板见[SPP－TEMP－CM－LIB]。
☆《配置项变更控制报告》，模板见[SPP－TEMP－CM－CHANGE]。
17.2 制定配置管理计划17.2.1 目的●制定配置管理计划，以便有计划的开展配置管理工作。
17.2.2 角色与职责●配置管理员制定《配置管理计划》。
●CCB审批《配置管理计划》。
CBB的人数视项目的规模而定。
通常CCB有项目经理、资深项目成员等人组成，项目经理为CCB负责人。
CCB的决策采用“少数服从多数”的原则。
17.2.3 启动准则●《项目计划》已经制定。
●配置管理员和CCB已经确定。
17.2.4 输入●《项目计划》17.2.5 主要步骤[Step1] 确定配置管理的软硬件资源●配置管理员根据项目的规模以及财力，确定配置管理软件以及计算机资源（考虑内存、外存CPU等）。
常用得配置管理软件有Micosoft公司的Visual SourcevSafe 和Rational的ClearCase等。
[Step2]制定配置计划●配置管理员识别项目的主要配置项。
每个配置项都有唯一的标识符，标识符的参考格式为Project－Type...Type－Number。
☆可以在Project（或Product）前面加上公司的标识符。
☆Type...Type表示配置类型，可以采用多级缩写。
☆Number为数字，范围从001－999，表示一个配置项有若干的文件。
若配置项只有一个文件，则该项可以省略。
[Step3]制定基线计划●配置管理员确定每个基线的名称（标识符）及其主要配置项，估计每个基线建立的时间。
基线计划的参考格式如表17－2所示。
[Step4]制定配置库备份计划●配置管理员制定配置库备份计划，指明"何人"在"何时"（频度）将配置库备份在"何处"。
[Step5]审批《配置管理计划》●CCB审批《配置管理计划》。
若该计划被批准，则请CCB负责人签字认可。
否则，配置管理员按照CCB的意见修改配置管理计划，直到该计划被批准为止。
17.2.6 输出●《配置管理计划》17.2.7 结束准则●《配置管理计划》已经制定并被CCB批准。
17.2.8 度量●配置管理统计工作量以及文档的规模，汇报给项目经理。
17.3 配置库管理17.3.1 目的●所有人员依照配置管理规范和《配置管理计划》操作配置库。
17.3.2 角色与职责●配置管理创建并维护配置库。
●项目成员在权限之内操作配置库。
17.3.3 启动准则●《配置管理计划》已经制定。
●配置管理的软硬件已经存在。
17.3.4 输入●《配置管理计划》17.3.5 主要步骤[Step1]创建配置库●配置管理员的创建配置库，并且至少创建库的所以第一级目录。
[Step2]分配权限●配置管理员为每个项目成员分配操作权限。
一般地，项目成员拥有Add、Checkin/Checkout、Download等权限，但是不能拥有“删除”权限。
配置管理员的权限最高。
具体操作视所采用的配置管理软件而定。
[Step3]配置管理操作与管理●项目成员根据自己的权限操作配置库。
例如Add、Checkin/Checkout、Download等。
●配置管理员根据“基线计划”创建与维护基线，“冻结”配置项，控制变更。
●配置管理员定期清除配置库里的垃圾文件。
●配置管理员定期备份配置库。
●交付管理。
这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。
交付出去的配置项必须有据可查，避免发生混乱。
流程如下：☆“索取人”向CCB提出交付申请。
☆CCB审批该申请。
如果该申请不合法（合理）。
则拒绝交付配置项。
如果同意交付，CCB应给出详细的交付清单。
☆配置管理员依据CCB的批示，从配置库中提取配置项交付给“索取人”。
☆索取人验收后签字。
17.3.6输出●《配置库管理报告》（由配置管理员撰写）17.3.7结束准则●对配置库的操作与管理将持续到项目结束。
17.3.8度量●配置管理员统计工作量以及文档规模。
17.4版本控制17.4.1 目的●按照一定的规则保存配置项的所有的版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
17.4.2 角色与职责●所有项目成员都必须遵照版本控制规程操作配置库。
17.4.3 配置项状态变迁规则配置项的状态有3种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”(Changging).配置项状态变迁如图17—2所示。
配置项刚建立时其状态为“草稿”。
配置项通过评审（或审批）后，其状态变为“正式发布”。
此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正式修改”。
当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。
图17－2 配置项状态变迁图17.4.4 配置项版本号规则配置项的版本号与配置项的状态紧密相关：●处于“草稿”状态的配置项的版本号格式为：0.YZ。
☆YZ数字范围为01~99。
☆随着草稿的不断完善，“YZ”的取值应该递增。
“YZ”的初值和增幅由用户自己把握。
●处于“正式发布”状态的配置项的版本号格式为：X.Y。
☆X为主版本号，取值范围为1~9。
Y为次版本号，取值范围为1~9。
☆配置项第一次“正式发布”时，版本号1.0。
☆如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。
只有当配置项版本升级幅度比较大时，才允许增大X值。
●处于“正在修改”状态的配置项的版本号格式为：X.YZ。
☆配置项正在修改时，一般只增大Z值，X.Y值保持不变。
☆当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。
17.4.5 配置项版本控制流程[Step1] 创建配置项●项目成员依据《配置管理计划》，在配置库中创建属于其任务范围内的配置项。
此时配置项的状态为“草稿”，其版本号格式为0.YZ。
[Step2] 修改处于“草稿”状态的配置项●项目成员使用配置管理软件的Checkout/Checkin功能，可以自由修改处于“草稿”状态的配置项（不受变更控制规程约束），版本号格式为0.YZ。