变更管理规程Word格式.docx

变更管理规程Word格式.docx

《变更管理规程Word格式.docx》由会员分享，可在线阅读，更多相关《变更管理规程Word格式.docx（11页珍藏版）》请在冰豆网上搜索。

版本号

修订说明

修订人

审核人

批准人

20XX-5-15

V1.0

正式发布

20XX-3-3

优化文档

a、

b、5.1.基线变更流程：

（说明修改）定制软件/产品研发直接选择方式一，两种方式工作量超过10%可以选择方式二，第3点说明直接删除：

c、

CCB（变更通知委员会）成员的确定（详参《配置管理过程》c点）

d、配置项的变更流程图：

“项目经理”改成“项目经理/部门经理”；

1.目的3

2.角色与职责3

3.入口准则3

4.输入3

5.主要步骤3

5.1.基线变更流程3

5.1.1变更申请5

5.1.2变更评估5

5.1.3变更实施6

5.1.4变更验证与确认6

5.1.5变更的发布6

5.2.配置项变更流程6

5.2.1变更申请7

5.2.2变更评估8

5.2.3变更实施8

5.2.4变更验证8

5.2.5变更的发布8

6.输出8

7.出口准则9

8.引用文档9

9.使用模板9

1.目的

通过变更管理活动，保证产品的完整、正确、一致，防止配置项被随意地修改而导致混乱。

2.角色与职责

角色

职责

变更发起人

提出基线变更请求

提出配置项变更请求

项目经理

审批配置项变更请求

审核配置项变更发布申请

CCB

审批基线变更请求

审核基线变更实施结果

变更实施人

填写软件变更单提取配置项

实施对基线、配置项变更涉及配置项的具体修改

CM

对变更的配置项进行出、入库管理，并且在基线变更发布后改变基线

项目推进部

监督变更过程

检查变更文档

3.入口准则

●客户提出的变更申请被接受时

●内部提出变更申请时

4.输入

●《变更记录表》

5.主要步骤

5.1.基线变更流程

流程名称：

基线变更流程

描述：

描述项目基线变更的过程。

流程目标：

控制基线变更，确保项目工作依据的正确、一致

驱动事件：

基线变更申请被接受

输入：

需求变更申请表、变更记录表

输出：

变更记录表、配置项状态报告、基线记录表、需求跟踪矩阵

流程涉及的部门或角色：

变更申请人、项目经理、CCB（CCB（变更通知委员会）成员的确定详参《配置管理过程》）、CM工程师、变更实施人

与其它流程的关系：

属于《配置管理过程》的子流程。

关键控制点：

变更评估与分析、变更的确认与验证

流程负责人：

CCB

流程图

在项目实施过程中，基线变更通常存在两种方式：

1）方式一：

直接对相关基线配置项进行变更，升级基线版本；

2）方式二：

将已积累的若干个变更合并形成新的基线，替换原有的基线.

说明：

定制软件/产品研发直接选择方式一，若项目变更所需工作量超过10%可以选择方式二

。

5.1.1变更申请

1）来自外部的变更申请：

例如来自用户、工程实施人员等。

这类申请通过《需求变更申请表》提出，并由项目组评审确认为接受后进入本过程，并形成《变更记录表》。

2）内部变更申请：

由项目组内部通过《变更记录表》直接提出变更申请。

项目经理或变更申请人填写《变更记录表》，说明要变更的内容、变更的原因、受变更影响的关联配置项、工作量等，并提交给CCB组长。

5.1.2变更评估

CCB组长负责组织对基线变更申请进行评估并确定以下内容：

●变更的内容是否合理

●变更的范围是否正确、考虑周全

●受影响的配置项是否已被充分考虑，是否需要同时进行变更

●工作量估计是否合理

●基线变更的实施方案是否合理

CCB评估的方式：

●变更工作的工作量小于10人日时，由CCB组长直接评估并审批

●变更工作的工作量大于10人日或小于20人日时，应召开CCB讨论会讨论并确定评估结果；

