第15章 - 组织保障

15.1信息和文档管理

信息系统相关信息(文档)是指某种数据媒体和其中所记录的数据。

15.1.1信息和文档

1.信息系统信息
信息系统中的信息可以分为用户信息、业务信息、经营管理信息和系统运行信息等。

2.信息系统文档:

文档的质量通常可以分为4级。

15.1.2信息(文档)管理规则和方法

信息系统文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。

• (1)文档书写规范:应该遵循统一的书写规范,包括符号的使用、图标的含义、程 序中注释行的使用、注明文档书写人及书写日期等;
• (2)图表编号规则：对图表进行有规则的编号，可以方便查找图标
• (3)文档目录编写标准;
• (4)文档管理制度:应该建立相应的文档管理制度

2.信息(文档)定级保护
应根据侵害可能影响对象和影响程度,对信息系统项目的信息(文档)进行分析并 定级,按相应的定级保护策略进行管理。

• (1)根据项目干系人和项目价值目标的识别,影响对象主要包括:
  • 个人、法人和其他组织的合法权益和经济利益;
  • 社会秩序、公共利益;
  • 国家安全。
• (2)对影响对象的侵害影响程度,归结为:
  • 无影响;
  • 造成一般损害;
  • 造成严重损害;
  • 造成特别严重损害。

基于以上定级方法,组织可以将项目信息(文档),结合自身业务的特点来定义分 级标准,并建立相应的分级管理策略。

特别要注意的是,在项目应用时,应结合客户要求和合同要求,建立项目信息 (文档)管理策略。文档中有密级要求的,应注意保密和权限管理。项目干系人签字确 认后的文档要与相关联的电子文档一一对应,这些电子文档还应设置为只读。

3.信息(文档)配置管理
在信息系统项目中,配置管理可用于问题分析、变更影响度分析、异常分析等, 因此,配置项与真实情况的匹配度和详细度非常重要。

在组织实施信息系统项目过程中,常常会遇到变更的发生。变更一般有主动变 更和被动变更两种。

• 主动变更是主动发起的变更,常用于提高项目收益,包括降低成本、改进过程 以及提高项目的便捷性和有效性等;
• 被动变更常用于范围变化、异常、错误和适应不断变化的环境等,如随需求 的增加,相应需要增加系统的功能或投资等。

变更管理是对变更从提出、审议、批准、实施到完成的整个过程的管理。

15.2配置管理

配置管理是为了系统地控制配置变更,在信息系统项目的整个生命周期 中维持配置的完整性和可跟踪性,而标识信息系统建设在不同时间点上配置 的学科。

15.2.1基本概念

1.配置项(Configuration Item, CI)
配置项的定义为:”为配置管理设计的硬件、软件或两者的集合,它在配置管理过 程中作为一单个实体来对待”。

比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等,它们经评审和检查通过后进入配置管理。

配置项可以分为基线配置项和非基线配置项两类

• 基线配置项可能包括所有的设计文档和源程序等;
• 非基线配置项可能包括项目的各类计划和报告等。

所有配置项的操作权限应由配置管理员严格管理,基本原则是:

• 基线配置项向开发人员开放读取的权限;
• 非基线配置项向项目经理、CCB及相关人员开放。

2.配置项状态
配置项的状态可分为”草稿”“正式“和”修改“三种。

• 配置项刚建立时,其状态为”草稿”。配置项通过评审后,其状态变为 “正式”。
• 此后若更改配置项,则其状态变为”修改”。当配置项修改完毕并重新通 过评审时,其状态又变为”正式”

3.配置项版本号

• ①处于”草稿“状态的配置项的版本号格式为0.YZ,YZ的数字范围为01~ 99。 随着草稿的修正,YZ的取值应递增。YZ的初值和增幅由用户自己把握。(例 如: 0.5、0.91)
• ②处于”正式“状态的配置项的版本号格式为X.Y,X为主版本号,取值范围 为1~9。Y为次版本号,取值范围为0~9。配置项第一次成为”正式”文件 时,版本号为1.0。(例如:正式V1.0,升级幅度小变为:V1.1、V1.2,升级幅 度大变为:V2.0)
• ③处于”修改“状态的配置项的版本号格式为X.YZ。配置项正在修改时,一般 只增大z值,X.Y值保持不变。当配置项修改完毕,状态成为”正式”时,将z 值设置为0,增加X.Y值。(例如:1.13)

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

5.配置基线
配置基线由一组配置项组成,这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被"冻结"了,不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。

