系统集成项目管理工程师第3版 第15章 组织保障思维导图

系统集成项目管理工程师第3版/第15章 组织保障，主要包含信息和文档管理、配置管理、变更管理等。

组织保障

• 一、 信息和文档管理
  • I. 概要
    • 信息系统相关信息(文档)是指某种数据媒体和其中所记录的数据。
    • 这些信息通常用于描述人工可读的东西，具有永久性，可以由人或机器阅读。在软件工程中，文档常用来表示对活动、需求、过程或结果，进行描述、定义、规定、报告或认证的任何书面或图示的信息(包括纸质文档和电子文档)。
    • 信息和文档管理是指对信息及文档的收集、整理、处理、储存、传递与应用等一系列工作的总称。
    • 项目信息、文档管理是为项目的管理人员及决策者提供所需要的各种信息和数据，并支持其进行统计分析处理。
  • II. 信息和文档
    • i. 信息系统信息
      • （1） 用户信息
        • 1||| 个人或组织的基本信息；
        • 2||| 个人或组织的账号信息；
        • 3||| 个人或组织的信用信息；
        • 4||| 个人或组织的行为数据信息。
      • （2） 业务信息
        • 1||| 根据业务所属行业划分，如金融行业信息、能源行业信息、交通行业信息等；
        • 2||| 根据业务自身特点进行细分，如研发信息、生产信息、维护信息等。
      • （3） 经营管理信息
        • 1||| 市场营销信息
        • 2||| 经营信息
        • 3||| 财务信息
        • 4||| 并购或融资信息
        • 5||| 产品信息
        • 6||| 运营或交付信息等。
      • （4） 系统运行信息
        • 1||| 系统配置信息
        • 2||| 监测数据
        • 3||| 备份数据
        • 4||| 日志数据
        • 5||| 安全漏洞信息等。
    • ii. 信息系统文档
      • （1） 开发文档
        • 开发文档描述开发过程本身
        • 包括：
          • 1||| 可行性研究报告和项目任务书；
          • 2||| 需求规格说明；
          • 3||| 功能规格说明；
          • 4||| 设计规格说明，包括程序和数据规格说明；
          • 5||| 开发计划；
          • 6||| 软件集成和测试计划；
          • 7||| 质量保证计划；
          • 8||| 安全和测试信息。
      • （2） 产品文档
        • 产品文档描述开发过程的产物
        • 包括：
          • 1||| 培训手册：
          • 2||| 参考手册和用户指南；
          • 3||| 软件支持手册；
          • 4||| 产品手册和广告。
      • （3） 管理文档
        • 管理文档记录项目管理的信息
        • 例如：
          • 1||| 开发过程的每个阶段的进度和进度变更的记录；
          • 2||| 软件变更情况的记录；
          • 3||| 开发团队的职责定义；
          • 4||| 项目计划、项目阶段报告；
          • 5||| 配置管理计划。
    • iii. 文档的质量通常可以分为4级
      • （1） 最低限度文档(1级文档):
        • 适合开发工作量低于一个人·月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。
      • （2） 内部文档(2级文档):
        • 可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
      • （3） 工作文档(3级文档):
        • 适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
      • （4） 正式文档(4级文档):
        • 适合那些要正式发行并供普遍使用的软件产品。关键性程序或具有重复管理应用性质(如工资计算)的程序需要4级文档。
  • III. 信息（文档）管理规则和方法
    • i. 信息(文档)编制规范
      • 信息(文档)的规范化管理主要体现在几个方面
        • （1） 文档书写规范
          • 管理信息系统的文档资料涉及文本、图形和表格等多种类型，无论是哪种类型的文档都应该遵循统一的书写规范
        • （2） 图表编号规则
          • 在管理信息系统的开发过程中会用到很多的图表，对这些图表进行有规则的编号，可以方便查找图表。
          • 图表的编号一般采用分类结构。根据生命周期法的5个阶段，可以给出如图15-1所示的分类编号规则。
        • （3） 文档目录编写标准
          • 文档编号一般为分类结构，可以采用同图表编号类似的编号规则。
        • （4） 文档管理制度
          • 建立文档的相关规范是指文档书写规范、图表编号规则和文档目录编写标准等。
    • ii. 信息(文档)定级保护
      • 根据项目干系人和项目价值目标的识别，影响对象主要包括：
        • （1） 个人、法人和其他组织的合法权益和经济利益；
        • （2） 社会秩序、公共利益；
        • （3） 国家安全。
      • 对影响对象的侵害影响程度，归结为：
        • （1） 无影响；
        • （2） 造成一般损害；
        • （3） 造成严重损害；
        • （4） 造成特别严重损害。
    • iii. 信息(文档)配置管理
      • 信息(文档)配置管理是通过技术或者行政的手段对项目管理对象和信息系统的信息进行管理的一系列活动，这些信息不仅包括具体配置项信息，还包括这些配置项之间的相互关系。
      • 配置管理包含配置库的建立和配置管理数据库(Configuration Management Databases,CMDB)准确性的维护，以支持信息系统项目的正常运行。
      • 在信息系统项目中，配置管理可用于问题分析、变更影响度分析、异常分析等，因此，配置项与真实情况的匹配度和详细度非常重要。
