【中项第三版】系统集成项目管理工程师 | 第 15 章组织保障

Jackilina_Stone

于 2024-08-21 12:30:53 发布

阅读量571

点赞数 22

分类专栏：【软考】系统集成项目管理工程师文章标签：中项第三版系统集成项目管理工程师软考中级

本文链接：https://blog.csdn.net/wss794/article/details/141390350

版权

【软考】系统集成项目管理工程师专栏收录该内容

33 篇文章 32 订阅

订阅专栏

前言

本章的知识点预计上午会考1-2分，下午可能会考，一般与其他管理领域进行结合考查。学习要以教材为主。

15.1 信息和文档管理

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

15.1.1 信息和文档

1 信息系统信息

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

2 信息系统文档

▲开发文档

描述开发过程本身。

①可行性研究报告和项目任务书；②需求规格说明③功能规格说明；④设计规格说明，包括程序和数据规格说明；⑤开发计划；⑥软件集成和测试计划；⑦质量保证计划；⑧安全和测试信息。

▲产品文档

描述开发过程的产物。

①培训手册；②参考手册和用户指南；③软件支持手册；④产品手册和信息广告。

▲管理文档

记录项目管理的信息。

①开发过程的每个阶段的进度和进度变更的记录；②软件变更情况的记录；③开发团队的职责定义：④项目计划、项目阶段报告；⑤配置管理计划。

文档的质量通常分为4级。包括：

最低限度文档（1级文档）：适合开发工作量低于一个人·月的开发者自用程序。该文档应包含程序清单，开发记录，测试数据和程序简介。

内部文档（2级文档）：可用于没有与其他用户共享资源的专用程序。2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。

工作文档（3级文档）：适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。

正式文档（4级文档）：适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要4级文档。

15.1.2 信息（文档）管理规则和方法

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

①文档书写规范：应该遵循统一的书写规范，包括符号的使用，图标的含义、程序中注释行的使用，注明文档书写人及书写日期等；

②图表编号规则：对这些图表进行有规则的编号，可以方便查找图表；图表编号规则如下图15-1所示：

③文档目录编写标准；

④文档管理制度：应该建立相应的文档管理制度。

● 信息（文档）定级保护

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

①根据项目干系人和项目价值目标的识别，影响对象主要包括：

个人、法人和其他组织的合法权益和经济利益；

社会秩序、公共利益；

国家安全。

②对影响对象的侵害影响程度，归结为：

无影响；

造成一般损害；

造成严重损害；

造成特别严重损害。

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

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

● 信息（文档）配置管理

在信息系统项目中，配置管理可用于问题分析、变更影响度分析、异常分析等，因此，配置项与真实情况的匹配度和详细度非常重要。在组织实施信息系统项目过程中，常常会遇到变更的发生。变更一般有主动变更和被动变更两种。

·主动变更是主动发起的变更，常用于提高项目收益，包括降低成本、改进过程以及提高项目的便捷性和有效性等；

·被动变更常用于范围变化、异常、错误和适应不断变化的环境等，如随需求的增加，相应需要增加系统的功能或投资等。

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

15.2 配置管理

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

15.2.1 基本概念

1.配置项(Configuration Item, Cl)

配置项的定义为：“为配置管理设计的硬件、软件或两者的集合，它在配置管理过程中作为一单个实体来对待”。

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

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

●基线配置项可能包括所有的设计文档和源程序等；

●非基线配置项可能包括项目的各类计划和报告等。

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

●基线配置项向开发人员开放读取的权限；

●非基线配置项向项目经理、CCB及相关人员开放。

2.配置项状态

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

●配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。

●此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。配置项状态变化如下图15-2所示：

3.配置项版本号

①处于“草稿”状态的配置项的版本号格式为O.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。

②处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0～9。配置项第一次成为“正式”文件时，版本号为1.0。

③处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。

4.配置项版本管理

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

5.配置基线

配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、己编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。

6.配置管理数据库

配置管理数据库主要内容包括：

①发布内容，包括每个配置项及其版本号；

②经批准的变更可能影响到的配置项；

③与某个配置项有关的所有变更请求；

④配置项变更轨迹；

⑤特定的设备和软件；

⑥计划升级、替换或弃用的配置项；

⑦与配置项有关的变更和问题；

⑧来自于特定时期特定供应商的配置项；

⑨受问题影响的所有配置项。

7.配置库

配置库可以分开发库、受控库、产品库3种：

①开发库。开发库也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。无须对其进行配置控制。【可以任意的修改】。

②受控库，受控库也称为主库，包含当前的基线以及对基线的变更，受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。【可以修改，需要走变更流程】。

③产品库、产品库也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。【一般不再修改，要修改的话需要走变更流程】。

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

①按配置项的类型分类建库。这种模式适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。

②按开发任务建立相应的配置库。这种模式适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以没必要把配置项严格分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。

15.2.2 角色与职责

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

1 配置控制委员会CCB

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

①制定和修改项目配置管理策略；

②审批和发布配置管理计划；

③审批基线的设置、产品的版本等；

④审查、评价、批准、推迟或否决变更申请；

⑤监督己批准变更的实施；

