配置管理：为配置管理设计的硬件、软件或二者的集合，在配置管理过程中做为一个单个实体来对待。、所有配置项应按照相关规定统一编号，按照响应的模板生成，经评审和检查通过后进入配置管理，并都以一定的目录结构保存在配置库中。
配置项关键词：受控管理、任何组件
典型的配置项：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、原型图、各种数据。
基准、计划以及配置项任何一个都要走变更。
类型：
基线配置项：向开发人员开放的读取的权限，设计文档、开发需求文档等。
非基线配置项：向管理人员开放，PM、CCB等人员。
配置项的权限由CMO（配置管理员）严格管理。
配置项的状态和版本号
状态：
草稿状态，版本号：0.YZ（YZ是01到99），例如0.11。这个版本改动不需要审批。
草稿通过评审委 正式状态，版本号 X.Y，X、X是1~几十都可以，表明是正式版本，Y是0~几十都可以。比如第一个正式版本 1.0。
经过CCB审批的变更控制，变为【正在修改】的版本，X.YZ。修改时，Z增大，XY不变，修改完毕（也要经过审批变为正式版本），Z为0。
对配置项的任何修改都将产生新的版本，不能抛弃旧版本，要按一定规则保存配置项的所有版本。
配置基线，有一组配置项组成，构成一个相对文档的逻辑实体，基线中的配置项被“冻结”了，不能再被任何人修改，如果要变更需要走正式的变更控制程序。例如，一个产品的测试版本就是基线的一个例子。
基线通常对应开发过程中的里程碑，一个产品可以有多个基线，也可以有一个基线。
每一个基线要定义的内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。
基线类别：发行基线：交给外部客户。构造基线：内部开发使用。
配置库，存放配置项并记录与配置配置项相关的所有信息，是一个介质或载体。
第一类开发库（动态库、程序员库、工作库），用于保存开发人员正在开发的配置实体。开发人员自行控制，修改无需提交变更流程。
第二类受控库（主库、动态库），包含当前基线加上对基线的变更，被置于完全的配置管理之下，修改需要走变更流程。
第三类产品库（静态库、发行库、软件仓库），包含已发布使用的各种极限的存档，被治愈完全的配置管理下。一般不修改，如需修改要走变更流程。
配置库的建库模式：按配置项的类型适用于通用软件的开发组织。按开发任务适用于专业软件的开发组织。
配置管理基础—基于配置库的变更控制
产品库—导出—>受控库—导出—>开发库。
配置管理的角色与职责
变更控制委员会（CCB）：一个正式组成的团体，负责审议、批准、推迟或否决项目变更，以及变更和传达变更处理决定。
CCB由项目涉及的多方人员共同组成，通常由用户和实施方的决策人员，属于决策机构。
配置负责人—配置经理：负责管理和决策整个项目周期中的配置活动，包括：
1、管理所有活动（计划制定、识别、控制、审计、回顾）；2、负责、评估配置管理的过程、变更管理过程并持续改进；3、定义配置项负责人；4、指派配置审计员；5、对项目成员进行配置管理培训；6、审批配置库或配置管理数据库；7、确保配置管理数据库的准确和真实。
记忆点：配置相关的活动和过程、跟配置人员指派定义培训、配置库的实际操作管理。
配置管理员（CMO）负责整个生命周期中进行配置管理的主要实施活动。
建立和维护配置库、配置管理系统、配置识别项、建立和管理基线、配置状态报告、配置审计、版本管理、发布管理、配置控制。
配置项负责人：确保配置项的准确和真实。
记录配置项的所有变更；维护配置项之间的关系；调查审计发现配置项差异，完成差异报告；遵从配置管理过程；参与配置管理过程评估。
配置管理的日常管理活动
应用技术和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变化、记录和报告变更处理和实现状态并验证与规定的需求的遵循性。
1、制定配置管理计划
如何开展配置管理工作的规划，CCB审批。
2、配置项识别
确定配置项的范围、属性、标识符、基准线、配置结构、命名规则等。
3、配置项控制
配置项和基线的变更控制，参照变更控制。
4、配置状态报告
记录和报告配置项的当前状况
5、配置审计
功能审计：一致性，实际功能是否需求。
物理审计：完整性，物理存在是否预期，（配置项在不在，全不全）
6、配置管理回顾与改进
定期改进、找到改进点、优化过程。
配置管理计划内容：
1、配置管理的目标和范围；配置管理角色和责任安排；
2、配置管理活动；实施这些活动的规范和流程、进度安排、实施人员及和其他团队之间的关系；
3、配置管理与其他管理之间的接口控制；配置管理的日常事务；
4、配置管理信息系统的规划；
5、计划的配置基准线、重大发布、里程碑，以及针对以后每个期间的工作量计划和资源计划。
配置项控制任务：变更申请、变更评估、通告评估结果、实施变更、变更验证与确认、变更发布、基于配置库的变更控制。
配置审计内容：是为了确保项目配置管理的有效性，提现配置管理的最根本要求—不允许出现任何混乱现象。
功能审计具体内容：配置项的开发是否已圆满完成；配置项已达到配置标识中规定的性能和功能特征；配置项的操作和支持文档已完成并符合要求。
物理审理的具体内容：要交付的配置项是够存在；是否包含了所有必须的项目。
变更管理
在信息系统项目实施过程中，由于项目环境或其他原因对项目功能、性能、架构、技术指标、集成方法、项目进度等方面做出的改变。
变更管理的实质：根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度的满足项目需求，提升项目价值。
变更管理原则：基准管理、变更控制流程化、明确组织分工、评估变更影响、保存变更文档。
变更常见原因
1、产品范围和项目范围定义的过失或疏忽。
2、增值变更，客户提功能能带来价值。
3、应对风险的计划。
4、绩效与基准不一致带来的调整。
5、额外的外部事件。
变更的分类
按性质分：重大变更、重要变更、一般变更。
按迫切程度分：紧急变更、非紧急变更
变更管理的角色与职责
变更管理负责人（变更经理）：变更方案的结果、变更过程监控、协调资源、确认变更类型、变更日常安排、完成回顾与关闭、承担相关责任、风险评估与审批。
变更请求者：负责记录与提交变更请求单。
变更实施者：负责按照实施计划实施具体变更任务。
变更顾问委员会（CAB）：对重大变更行使审批、提供专业意见和辅助审批。
在整合管理里有变更的8个步骤：变更申请、变更初审、评估变更方案论证、变更审查（CCB审查，大型变更由CAB审查）、变更通知并实施、实施变更监控、效果评估、变更收尾。
变更控制：
1、越大型项目，随意调整带来的后果更多。
2、整体压力较大情况下，可以分批处理、分优先级
3、小项目立秋简便高效，注意影响，确认应该正式化，过程规范化。
4、关注变更申请的控制和变更过程的控制。
变更过程控制：进度变更的控制、合同变更的控制、成本变更的控制。
版本发布前的准备工作：1、回退分析；2、备份存储；3、备份配置数据；4、备份应用程序、接口程序、工作流；5、启动回退机制的出发条件；6、对变更回退的机制职责的说明。
版本回退计划：1、通知用户；2、通知各关联系统；3、回退存储过程等数据；4、回退配置数据；5、回退应用程序、接口程序、工作流；6、回退完成通知各关联系统；7、回退后测试；8、通知用户。
文档管理
文档类别：
1、开发文档（描述开发过程的本身，可研报告、需求说明书、设计规格说明书、开发计划、质量保证计划等）
2、管理文档（项目计划、阶段报告、变更情况记录、配置管理计划等）
3、产品文档（产品说明书、用户手册、培训手册等）
文档质量等级：
1、1级文档，最低限度文档：适用于自用。
2、2级文档，内部文档：位于其他用户共享资源的专用程序，内容比1级文档详细；
3、3级文档：工作文档，同单位内共享
4、4级文档：正式文档，正式发布普遍使用的文档
文档规范化管理：书写规范、图标编号规则、目录编写标准、文档管理制度。