●变更工作的工作量大于等于20人日时，CCB应邀请项目管理部门参加CCB会议，讨论并确定评估结果；

●对于方式二的基线变更应采用CCB会议方式进行评估。

变更评估目的是分析变更带来的影响有多少，评估采用的方式与方法

CCB变更评估通过并最终确定了基线变更方案后，填写《变更记录表》并提交CM工程师。

5.1.3变更实施

1）方式一的变更实施：

●若变更的是代码时，CM工程师在测试库中开辟工作空间，从受控库中取出相关的配置项放于工作空间，并分配权限给变更实施人；

●若变更的是文档时，CM工程师在开发库中开辟工作空间，从基线目录中签出相关的配置项放于工作空间，并分配权限给变更实施人；

●CM工程师在《配置项状态报告》将相关变更项的状态更改为“变更中”并填写相关变更信息。

●项目经理组织修改相关的配置项，并在相应的文档或程序代码中记录变更信息

●变更实施人完成并提交后，项目经理指派其他的人员完成单元测试/代码走查

2）方式二的变更实施：

项目经理组织将配置项变更配置项进行整合，形成基线产品；

5.1.4变更验证与确认

1）项目经理应将变更与验证的结果记录到《变更记录表》。

5.1.5变更的发布

1）由CM填写《基线记录表》，依据《配置管理过程》的要求将基线发布给相关人员与部门。

2）CM工程师在《配置项状态报告》中将更新配置项变更次数。

3）CM工程师应检查项目的《需求跟踪矩阵》，对本次变更引起的需求对应关系的变化进行调整，并填写在需求跟踪矩阵中。

5.2.配置项变更流程

配置项变更流程

描述项目配置项变更的过程。

控制配置项变更，确保产品间的一致性与完整性

配置项变更申请被接受

变更记录表

变更记录表、配置项状态报告

变更申请人、项目经理、CM工程师、变更实施人

项目经理

配置项变更是指对受控库中的配置项的变更，变更步骤如下：

5.2.1变更申请

项目经理或变更申请人填写《变更记录表》，说明要变更的内容、变更的原因、受变更影响的关联配置项、工作量、变更实施人等，并提交给项目经理。

5.2.2变更评估

项目经理/部门经理根据变更申请单的内容，确定变更关联项，估算变更工作量，确定变更完成时限，指定变更实施人，必要时还应给出实施建议，将评估结果填写于《变更记录表》。

5.2.3变更实施

1）变更实施人根据评估结果，在《变更记录表》中填写需要变更的具体配置项，并提交给CM工程师。

2）如果是变更配置项是文档，则由CM工程师直接将其从受控库迁出到开发库的指定工作空间中并分配权限给变更实施人；

如果变更配置项是代码，则由CM工程师在测试库开辟工作空间，并从受控库中将相关的配置项迁出到工作空间，分配权限给变更实施人。

3）由变更实施人组织实施变更，并在相应的文档或程序代码中记录变更信息。

4）变更实施人完成并提交后，项目经理指派其他的人员完成单元测试/代码走查。

5.2.4变更验证

1）变更完成后，如果变更配置项是源代码则由测试工程师进行确认测试；

如果是文档则需由项目经理组织进行文档评审（技术类文件选用技术类评审方法，管理类文档可选用管理类评审方式，评审流程详见《评审规程》）。

2）在配置项验证通过后，CM工程师将相关配置项重新迁入受控库的相应目录中。

同时CM工程师在《配置项状态报告》中将更新配置项变更次数。

5.2.5变更的发布

1）由CM依据《配置管理过程》的要求将产品发布给相关人员与部门。

6.输出

●变更后的基线配置项和非基线配置项

●《需求变更申请表》

●《配置项状态报告》

●《需求跟踪矩阵》

●《基线记录表》

7.出口准则

●基线变更：

配置项纳入了受控库的基线目录

●配置项变更：

配置项纳入了受控库

8.引用文档

●《配置管理过程》

●《测试管理过程》

●《评审规程》

9.使用模板