第十九章 配置与变更管理

选择题4分左右，案例论文均可能考

配置管理

管理基础

• 配置项
  1）配置项是信息系组件或与其有关的项目，包扣软件，硬件和各种文档。
  2）典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及关键部件等。
  3）在信息系统的开发项目中需要加以控制的配置项可以分为基线配置项和非基线配置项两类：
  基线配置项可能包括所有的设计文档和源程序等；基线配置项向开发人员开放读取的权限。
  非基线配置项可能包括项目的各类计划和报告等；非基线配置项向项目经理、CCB及相关人员开放。
• 配置项状态
  1）配置项可分为“草稿”“正式”“修改”三种。
  配置项刚建立时，其状态为“草稿”。
  配置项通过评审后，其状态变为“正式”。
  若更改配置项，则其状态变为“修改”。
  当配置项修改完毕并重新通过评审时，其状态又变为“正式”。
• 配置项的版本号
  1）处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01-99，随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
  2）处于“正式”状态的配置项的版本号格式为X.Y。X为主版本号，取值范围为1-9，Y为次版本号，取值范围为0-9.
  3）处于“修改”状态的配置项的版本号格式为X.YZ。**配置项正在修改时，一般指增大Z值，X.Y值保持不变。**当配置项修改完毕，状态成为“正式”时，将Z值设为0，增加X.Y值。
• 配置项版本管理
  1）对配置项的任何修改都将产生新的版本，由于我们不能保证新版本好于旧版本，所以就版本不能抛弃。
  2）版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象。
• 配置基线
  1）配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线的配置项被冻结了，不能在被任何人更改。对基线的变更必须遵循正式的变更控制程序。
  2）基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部客户的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。
  3）对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。
• 配置管理数据库
  1）配置管理数据库主要内容包括：发布内容，包括每个配置项及其版本号；经批准的变更可能影响到的配置项；与某个配置项有关的所有变更请求；配置项变更轨迹；特定的设备和软件；计划升级、替换或弃用的配置项；与配置向有关的变更和问题；来自于特定时期特定供应商的配置项；受问题影响的所有配置项。
• 配置库
  1）配置库可以分开发库、受控库、产品库三种：
  开发库：也称动态库、程序库或工作库。动态库是开发人员的个人工作区，有开发人员自行控制。无需对其进行配置控制。
  受控库：也成为主库，包含当前的基线以及对基线的变更。受控库的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
  产品库：也成为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档。**被置于完全的配置管理之下。**在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
  2）配置库的艰苦模式有两种：按配置项类型建库和开发任务建库。
  按配置类型建库：这种模式一般适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的个需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。
  按开发任务建立相应的配置库：这种模式适用于通用软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式已先行开发为主，采用这种设置策略比较灵活。

角色与职责

• 配置管理相关角色包括：变更控制委员会、配置管理负责人、配置管理员和配置项负责人等。
  1）配置管理负责人也称配置经理，负责管理和决策真各个项目生命周期中的配置活动，具体有：
  管理所有活动，包括计划、识别、控制、审计和回顾；
  负责配置管理过程；
  通过审计过程确保配置管理数据库的准确和真实；
  审批配置库或配置管理数据库的结构性变更；
  定义配置项责任人；
  指派配置审计员；
  定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态；
  评估配置管理过程并持续改进；
  参与变更管理过程的评估；
  对项目成员进行配置管理培训；
  2）**“配置管理员”**负责在整个项目生命周期中进行配置管理的主要实施活动，具体有：
  建立和维护配置管理系统；
  建立和维护配置库或配置管理数据库；
  配置项识别；
  建立和管理基线；
  版本管理和配置控制；
  配置状态报告；
  配置审计；
  发布管理和交付；
  3）配置项负责人确保所有的配置项的准确和真实：
  记录所负责的配置项的所有变更；
  维护配置项之间的关系；
  调查审计中发现的配置项差异，完成差异报告；
  遵从配置管理过程；
  参与配置管理过程评估。

管理活动

• 配置管理的日常管理活动主要包括6各主要活动：
  1）制定配置管理计划：写一个文档，叫配置管理计划，规定如何做好配置管理。CCB负责审批该计划。
  2）配置项标识：识别出需要把那些东西作为配置项来管理。包括为配置项分配标识和版本号等。配置项是配置管理的一项基础性工作，要确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等。
  3）配置项控制：配置项有一些变更，需要做好配置变更的控制。包括：识别和记录变更申请、分析和评价变更、批准或否决申请、实现、验证和发布已修改的配置项等任务。
  4）配置项状态报告：需要报告配置项的状态是什么样的记录和报告“配置项”瞬时状况。
  5）配置审计：做好审计，看有哪些好的，那些不好的经验教训，效果怎么样。也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置的一致性和完整性。目的是为了确保项目配置管理的有效性，不允许出现任何乱象。
  6）配置管理回顾和改进：定期回顾配置管理活动的实施情况，发现在配置管理之心过程中的有无问题找到改进点，继而优化配置管理过程。

