❶ 论述软件项目管理过程中如何开展好配置管理工作
1、配置管理员水平很重要。
2、领导要很重视（比如告诉他代码需要控制不同的权限，集中保存防止出现各种意外比如离职泄露啊，电脑坏了啊等等，与开发过程相关的就不用说了，他不关心的）。
3、项目经理要很重视，很多项目经理本身是技术出身，可能管理跟的不是那么上~.~。
4、项目成员有这样的概念。
以上是前提。
开展配置管理工作的关键是让公司内部的项目干系人的人感觉到配置管理工作在起作用。
最重要的手段：
针对不同的人进行不同层次的培训。
1、对于老板/总监/技术老大/项目老大等等所有项目的统筹负责人，可以做一些月度季度年度报表PPT什么的告诉他你做了什么。取得了什么样的效果。
2、对于项目经理们或者准项目经理们，做配置管理里关于流程方面的培训（比如配置项管理、基线管理、变更管理、构建管理、版本管理、发布管理、审计管理、外部发布管理等）、然后就是一些配合不同开发模式（比如瀑布、螺旋、敏捷等）进行配置工具培训、 比如分支开发、自动构建、持续集成等
3、对于普通开发测试等项目组成员，就是培训各类工具的使用了比如svn/git/cc等，比如一些好的操作，版本对比、回退机制、代码共享、同步开发等等。
至于配置管理过程的话，网上一大堆，随便凭记忆总结下，可能不全：
1、从组织上定义标准流程规范制度等。这个规范制度是用来指导配置管理工作的总规范。包括具体的配置管理简介、配置管理过程中涉及到的人的权责、然后就是配置管理实施的策略（比如计划、配置项、基线、变更、发布、审计、报告、服务器管理、配置工具说明、权限管理总则、配置库结构标准、库备份啊、收尾工作比如移交转产交付取消权限刻盘保存等），可能还要定义一个内测版本、外测版本、正式版本号的附则。制作好所有的excel/word/ppt/txt模版。给领导审批通过就OK了。
2、项目开始就后按照组织定义的配置管理流程去做，不断裁剪修改，不同规模的配置管理工作的需求是不同的，要考虑投入产出是否合理，与项目是否适配。
------------------------------------------
以上所有涉及到和领导相关的步奏，请考虑你在公司的实际地位和能力水平，有可能你的项目的配置管理工作没有到这个高度，还只是初级阶段，领导都不知道。一般来说成熟的软件公司、规模比较大配置管理是单独的。如果你只是某个项目的，没有那么高的地位那就只针对本项目的经理和普通成员来操作吧.......~.~
❷ 在工程实施项目中如何开展配置管理工作
实施阶段的配置管理阶段从广义上将已经算是维护阶段了。
代码开发已经结束，配置项已经被基线。
1.理想状况是在测试阶段就模拟出现场环境做安装测试。基本不需要配置管理介入。发现问题也是维护类型bug，发下一个维护版本时解决。这时体现出产品可配置性很重要。
2.最糟的情况才安装实施过程中发现问题必须修改代码重新编译，这个就复杂一些了。
排到现场去的实施人员必须是骨干力量，能够迅速定位问题，或者把出线的问题描述清楚，由后方架构师处理。
修复bug后重新发布紧急维护版本。如果这个过程配置管理没有介入，那后期升级可能会带来代码版本与实施现场的不一致。导致下次实施再次出问题
❸ 如何为所需的配置管理配置配置基线
基线”是一个很常见的术语，在配置管理和项目管理里面都能看到，而且还有很多衍生的术语，例如基线提升、基线化、基线审计，等等等等。 我个人以前对微软的那套开发流程（就是proct cycle model）以及PSP、TSP了解比较多一些，这些流程里面对“...
❹ 关于项目管理中配置管理的实现过程，配置项的知识请教以及相比版本管理的差异
你的理解更多是“产品集成”的概念，即怎么把几个产品模块或构件组合成一个产品，但这不是配置管理的概念。
配置管理：简称CM（Configuration Management的缩写），标识、控制和管理变更的一种管理活动。它控制配置项的修改和发行；记录和报告配置项的状态和变更；保证配置项的完整性、一致性和正确性；以及控制配置项的储存、装载和交付。
根据这个定义，配置管理的主要工作包括：
1）配置库的管理活动。配置库现在工具非常多，例如GIT、SVN、CVS、VSS等等。通常会根据开发所处的阶段，设立开发库、受控库与产品库。
2）标识配置项，即需要定义如何去标识配置项。配置管理中受控制的对象被称为配置项，是生命周期中创建的信息，包含程序、数据、文档，分基线配置项和非基线配置项两类。特别是你的产品最终是如何标识的，比如怎样定义V1.0.0的规则。
3）基线的管理。是一组经过正式审查并且达成一致的规范或工作产品，是下一阶段工作的基础。怎样确定、发布基线，怎样管理基本的变更。
4）配置项变更管理。可以根据不同的配置项、不同的开发周期，明确变更的管理规则。
5）配置项状态管理与配置审计 。
而产品集成是如何把一个产品逐步的从一个个模块或组件，最后组合成一个产品的过程。
1）首先产品的技术结构上要能够支持，如果模块不能相互独立和拆解，谈不上灵活的组合。
2）在开发实现上，需要有一个集成的策略，哪些先实现，哪些后实现，哪些可以先进行集成
3）需要建立 集成的环境，使开发好的模块可以在集成环境中进行调试
4）通常开发完成后，需要进行源代码的编译，并打包成一个测试包，然后装在集成环境中，进行调试，以确认各个模块之前是否可以兼容和运转，这时通常会进行测试工作。
5）如果你想进行ABC组合，或者AC组合，那么都需要进行相应的编译、打包（例如形成EXE）过程，然后在集成环境中进行联调和测试。
❺ 什么是配置项管理
按管理的严格程度，配置项一般分3个等级：
（1）纳入基线管理的配置项
纳入基线管理的配置项是指变化时要走严格变更手续的配置项，需要做变更申请，要审批。审批一般分2种严格程度：
i) 项目经理或分CCB审批就可以，一般是局部的小的变更。
ii）变更控制委员会（CCB）审批
纳入基线前，一般要经过评审或测试（称为验证）和质量保证。
(2) 没有纳入基线但是也不能随意变更的配置项，一般称为受控项
这类配置项不需要变更申请，但是要经过配置管理员或项目经理的允许才可以变更。
基线项与受控项写的权限要唯一，一般是CM或PM有唯一的写权限。
（3）非受控项
对变更不做控制。
拟纳入基线管理的配置项状态变化一般是先非受控，然后受控，最后基线化。变更时，先检出（checkou）进行修改，修改完毕后再检入（checki）转为受控，等待验证（测试或评审），通过验证后进行基线化。
拟纳入受控而不入基线的配置项状态变化一般是先非受控，然后受控。变更时，检出进行修改，修改完毕后再检入提交受控。
纳入基线管理的时机是管理平衡问题，一般是当配置项基本稳定后才纳入基线管理，如果处与频繁的变动之中，纳入基线后会增加管理成本，如单元测试通过后一般不形成基线，因为此时代码并不稳定，但是可以作为受控项，也不能任意变化。这个问题的判断也和项目组的规模有关系，如果规模很大，涉及到的人员很多，也可能需要建立基线。在系统测试后要形成基线，一般称为产品基线，此时系统基本稳定了，可以对外发布，为更多的人所了解和使用了。代码在没有纳入基线但是受控后（提交测试人员测试了），也不能随便变更了，要经过配置管理员的批准，并通知测试人员。
❻ 配置管理员的标识和控制
所有配置项都都应按照相关规定统一命名，并在文档中的规定章节（部分）记录对象的标识信息。在引入软件配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中。
所有配置项的操作权限应由SCM严格管理，推荐原则是：基线配置项向软件开发人员开放读取得权限；非基线配置项向PM、CCB及相关人员开放。
1．工作空间管理
在引入了软件配置管理工具之后，所有开发人员都会被要求把工作成果存放到由软件配置管理工具所管理的配置库中去，或是直接工作在软件配置管理工具提供的环境之下。所以为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，对工作空间的管理和维护也成为了软件配置管理的一个重要的活动。
一般来说，比较理想的情况是把整个配置库视为一个统一的工作空间，然后再根据需要把它划分为个人（私有）、团队（集成）和全组（公共）这三类工作空间（分支），从而更好的支持将来可能出现的并行开发的需求。
每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作空间上，例如：对于私有开发空间而言，开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素；而集成分支对应的是开发团队的公共空间，该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限，它的管理工作由SIO负责；至于公共工作空间，则是用于统一存放各个开发团队的阶段性工作成果，它提供全组统一的标准版本，并作为整个组织的Knowledge Base。
当然，由于选用的软件配置管理工具的不同，在对于工作空间的配置和维护的实现上有比较大的差异，但对于CMO来说，这些工作是他的重要职责，他必须根据各开发阶段的实际情况来配置工作空间并定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。
2．版本控制
版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段，我们还需要定义、收集一些元数据（Metadata）来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然如果选用的工具支持的话，这些辅助数据将能直接统计出过程数据，从而方便我们软件过程改进（Software Process Improvement，SPI）活动的进行。
对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。
3．变更控制
在对SCI的描述中，我们引入了基线的概念。从IEEE对于基线的定义中我们可以发现，基线是和变更控制紧密相连的。也就是说在对各个SCI做出了识别，并且利用工具对它们进行了版本管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就成为了软件配置管理的另一重要任务。因此，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制。
在本文的前面的部分中，已经把SCI分为基线配置项和非基线配置项两大类，所以这里所涉及的变更控制的对象主要指配置库中的各基线配置项。
变更管理的一般流程是：
A) （获得）提出变更请求；
B) 由CCB审核并决定是否批准；
C) （被接受）修改请求分配人员为，提取SCI，进行修改；
D) 复审变化；
E) 提交修改后的SCI；
F) 建立测试基线并测试；
G) 重建软件的适当版本；
H) 复审（审计）所有SCI的变化；
I) 发布新版本。
在这样的流程中，SCM通过软件配置管理工具来进行访问控制和同步控制，而这两种控制则是建立在前文所描述的版本控制和分支策略的基础上的。
4．状态报告
配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。
配置状态报告应根据报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。同时也能从中根据开发人员对配置项的操作记录来对开发团队的工作关系作一定的分析。
配置状态报告应该包括下列主要内容：
A) 配置库结构和相关说明；
B) 开发起始基线的构成；
C) 当前基线位置及状态；
D) 各基线配置项集成分支的情况；
E) 各私有开发分支类型的分布情况；
F) 关键元素的版本演进记录；
G) 其它应予报告的事项。
5．配置审计
配置审计是指在配置标识、配置控制、配置状态记录的基础上对所有配置项的功能及内容进行审查，以保证软件配置项的可跟踪性。一般的，独立的SCM可以担当配置审计。
总之，软件配置管理的对象是软件研发活动中的全部开发资产。所有这一切都应作为配置项纳入管理计划统一进行管理，从而能够保证及时的对所有软件开发资源进行维护和集成。因此，软件配置管理的主要任务也就归结为以下几条：（1）制定项目的配置计划；（2）对配置项进行标识；（3）对配置项进行版本控制；（4）对配置项进行变更控制；（5）定期进行配置审计；（6）向相关人员报告配置的状态。
由于软件配置管理覆盖了整个软件的开发过程，因此它是改进我们的软件过程、提高过程能力成熟度的理想的切入点。
❼ 项目章程应该包括哪些内容
项目章程的内容
1. 基于项目干系人的需求和期望提出的要求。
2. 项目必须满足的业务要求或产品需求。
3. 项目的目的或项目立项的理由。
4. 委派的项目经理及项目经理的权限级别。
5. 概要的里程碑进度计划。
6. 项目干系人的影响。
7. 职能组织及其参与。
8. 组织的、环境的和外部的假设。
9. 组织的、环境的和外部的约束。
10. 论证项目的业务方案，包括投资回报率。
11. 概要预算。
组织过程资产的内容
组织过程资产包含：项目实施组织的企业计划、政策方针、规程、指南和管理系统，
实施项目组织的知识和经验教训。
项目范围说明书的内容
1. 项目和范围的目标。
2. 产品或服务的需求和特性。
3. 项目的需求和可交付物。
4. 产品验收标准。
5. 项目的边界。
6. 项目约束条件。
7. 项目假设。
8. 最初的项目组织。
9. 晟初定义的风险。
10. 进度里程碑。
11. 对项目工作的初步分解。
12. 初步的量级成本估算。
13. 项目配置管理的需求。
14. 审批要求。
项目管理计划的内容
1. 项目背景如项目名称、客户名称、项目的商业目的等。
2. 项目经理、项目经理的主管领导、客户方联系人、客户方的主管领导，项目领导小组（即项目管理团队）和项目实施小组人员。
3. 项目的总体技术解决方案。
4. 对用于完成这些过程的工具和技术的描述。
5. 选择的项目的生俞周期和相关的项目阶段。
6. 项目最终目标和阶段性目标。
7. 进度计划。
8. 项目预算。
9. 变更流程和变更控制委员会。
10. 沟通管理计划。
11. 对于内容、范围和时间的关键管理评审，以便于确定悬留问题和未决决策。
项目计划的编制流程
1. 明确目标
2. 成立初步的项目团队
3. 工作准备与信息收集
4. 依据标准、模板，编写初步的概要的项目计划。
5. 编写范围管理、质量管理、进度、预算等分计划。
6. 把上述分计划纳入项目计划，然后对项目计划进行综合平衡、优化。
7. 项目经理负责组织编写项目计划。
8. 评审与批准项目计划。
9. 获得批准后的项目计划就成为了项目的基准计划。
WBS的表现形式
1. 分级的树型结构
WBS层次清晰，非常直观，结构性很强，但不是很容易修改，对于大的、复杂的项目也很难表示出项目的全景。
2. 列表形式
能够反映出项目所有的工作要素，可是直观性较差
工作分解结构应把握的原则
1. 在各层次上保持项目的完整性，避免遗漏必要的组成部分。
2. 一个工作单元只能从属于某个上层单元，避免变叉从属。
3. 相同层次的工作单元应有相同性质。
4. 工作单元应能分开不同的责任者和不同工作内容。
5. 便于项目管理进行计划和控制的管理需要。
6. 最低层工作应该具有可比性，是可管理的，可定量检查的。
7. 应包括项目管理工作，包括分包出去的工作。
8. WBS的最低层次的工作单元是工作包。
缩短工期的方法
1. 投入更多的资源以加速活动进程。
2. 指派经验更丰富的人去完成或帮助完成项目工作。
3. 减小活动范围或降低活动要求。
4. 遁过改进方法或技术提高生产效率。
进度控制关注的内容：
5. 确定项目进度的当前状态。
6. 对引起进度变更的因素施加影响，以保证这种变化朝着有利的方向发展。
7. 确定项目进度已经变更。
8. 当变更发生时管理实际的变更。
活动资源估算的方法
1. 专家判断
2. 多方案分析
3. 出版的估算数据
4. 项目管理软件
5. 自下而上估算
活动历时估算的内容：
1. 专家判断
2. 类比估算
3. 参数估算
4. 三点估算
5. 后备分析
制定进度计划的方法和工具：
1. 进度网络分析
2. 关键路线法
3. 进度压缩（赶进度、快速跟进）
4. 假设情景分析
5. 资源平衡
6. 关键链法（缓冲）
7. 项目管理软件
8. 应用日历
9. 调整时间提前与滞后量
10. 进度模型
成本估算的工具和技术
1. 类比估算
2. 确定资源费率
3. 自下而上估算
4. 参数估算
5. 项目管理软件
6. 供货商投标分析
7. 准备金分析
8. 质量成本
成本预算的工具和方法
1. 成本汇总
2. 准备金分析
3. 参数估算
4. 资金限制平衡
项目成本控制的主要内容
1. 对造成成本基准变更的因素施加影响；
2. 确保变更请求获得同意；
3. 当变更发生时，管理这些实际的变更；
4. 保证潜在的成本超支不超过授权的项目阶段资金和总体资金；
5. 监督成本执行（绩效），找出与成本基准的偏差；
6. 准确记录所有的与成本基准的偏差；
7. 防止错误的、不恰当的或未批准的变更被纳入成本或资源使用报告中{
8. 就审定的变更，通知项目干系人；
9. 采取措施，将预期的成本超支控制在可接受的范围内
质量管理过程的4个环节
1. 确立质量标准体系
2. 对项目实施进行质量监控
3. 将实际与标准对照
4. 纠偏纠错
制定项目质量的工具和技术
小鸡公爵六十只
1. 效益／成本分析
2. 基准比较
3. 流程图
4. 实验设计
5. 质量成本分析
6. 质量功能展开
7. 过程决策程序图法
质量保证活动的基本内容
1. 制定质量标准
2. 制定质量控制流程
3. 提出质量保证所采用方法和技术
4. 建立质量保证体系
质量控制的方法：
1. 新七：因果图、流程图、直方圈、检查表、散点图、排列图和控制图
2. 老七：相互关系图、亲和圈、树状图、矩阵图、优先矩阵图、过程决策方法图和活动网络图
3. 测试、检查、统计抽样、6西格玛
质量控制的步骤：
1. 选择控制对象
2. 为控制对象确定标准或目标。
3. 制定实施计划，确定保证措施。
4. 按计划执行。
5. 对项目实施情况进行跟踪监测、检查，并将监测的结果与计划或标准相比较。
6. 发现并分析偏差。
7. 根据偏差采取相应对策
组件项目团队的工具和技术
1. 事先分派：预先分配到项目中
2. 谈判：人员分派多少在谈判中
3. 采购：聘用和分包
4. 虚拟团队：互联网
成功的项目团队的特点：
1. 团队的目标明确，成员清楚自己的工作对目标的贡献。
2. 团队的组织结构清晰，岗位明确。
3. 有成文或习惯的工作流程和方法，而且流程简明有效。
4. 项目经理对团队成员有明确的考核和评价标准，工作结果公正公开，赏罚分明。
5. 共同制订并遵守的组织纪律。
6. 协同工作，也就是一个成员工作需要依赖于另一个成员的结果，善于总结和学习。
沟通管理计划的内容：
1. 项目干系人沟通要求。
2. 对要发布信息的描述，包括格式、内容和详尽程度。
3. 信息接收的个人或组织。
4. 传达信息所需的技术或方法。如备忘录、电子邮件、新闻发布等。
5. 沟通频率。如每周沟通。
6. 上报过程，对下层无法解决的问题，确定问题上报的时间要求和管理链（名称）。
7. 随项目的进展对沟通管理计划更新与细化的方法。
8. 通用词语表。
项目总结会议的目的（意义）：
1. 了解项目全过程的工作情况及相关的团队或成员的绩效状况
2. 了解出现的问题并进行改进措施总结
3. 了解项目全过程中出现的值得吸取的经验并进行总结
4. 对总结后的文档进行讨论，通过后存入公司的知识库，从而纳入企业的过程。
4种违约责任的承担方式：
1. 继续履行
2. 采取补救措施
3. 赔偿损失
4. 支付约定违约金或定金。
项目合同签订事项：
1. 当事人的法律资格；
2. 质量的验收标准；
3. 验收时间；
4. 技术支持服务；
5. 损害赔偿；
6. 保密约定；
7. 合同附件、法律公正。
合同不明确情况的处理方法：
先协商，未完成补充协议
1. 当事人对标的物的质量要求不明确的，按国家标准和行业标准。没有标准的，按产品通常标准或符合合同目的的标准。
2. 履行地点不明确时，按性质不同而定，接受货币在接受方，交付不动产的在不动产所在地，其他标的在履行义务方所在地。
3. 履行期限不明的，债务人可以随时履行，债权人可随时要求履行，但应给对方必要的准备时间。
4. 履行费用负担不明确的，由履行义务一方承担，履行费用是履行义务过程中何种附随发生的费用。
索赔程序：
项目发生索赔事件后，一般先由监理工程师调解，若调解不成，由政府建设主管机构进行调解，若仍调解不成由合同仲裁委员会进行调解或仲裁。在整个过程中，遵循的原则是索赔的有理性、索赔依据的有效性、索赔计算的正确性。
配置管理包括4个主要活动：
5. 配置识别
6. 变更控制
7. 状态报告
8. 配置审计
配置管理流程：
1. 制定配置管理计划
2. 配置识别与建立基线
3. 建立配置管理系统
4. 版本管理
5. 配置状态报告和配置审计
配置识别的内容：
1. 识别需要受控的软件配置项。
2. 给每个产品和它的组件及相关的文档分配唯一的标识。
3. 定义每个配置项的重要特征以及识别其所有者。
4. 识别组件、数据及产品获取点和准则。
5. 建立和控制基线。
6. 维护文档和组件的修订与产品版本之间的关系。
配置识别的基本原则：
基线配置项向软件开发人员开放读取权限；非基线配置向PM、CCB及相关人员开放。基线配置包括设计文档和源程序；非基线配置包括各类计划和报告。
建立配置管理方案的步骤：
1. 组建配置管理方案构造小组
2. 对目标机构进行了解、评估
3. 配置管理工具及其提供商评估
4. 制订实施计划
5. 定义配置管理流程
6. 试验项目的实施
7. 全面实施
变更的流程：
1. 提出与接受变更申请。
2. 对变更的初审（常见方式：变更申请文档的审核流转）。
3. 变更方案论证（技术评估转换成果、经济评估转换价值和风险）。
4. 项目变更控制委员会审查（文档会签形式）。
5. 发出变更通知并开始实施。
6. 变更实施的监控（由项目经理负责项目基准的监控；管理委员会监控成果、进度里程碑）。
7. 变更效果的评估。
8. 判断发生变更后的项目是否已纳入正常轨道。
系统集成项目系统验收文档的内容：
1. 系统集成项目介绍。
2. 系统集成项目最终报告。
3. 信息系统说明手册。
4. 信息系统维护手册。
5. 软硬件产品说明书、质量保证书等
项目总结的意义：
1. 了解项目全过程的工作情况及相关的团队或成员的绩效状况。
2. 了解出现的问题并进行改进措施总结。
3. 了解项目全过程中出现的值得吸取的经验并进行总结。
4. 对总结后的文档进行讨论，通过后即存入公司的知识库，从而纳入企业的过程资产。
项目总结会的内容：
1. 项目绩效
2. 技术绩效
3. 成本绩效
4. 进度计划绩效
5. 项目的沟通
6. 识别问题和解决问题
7. 意见和建议
项目人员转移流程：
1. 项目团队成员的管理计划，也就是项目人力资源管理计划中描述所说的人员转移条件已经触发。
2. 项目团队成员所承担的任务已完成，提交了经过确认的可交付物并已完成工作交接。
3. 项目经理与项目团队成员确认该成员的工作衔接已经告一段落或者已经完成。
4. 项目经理签发项刚团趴成员转移确认文件。
5. 项目经理签发项目团队成员的绩效考核文件。
6. 项目经理通知所有相关的干系人。
7. 若是项目收尾全体项目成员结束项目工作，应召开项目总结表彰大会，肯定项目的成绩、团队成员的业绩，同时总结项目的经验教训。
❽ 管理配置的基本操作有哪些三种
管理配置的基本操作有这三种：1.事前控制、2.即时控制、3..事后控制。
事前控制是指一个组织，在一项活动正式开始之前所进行的管理上的努力。
即时控制是在某项活动或工作过程中进行的控制。
事后控制即发生在行动或任务终了之后的控制。
制定配置管理计划
配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。
配置库管理
配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清除垃圾文件、备份配置库等。