产品的一个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计 说明书、己编译的可执行代码、测试大纲、测试用例、使用手册等) 是基线的一个例子。

基线通常对应于开发过程中的里程碑,一个产品可以有多个基线,也可以只有一个基线。交付给外部顾客的基线一般称为发行基线,内部开发使用的基线一般称为构造基线。

对于每一个基线,要定义下列内容:建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。

6.配置管理数据库
配置管理数据库主要内容包括:

• 1发布内容,包括每个配置项及其版本号;
• 2经批准的变更可能影响到的配置项;
• 3与某个配置项有关的所有变更请求;
• 4配置项变更轨迹;
• 5特定的设备和软件;
• 6计划升级、替换或弃用的配置项;
• 7与配置项有关的变更和问题;
• 8来自于特定时期特定供应商的配置项;
• 9受问题影响的所有配置项。

7.配置库
配置库可以分开发库、受控库、产品库3种:

• (1)开发库。开发库也称为动态库、程序员库或工作库,用于保存开发人员当前正在开发的 配置实体,如新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本 管理之下。动态库是开发人员的个人工作区,由开发人员自行控制。无须对其进行配置控制。 【可以任意的修改】
• (2)受控库。受控库也称为主库,包含当前的基线以及对基线的变更。受控库中的配置项被 置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时,将当前的工作产品存入 受控库。 【可以修改,需要走变更流程】
• (3) 产品库。产品库也称为静态库、发行库、软件仓库,包含已发布使用的各种基线的存档, 被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后,作为最终产品存入 产品库内,等待交付用户或现场安装。 【一般不再修改,真要修改的话需要走变更流程】

配置库的建库模式有两种:按配置项类型建库和按开发任务建库

• (1)按配置项的类型分类建库。这种模式适用于通用软件的开发组织。在这样的组织内, 往往产品的继承性较强,工具比较统一,对并行开发有一定的需求。使用这样的库结构有利 于对配置项的统一管理和控制,同时也能提高编译和发布的效率。但由于这样的库结构并不 是面向各个开发团队的开发任务的,所以可能会造成开发人员的工作目录结构过于复杂,带 来一些不必要的麻烦。 【如:通用产品】
• (2)按开发任务建立相应的配置库。这种模式适用于专业软件的开发组织。在这样的组织 内,使用的开发工具种类繁多,开发模式以线性发展为主,所以没必要把配置项严格分类存 储,人为增加目录的复杂性。对于研发性的软件组织来说,采用这种设置策略比较灵活。 【如:定制产品】

15.2.2角色与职责

配置管理相关角色常包括:配置控制委员会(CCB)、配置管理负责人、配置管理员和配置项负责人等。

1.配置控制委员会
配置控制委员会也称为变更控制委员会,它不只是控制变更,也负有更多的配置 管理任务,具体工作包括:

• ①制定和修改项目配置管理策略;
• ②审批和发布配置管理计划;
• ③审批基线的设置、产品的版本等;
• ④审查、评价、批准、推迟或否决变更申请;
• ⑤监督己批准变更的实施;
• ⑥接收变更与验证结果,确认变更是否按要求完成;
• ⑦根据配置管理报告决定相应的对策。

2.配置管理负责人
配置管理负责人也称配置经理,负责管理和决策整个项目生命周期中的配置活动, 具体有:

• ①管理所有活动,包括计划、识别、控制、审计和回顾;
• ②负责配置管理过程;
• ③通过审计过程确保配置管理数据库的准确和真实;
• ④审批配置库或配置管理数据库的结构性变更;
• ⑤定义配置项责任人;
• ⑥指派配置审计员;
• ⑦定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态;
• ⑧评估配置管理过程并持续改进;
• ⑨参与变更管理过程评估;
• ⑩对项目成员进行配置管理培训

3.配置管理员
配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动,具体 有:

• ①建立和维护配置管理系统;
• ②建立和维护配置库或配置管理数据库;
• ③配置项识别;
• ④建立和管理基线;
• ⑤版本管理和配置控制;
• ⑥配置状态报告;
• ⑦配置审计;
• ⑧发布管理和交付。

4.配置项负责人
配置项负责人确保所负责的配置项的准确和真实:

• ①记录所负责配置项的所有变更;
• ②维护配置项之间的关系;
• ③调查审计中发现的配置项差异,完成差异报告;
• ④遵从配置管理过程;
• ⑤参与配置管理过程评估。