变更管理

管理基础

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

• 变更管理与配置管理：如果把项目整体的交付物视作项目的配置项，项目配置管理可视为对项目完整性管理的一套系统，当用于项目基准调整时，变更管理可是为其一部分。

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

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

管理原则

• 变更的管理原则是项目基准化、变更管理过程规范化。包括：
  1）基准管理：基准是变更的依据。
  2）变更控制流程化：所有变更都必须遵循这个控制流程进行控制。
  3）明确组织分工：至少应明确变更相关工作的评估、评审、执行的职能。
  4）评估变更的可能影响：变更的来源是多样的，既需要完成对客户可视的成果、交付期等变更操作，好需要完成对客户不可视的项目内部工作的变更。
  5）妥善保存变更产生的相关文档：确保其完整、即时、准确、清晰，适当时可以引入配置管理工具。

角色与职责

• 在项目系统中，除项目经理和CCB外，通常还会定义变更管理负责人、变更请求者、变更实施者和变更顾问委员会等。
  项目经理：再变更中起到的作用是相应变更提出者的需求、评估变更对项目的影响及应对方案、将需求由技术要求转化为资源需求，共授权人决策、并据评审结果实施，确保项目基准反应项目实施情况。
  变更管理负责人：也称变更经理，通常是变更管理过程解决方案的负责人，主要职责包括负责整个变更过程方案的结果、负责变更管理过程的监控、负责协调相关的资源，保障所有变更按照预定过程顺利运作、确定变更类型，组织变更计划和日程安排、管理变更的日程安排、变更实施完成之后的回顾和关闭、承担变更相关责任，并且具有相应权限、可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。
  变更请求者：负责记录与提交变更的请求单。具体为提交初步的变更方案和计划、初步评价变更的风险和影响，给变更请求设定适当的变更类型、对理解变更过程的能力要求等。
  变更实施者：需要拥有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变更任务。
  变更顾问委员会：负责对重大变更行驶审批，提供专业意见和辅助审批。具体为在紧急变更时，其中被授权者形式审批权限、定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等。

工作程序变更流程（背诵）

• 1）**变更申请：**变更提出应当及时以正是方式进行，并留下书面记录。项目的干系人都可以提出变更，一般项目经理或者项目配置管理员负责该相关信息的收集，以及对变更申请的初审。
• 2）**对变更的初审：**出身的目的主要包括对变更提出方施加影响，确认变更的必要性，确保变更的价值；格式校验，完整性校验，确保评估所需信息准备充分；在干系人间就提出供评估的变更信息达成共识。
• 3）**变更方案论证：**主要作用是首先是对变更请求是否可以实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。对于大型的变更，可以召开相关的变更方案论证会议。
• 4）**变更审查：**审查通常采用文档、会签形式，重大的变更审查可以采用正式会议形式。客户和服务对象的意见应放在核心位置。
• 5）**发出通知并实施：**如果变更造成交付期调整，应在变更确认时发布，而非在交付前公布。
• 6）**实时监控：**通常由项目经理负责基准的监控。CCB监控变更明确的主要成果、进度里程碑等，也可以通过监理单位完成监控。
• 7）**效果评估：**主要包括评估依据时项目的基准；结合变更的目标，评估变更所有达到的目的是否已达成；评估变更方案中的技术论证、经济论证内容与事实过程的差距，并促使解决。
• 8）变更收尾

项目文档管理

管理基础

• 信息系统开发项目文档分三类：开发文档、产品文档、管理文档

类型	作用	文档种类
开发文档	描述开发过程本身	可行性研究报告和项目任务书；需求规格说明；功能能规格说明；设计规格说明；
产品文档	描述开发过程的产物	培训手册；参考手册和用户指南；软件支持手册；产品手册和信息广告
管理文档	记录项目管理的信息	开发过程每个阶段的进度和进度的变更记录；软件变更情况的记录；开发团队的职责定义、项目计划。项目阶段报告；配置管理计划

• 文档的质量可以分为4级

文档分级	适用范围
最低限度文档（1级文档）	适合开发工作量低于一个人/月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。
内部文档（2级文档）	可用于没有其他用户共享资源的专用程序。2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
工作文档（3级文档）	适用于由同一单位内肉干人联合开发的程序，或可悲其他单位使用的程序。
正式文档（4级文档）	适用那些要正式发行供普遍使用的软件产品

规则和方法

• 文档的规范化管理主要体现在：文档书写规范；图标编号规则；文档目录编写标准；文档管理制度。