⑥接收变更与验证结果，确认变更是否按要求完成；

⑦根据配置管理报告决定相应的对策。

2 配置管理负责人

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

①管理所有活动，包括计划、识别、控制、审计和回顾；

②负责配置管理过程；

③通过审计过程确保配置管理数据库的准确和真实；

④审批配置库或配置管理数据库的结构性变更；

⑤定义配置项责任人；

⑥指派配置审计员；

⑦定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态；

⑧评估配置管理过程并持续改进；

⑨参与变更管理过程评估；

⑩对项目成员进行配置管理培训。

3 配置管理员

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

①建立和维护配置管理系统；

②建立和维护配置库或配置管理数据库；

③配置项识别；

④建立和管理基线；

⑤版本管理和配置控制；

⑥配置状态报告；

⑦配置审计；

⑧发布管理和交付。

4 配置项负责人

配置项负责人确保所负责的配置项的准确和真实：

①记录所负责配置项的所有变更；

②维护配置项之间的关系；

③调查审计中发现的配置项差异，完成差异报告；

④遵从配置管理过程；

⑤参与配置管理过程评估。

15.2.3 目标与方针

1 管理目标

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

2 管理方针

为了实现配置管理目标，组织应定义配置管理过程，制定配置管理相关制度。

15.2.4 管理活动

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

①制订配置管理计划（写一个文档，叫做配置管理计划，规定如何做好配置管理）;

②配置项标识（识别出需要把哪些东西作为配置项来管理）;

③配置项控制（配置项有一些变更，需要做好配置变更的控制）;

④配置状态报告（需要报告配置项的状态是什么样的）;

⑤配置审计（做好审计，看有哪些好的，哪些不好的经验教训，以及效果怎么样）；

⑥配置管理回顾与改进（定期回顾配置管理活动的实施情况，发现在配置管理执行过程中有无问题，找到改进点，继而优化配置管理过程）。

1 制定配置管理计划

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

2 配置项标识

配置项识别是针对所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构进行识别的过程。它包括为配置项分配标识和版本号等。配置项识别是配置管理员的职能。

配置项识别的基本步骤如下：

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

3 配置项控制

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

▲变更申请。相关人员（如项目经理）填写变更申请表，说明要变更的内容、变更的原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，并提交给CCB。

▲变更评估。CCB负责组织对变更申请进行评估并确定：

①变更对项目的影响；

②变更的内容是否必要；

③变更的范围是否考虑周全；

④变更的实施方案是否可行；

⑤变更工作量估计是否合理。

CCB决定是否接受变更，并将决定通知相关人员。

▲通告评估结果。CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。

▲变更实施：项目经理组织修改相关的配置项，并在相应的文档、程序代码或配置管理数据中记录变更信息。

▲变更验证与确认：项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交给CCB，由其确认变更是否已经按要求完成。

▲变更的发布：配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员并做好记录。

▲基于配置库的变更控制：

现以某软件产品升级为例，其过程简述为：

①将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库。

②程序员将欲修改的代码段从受控库中检出（Checkout），放入自己的开发库中进行修改。代码被检出后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out。

③程序员将开发库中修改好的代码段检入（Checkin）受控库。检入后，代码的“锁定”被解除，其他程序员可以Check out该段代码了。

④软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为V2.2，旧的V2.1版并不删除，继续在产品库中保存）。

基于配置库的变更控制见下图15-3。

4 配置状态报告

配置状态报告应该包含以下内容：

①每个受控配置项的标识和状态；

②每个变更申请的状态和已批准的修改的实施状态。

③每个基线的当前和过去版本的状态以及各版本的比较。

④其他配置管理过程活动的记录等。

5 配置审计

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

①防止向用户提交不适合的产品，如交付了用户手册的不正确版本。

②发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。

③找出各配置项间不匹配或不相容的现象。

④确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。

⑤确认记录和文档保持着可追溯性。

功能配置审计是审计配置项的一致性（配置项的实际功效是否与其需求一致)，验证：①配置项的开发已圆满完成；②配置项已达到配置标识中规定的性能和功能特征；③配置项的操作和支持文档己完成并且是符合要求的。

物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一致），验证：①要交付的配置项是否存在；②配置项中是否包含了所有必需的项目。

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

①实施新的配置库或配置管理数据库之后；

②对信息系统实施重大变更前后；

③在一项软件发布和安装被导入实际运作环境之前；

④灾难恢复之后或事件恢复正常之后；

⑤发现未经授权的配置项后；

⑥任何其他必要的时候等。

6 配置管理回顾及改进

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

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

①对本次配置管理回顾进行准备，设定日期和主题，通知相关人等参加会议。根据配置管理绩效衡量指标，要求配置项责任人提供配置项统计信息；

②召开配置管理回顾会议，在设定日期召开回顾会议，对配置管理报告进行汇报，听取各方意见，回顾上次过程改进计划执行情况；

③根据会议结论，制订并提交服务改进计划；

④根据过程改进计划，协调落实改进。

15.3 变更管理

15.3.1 基本概念

1 项目变更的含义

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

2 变更产生的原因

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

3 变更分类

