配置管理流程

制定配置管理计划

配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。

配置库管理

配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限 *** 作配置库。配置管理员定期维护配置库，例如清除垃圾文件、备份配置库等。

版本控制

在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则。

变更控制

在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。

修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。

当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请→审批→执行变更→再评审→结束”的规则执行。

配置审计

为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。

一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。 一个项目设立之初PM首先需要制定整个项??研发计划之后，软件配置管理的活动就可以展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火”的行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功的重要保证。

在软件配置管理计划的制定过程中，它的主要流程应该是这样的：

CCB根据项目的开发计划确定各个里程碑和开发策略；

CMO根据CCB的规划，制定详细的配置管理计划，交CCB审核；

CCB通过配置管理计划后交项目经理批准，发布实施。 这一阶段是项目研发的主要阶段。在这一阶段中，软件配置管理活动主要分为三个层面：

⑴主要由CMO完成的管理和维护工作；

⑵由SIO和DEV具体执行软件配置管理策略；

⑶变更流程。这三个层面是彼此之间既独立又互相联系的有机的整体。

在这个软件配置管理过程中，它的核心流程应该是这样的：

⑴CCB设定研发活动的初始基线；

⑵CMO根据软件配置管理规划设立配置库和工作空间，为执行软件配置管理计划做好准备；

⑶开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作；

⑷SIO按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进；

⑸CCB根据项目的进展情况，审核各种变更请求，并适时的划定新的基线，保证开发和维护工作有序的进行。

这个流程就是如此循环往复，直到项目的结束。当然，在上述的核心过程之外，还涉及其他一些相关的活动和 *** 作流程，下面按不同的角色分工予以列出：

各开发人员按照项目经理发布的开发策略或模型进行工作；

SIO负责将各分项目的工作成果归并至集成分支，供测试或发布；

SIO可向CCB提出设立基线的要求，经批准后由CMO执行；

CMO定期向项目经理和CCB提交审计报告，并在CCB例会中报告项目在软件过程中可能存在的问题和改进方案；

在基线生效后，一切对基线和基线之前的开发成果的变更必须经CCB的批准；

CCB定期举行例会，根据成员所掌握的情况、CMO的报告和开发人员的请求，对配置管理计划作出修改，并向项目经理负责。

综上所述，配置管理的工作流程如图1所示：

实施整体并更控制过程跟变更控制流程的区别及包含关系。实施整体变更控制过程是变更控制流程中对控制已有变更最为核心的部分。后者包含了前者。变更请求需要经实施整体变更控制过程的审查和处理。

根据PMBOK 对整体变更控制的描述：实施整体变更控制是审查所有变更请求，批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。变更请求是实施整体变更控制的输入，也就是说实施整体变更控制之前，变更请求已经存在。

第一，区分整体变更控制和变更控制过程的被包含关系

实施整体变更控制过程要做的主要要做的几件事是：

1. 项目经理接收（注意不是接受）变更，

2. 针对变更方案分析影响（本领域和其它领域）；

3. 针对变更方案与相关关系人沟通；

4. 必要时提及CCB/项目发起人批准；（根据批准的变更更新相关项目管理计划和项目文件；注变更批准或者未被批准，都要记录在变更日志）

5. 针对批准的变更请求审批结果（批准还是否决变更）与相关干系人沟通；

经过这些步骤，（始于变更请求的提出，终于与相关干系人沟通变更处理的结果，即批准的变更）实施整体变更过程就结束了。

现在再说一下在变更控制流程中没有包括在实施整体变更控制过程的事。

1. 在变更存在之前（在实施整体变更控制过程之前）

   a. 识别/确认潜在的变更；

   b. 对潜在变更施加影响（最好不变更）。

   c. 提交变更请求（如果变更已经存在或者不得不变时）

2. 在与相关干系人沟通变更处理结果（批准还是否决）之后（实施整体变更控制过程之后）

  a. 执行变更（执行预防，纠正或者补救措施）；

  b. 确认变更执行的情况（控制质量过程输出确认的变更）；

  c. 针对确认的变更（变更处理的结果）与相关干系人沟通。

  d. 总结经验教训，为未来的变更控制流程的有效性做为经验参考。

第二， 区别关于变更中几个重要角色审批作用

1. 项目经理

2. 变更控制委员会（CCB）

概念：CCB 是一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，

以及记录和传达变更处理决定。

3. 发起人

4. 客户

5. 变更批准责任人：通常指项目经理和发起人。

---