• 二、 配置管理
  • I. 概要
    • i. 配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。
    • ii. “配置管理”定义为：“应用技术的和管理的指导和监控方法以 标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性”
  • II. 基本概念
    • i. 配置项(Configuration ltem,Cl)
      • 配置项的定义为：“为配置管理设计的硬件、软件或两者的集合，它在配置管理过程中作为一单个实体来对待”。
      • 配置项是信息系统组件或与其有关的项目，包括软件、硬件和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议和电信服务等。
      • 比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等，它们经评审和检查通过后进入配置管理。
      • 所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在CMDB中。例如在信息系统的开发项目中须加以控制的配置项可以分为基线配置项和非基线配置项两类，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。
      • 所有配置项的操作权限应由配置管理员严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向项目经理、CCB及相关人员开放。
    • ii. 配置项状态
      • 配置项的状态需要根据配置项的不同类型和管理需求进行分别定义，如基于配置项建设过程阶段视角，可将状态分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。
    • iii. 配置项版本号
      • 配置项的版本号规则与配置项的状态定义相关。
      • ①处于“草稿”状态的配置项的版本号格式为0.YZ,YZ的数字范围为01～99;随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
      • ②处于“正式”状态的配置项的版本号格式为X.Y,X为主版本号，取值范围为1～9;Y为次版本号，取值范围为0～9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0,1.1,……当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加到一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。
      • ③处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0,增加 X.Y值。参见上述规则②。
    • iv. 配置项版本管理
      • 配置项的版本管理作用于多个配置管理活动中，如配置标识、配置控制和配置审计、发布和交付等。例如，在信息系统开发项目过程中，绝大部分的配置项都要经过多次修改才能最终确定下来。
      • 对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”,所以不能抛弃旧版本。
      • 版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
    • v. 配置基线
      • 配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。配置基线也是指一个产品或系统在某一特定时刻的配置状况。
      • 基线通常对应于项目过程中的里程碑(Milestone),一个项目可以有多条基线，也可以只有一条基线。交付给用户使用的基线一般称为发行基线(Release),内部过程使用的基线一般称为构造基线(Build)。
      • 对于每一条基线，要定义下列内容：
        • （1） 建立基线的事件
        • （2） 受控的配置项
        • （3） 建立和变更基线的程序
        • （4） 批准变更基线所需的权限
      • 在项目实施过程中，每条基线都要纳入配置控制，对这些基 线的更新只能采用正式的变更控制程序。
      • 建立基线的价值可包括：
        • （1） 基线为项目工作提供了一个定点和快照；
        • （2） 新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目(在主要分支上)所进行的变更进行隔离；
        • （3） 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法；
        • （4） 可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。
    • vi. 配置管理数据库
      • 是指包含每个配置项及配置项之间重要关系的详细资料的数据库。
      • 对于信息系统开发项目来说，常使用配置库实施配置数据的管理。
      • 配置管理数据库主要内容包括：
        • （1） 发布内容，包括每个配置项及其版本号；
        • （2） 经批准的变更可能影响到的配置项；
        • （3） 与某个配置项有关的所有变更请求；
        • （4） 配置项变更轨迹；
        • （5） 特定的设备和软件：
        • （6） 计划升级、替换或弃用的配置项；
        • （7） 与配置项有关的变更和问题；
        • （8） 来自于特定时期特定供应商的配置项；
        • （9） 受问题影响的所有配置项。
      • 配置管理数据库管理所有配置项及其关系，以及与这些配置项有关的事件、问题、已知错误、变更和发布及相关的员工、供应商和业务部门信息；保存多种服务的详细信息及这些服务与IT组件之间的关系；保存配置项的财务信息，如供应商、购买费用和购买日期等。
    • vii. 配置库
      • 配置库(Configuration Library)存放配置项并记录与配置项相关的所有信息，它是配置管理的有力工具。
      • 利用库中的信息可回答许多配置管理的问题，例如：
        • （1） 哪些用户已提取了某个特定的系统版本；
        • （2） 运行一个给定的系统版本需要什么硬件和系统软件；
        • （3） 一个系统到目前已生成了多少个版本，何时生成的；
        • （4） 如果某一特定的构件变更了，会影响到系统的哪些版本；
        • （5） 一个特定的版本曾提出过哪几个变更请求；
        • （6） 一个特定的版本有多少已报告的错误。
      • 使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。
      • 配置库可以分3种类型
        • （1） 开发库
          • 也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如新模块、文档、数据元素或进行修改的已有元素。
          • 动态库中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其进行配置控制，因为这通常不会影响到项目的其他部分。
        • （2） 受控库
          • 也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。
          • 在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
        • （3） 产品库
          • 也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置
          • 于完全的配置管理之下。
          • 在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
      • 配置库的建库模式有两种：
        • （1） 按配置项类型建库
          • 适用于通用软件的开发组织。
          • 在这样的组织内，产品的继承性较强，工具比较统一，对并行开发有一定的需求。
          • 使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
        • （2） 按开发任务建库
          • 适用于专业软件的开发组织。
          • 在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。
  • III. 角色与职责
    • i. 配置控制委员会(CCB)
      • 也称为变更控制委员会，它不只是控制变更，也负有更多的配置管理任务
      • 具体工作包括：
        • （1） 制定和修改项目配置管理策略；
        • （2） 审批和发布配置管理计划；
        • （3） 审批基线的设置、产品的版本等；
        • （4） 审查、评价、批准、推迟或否决变更申请；
        • （5） 监督已批准变更的实施；
        • （6） 接收变更与验证结果，确认变更是否按要求完成；
        • （7） 根据配置管理报告决定相应的对策。
    • ii. 配置管理负责人
      • 也称配置经理，负责管理和决策整个项目生命周期中的配置活动
      • 具体工作包括：
        • （1） 管理所有活动，包括计划、识别、控制、审计和回顾；
        • （2） 负责配置管理过程；
        • （3） 通过审计过程确保配置管理数据库的准确和真实；
        • （4） 审批配置库或配置管理数据库的结构性变更；
        • （5） 定义配置项责任人；
        • （6） 指派配置审计员；
        • （7） 定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态；
        • （8） 评估配置管理过程并持续改进；
        • （9） 参与变更管理过程评估；
        • （10） 对项目成员进行配置管理培训。
    • iii. 配置管理员
      • 配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动
      • 具体工作包括：
        • （1） 建立和维护配置管理系统；
        • （2） 建立和维护配置库或配置管理数据库；
        • （3） 配置项识别；
        • （4） 建立和管理基线；
        • （5） 版本管理和配置控制；
        • （6） 配置状态报告；
        • （7） 配置审计；
        • （8） 发布管理和交付。
    • iv. 配置项负责人
      • 配置项负责人确保所负责配置项的准确和真实
      • 具体工作包括：
        • （1） 记录所负责配置项的所有变更；
        • （2） 维护配置项之间的关系；
        • （3） 调查审计中发现的配置项差异，完成差异报告；
        • （4） 遵从配置管理过程；
        • （5） 参与配置管理过程评估。
  • IV. 目标与方针
    • i. 管理目标
      • 配置管理的目标主要用以定义并控制信息系统的组件，维护准确的配置信息
      • 包括：
        • （1） 所有配置项能够被识别和记录；
        • （2） 维护配置项记录的完整性；
        • （3） 为其他管理过程提供有关配置项的准确信息；
        • （4） 核实有关信息系统的配置记录的正确性并纠正发现的错误；
        • （5） 配置项当前和历史状态得到汇报；
        • （6） 确保信息系统的配置项的有效控制和管理。
      • 组织需要实现的配置管理目标主要有：
        • （1） 确保软件配置管理计划得以制定，并经过相关人员的评审和确认；
        • （2） 应该识别出要控制的项目产品有哪些，并且制定相关控制策略，以确保这些项目产品被合适的人员获取；
        • （3） 应制定控制策略，以确保项目产品在受控制范围内更改；
        • （4） 应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容。
    • ii. 管理方针
      • 配置管理的关键成功因素主要包括：
        • （1） 所有配置项应该记录；
        • （2） 配置项应该分类；
        • （3） 所有配置项要进行编号；
        • （4） 应该定期对配置库或配置管理数据库中的配置项信息进行审计；
        • （5） 每个配置项在建立后，应有配置负责人负责；
        • （6） 要关注配置项的变化情况；
        • （7） 应该定期对配置管理进行回顾；
        • （8） 能够与项目的其他管理活动进行关联。
  • V. 管理活动
    • i. 制订配置管理计划
      • 配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。
      • CCB负责审批该计划。
      • 配置管理计划的主要内容包括：
        • 1||| 配置管理的目标和范围；
        • 2||| 配置管理活动主要包括配置项识别、配置项控制、配置状态报告、配置审计、配置管理回顾及改进等；
        • 3||| 配置管理角色和责任安排；
        • 4||| 实施这些活动的规范和流程，如配置项命名规则；
        • 5||| 实施这些活动的进度安排，如日程安排和程序；
        • 6||| 与其他管理之间(如变更管理等)的接口控制；
        • 7||| 负责实施这些活动的人员或团队，以及他们和其他团队之间的关系；
        • 8||| 配置管理信息系统的规划包括配置数据的存放地点、配置项运行的受控环境、与其他服务管理系统的联系和接口、构建和安装等支持工具；
        • 9||| 配置管理的日常事务包括许可证控制、配置项的存档等；
        • 10||| 计划的配置基准线、重大发布、里程碑，以及针对以后每个期间的工作量计划和资源计划。
    • ii. 配置项识别
      • 配置项识别是针对所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构进行识别的过程。它包括为配置项分配标识和版本号等。
      • 配置项识别是配置管理员的职能。
      • 配置项识别的基本步骤如下：
        • （1） 识别需要受控的配置项；
        • （2） 为每个配置项指定唯一的标识号；
        • （3） 定义每个配置项的重要特征；
        • （4） 确定每个配置项的所有者及其责任；
        • （5） 确定配置项进入配置管理的时间和条件；
        • （6） 建立和控制基线；
        • （7） 维护文档和组件的修订与产品版本之间的关系。
    • iii. 配置项控制
      • 1. 配置控制即配置项和基线的变更控制
      • 2. 包括
        • 变更申请
          • 相关人员(如项目经理)填写变更申请表，说明要变更的内容、变更的原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，并提交给 CCB。
        • 变更评估
          • CCB负责组织对变更申请进行评估并确定：
            • 1||| 变更对项目的影响；
            • 2||| 变更的内容是否必要；
            • 3||| 变更的范围是否考虑周全；
            • 4||| 变更的实施方案是否可行；
            • 5||| 变更工作量估计是否合理。
          • CCB 决定是否接受变更，并将决定通知相关人员。
        • 通告评估结果
          • CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意 见影响的每个干系人。
        • 变更实施
          • 项目经理组织修改相关的配置项，并在相应的文档、程序代码或配置管理数据中记录变更信息。
        • 变更验证与确认
          • 项目经理指定人员对变更后的配置项进行测试或验证。
          • 项目经理应将变更与验证的结果提交 CCB,由其确认变更是否已经按要求完成。
        • 变更的发布
          • 配置管理员将变更后的配置项纳入基线。
          • 配置管理员将变更内容和结果通知相关人员，并做好记录。
        • 基于配置库的变更控制
          • 在信息系统开发项目中，一处出现了变更，经常会连锁引起 多处变更，会涉及参与开发工作的许多人员。
          • 基于配置库的变更控制可以完美地解决上述问题，如图
      • 3. 现以某软件产品升级为例，其过程简述为：
        • （1） 将待升级的基线(假设版本号为V2.1)从产品库中取出，放入受控库。
        • （2） 程序员将欲修改的代码段从受控库中检出(Check out),放入自己的开发库中进行修改。代码被检出后即被“锁定”,以保证同一段代码只能同时被一个程序员修改，如果甲正在对其修改，乙就无法将其检出。
        • （3） 程序员将开发库中修改好的代码段检入(Check in)受控库。代码检入后，代码的“锁定”被解除，其他程序员就可以检出该段代码了。
        • （4） 软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中(软件产品的版本号更新为V2.2,旧的V2.1版并不删除，继续在产品库中保存)。
    • iv. 配置状态报告
      • 也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
      • 配置状态报告主要包含下述内容
        • （1） 每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。
        • （2） 每个变更申请的状态和已批准的修改的实施状态。
        • （3） 每个基线的当前和过去版本的状态以及各版本的比较。
        • （4） 其他配置管理过程活动的记录等。
    • v. 配置审计
      • 也称配置审核或配置评价，包括
        • （1） 功能配置审计
          • 计是审计配置项的一致性(配置项的实际功效是否与其需求一致)
          • 具体验证主要包括：
            • 1||| 配置项的开发已圆满完成；
            • 2||| 配置项已达到配置标识中规定的性能和功能特征；
            • 3||| 配置项的操作和支持文档已完成并且符合要求等。
        • （2） 物理配置审计
          • 审计配置项的完整性(配置项的物理存在是否与预期一致)
          • 具体验证主要包括：
            • 1||| 要交付的配置项是否存在；
            • 2||| 配置项中是否包含了所有必需的项目等。
      • 配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求：不允许出现任何混乱现象。例如：
        • （1） 防止向用户提交不适合的产品，如交付了用户手册的不正确版本；
        • （2） 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更；
        • （3） 找出各配置项间不匹配或不相容的现象；
        • （4） 确认配置项已在所要求的质量控制审核之后纳入基线并入库保存；
        • （5） 确认记录和文档保持可追溯性等。
      • 应当进行配置审计的场景包括：
        • （1） 实施新的配置库或配置管理数据库之后；
        • （2） 对信息系统实施重大变更前后；
        • （3） 在一项软件发布和安装被导入实际运作环境之前；
        • （4） 灾难恢复之后或事件恢复正常之后；
        • （5） 发现未经授权的配置项后；
        • （6） 任何其他必要的时候等。
      • 部分常规配置审计工作可由审计软件完成，审计软件即使发现不一致的情况，也不允许自动更新配置库或配置管理数据库，必须由有关负责人调查后再进行更新。
    • vi. 配置管理回顾与改进
      • 配置管理回顾与改进是指定期回顾配置管理活动的实施情况，目的是发现在配置管理执行过程中有无问题，找到改进点，优化配置管理过程。
      • 配置管理回顾与改进活动包括：
        • （1） 对本次配置管理回顾进行准备，设定日期和主题，通知相关人等参加会议。根据配置管理绩效衡量指标，要求配置项责任人提供配置项统计信息；
        • （2） 召开配置管理回顾会议，在设定日期召开回顾会议，对配置管理报告进行汇报，听取各方意见，回顾上次过程改进计划执行情况；
        • （3） 根据会议结论，制订并提交服务改进计划；
        • （4） 根据过程改进计划，协调落实改进等。
