CMMI 配置管理
CMMI 3标准文档模板-配置管理-配置管理计划
CMMI 3标准文档模板-配置管理
{ 项目名称}
配置管理计划
Company Information
版本历史
目录
1. 人员及职责 (4)
2. 配置管理软硬件资源 (4)
3. 配置项计划 (4)
4. 基线计划 (5)
5. 配置库备份计划 (5)
附录：本计划审批意见 (6)
1. 人员及职责
提示：
（1）根据《项目计划》中的角色分配，确定配置管理员，CCB（配置控制委员会）成员。
（2）CCB的人数根据项目规模而定。
一般地，项目经理是CCB的负责人。
2. 用于配置管理的软硬件资源
提示：
（1）配置管理员确定本项目的配置管理软件。
例如采用Microsoft公司的Visual SourceSafe或者Rationa公司的l ClearCase。
（2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑内存、外存、CPU 等）。
3. 配置项计划
提示：配置管理员标识配置项，估计每个配置项的正式发布时间。
标识符的参考格式为Project-Type…Type-Number。
例如：
4. 基线计划
5. 配置库备份计划
提示：配置管理员制定配置库备份计划，指明“何人”在“何时”（频度）将配置库备份到“何处”。
附录：本计划审批意见。
CMMI配置管理规程
配置管理广东×××技术股份有限公司修订历史记录目录1目的 (4)2适用范围 (4)2.1机构 (4)2.2业务 (4)3名词术语 (4)4概述 (5)5过程定义 (5)5.1配置管理 (5)5.1.1 角色与职责 (6)5.1.2 入口准则 (6)5.1.3 输入 (6)5.1.4 过程活动 (6)5.1.5输出 (8)5.1.6 出口准则 (9)5.1.7 过程度量 (9)5.1.8 确认与验证 (9)6规程 (9)7标准与规范 (9)8裁剪指南 (9)9模板与表格 (9)10实施指导 (10)运用配置标识、版本控制、配置变更控制、配置审计，以及通过使用配置管理软件，来保证所有配置项的完整性和可跟踪性。
2适用范围2.1机构研发中心技术部门及PMO、技术拓展部。
2.2业务贯穿整个项目的配置管理活动。
3名词术语3.1 PP（Project planning）：项目策划。
3.2项目干系人（Stakeholder）：在一定程度上，对项目的实施和成果负责，或受其影响的群组或个人。
项目干系人可能包括项目团队成员、提供商、客户、最终用户等。
3.3 PMO（Project Management Office）：项目管理办公室。
3.4 CCB(Changing Control Board)：变更控制委员会。
3.5 CM(Configuration Management)：配置管理。
标识和确定系统中配置项的过程，在系统整个生命周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。
3.6 CMO（Configuration Management Officer）：配置管理员。
3.7 基线：基线就是项目存储库中每个工件版本在特定时期的一个快照。
在配置管理系统中，基线就是一个CI或一组CI在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。
【CMMI认证】CM访谈问题 - 配置管理员 -(含答案)
一、CM 配置管理（访谈角色：CM、CMO）1、组织/项目中识别了哪些配置项，是依据什么识别的？CM 2.1答：⚫组织中主要配置项有：过程改进计划、改进建议、过程改进总结报告、年度培训计划等⚫项目中主要配置项目有项目计划书、用户需求说明书、需求规格说明书、系统设计说明书、源代码、测试用例、用户手册等。
⚫是依据公司EPG小组制定的《配置项识别指南》和项目过程定义书（PDP）来识别项目配置项的。
2、你们采用什么软件进行配置管理？配置管理系统提供哪些功能？CM 2.2答：我们采用GIT（这里根据公司实际情况回答）进行配置管理，配置管理系统主要提供了源代码和文件的管理功能，比如操作用户角色定义、权限分配、文件存档、配置库备份、版本恢复等功能。
3、组织/项目中建立了哪些基线？基线建立的流程是怎样的？CM 2.3答：⚫组织中建立的基线有OSSP（组织软件过程规范）版本基线⚫项目中建立的基线有计划基线、需求基线、设计基线、开发基线、测试基线、交付基线等。
⚫基线建立流程是：根据项目整体计划安排制定基线发布计划，在项目各里程碑节点对评审通过后的阶段配置项进行基线发布，把配置项纳入到基线区。
发布基线通知，基线通知中有基线名称、配置库位置、包含的配置项、发布人、发布日期等。
4、配置项/基线是如何进行变更控制的？CM 2.4答：如果项目中出现需求变更时，则需要执行配置变更。
首先责任人进行变更申请，包括需求变更内容、影响的阶段、变更期限、责任人等，并与CCB（配置变更委员会，一般包括项目经理、需求、项目核心成员、QA、CM等）一起进行评审，最后确定变更。
如果需要变更，则在后面的阶段跟踪变更后的配置项的修改记录、修改内容等。
5、配置管理产生哪些记录？如何了解配置项/基线的状态？CM 2.5答：配置管理产生了配置管理计划、识别的配置项、配置审计记录和报告、配置项状态表等记录，项目组成员是通过配置项状态表来了解配置项和基线的状态。
配置管理实现CMMI
§1. 基线管理§1.1 识别配置项1. CMMI要求：具有文档化的配置项选择准则，并依据该准则进行选择配置项和确定组成配置项的工作产品。
注：关键差距在于有没有这个文档作为指导。
2. CMMI要求：具有配置项标识规范，并为每个配置项分配唯一标识。
注：个人认为标识规范的文档部分可以和质量保证的命名规范合在一起。
3. CMMI要求：要说明每个配置项的重要特性，例如：作者、代码语言、存放位置等注：对于产品开发型公司，最好为每一个较复杂的产品整理一份资产结构图，将各模块、配置项用图的形式列出来（用visio画并维护），写明特性。
4. CMMI要求：说明每个配置项何时纳入配置管理，如何时入库、该配置项的变更受何种控制级别。
注：原文，确定何时将工作产品纳入配置管理的准则的示例如下：[PA159.IG101.SP101.SubP104.N101]• 项目生命周期阶段• 工作产品何时可供测试• 工作产品所需要的控制程度• 成本和进度限制• 客户需求我觉得这一子实践实际上做到“说明何时入库”、“所需要的控制程度”这2点就可以了，这一点应该是在配置管理计划的配置识别章节里描述5. CMMI要求：确定每个配置项的负责人。
§1.2 建立配置管理系统本节工作产品：包括受控工作产品的配置管理系统、配置管理系统访问控制规程、变更请求数据库。
1. CMMI要求：建立包含多个配置管理控制等级的控制机制。
注：如包含权限控制规范，变更控制规范：不同的基线级别采用不同的控制等级。
2. CMMI要求：在配置管理系统中存和取配置项。
注：按照等级控制进行存和取，对基线的变更要履行变更流程。
3. CMMI要求：在配置管理系统中不同等级之间共享和传递配置项。
注：这是发布基线/rebase动作。
4. CMMI要求：存储并恢复归档的配置项版本。
CMMI-配置管理计划
项目编号：项目名称：数字签名配置管理支配状态 草稿标识号V1.0初始版当前版本修订版发布日期2C1模板编号密级 无密级 秘密 绝密修订历史记录日期版本说明作者变更恳求号0.1起草李晓娅1.0发布李晓娅目录1.简介41.1目的41.2范围41.3定义、首字母缩写词和缩略语41.4参考资料51.5概述52.软件配置管理52.1组织、职责和接口52.2工具、环境和基础设施63.配置管理活动93.1配置标识93.2配置项变更限制103.3配置管理活动支配113.4报告和审计144.培训和资源154.1培训所需环境154.2培训参与人员164.3培训具体支配165.分包商和厂商软件限制16配置管理支配1.简介1.1目的在数字签名项目的生命周期内，为了保证该项目工作产品、过程记录及项目相关资料的版本统一和完整，特制定本支配。
1.2范围纳入数字签名项目配置管理的配置项、过程记录及其它相关资料。
1.3定义、首字母缩写词和缩略语本小节应供应正确理解此配置管理支配所需的全部术语、首字母缩写词和缩略语的定义。
这些信息可以通过引用项目词汇表来供应。
配置管理。
1.3.1配置项（ )指定为配置管理的对象且作为单个实体进行处理的硬件、软件或两者的集合。
1.3.2基线（）一种通过正式评审和认可的规范说明或产品，此后将其作为进一步开发的基础，只有通过正式的变更限制过程才可以变更。
1.3.3基线库（）项目软件生命周期中基线的集合。
用软件工具管理时，基线库可以是一个独立的系统，也可以是系统中的一个书目。
1.3.4配置审计（）审核配置管理库系统的结构和设施，验证软件基线库内容的完备性和正确性，验证及适用的配置管理标准和规程的符合性1.3.5配置限制委员会（）有权力管理项目基线的委员会，它代表项目经理和全部可能受到项目基线更改影响的组的利益，由它审定项目基线的建立和配置项/单元的标识，评审和审定对项目基线的更改，审定对项目基线库制造的产品的生成。
全套CMMI（信息系统项目管理）文档模板-配置管理方案
全套CMMI（信息系统项⽬管理）⽂档模板-配置管理⽅案配置管理⽅案⽬录1简介 (2)1.1⽬的 (2)1.2适⽤范围 (2)1.3术语表 (2)1.4参考资料 (2)1.5职责描述 (2)2配置管理活动 (3)2.1软件资源与硬件资源 (3)2.2标识配置项 (3)2.2.1配置项标识规则 (3)2.2.2配置项名称格式说明 (4)2.2.3配置项 (4)2.3项⽬基线管理 (4)2.3.1基线列表 (5)2.3.2基线建⽴流程 (5)2.3.3基线的变更控制 (6)2.4发布管理 (7)2.5配置库管理 (7)2.5.1各类库结构 (7)2.5.2库的权限设置 (8)2.5.3库的备份与恢复 (8)2.6配置状态的记录和报告 (8)2.7配置审计 (8)2.8⼈员安排与时间安排 (9)3数据资料管理计划 (9)1简介1.1 ⽬的本计划是⽤来指导项⽬配置管理作业的过程与步骤，以便全⾯地管理、保存软件⽣命周期各个配置项，监控各配置项的状态，让⼩组所有成员能及时了解软件基线的状态和内容，从⽽实现对软件过程的控制，持续改进软件流程，保证软件产品质量、降低风险，实现项⽬规划的所有需求，同时提⾼开发团队的⼯作效率、降低软件开发成本。
1.2 适⽤范围本项⽬中纳⼊配置管理的活动：项⽬管理⽂档(如项⽬计划、配置计划等)、项⽬技术⽂档（需求规格说明书、概要设计等）、源程序及模块⽂档、基线、产品、⽤户⽂档、项⽬⼯具。
1.3 术语表1.4 参考资料⽆1.5 职责描述表2-12配置管理活动配置活动的⽬的是向项⽬组每⼀个⼈传达在本项⽬中如何进⾏配置。
参见《配置管理过程⽂件》。
2.1 软件资源与硬件资源2.2 标识配置项2.2.1配置项标识规则项⽬级的配置项是指由于项⽬实施⽽产⽣的记录。
为了便于查询、搜索今后各项⽬的⽂档及版本，下⾯将专门制订⼀套约定，统⼀、规范项⽬的命名格式。
凡进⼊项⽬级配置管理库下的⼯作产品都应依照下列命名约定进⾏。
cmmi对配置管理的定义
CMMI（Capability Maturity Model Integration）是一种用于评估和改进组织过程能力的模型。
在CMMI中，配置管理（Configuration Management）被视为一项重要的过程领域，它有以下定义：
配置管理是一种系统化的方法，用于识别和管理软件和系统开发生命周期中的配置项。
它包括对配置项进行标识、控制、审查和记录，以确保产品和过程的正确性、一致性和完整性。
配置管理在CMMI中被视为一个关键过程领域，涵盖了以下关键实践领域：
1. 配置管理计划（Configuration Management Planning）：制定和维护配置管理计划，确定配置管理的目标、活动和责任。
2. 配置标识（Configuration Identification）：为配置项分配唯一的标识符，并跟踪配置项及其变更的版本和状态。
3. 变更控制（Change Control）：管理对配置项的变更请求，包括评审和批准变更，确保变更的正确性、合理性和一致性。
4. 配置状态记录（Configuration Status Accounting）：记录配置项的状态和历史变更信息，跟踪配置项的版本和配置状态。
5. 配置审核（Configuration Audit）：定期进行配置项的审查，验证配置项是否符合规定的要求和标准。
通过配置管理的实践，组织能够更好地控制和管理软件和系统开发过程中的配置项，确保其一致性、可追溯性和可控性，减少配置相关问题的风险，提高产品质量和开发效率。
CMMI3级软件过程 第17章 配置管理
第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),一个产品可以有多个基线，也可以只有一个基线。
基线的主要属性有：名称、标识符、版本、日期等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
CMMI之配置管理
2008-01-11 作者：张瑾来源：希赛网
在笔者进行CMMI咨询时，当问及软件技术人员什么是”配置管理”的时候，很多人的回答就是“版本管理”，而且很多人都会说出各种各样的版本管理工具，例如：VSS、TFS、CVS或SVN等等。
但这样的回答是不正确、不全面的。
版本管理只是软件配置管理的一个小的部分，在CMMI中配置管理分为“配置项和基线的管理”、“变更控制管理”和“基线的完整性”三个部分。
凡是提到软件“配置管理”（Configuration Management），我会先给它下个定义：“它是软件工程的核心部分，是CMMI中最基础的PA”。
为什么它会如此重要呢？首先配置管理的工作就是确保软件项目时时保持条理清晰，随时想要任何工作产品都可以迅速找到，并且工作产品的内容不会出错，这也就是大家常讲的可回溯性、完整性和正确性；其次软件配置管理活动始终贯穿整个软件项目的生命周期。
因此说软件配置管理是最基础、最核心的管理工作一点都不夸张。
(一) 软件配置项
在CMMI的“配置管理”过程域CM中SP1.1首先提到的就是“配置项”的概念，在大家开展配置管理工作前应该先识别哪些是本项目的配置项。
“配置项”就是配置管理的对象，简单来讲它符合以下任意一个特点：
1、它会被两个或两个以上的项目成员共同使用。
2、它会随着项目的开展而发生变化。
3、对项目重要的工作产品。
4、一些工作产品之间的关系非常紧密，一个变化其他的就会受到影响。
通过以上定义大家会发现项目中的很多东西都属于配置项，例如：各种需求文档、设计文档等都会经常变更；程序的代码是大家共享的，而且代码文件之间又有较高的相互依赖性。
那大家也许会发现还有一些工作产品不符合以上定义，例如：各种周报、会议记录等。
这些也是配置项
吗？很显然，它们不符合以上特点，那么这些工作产品就不属于配置项的范围，但有时在进行CMMI实施时，项目组也往往会将其一并进行管理。
既然配置项是“配置管理”的基础，那么大家还需要给每一个配置项起一个唯一标识，这样才能够做到清晰不混淆。
举个例子：“今晚大家一起出去聚餐，到中山一路的‘东北人’吃饭”，这里的‘东北人’餐厅是特指中山一路的，因此这唯一确定了就餐的地点；“我们订的包房叫‘靠山屯’”，这里具体的就餐房间也被唯一标识了出来，是‘靠山屯’而不是‘瘦狗岭’；服务员拿来的菜单上每个菜的名字也是唯一的，这样送上来的菜就不会重样，当我们吃完结账的时候就不会算错价钱，这些都是典型的唯一标识配置项的例子。
假如配置项没有被唯一识别出来，那么大家去聚会就会找错地方，点的菜也可能会上错，结账的时候也可能会算错，那么将是一团糟，因此在项目管理中一定要将识别配置项重视起来。
配置项本身的变化可以使用“版本管理”对其进行控制。
通常像大家的程序代码已经被各种版本管理工具进行控制，但大家千万不要忘记对文档也要进行版本管理。
(二)软件的基线
前面提到“配置项”的其中一个定义就是“配置项可能会随着项目的开展而发生变化”，那么单个的配置项是通过版本管理工具进行管理的，每次变化都会产生一个新的版本号。
但是对于一组配置项该如何进行管理呢？根据CMMI配置管理过程域的SP1.3中的要求，这就需要使用基线管理的方法。
简单来讲就是将一组配置项拿“线”穿起来作为一个整体进行统一命名，并将其作为一个新的配置项进行管理。
在上面聚餐的例子中，最后结账时的账单就是一条基线，它将所有菜肴集中起来一起买单。
(三)配置库的划分
配置库就是指各种版本管理工具所创建的用于管理配置项的数据库，也就是大家常用的VSS或CVS等工具创建的数据库或文档库。
笔者在以往进行的CMMI咨询时常常发现项目组对配置库的目录结构没有进行功能的划分，为了确保项目永远不会出现混淆，简单来说按照权限应该将配置库划分为三大类，如图1-1所示：
1、开发库
2、受控库
3、基线库
图1-1 配置库示意图
各种控制库的划分是根据其访问权限来定义的，在没有进行CMMI认证的公司，通常项目组的配置库只起到“开发库”的作用。
以CMMI配置管理SP1.2中的理论为依据，“开发库”对项目组成员具有比较宽松的“CheckIn”和“CheckOut”的权限。
不会给大家的工作带来不便，根据大家的需要随时都可以对其保管的配置项进行各种操作。
“受控库”对项目组成员来说是没有“CheckIn”和“CheckOut”的权限的。
对“受控库”的操作只能由配置管理员来完成。
因为受控库中存放的是等待评审的文档或待测试的程序。
假如有份文档要送去评审，会议的主持人已经将其进行了分发，可是这份文档却保存在“开发库”中，如果这时被别人修改了，那么之前所分发的文档就是旧的，那随后的评审也就没有意义了，这就是“受控库”存在的意义。
“基线库”就是对“受控库”中通过验证的工作产品所形成的基线进行统一管理，并且新的基线将按照要求发送给项目的相关人员并与其分享项目的状态和信息。
大家回想一下以往发布给客户的版本是否可以找到全部的程序和文档，如果找不到那就请从现在开始使用“基线库”进行管理吧：）
(四)软件变更管理
软件开发项目经常出现变更，但大家千万不要对项目中的变更产生恐惧，在项目管理的先进理念中“变化是永恒的，不变是短暂的”，“没有计划就没有变化”。
大家应该正视软件变更的存在，它是软件世界中客观存在的一种现象，就像初一、十五大海的潮汐一样。
在CMMI配置管理的SP2.1中就变更管理的流程和规范进行了定义。
1、软件变更的起因
为什么会出现软件变更呢？这要从软件项目的性质出发进行探讨。
PMP定义的项目特点是“临时性”和“独特性”，大家就算把已经完成的项目重新再做一遍，其过程也不可能是一模一样的。
其实软件开发就是将客户脑子里主观的思想转换为客观的代码行，主观的东西都是虚无缥缈的，根据人的意识会经常改变的；另外软件开发就是将企业的最佳实践转化为客观的产品，接受需求调研的客户一般都是他们行业中的佼佼者，他的思想就是企业的最佳实践，这些最佳实践也许连他的同事都不一定完全理解，何况是我们这些做软件开发的技术人员。
通过以上软件开发项目的特点进行分析，大家应该也理解了为什么软件开发会有那么多的变更了吧。
除了应该理解变更的起因外，还应该让我们的客户对变更的起因有所认识，做到大家互相理解，和谐的项目才是共赢的。
另外大家不要以为变更给项目带来很多麻烦，有时变更也会为项目带来效益，技术的革新就是一种特殊的变更，在我国实现现代化建设的过程中不知道有多少技术革新为国家带来或挽回数以亿计的财富，在我们的软件项目中一些新的技术或架构，也一样会减少项目的开发周期和成本。
2、软件变更的必要性
变更会有其相应的流程，有流程就会有工作量，有人会觉得变更太麻烦没有必要，在笔者进行CMMI 咨询时往往推荐两种级别的变更：“一般变更”和“重大变更”。
“重大变更”常指里程碑的延误、项目组成员的变化、项目成本的变化，具体每种变化有多大才算是重大变更呢？这就要针对不同公司的不同情况来定义。
为什么重大变更没有定义软件范围也就是需求的变更
呢？因为需求的变更可以通过项目里程碑的延误或项目成本的增加来判断。
重大变革要走正规的变更流程，并且要通过“变更控制委员会”CCB的评审通过后才能实施。
除了“重大变更”以外的都属于“一般变更”，例如项目进度虽然有延迟，但是不会影响项目里程碑。
“一般变更”不再需要CCB的评审，项目负责人就可以全权处理。
通过对变更级别的划分，给项目负责人一定的权利，这样项目变更就不会让人觉得繁琐了。
(五)配置管理的审计
配置审计的目的是配置管理员要确保配置库中的配置项和基线的完整性和正确性，这就是CMMI配置管理SP3.2所提到的概念。
在“开发库”中的配置项是不需要进行审计的，一旦带有缺陷的配置项进入“受控库”或“基线库”，那么将会给项目带来不小的负面影响。
配置管理的审计分为“物理审计”和“功能审计”两种。
“物理审计”比较简单，配置管理员只需根据项目组提交的“入库清单”逐一检查文档或程序是否存在，命名规则是否符合规范既可。
“功能审计”的理解会相对比较复杂一点，“功能审计”是对配置项的内容是否正确进行检查。
但配置管理员有可能是不懂技术的，那么他将如何开展功能审计呢？进入“受控库”或“基线库”的文档肯定是经过并通过评审的，代码程序也肯定要经过并通过测试的，因此配置管理员可以利用这些验证的结果来间接对其入库的内容进行检查。
这样配置管理员就可以保证其功能的正确。
(六)总结
通过以上内容的介绍，相信大家应该对CMMI配置管理的概念和重点有所认识了。
配置管理工作是贯穿整个项目生命周期的核心工作之一，只有利用配置管理的理论把项目条理化、清晰化，那么才能开展例如需求、设计、开发、测试等其他工作。
通过本篇文章笔者希望大家知道什么是配置项和基线，配置库是如何划分的，为什么软件项目会有变更，同时我们也要正视和接受变更的存在，以及配置管理员是如何进行功能和物理审计的。