根据变更性质可分为：重大变更、重要变更和一般变更。通过不同审批权限控制。

根据变更的迫切性可分为：紧急变更、非紧急变更。通过不同变更处理流程进行。

4 变更管理原则

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

▲基准管理：基准是变更的依据。

▲变更控制流程化：所有变更都必须遵循这个控制流程进行控制。

▲明确组织分工：至少应明确变更相关工作的评估、评审、执行的职能。

▲与干系人充分沟通：须征求项目重要干系人的意见，获得对项目变更的支持。

▲变更的及时性：变更宜早不宜晚，只做必须要变更的。由于变更可能带来连锁反应，所以可做可不做的，尽量不做。

▲评估变更的可能影响：变更的来源是多样的，既需要完成对客户可视的成果、交付期等变更操作，还需要完成对客户不可视的项目内部工作的变更。

▲妥善保存变更产生的相关文档，确保其完整、及时、准确、清晰，适当时可以引入配置管理工具。

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

▲变更管理与项目整合管理的关系

变更管理是项目整合管理的一部分，实施整体变更控制过程贯穿项目始终。

▲变更管理与配置管理的关系

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

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

15.3.2 角色与职责

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

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

响应变更提出者的需求；

评估变更对项目的影响及应对方案；

将需求由技术要求转化为资源需求，供授权人决策；

依据变更评审结果调整基准，确保项目基准反映项目实施情况，并监控变更及已批准的变更正确实施。

1 变更控制委员会（CCB）

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

①负责审查、评价、批准、推迟或否决项目变更；

②将变更申请的批准、否决或推迟的决定通知受此处置意见影响的相关干系人；

③接收变更与验证结果，确认变更是否按要求完成。

2 变更管理负责人

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

①负责整个变更过程方案的结果；

②负责变更管理过程的监控；

③负责协调相关的资源，保障所有变更按照预定过程顺利运作；

④确定变更类型，组织变更计划和日程安排；

⑤管理变更的日程安排；

⑥变更实施完成之后的回顾和关闭；

⑦承担变更相关责任，并且具有相应权限；

⑧可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。

3 变更请求者

需要具备理解变更过程的能力要求，提出变更需求。其主要职责包括：

①提出变更需求，记录并提交变更请求单；

②初步评价变更的风险和影响，给变更请求设定适当的变更类型。

4 变更实施者

需要具备执行变更方案的技术能力，按照批准的变更计划实施变更的内容（包括必要时的恢复步骤）。其主要职责包括：

①负责按照变更计划实施具体的变更任务；

②负责记录并保存变更过程中的产物，将变更后的基准纳入项目基准中；

③参与变更正确性的验证与确认工作。

5 变更顾问委员会

主要职责包括：：

①在紧急变更时，可以对被授权者行使审批权限；

②定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等。

15.3.3 工作程序

变更的流程如下：

①变更申请

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

②对变更的初审

变更初审的目的主要包括：

①对变更提出方施加影响，确认变更的必要性，确保变更是有价值的；

②格式校验，完整性校验，确保评估所需信息准备充分；

③在干系人间就提出供评估的变更信息达成共识等。

变更初审的常见方式为变更申请文档的审核流转。

③变更方案论证

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

④变更审查

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

⑤发出通知并实施

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

⑥实施监控

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

⑦效果评估

变更评估的关注内容主要包括：

评估依据是项目的基准；

结合变更的初衷来看，变更所要达到的目的是否已达成；

评估变更方案中的技术论证、经济论证内容与实施过程的差距，并促发解决。

⑧变更收尾

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

15.3.4 变更控制

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

▲变更申请的控制

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

▲变更内容的控制

①对进度变更的控制

②对成本变更的控制

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

▲变更类型的控制

①标准变更的控制

标准变更通常是低风险、预先授权的变更，这类变更已得到充分理解和完整记录，并且可以在不需要额外授权的情况下实现。它们通常作为服务请求发起，但也可以是操作改变。当创建或修改标准变更时，对于任何其他变更，应进行全面的风险评估和授权。此风险评估不需要在每次实施标准变更时重复，只有在对此类执行方式修改时进行评估。

②正常变更的控制

正常变更通常是常规的、较低风险的变更，依据15.3.3节的工作程序，通过已确定的变更授权角色和变更管理流程进行管理。组织可通过使用自动化来提高变更效率，使用连续集成和连续部署的自动化管道控制大部分变更控制过程。

③紧急变更的控制

紧急变更通常不包括在变更计划中，必须快速响应，尽快实施，例如业务中断故障或事故、安全攻击等。处理紧急变更的程序在需要时可以精简，遇到紧急变化时和决策权限变更时可以临时调整，如少数了解业务风险的高级管理人员和重要干系人的决策权发生变化时。

▲变更输入输出的控制

①变更输入的控制主要包括：

·项目控制变更的基准、项目计划、配置管理计划、项目文件和组织过程资产等；

·变更前的项目工作绩效报告；

·提出的变更请求和变更方案等。

②变更输出的控制主要包括：

·批准的变更请求；

·更新的项目基准，更新的项目计划、配置管理计划、项目文件和变更日志等；