• 三、 变更管理
  • I. 基本概念
    • i. 项目变更的含义
      • 项目变更是指在信息系统项目的实施过程中，由于项目环境或者其他的原因而对项目的功能、性能、架构、技术指标、集成方法和项目进度等方面做出的改变。
      • 项目管理方法的基本原理，是将特定的目标通过规范的计划过程，转化为基准共识之后以指导项目执行，同时作为项目有效监控、收尾的依据。
      • 变更管理，即是为使项目基准与项目实际执行情况相一致，应对项目变化的一套管理方法。其可能的结果是拒绝变化，或是调整项目基准。变更管理的实质是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值。
    • ii. 变更产生的原因
      • （1） 产品范围(成果)定义的过失或者疏忽；
      • （2） 项目范围(工作)定义的过失或者疏忽；
      • （3） 增值变更；
      • （4） 应对风险的紧急计划或回避计划；
      • （5） 项目执行过程与基准要求不一致带来的被动调整；
      • （6） 外部事件等。
    • iii. 变更分类
      • 1. 根据变更性质可分为重大变更、重要变更和一般变更，可通过不同审批权限来控制；
      • 2. 根据变更的迫切性可分为紧急变更、非紧急变更；
      • 3. 根据行业特征进行的变更，如弱电工程行业的常见分类方法为产品(工作)范围变更、环境变更、设计变更、实施变更和技术标准变更。
    • iv. 变更管理原则
      • 变更管理的原则是项目基准化、变更管理过程规范化。
      • 变更管理的主要内容包括：
        • （1） 基准管理
          • 基准是变更的依据。
          • 在项目实施过程中，基准计划确定并经过评审后(通常用户应参与部分评审工作),建立初始基准。此后每次变更通过评审后，都应重新确定基准。
        • （2） 变更控制流程化
          • 建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控制流程进行控制。
          • 流程化的作用在于将变更的原因、专业能力、资源运用方案、决策权、干系人的共识、信息流转等元素有效综合起来，按科学的顺序进行。
        • （3） 明确组织分工
          • 至少应明确变更相关工作的评估、评审、执行的职能。
        • （4） 与干系人充分沟通
          • 须征求项目重要干系人的意见，获得对项目变更的支持。
        • （5） 变更的及时性
          • 变更宜早不宜晚，只做必须要变更的。越在项目早期，项目变更的代价越小，随着项目的开展，项目变更的代价就会越来越大。由于变更可能带来连锁反应，所以可做可不做的，尽量不做。
        • （6） 评估变更的可能影响
          • 变更的来源是多样的，既需要完成对客户可视的成果、交付期等变更操作，还需要完成对客户不可视的项目内部工作的变更，如实施方的人员分工、管理工作、资源配置等。
        • （7） 妥善保存变更产生的相关文档
          • 确保其完整、及时、准确、清晰，适当时可以引入配 置管理工具。
    • v. 变更管理与相关活动的关系
      • 1. 变更管理与项目整合管理的关系
        • 变更管理是项目整合管理的一部分，实施整体变更控制过程贯穿项目始终。
      • 2. 变更管理与配置管理的关系
        • 项目的配置管理计划应规定哪些项目组件受控于配置控制程序。
        • 对配置项的任何变更都应该提出变更请求，并经过变更控制。
        • 配置管理重点关注可交付产品(包括中间产品)及各过程文档，而变更管理则着眼于识别、记录、批准或否决对项目文件、可交付产品或基准的变更。
        • 变更管理过程中包含的部分配置管理活动如下
          • 1||| 配置项识别：
            • 识别与选择配置项，从而为核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
          • 2||| 配置状态记录：
            • 为了能及时提供关于配置项的准确数据，应记录和报告配置项的相关信息。
            • 此类信息包括变更控制中的已批准的配置项清单、变更申请的状态和已批准变更的实施状态。
          • 3||| 配置确认与审计：
            • 通过配置确认与配置审计，可确保项目各配置组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。
  • II. 角色与职责
    • i. 变更控制委员会(CCB)
      • 变更控制委员会是由主要项目干系人代表组成的一个正式团体，它是决策机构，不是作业机构，通过评审手段决定项目基准是否能变更。
      • 其主要职责包括：
        • （1） 负责审查、评价、批准、推迟或否决项目变更；
        • （2） 将变更申请的批准、否决或推迟的决定通知受此处置意见影响的相关干系人：
        • （3） 接收变更与验证结果，确认变更是否按要求完成。
    • ii. 变更管理负责人
      • 也称变更经理，通常是变更管理过程解决方案的负责人
      • 其主要职责包括：
        • （1） 负责整个变更过程方案的结果；
        • （2） 负责变更管理过程的监控；
        • （3） 负责协调相关的资源，保障所有变更按照预定过程顺利运作；
        • （4） 确定变更类型，组织变更计划和日程安排；
        • （5） 管理变更的日程安排；
        • （6） 变更实施完成之后的回顾和关闭；
        • （7） 承担变更相关责任，并且具有相应权限；
        • （8） 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。
    • iii. 变更请求者
      • 变更请求者需要具备理解变更过程的能力要求，提出变更需求。
      • 其主要职责包括：
        • （1） 提出变更需求，记录并提交变更请求单；
        • （2） 初步评价变更的风险和影响，给变更请求设定适当的变更类型。
    • iv. 变更实施者
      • 变更实施者需要具备执行变更方案的技术能力，按照批准的变更计划实施变更的内容(包括必要时的恢复步骤)。
      • 其主要职责包括：
        • （1） 负责按照变更计划实施具体的变更任务；
        • （2） 负责记录并保存变更过程中的产物，将变更后的基准纳入项目基准中；
        • （3） 参与变更正确性的验证与确认工作。
    • v. 变更顾问委员会
      • 主要职责包括：
        • （1） 在紧急变更时，可以对被授权者行使审批权限；
        • （2） 定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等。
  • III. 工作程序
    • i. 变更申请
      • 变更的提出应当及时以正式方式进行，并留下书面记录。
      • 变更的提出可以是各种形式，但在评估前应以书面形式提出。
      • 项目的干系人都可以提出变更申请，但一般情况下都需要经过指定人员进行审批，一般项目经理或者项目配置管理员负责相关信息的收集，以及对变更申请的初审。
    • ii. 对变更的初审
      • 变更初审的目的主要包括：
        • （1） 对变更提出方施加影响，确认变更的必要性，确保变更是有价值的；
        • （2） 格式校验，完整性校验，确保评估所需信息准备充分；
        • （3） 在干系人间就提出供评估的变更信息达成共识等。
      • 变更初审的常见方式为变更申请文档的审核流转。
    • iii. 变更方案论证
      • 变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。
      • 常见的方案内容包括技术评估和经济与社会效益评估，前者评估需求如何转化为成果，后者评估变更方面的经济与社会价值和潜在的风险。
      • 对于一些大型的变更，可以召开相关的变更方案论证会议，通常需要由变更顾问委员会(相关技术和经济方面的专家组成)进行相关论证，并将相关专家意见作为项目变更方案的一部分，报项目CCB作为决策参考。
    • iv. 变更审查
      • 变更审查是项目所有者根据变更申请及评估方案，决定是否变更项目基准。
      • 评审过程常包括客户、相关领域的专业人士等。审查通常是文档、会签形式，重大的变更审查可以包括正式会议形式。
    • v. 发出通知并实施
      • 变更评审通过后，意味着基准的调整，同时确保变更方案中的资源需求及时到位。基准调整包括项目目标的确认，最终成果、工作内容和资源、进度计划的调整。
      • 需要强调的是：变更通知不只是包括项目实施基准的调整，更要明确项目的交付日期，以及成果对相关干系人的影响。如变更造成交付期的调整，应在变更确认时发布，而非在交付前公布。
    • vi. 实施监控
      • 变更实施的监控，除了调整基准中涉及变更的内容外，还应当对项目的整体基准是否反映项目实施情况负责。
      • 通过监控行动，确保项目的整体实施工作是受控的。
      • 变更实施的过程监控，通常由项目经理负责基准的监控。CCB监控变更的主要成果、进度里程碑等，也可以通过监理单位完成监控。通过对变更实施的监控，确认变更是否正确完成，对于正确完成的变更，需按配置管理计划中定义的配置控制范围，纳入配置管理系统中。
    • vii. 效果评估
      • 关注内容主要包括：
        • （1） 评估依据是项目的基准；
        • （2） 结合变更的初衷来看，变更所要达到的目的是否已达成；
        • （3） 评估变更方案中的技术论证、经济论证内容与实施过程的差距并促发解决。
    • viii. 变更收尾
      • 变更收尾是判断发生变更后的项目是否已纳入正常轨道。
      • 配置基准调整后，需要确认的是资源配置是否及时到位，若涉及人员的调整，则需要更加关注。变更完成后对项目的整体监控应按新的基准进行。若涉及变更的项目范围及进度，则在变更后的紧邻监控中，应更多关注确认新的基准生效情况，以及项目实施流程的正常使用情况。
  • IV. 变更控制
    • i. 变更申请的控制
      • 变更控制的前提是项目基准健全，变更处理的流程事先达成共识。
      • 严格控制是指变更管理体系能确保项目基准反映项目的实施情况。
    • ii. 变更内容的控制
      • 1. 对进度变更的控制主要包括：
        • （1） 判断当前项目进度的状态；
        • （2） 对造成进度变化的因素施加影响；
        • （3） 查明进度是否已经改变；
        • （4） 在实际变化出现时对其进行管理。
      • 2. 对成本变更的控制主要包括：
        • （1） 对造成费用基准变更的因素施加影响；
        • （2） 确保变更请求获得同意；
        • （3） 当变更发生时，管理这些实际的变更；
        • （4） 保证潜在的费用超支不超过授权的项目阶段资金和总体资金；
        • （5） 监督项目费用绩效，找出与费用基准的偏差；
        • （6） 准确记录所有的与费用基准的偏差；
        • （7） 防止错误的、不恰当的或未批准的变更被纳入费用或资源使用报告中；
        • （8） 就审定的变更，通知利害关系者；
        • （9） 采取措施，将预期的费用超支控制在可接受的范围内；
        • （10） 控制项目费用，查找造成正、负偏差的原因。
      • 3. 对合同变更的控制。
        • 合同变更控制是规定合同修改的过程，它包括文书工作、跟踪系统、争议解决程序以及批准变更所需的审批层次。
        • 合同变更控制应当与整体变更控制结合起来。
    • iii. 变更类型的控制
      • 1. 标准变更的控制
        • 标准变更通常是低风险、预先授权的变更，这类变更已得到充分理解和完整记录，并且可以在不需要额外授权的情况下实现。
        • 它们通常作为服务请求发起，但也可以是操作改变。当创建或修改标准变更时，对于任何其他变更，应进行全面的风险评估和授权。
        • 此风险评估不需要在每次实施标准变更时重复，只有在对此类执行方式修改时进行评估。
      • 2. 正常变更的控制
        • 正常变更通常是常规的、较低风险的变更，通过已确定的变更授权角色和变更管理流程进行管理。
        • 组织可通过使用自动化来提高变更效率，使用连续集成和连续部署的自动化管道控制大部分变更控制过程。
      • 3. 紧急变更的控制
        • 紧急变更通常不包括在变更计划中，必须快速响应，尽快实施，例如业务中断故障或事故、安全攻击等。
        • 处理紧急变更的程序在需要时可以精简，遇到紧急变化时和决策权限变更时可以临时调整，如少数了解业务风险的高级管理人员和重要干系人的决策权发生变化时。
        • 在考虑到规避问题复杂化的风险的同时，尽可能迅速地进行变更，尽可能接受相同的测试，但有些情况下，更全面的测试和调整可能会在实现之后持续一段时间再进行。
    • iv. 变更输入输出的控制
      • 1. 变更输入的控制主要包括：
        • （1） 项目控制变更的基准、项目计划、配置管理计划、项目文件和组织过程资产等；
        • （2） 变更前的项目工作绩效报告；
        • （3） 提出的变更请求和变更方案等。
      • 2. 变更输出的控制主要包括：
        • （1） 批准的变更请求：
        • （2） 更新的项目基准，更新的项目计划、配置管理计划、项目文件和变更日志等；
        • （3） 变更后的项目工作绩效报告，对比变更执行效果；
        • （4） 共享经验教训，如偏差产生的原因，已采取的行动措施，以及所吸取的经验教训，使其成为本项目和实施组织内其他项目历史数据的组成部分。
  • V. 版本发布和回退计划
    • i. 版本发布前的准备工作包括：
      • 1. 进行相关的回退分析；
      • 2. 备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理；
      • 3. 备份配置数据，包括数据备份的方式；
      • 4. 备份在线生产平台接口、应用和工作流等版本；
      • 5. 启动回退机制的触发条件；
      • 6. 对变更回退的机制职责的说明，如通知相关部门，确定需要回退的关联系统和回退时间点等。
    • ii. 回退步骤通常包括：
      • 1. 通知相关用户系统开始回退；
      • 2. 通知各关联系统进行版本回退；
      • 3. 回退存储过程等数据对象；
      • 4. 配置数据回退；
      • 5. 应用程序、接口程序、工作流等版本回退；
      • 6. 回退完成通知各周边关联系统；
      • 7. 回退后进行相关测试，保证回退系统能够正常运行；
      • 8. 通知用户回退完成等。