15.2.3目标与方针

1.管理目标
针对信息系统开发项目,常需要通过实施软件配置管理达到配置管理的目标, 即在整个软件生命周期中建立和维护项目产品的完整性。

2.管理方针
为了实现配置管理目标,组织应定义配置管理过程,制定配置管理相关制度。配 置管理应基于项目类型和交付物等定义覆盖全面的管理范围。

配置管理的关键成功因素主要包括:

• 所有配置项应该记录;
• 配置项应该分类;
• 所有配置项要进行编号;
• 应该定期对配置库或配置管理数据库中的配置项信息进行审计;
• 每个配置项在建立后,应有配置负责人负责;
• 要关注配置项的变化情况;
• 应该定期对配置管理进行回顾;
• 能够与项目的其他管理活动进行关联。

15.2.4管理活动

配置管理的日常管理活动主要包括6个主要活动

• ①制订配置管理计划(写一个文档,叫做配置管理计划,规定如何做好配置管理)
• ②配置项标识(识别出需要把哪些东西作为配置项来管理)
• ③配置项控制(配置项有一些变更,需要做好配置变更的控制)
• ④配置状态报告(需要报告配置项的状态是什么样的)
• ⑤配置审计(做好审计,看有哪些好的,哪些不好的经验教训,效果怎么样)
• ⑥配置管理回顾与改进(定期回顾配置管理活动的实施情况,发现在配置管理执 行过程中有无问题,找到改进点,继而优化配置管理过程)

1.制定配置管理计划
配置管理计划是对如何开展项目配置管理工作的规划,是配置管理过程的 基础,应该形成文件并在整个项目生命周期内处于受控状态。CCB负责审批该计划。

配置管理计划的主要内容包括:

• 配置管理的目标和范围;
• 配置管理活动主要包括配置项识别、配置项控制、配置状态报告、配置审计、 配置管理回顾及改进等;
• 配置管理角色和责任安排;
• 实施这些活动的规范和流程,如配置项命名规则;
• 实施这些活动的进度安排,如日程安排和程序;
• 与其他管理之间(如变更管理等)的接口控制;
• 负责实施这些活动的人员或团队,以及他们和其他团队之间的关系;
• 配置管理信息系统的规划包括配置数据的存放地点、配置项运行的受控环境、 与其他服务管理系统的联系和接口、构建和安装等支持工具;
• 配置管理的日常事务包括许可证控制、配置项的存档等;
• 计划的配置基准线、重大发布、里程碑,以及针对以后每个期间的工作量计 划和资源计划。

2.配置项识别
配置项识别的基本步骤如下:

• (1)识别需要受控的配置项;
• (2)为每个配置项指定唯一的标识号;
• (3)定义每个配置项的重要特征;
• (4)确定每个配置项的所有者及其责任;
• (5)确定配置项进入配置管理的时间和条件;
• (6)建立和控制基线;
• (7)维护文档和组件的修订与产品版本之间的关系。

3.配置项控制
配置项控制即配置项和基线的变更控制,包括:变更申请、变更评估、 通告评估结果、变更实施、变更验证与确认、变更的发布、基于配置库的变 更控制等任务。

• (1)变更申请。相关人员(如项目经理)填写变更申请表,说明要变更的内容、变更的原因、受变更影响 的关联配置项和有关基线、变更实施方案、工作量和变更实施人等,并提交给CCB。
• (2)变更评估。CCB负责组织对变更申请进行评估并确定:
  • ①变更对项目的影响;
  • ②变更的内容是否必要;
  • ③变更的范围是否考虑周全;
  • ④变更的实施方案是否可行;
  • ⑤变更工作量估计是否合理。
  • CCB决定是否接受变更,并将决定通知相关人员。
