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),一个产品可以有多个基线，也可以只有一个基线。
基线的主要属性有：名称、标识符、版本、日期等。
CMMI_配置管理员访谈问题及答案
CM访谈1．是否有独立的配置管理组？有组织级的配置管理员吗？CM GP2.4提示：公司建立了一个质管部，配置管理组属于质量管理部配置管理组由组织级配置管理员（建立配置管理系统、对公司的产品库进行管理、对项目级的配置管理员进行培训指导）和项目级的配置管理员组成。
2．你是如何知道自己是项目中的配置管理员的？CM GP2.2 、GP2.4提示：《立项报告》确定了该项目的配置管理员，同时在《配置管理计划》、《项目计划书》具体进行了说明。
项目级的配置管理员的职责：编写《配置管理计划》、《基线发布报告》，建立配置库目录结构、执行配置审计、报告配置项状态、管理配置库、控制配置项变更。
3．每个项目都有CCB吗？通常由哪些角色组成？他们的职责有哪些？CM SP1.3 ；GP2.4、 GP2.7、GP2.10 每个项目都有CCB（配置控制委员会），通常是由项目经理、QA人员、CM人员等组成。
CCB职责：审批《配置管理计划》; 审批基线的建立和发布；审批配置项、基线的变更。
4．你是如何制定配置管理计划的？在什么时间？权限设置、目录结构设置？CM GP2.2提示：在项目立项后，根据《项目计划》、配置管理过程文件及相关指南、模板制定《配置管理计划》。
《配置管理计划》经项目组评审，提交CCB审批。
配置管理员依据《配置项及配置库定义指南》进行设置，权限设置、目录结构在《配置管理计划》详细描述。
5．你参加过哪些方面的培训，是否给项目组、相关组做过配置管理方面培训？ OT SP1.3提示：（1）首先参加了CMMI相关知识方面的培训和配置管理方面的培训，如配置管理工具VSS、公司配置管理规范、指南的培训等。
（2）组织级配置管理人员对项目级配置管理人员、项目组人员进行配置管理的指导和培训。
6．配置管理计划包括哪些方面内容？是否发生过计划变更？如何进行变更？CM GP2.10提示：《配置管理计划》包括人员、职责、软硬件资源、配置库结构、基线计划, 配置库备份计划、配置报告计划和配置审计计划等。
CMMI配置管理计划
CMMI配置管理计划项目配置管理员负责数字签名项目的配置管理，包括配置项的识别、控制、审计和变更管理等。
同时，还需与项目经理、开发团队、测试团队等相关人员建立良好的沟通和协作关系，确保配置管理活动的顺利进行。
2.1.2配置控制委员会配置控制委员会是数字签名项目的决策机构，由项目经理和各相关组织的代表组成。
委员会负责审定项目基线的建立和配置项/单元的标识，评审和审定对项目基线的更改，审定对项目基线库制造的产品的生成。
配置管理员应该与配置控制委员会保持密切的联系，及时向其汇报配置管理的情况，以便委员会能够及时做出决策。
2.1.3项目经理项目经理是数字签名项目的领导者，负责项目的整体规划、组织、实施和控制。
在配置管理方面，项目经理需要与配置管理员、配置控制委员会等相关人员协作，确保配置管理活动符合项目的整体计划和目标。
2.1.4开发团队和测试团队开发团队和测试团队是数字签名项目的核心团队，他们负责开发和测试项目的软件产品。
在配置管理方面，他们需要与配置管理员密切合作，确保软件产品的配置项得到正确的识别、控制和变更管理。
2.2配置管理活动2.2.1配置项识别配置项是指作为单个实体进行处理的硬件、软件或两者的集合。
在数字签名项目中，配置项包括软件产品、文档、测试数据等。
配置管理员需要确定哪些项是配置项，以便进行后续的配置管理活动。
2.2.2配置项控制配置项控制是指对配置项进行标识、版本控制、访问控制等，以确保配置项的正确性和完整性。
配置管理员需要使用相应的工具和流程对配置项进行控制，防止配置项的误用或丢失。
2.2.3配置项审计配置项审计是指对配置管理库系统的结构和设施进行审核，以验证软件基线库内容的完备性和正确性，验证与适用的配置管理标准和规程的符合性。
配置管理员需要定期进行配置项审计，确保配置管理库的正确性和完整性。
2.2.4配置项变更管理配置项变更管理是指对配置项进行变更控制，以确保变更的正确性和可追溯性。
CMMI-配置管理计划
EPG过程改进项目_x001D_ 配置管理计划广东×××技术股份有限公司修订历史记录目录1人员及职责 (4)2软件硬件资源 (4)3配置项计划 (4)4基线计划 (5)5配置库备份计划 (5)6版本控制规则 (5)7变更控制规则 (6)1人员及职责2软件硬件资源3配置项计划4基线计划5配置库备份计划6版本控制规则文档版本号规则文档版本和配置管理中的版本概念不同，它指的是文档的发布版本。
1、处于“草稿”状态（开发库）的文档的版本号格式定义为:0.YZ.➢YZ数字范围可以为01～99。
➢随着草稿的不断完善, “YZ”的取值应不断递增。
2、处于“正式发布”状态（基线库）的文档的版本号格式定义为:X.Y。
➢X为主版本号,取值范围为1～9。
Y为次版本号,取值范围为1～9。
➢如果文档第一次“正式发布”时,版本号为1.0。
➢如果文档的版本升级幅度比较小,一般只增大Y值,X值保持不变。
只有当文档版本升级幅度比较大时,才允许增大X值。
3、处于“正在修改”状态（开发库）的文档的版本号格式定义为:X.YZ。
➢文档正在修改时,一般只增大Z值,X.Y值保持不变。
➢当文档修改完毕,状态重新成为“正式发布”时,将Z值设置为0,增加X.Y值。
注：产品发布后要注意产品发布版本号与VSS版本号的对应关系7变更控制规则基线了的配置项需要修改的时候按照《配置变更控制规程》执行。
具体操作如下：配置管理员向CCB提交变更申请（变更申请表合并在《项目、产品变更表》中，由项目经理一起提交给CCB）。
如果CCB同意变更,CMO给项目组足够的权限修改同意变更的配置项，CCB 督促变更任务的执行，项目组修改完成后，CMO审核变更后的配置项，审核通过后发布变更的配置项；如果不同意变更，终止变更。
无论配置项变更是否同意，最终由CMO保存变更申请单。
对于那些在“变更控制和管理流程”中确定的小型变更则不必执行此配置变更规程，只需项目组口头向CMO申请变更，项目组修改后由CMO审核通过即可，并通知项目组。
cmmi配置管理CM
Tool configurations 工具配置
Code and libraries 代码和库
Compilers 编译器
Test tools and test scripts 测试工具和测试脚本
Installation logs 安装日志
An example of a baseline is an approved description of a product that includes internally consistent versions of requirements, requirement traceability matrices, design, discipline-specific items, and end-user documentation. 例如，被批准的产品说明是一个基线，它是由需求、需求跟踪矩 阵、设计、特定专业项目及最终用户文档构成的内部一致的版本。
配置管理（CM）的目的是通过使用配置识别、配置控制、配置 状态记录及配置审计，来建立和维护工作产品的完整性。
Introductory Notes 简介
The Configuration Management process area involves the following activities: 配置管理过程域包括以下活动：
This process area applies not only to configuration management on projects but also to configuration management of organizational work products such as standards, procedures, reuse libraries, and other shared supporting assets. 本过程域不仅适用于项目的配置管理，也适用于组织工作产品（如 标准、规程、重用库和其他共享的支持资产）的配置管理。
基于CMM和CMMI的配置管理(一)
基于CMM和CMMI的配置管理（一）1 配置管理内容的逻辑关系在CMM和CMMI中，将配置管理的目的定义为“建立和维护产品的完整性”，这个目标没有提到对项目管理的支持，也就是说，它定义的配置管理的目标比当前业界对配置管理的认识有些缩小。
但是，仔细分析可以发现“建立和维护产品的完整性”是其他配置管理目标的基础。
下面就从这个目标出发进行分析。
逻辑关系见下图：配置完整性（对标准的理解）1. 产品完整性：就是项目提交的工作成果是“产品集合完整、子产品的正确”的2. 产品集合完整：产品包含的子产品（配置项）是完整的3. 子产品的正确：子产品（配置项）达到了需求要求，满足标准、规程的要求逻辑关系分析1. “基线管理”支持“产品集合完整”，明确产品的“子产品”（配置项）集合，并进行管理和控制2. “配置项管理”，提供了了对子产品（配置项）的控制管理，支持“子产品的正确”3. “变更管理”，同时支持“产品集合完整、子产品的正确”，用于控制子产品（配置项）和产品（基线）的变更4. “配置标示”，建立对配置项（子产品）的识别、命名，支持“配置项管理”5. “版本控制”，控制配置项（子产品）生命历程，保留配置项（子产品）演进历史6. “过程管理”，就是对配置项、基线的建立、变更的状态标示、过程控制，保证产品（或子产品）按照规定的流程进行了操作；例如“配置项”进入“基线”的过程包括：配置项标示、产品验证、进入配置、配置审计等7. “配置计划”、“配置库管理”、“配置审计”、“配置报告”等是整个配置管理得支持系统。
提供了配置管理“可视性”和监督管理2 配置和配置项在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。
因此“配置”包括了即将受控的所有产品特性，其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的“配置”包括更多的内容并具有易变性。
CMMI各种缩写及内容
CMMI主要内容有：1．CM：（Configuration Management）软件配置管理。
建立和维护在项目的整个软件生存周期中软件项目产品的完整性。
2．DAR：（Decision Analysis and Resolution）。
应用正式的评估过程依据指标评估候选方案，在此基础上进行决策。
3． IPM：（Integrated Project Management）集成项目管理。
根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。
4． Life Cycle：（Software Life Cycle Model）项目管理的生命周期。
关注的是项目的过程管理。
5．MA：（Measurement & Analysis）。
开发并持续发展度量能力以满足项目管理的信息需求。
6．Milestone Review：（Milestone Review）阶段评审。
在阶段结束时评审项目的状态并确定项目是否应该进入下一阶段。
7．OPD：（Organizational Process Definition）组织级过程定义。
建立和维护有用的组织过程资产。
8．OPF：（Organizational Process Focus）组织级过程焦点。
在理解现有过程强项和弱项的基础上计划和实施组织过程改善。
9．OT：（Organizational Training）培训管理。
增加开发人员的技能和知识，使他们能有效地执行他们的任务。
10. PI：（Product Integration）产品集成。
从产品部件组装产品，确保集成产品功能正确并交付产品。
11． PMC：（Project Monitoring and Control）项目监督与控制。
通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目。
CMMI中配置管理
基线管理的步骤： 基线管理的步骤： 1、在开发前确定基线的“配置” 2、基线批准前，根据“配置”检查配置项是否齐备 3、对各个配置项，确认其版本的正确性 4、对每个配置项建立基线标志， 5、基线变更管理 6、基线的各类报告和审计信息
变更管理
在有效标示了配置并进行了管理之后，如何保证它们在复杂多变得开发 过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一 历史状态就要依赖以下的变更管理。
基线 在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间 点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基 线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了 元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一 般在指定的里程碑处创建，并与项目中的里程碑保持同步。 一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基 线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的 出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进 行功能评审的基础。 每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更 控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增 加和修改的基线内容形成下一个基线，这就是“基线管理”的过程。
1. 产品完整性：就是项目提交的工作成果是“产品集合完整、 子产品的正确”的 2. 产品集合完整：产品包含的子产品（配置项）是完整的 3. 子产品的正确：子产品（配置项）达到了需求要求，满足 标准、规程的要求
பைடு நூலகம்
配置和配置项 在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技 术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置” 包括了即将受控的所有产品特性，其内容及相关文档，软件版本，变更 文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素， 相对与硬件类配置，软件产品的“配置”包括更多的内容并具有易变性。 受控软件经常被划分为各类配置项（Configuraion items, CIs），这类 划分是进行软件配置管理的基础和前提，CIs是逻辑上组成软件系统的各 组成部分。比如一个软件产品包括几个程序模块，每个程序模块及其相 关文档和支撑数据可能被命名为一个CI。一个系统包括的CIs的数目是一 个与设计密切相关的问题。一个纯软件的CI通常也称之为软件配置项 （CSCI）。 现在所有的配置管理工具均提供对配置项的管理工具，包括(Check in 和Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比 较繁琐，一般推荐使用配置管理工具，减少事务性工作。
CMMI3配置管理文件
基础管理篇
之（一）
1
配置管理（CM)
Agenda
项目中的CM问题 CMMI中CM过程域描述与定义 CM的实践 CM工具
3
项目中的CM问题
4
开发中典型的CM问题
发错了版本 安装后不工作 异地不能正常工作 已经解决的缺陷过后又出现错误 开发人员把产品拿出去出售赢利 找不到最新修改了的源程序
5
CMMI模型有关CM实践解析
基线是一组配置项(CI)的集合：
– 经过了正式的评审和批准 – 作为进一步工作的基础 – 变更必须经过正式的变更控制程序
不同的基线可能：
– 在开发的不同阶段建立 – 控制权限会有不同
1.2 定义基线
31
推荐的基线
基线 需求 开发 运行 何时建立 客户需求评审 概要设计评审 发布给客户 CCB 项目经理 CCB 控制者
职能：
– – – – 确保变更被分类以及被评估 评审和批准变更 确保只有被批准的变更得到实施 决定需要实施的变更的优先级
变更控制活动必须在整个项目中具有可视性 CCB成员可能包括： 项目经理，配置管理员，质 量保证人员，开发人员代表，客户代表
36
CCB主席的职责
设立接收变更的标准 发起对请求的变更的评估 从CCB成员获取建议的行动方案 解决关于变更请求的争议 做出CCB负责的裁决的最终决策 记录CCB会议纪要，记录 CCB对变更请求的 处理行动
ISO 20000与CMMI配置管理的比较分析
ISO 20000与CMMI配置管理的比较分析ISO20000配置管理与CMMI配置管理的比较分析ISO9000是一个公司级的管理标准，CMMI是研发活动的管理模型，ISO20000是运维服务的体系标准，三者专注不同的活动领域，经过咨询认证之后，组成企业管理体系。
其中CMMI的22个过程与ISO2000的13个过程，都包含同一个过程—配置管理过程。
公司通过ISO9000及CMMI5认证已有多年，并已经建立、持续改进成熟的管理体系，现在要通过ISO20000认证，且不说ISO9000、ISO20000与现有体系的无鏠融合问题， ISO20000与CMMI都有配置管理，他们有什么差异性呢?让我们一起分析比较一下：1、服务范围。
前者支持标准本身其它的12个过程，后者支持模型本身其它的21个过程。
2、服务对象。
前者主要支持运维活动;后者主要支持研发活动。
3、配置项定义。
前者主要分为三大类：硬件类、软件类、网络链路的信息，主要是指硬件网络设备的信息，作为配置项，纳入CMDB中进行管理。
而如：事件管理、问题管理等流程情文件，不作为配置项纳入配置管理;后者作为配置项的范围并没有进行特别的说明，范围比较广泛，所有纳入配置管理的项都称为配置项，但主要是指文档和源代码。
4、配置与变更。
在ISO20000中，配置管理与变更管理是独立但有关联的两个过程;CMMI中，配置管理包含有变更管理，变更管理是配置管理的一个组成部分。
5、关于配置审计。
20000强调实物与配置信息的一致性，而CMMI的配置审计检查文档的正确性、与体系的一致性。
6、配置基准。
两者有定义有标准(基线)，20000中的基线定义，如：新机品的标准配置，CMMI定义了文档、产品的版本。
7、关于版本。
CMMI比20000更强调版本的概念、版本管理。
8、配置流程活动。
两者基本相同，都包含有规划、识别、控制、审计。
以上根据个人理解体验总结而成，为标准、体系、过程之间的融合作为参考，希望对大家有所帮助，关于ISO20000与CMMI的比较分析，需大家进步学习研究。
- 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配置管理的概念和重点有所认识了。
配置管理工作是贯穿整个项目生命周期的核心工作之一，只有利用配置管理的理论把项目条理化、清晰化，那么才能开展例如需求、设计、开发、测试等其他工作。
通过本篇文章笔者希望大家知道什么是配置项和基线，配置库是如何划分的，为什么软件项目会有变更，同时我们也要正视和接受变更的存在，以及配置管理员是如何进行功能和物理审计的。