• (3)通告评估结果。CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干 系人。
• (4)变更实施:项目经理组织修改相关的配置项,并在相应的文档、程序代码或配置管理数据中记录变更 信息
• (5)变更验证与确认:项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的 结果提交给CCB,由其确认变更是否已经按要求完成。
• (6) 变更的发布:配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员 并做好记录。
• (7)基于配置库的变更控制:现以某软件产品升级为例,其过程简述为:
  • ①将待升级的基线(假设版本号为v2.1)从产品库中取出,放入受控库。
  • ②程序员将修改的代码段从受控库中出(Check out,放入的开发库中进行修改。代被检出后 即被”锁定”,以保证同一段代码只能同时被一个程序员修改,如果甲正对其修改,乙就无法Check out。
  • ③程序员将开发库中修改的代码段检入(Check in)受控库。检入,代码的”定”被解除,其他程序 员可以Check out该段代码了。
  • ④软件产品的升级修改工作全部完成后,将受控库中的新基线存入产品库中(软件产品的版本号更新为 V2.2,旧的V2.1版并不删除,继续在产品库中保存)。
  • 

4.配置状态报告
配置状态报告应该包含以下内容:

• ①每个受控配置项的标识和状态
• ②每个变更申请的状态和已批准的修改的实施状态。
• ③每个基线的当前和过去版本的状态以及各版本的比较。
• ④其他配置管理过程活动的记录等。

5.配置审计
配置审计也称配置审核或配置评价,包括功能配置审计和物理配置审计,分别用以验证当前配置项的一致性和完整性。
配置审计的实施是为了确保项目配置管理的有效性性,体现了配置管理的最 根本要求:不允许出现任何混乱现象。包括:

• ①防止向用户提交不适合的产品,如交付了用户手册的不正确版本。
• ②发现不完善的实现,如开发出不符合初始规格说明或未按变更请求实施变 更。
• ③找出各配置项间不匹配或不相容的现象。
• ④确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。
• ⑤确认记录和文档保持着可追溯性。

功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需求一致),验证:

• ①配置项的开发已圆满完成;
• ②配置项已达到配置标识中规定的性能和功能特征;
• ③配置项的操作和支持文档己完成并且是符合要求的。

物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致), 验证:

• ①要交付的配置项是否存在;
• ②配置项中是否包含了所有必需的项目。

一般来说,配置审计应当定期进行,应当进行配置审计的场景包括:

• ①实施新的配置库或配置管理数据库之后;
• ②对信息系统实施重大变更前后;
• ③在一项软件发布和安装被导入实际运作环境之前;
• ④灾难恢复之后或事件恢复正常之后;
• ⑤发现未经授权的配置项后;
• ⑥任何其他必要的时候等。

6.配置管理回顾及改进
配置管理回顾与改进是指定期回顾配置管理活动的实施情况,目的是发现在 配置管理执行过程中有无问题,找到改进点,优化配置管理过程。

配置管理回顾与改进活动包括:

• ①对本次配置管理回顾进行准备,设定日期和主题,通知相关人等参加会议。 根据配置管理绩效衡量指标,要求配置项责任人提供配置项统计信息;
• ②召开配置管理回顾会议,在设定日期召开回顾会议,对配置管理报告进行 汇报,听取各方意见,回顾上次过程改进计划执行情况;
• ③根据会议结论,制订并提交服务改进计划;
• ④根据过程改进计划,协调落实改进。

15.3变更管理

15.3.1基本概念

1.项目变更的含义
变更管理的实质,是根据项目推进过程中越来越丰富的项目认知,不断 调整项目努力方向和资源配置,最大程度地满足项目需求,提升项目价值。

2.变更产生的原因
变更的常见原因:

• ①产品范围(成果)定义的过失或者疏忽。
• ②项目范围(工作)定义的过失或者疏忽。
• ③增值变更。
• ④应对风险的紧急计划或回避计划。
• ⑤项目执行过程与基准要求不一致带来的被动调整。
• ⑥外部事件。

3.变更分类

• (1)根据变更性质可分为:重大变更、重要变更和一般变更。通过不同审批权限控制。
• (2)根据变更的迫切性可分为:紧急变更、非紧急变更。通过不同变更处理流程进行。

4.变更管理原则
变更管理的原则是项目基准化、变更管理过程规范化。包括:

• (1)基准管理:基准是变更的依据。
• (2)变更控制流程化:所有变更都必须遵循这个控制流程进行控制。
• (3)明确组织分工:至少应明确变更相关工作的评估、评审、执行的职能。
• (4)与干系人充分沟通:须征求项目重要干系人的意见,获得对项目变更的 支持。
• (5)变更的及时性:变更宜早不宜晚,只做必须要变更的。由于变更可能带 来连锁反应,所以可做可不做的,尽量不做。
• (6)评估变更的可能影响:变更的来源是多样的,既需要完成对客户可视的 成果、交付期等变更操作,还需要完成对客户不可视的项目内部工作的变更。
• (7) 妥善保存变更产生的相关文档,确保其完整、及时、准确、清晰,适当 时可以引入配置管理工具。

5.变更管理与相关活动的关系

• 1)变更管理与项目整合管理的关系 变更管理是项目整合管理的一部分,实施整体变更控制过程贯穿项目始终。

• 2)变更管理与配置管理的关系 项目的配置管理计划应规定哪些项目组件受控于配置控制程序。对配置项的 任何变更都应该提出变更请求,并经过变更控制。配置管理重点关注可交付 产品(包括中间产品)及各过程文档,而变更管理则着眼于识别、记录、批 准或否决对项目文件、可交付产品或基准的变更。

变更管理过程中包含的部分配置管理活动如下。 配置项识别 配置状态记录 配置确认与审计

15.3.2角色与职责

信息系统项目中,通常会定义变更控制委员会(CCB)、变更管理负责人、变更请求者、变更实施者和变更顾问委员会等。

项目经理:项目经理在变更中的作用是:

• 响应变更提出者的需求;
• 评估变更对项目的影响及应对方案;
• 将需求由技术要求转化为资源需求,供授权人决策;
• 依据变更评审结果调整基准,确保项目基准反映项目实施情况,
• 并监控变更及己批准的变更正确实施。

1.变更控制委员会(CCB):变更控制委员会是由主要项目干系人代表组成的一个正式团体, 它是决策机构,不是作业机构,通过评审手段决定项目基准是否能变更。其主要职责包括:

• ①负责审查、评价、批准、推迟或否决项目变更;
• ②将变更申请的批准、否决或推迟的决定通知受此处置意见影响的相关干系人;
• ③接收变更与验证结果,确认变更是否按要求完成

2.变更管理负责人:也称变更经理,通常是变更管理过程解决方案的负责人,其主要职责包 括:

• ①负责整个变更过程方案的结果;
• ②负责变更管理过程的监控;
• ③负责协调相关的资源,保障所有变更按照预定过程顺利运作;
• ④确定变更类型,组织变更计划和日程安排;
• ⑤ 管理变更的日程安排;
• ⑥变更实施完成之后的回顾和关闭;
• ⑦ 承担变更相关责任,并且具有相应权限;
• ⑧可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。

3.变更请求者:需要具备理解变更过程的能力要求,提出变更需求。其主要职责包括:

• ①提出变更需求,记录并提交变更请求单;
• ②初步评价变更的风险和影响,给变更请求设定适当的变更类型。

4.变更实施者:需要具备执行变更方案的技术能力,按照批准的变更计划实施变更的内容 (包括必要时的恢复步骤)。其主要职责包括:

• ①负责按照变更计划实施具体的变更任务;
• ②负责记录并保存变更过程中的产物,将变更后的基准纳入项目基准中;
• ③参与变更正确性的验证与确认工作。

5.变更顾问委员会:主要职责包括:

• ①在紧急变更时,可以对被授权者行使审批权限;
• ②定期听取变更经理汇报,评估变更管理执行情况,必要时提出改进建议等。

15.3.3工作程序

变更的流程:

• ①变更申请
• ②对变更的初审
• ③变更方案论证
• ④变更审查
• ⑤发出通知并实施
• ⑥实施监控
• ⑦效果评估
• ⑧变更收尾;

(1)变更申请。变更的提出应当及时以正式方式进行,并留下面记录。变更的提出可以是各种形式,但在 评估前应以书面形式提出。项目的干系人都可以提出变更申请,但一般情况下都需要经过指定人员进行审 批,一般项目经理或者项目配置管理员负责相关信息的收集,以及对变更申请的初审。

(2)对变更的初审 变更初审的目的主要包括:
①对变更提出方施加影响,确认变更的必要性,确保变更是有价值的; ②格式校验,完整性校验,确保评估所需信息准备充分; ③在干系人间就提出供评估的变更信息达成共识等。 变更初审的常见方式为变更申请文档的审核流转。

(3)变更方案论证。
变更方案的主要作用,首先是对变更请求是否可实现进行论证,如果可能实现,则将变更请求由技术要求 转化为资源需求,以供CCB决策。 对于一些大型的变更,可以召开相关的变更方案论证会议,通常需要由变更顾问委员会(相关技术和经济 方面的专家组成) 进行相关论证,并将相关专家意见作为项目变更方案的一部分,报项目CCB作为决策参考。

(4)变更审查:评审过程常包括客户、相关领域的专业人士等。审查通常是文档、会签形式,重大的变更 审查可以采用正式会议形式。应当在评审过程中将专业评审、经济评审分开,对于涉及项目目标和交付成 果的变更,客户和服务对象的意见应放在核心位置。

(5)发出通知并实施 变更评审通过后,意味着基准的调整,同时确保变更方案中的资源需求及时到位。如果变更造成交付期的 调整,应在变更确认时发布,而非在交付前公布。

(6)实施监控:变更实施的过程监控,通常由项目经理负责基准的监控。CCB监控变更的主要成果、进度 里程碑等,也可以通过监理单位完成监控。

(7)效果评估:变更评估的关注内容主要包括:

• ①评估依据是项目的基准;
• ②结合变更的初衷来看,变更所要达到的目的是否已达成;
• ③评估变更方案中的技术论证、经济论证内容与实施过程的差距,并促发解决。

(8)变更收尾:变更收尾是判断发生变更后的项目是否已纳入正常轨道。配置基准调整后,需要确认的是 资源配置是否及时到位,若涉及人员的调整,则需要更加关注。变更完成后对项目的整体监控应按新的基 准进行。

15.3.4变更控制

项目规模小、与其他项目的关联度小时,变更的提出与处理过程可在操作上力求简便、高效。但小项目的变更仍应注意对变更产生的因素施加影响 (如防止不必要的变更,减少无谓的评估,提高必要变更的通过效率等),对变更的确认应当正式化,变更的操作过程应当规范化。

(1)变更申请的控制
变更申请是变更管理流程的起点,故应严格控制变更申请的提交。变更控制的前提是项目基准健全, 变更处理的流程事先达成共识。严格控制是指变更管理体系能确保项目基准反映项目的实施情况。
变更申请的提交,首先应当确保覆盖所有变更操作,这意味着如果变更申请操作可以被绕过,那么变 更申请的严格管理便毫无意义。

(2)变更内容的控制

• ①对进度变更的控制
• ②对成本变更的控制
• ③对合同变更的控制。合同变更控制是规定合同修改的过程,它包括文书工作、跟踪系统、争议解决程 序以及批准变更所需的审批层次。合同变更控制应当与整体变更控制结合起来。

(3) 变更类型的控制

• ①标准变更的控制
  标准变更通常是低风险、预先授权的变更,这类变更已得到充分理解和完整记录,并且可以在不需要额外 授权的情况下实现。它们通常作为服务请求发起,但也可以是操作改变。当创建或修改标准变更时,对于 任何其他变更,应进行全面的风险评估和授权。此风险评估不需要在每次实施标准变更时重复,只有在对 此类执行方式修改时进行评估。
• ②正常变更的控制
  正常变更通常是常规的、较低风险的变更,依据15.3.3的工作程序,通过已确定的变更授权角色和变更管 理流程进行管理。组织可通过使用自动化来提高变更效率,使用连续集成和连续部署的自动化管道控制大 部分变更控制过程。
• ③紧急变更的控制
  紧急变更通常不包括在变更计划中,必须快速响应,尽快实施,例如业务中断故障或事故、安全攻击等。 处理紧急变更的程序在需要时可以精简,遇到紧急变化时和决策权限变更时可以临时调整,如少数了解业 务风险的高级管理人员和重要干系人的决策权发生变化时。

(4)变更输入输出的控制

• ①变更输入的控制主要包括: 项目控制变更的基准、项目计划、配置管理计划、项目文件和组织过程资产等; 变更前的项目工作绩效报告; 提出的变更请求和变更方案等。

• ②变更输出的控制主要包括: - 批准的变更请求; - 更新的项目基准,更新的项目计划、配置管理计划、项目文件和变更日志等; - 变更后的项目工作绩效报告,对比变更执行效果; - 共享经验教训,如偏差产生的原因,己采取的行动措施,以及所吸取的经验教训,使其成为本项目和实 施组织内其他项目历史数据的组成部分。

15.3.5版本发布和回退计划

版本发布前的准备工作包括: ①进行相关的回退分析; ②备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理; ③备份配置数据,包括数据备份的方式; ④备份在线生产平台接口、应用、工作流等版本; ⑤启动回退机制的触发条件; ⑥对变更回退的机制职责的说明,如通知相关部门,确定需要回退的关联系 统和回退时间点等。

回退步骤通常包括: ①通知相关用户系统开始回退; ②通知各关联系统进行版本回退; ③回退存储过程等数据对象; ④配置数据回退; ⑤应用程序、接口程序、工作流等版本回退; ⑥回退完成通知各周边关联系统; ⑦回退后进行相关测试,保证回退系统能够正常运行; ⑧通知用户回退完成等