⑤配置库、配置管理数据库中的配置项信息应定期进行审计
⑥每个配置项建立后应指定一名配置管理员负责。
⑦ 配置管理应定期评审
⑧可与其他项目管理活动相衔接
配置管理的日常管理活动包括：制定配置管理计划、识别配置项、控制配置项、配置状态报告、配置审计、配置管理评审与改进等。
1.制定配置管理计划
配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，由CCB负责批准该计划。配置管理计划的主要内容有：1.配置管理的目标与范围2.配置管理活动主要包括：配置项识别、配置项控制、配置状态报告、配置审计发布管理和交付等（简写：时间制，状态审计不符）3.配置管理角色与职责安排4.负责实施这些活动的人员或团队，以及他们与其他团队的关系5.实施这些活动的规范和流程，如配置项命名规则6.实施这些活动的时间表，如计划表和规程7.与其他管理的接口控制（如变更管理等）8.配置管理信息系统的规划包括配置数据的存储、配置项运行的受控环境的位置、与其他业务管理系统的连接和接口以及支撑工具的构建和安装等。 9、配置管理的日常事务包括License控制配置项的归档等。10、计划的配置基线、主要版本、里程碑以及后续各时期的工作量、计划和资源计划。
2. 配置项识别
配置项识别是对所有信息系统组件的关键配置以及配置项与配置文档等结构化标识的对应关系进行识别，包括为配置项分配标识符和版本号，确定配置项的范围、属性、标识符、基线、配置结构和命名规则等。
1、确定配置项的范围。标识配置项的范围、配置项级别和详细配置项的版本信息、变更历史存储位置以及它们之间的关系等。
2、确认并记录配置项属性。提前确认并记录每个配置项的属性，特别是高风险或关键的配置项的属性。
3. 定义配置项的标识符。为了便于配置管理的识别，应该为每个配置项赋予唯一的标识符，并保持这些标识符的准确性。
4、确定配置基线。一个完整的配置基线主要包括：①、过去、当前和计划中的发布信息。②过去、当前和计划中的变更信息。③变更批准和实施时的信息系统状态及相关文档。④发布实施时的信息系统状态及相关文档。⑤按标准规范配置的硬件和软件。
5. 确定配置结构。配置结构描述了配置项的层次结构以及它们之间的关系。一个配置项可以是独立的硬件单元或软件模块，也可以是由多个不同的配置项组成的更大的配置项。一个配置可以同时是许多不同配置项（一个配置项集）的一部分。
6、确定配置项的命名规则。命名规则的制定应考虑配置项名称的连续性、易记性和可扩展性。每个配置项都能够通过自己的字符拷贝号/序列号和版本号唯一标识，同一配置项的不同版本可以同时并存。配置项的命名规则应体现：①配置结构中配置项之间的层级关系；②各配置与其相关文档之间的关系；③配置项与其相关文档之间的关系；④文档与变更之间的关系等。
3.配置项控制
配置项控制是指对配置项和基线的变更控制，包括：识别和记录变更请求、分析和评估变更、批准或拒绝请求、实施、验证和发布修改的配置项等。
1.变更申请。项目经理等相关人员填写变更申请表，提交至建设银行
2、变更评估。建设银行负责组织对变更申请进行评估、确定。内容包括：①、变更对项目的影响。②变更的内容是否必要。③变更的范围是否考虑周全。④变更的实施方案是否可行。⑤变更工作量估算是否合理。
建设银行决定是否接受变更，并将决定通知相关人员。
3. 公布评估结果。CCB 将变更请求的批准、拒绝或延期决定通知受影响的每个利益相关者。
4.变更实施。项目经理组织进行相关配置项的修改，并将变更信息记录在相应的文件、规程、代码或配置管理资料中。
5.变更验证与确认。项目经理指派人员对变更的配置项进行测试或验证。项目经理应将变更和验证的结果提交CCB，CCB确认变更是否按要求完成。
6.变更发布。配置经理将变更的配置项纳入基线。配置经理将变更情况及结果通知相关人员并做好记录。
7.基于配置库的变更控制
以某软件产品的升级为例，其流程简单描述如下：
1、从产品库中取出需要升级的基线（假设版本号为V2.1）放入受控库中。
2、程序员从受控库中检出预先修改过的代码段放入自己的开发库中进行修改，代码一旦检出就被锁定，保证同一时间只能由一个程序员修改同一个代码段。
3、程序员将开发库中修改的代码段check in到受控库中，check in后代码解锁，其他程序员就可以check out该代码了。
4、软件产品升级修改完成后，受控库中新的基线存放到产品库中（软件产品版本号更新为v2.2，老的v2.1版本不删除，继续存放在产品库中）
4.配置状态报告
配置状态报告任务是有效地记录和报告管理和配置所需的信息。配置状态报告主要应包括：
1. 每个受控配置项的标识和状态。
2.各变更请求的状态及已批准修改的实施状态。
3. 每个基线的当前和过去版本的状态，以及每个版本的比较。
4.其他配置管理过程和活动的记录等。
5.配置审计
配置审计包括：功能配置审计和物理配置审计，分别用于验证当前配置项的一致性和完整性。配置审计不允许出现任何混淆的情况包括：①防止不合适的产品提交给用户；②发现不完善的实施情况；③发现配置项之间的不匹配或不兼容情况；④确认配置项已纳入基础设施并在经过必要的质量控制评审后入库；⑤确认记录和文件保持可追溯性等。
功能配置审计。功能配置审计是对配置项的一致性（配置项的实际功能是否与其要求一致）进行审计。具体验证主要包括：
1. 该配置项的开发已成功完成
2.该配置项已实现配置标识规定的性能和功能特性
3.配置项的操作及支持文档已完成并满足要求等。
物理配置审计。物理配置审计是对配置项的完整性（配置项的物理存在是否与预期一致）进行审计。具体验证主要包括：
1、需要交付的配置项是否存在？
2.配置项是否包括所有必需的物品等？
应进行配置审计的场景包括：（什么情况下需要进行审计？） ① 实施新的配置存储库或配置管理数据库后 ② 信息系统发生重大变更前后 ③ 软件发布及安装引入实际运行环境之前 ④ 灾难恢复后或事件恢复正常后 ⑤ 发现非授权配置项后 ⑥ 其他必要的时候等。
6.配置管理评审与改进
配置管理评审和改进活动包括：
1、做好本次配置管理评审的准备，并通知相关人员参加会议。
2. 召开配置管理评审会议
3.根据会议结论制定并提交服务改进计划
4.根据流程改进计划软件安装维护管理规定，协调并实施改进。
管理基础
变革管理的本质是在项目推进过程中根据日益丰富的项目知识，不断调整项目方向和资源配置软件安装维护管理规定，最大程度地满足项目需求，提升项目价值。
1.变更管理和配置管理
变更管理最终应该将项目调整的结果反馈到配置管理过程，以确保项目执行与项目配置条件信息一致。
2、变动原因
常见的变更原因包括：
① 产品范围（结果）界定错误或疏忽
② 项目范围（工作）界定错误或遗漏
③增值变化
④ 应对风险的应急计划或规避计划
⑤项目执行过程与对标要求不一致，造成被动调整
⑥外部事件等。
3. 变更分类
按照变更性质可分为：重大变更、重要变更、一般变更；通过不同的审批权限进行控制，根据变更的紧急程度可分为：紧急变更、非紧急变更。
4. 项目变更的含义
变更管理是为使项目基准与项目实际执行情况相一致而采取的一套应对项目变更的管理方法。变更管理的原则是规范项目基准和变更管理流程。主要内容包括：
1.标杆管理2.变更控制流程3.明确组织分工4.评估变更可能产生的影响5.妥善保存变更产生的相关文档。
项目经理在变革中的作用是：
1. 响应变更提议者的需求
2.评估变更对项目的影响及应对计划
3. 将技术需求转化为资源需求，供授权方决策
4.根据评审结果进行落实（即调整基准），确保项目基准，反映项目实施情况。
除了项目经理和CCB之外，通常还定义变更管理负责人、变更请求人、变更实施者和变更顾问委员会。
1、变更管理负责人：变更管理负责人也叫变更经理，通常是变更管理流程解决方案的负责人，其主要职责包括：1、对整个变更流程计划的结果负责。2、负责监控变更管理流程。3、负责协调相关资源，确保所有变更按照预定的流程顺利进行。4、确定变更类型，组织变更计划和进度表。5、管理变更的进度表。6、实施后评审并关闭变更。7、承担变更的相关职责并拥有相应的权限。8、可以以分步审批或团队会议的形式参与变更的风险评估和审批。
2.变更请求人：变更请求人负责记录和提交变更请求，具体包括：1.提交初步的变更建议和计划2.对变更的风险和影响进行初步评估，并为变更请求设置合适的变更类型3.具有理解变更流程的能力等。
3、变更实施者：变更实施者需要具备执行变更计划内容的技术能力，并负责按照实施计划实施具体的变更任务。
4.变更咨询委员会：变更咨询委员会负责提供专业意见，协助重大变更的审批。具体为：1.发生紧急变更时，由授权人行使审批权。2.定期听取变更经理的汇报，评估变更管理的执行情况，必要时提出改善建议。
变更请求
变更应及时、正式提出，并留下书面记录。变更可以采用多种形式提出，但应在评估前以书面形式提出。项目利益相关方可以提出变更申请，但一般需要指定人员批准。一般由项目经理或项目配置管理员负责收集相关信息并初步审核变更申请。
初步审查变更：
变更预审的主要目的包括：
1.影响提出变更的一方，确认变更的必要性，并确保变更是有价值的
2. 格式验证和完整性验证，确保评估所需的信息准备齐全
3.对洁净室等拟评估的变更信息达成共识。
变更初步审查的常见方式是审阅、传阅变更申请文件。
变更方案演示
常见的项目内容包括技术评估、经济和社会效益评估。
变更评审
评审通常采用文件、联名签名的形式，重大变更评审可以采用正式会议的形式进行。
对于涉及项目目标和交付成果的变更，应以客户和服务接受者的意见为核心
下发通知并组织实施
如果变更导致交货期调整，则应在确认变更时宣布，而不是在交货前宣布。
实施监测
项目经理通常负责基线监测，CCB监测关键成果、进度里程碑等的变化，也可以由监理单位完成监测。
效果评估
变更评估的重点主要包括：1、评估的依据是项目的基准。2、结合变更的目标，评估变更目的是否已经达成。3、评估变更方案的技术经济论证内容与实施过程的差距，并推动解决。
变更完成
变更终结是为了确定变更后项目是否已经步入正常轨道。
项目的变更控制主要集中在变更申请的控制和变更过程的控制上，在变更过程控制中要特别重视进度变更控制、费用变更控制和合同变更控制。
1. 变更应用程序的控制
变更控制的前提是项目基线健全，变更处理流程事先商定，严格控制意味着变更管理系统能够确保项目基线反映项目的实施情况。
2. 改变过程控制
合同变更控制。合同变更控制是指定合同修改的过程。它包括文书工作、跟踪系统、争议解决程序以及批准变更所需的审批层级。合同变更控制应与总体变更控制相结合。
版本发布及回退计划
① 版本发布前的准备工作包括：
1. 进行相关回归分析
2.备份版本发布涉及的存储过程、函数等数据的存储及回滚管理
3.备份配置数据，包括数据备份方法
4.备份、在线生产平台、接口应用工作流等版本
5. 启动 fallback 机制的触发条件
6.变更回滚机制职责描述
②后备措施通常包括：
1.通知相关用户系统已开始回滚
2.通知所有相关系统回滚版本
3. 回滚存储过程和其他数据对象
4.配置数据回滚
5、应用程序、界面程序、工作流等版本回滚。
6. 回滚完成后通知所有周边相关系统
7.回滚后进行相关测试，确保回滚系统能正常运行
8.通知用户回滚完成等。
管理基础
信息系统开发项目文档分为：开发文档、产品文档、管理文档
1.开发文档描述开发过程本身。基本的开发文档包括：可行性研究报告及项目任务书、需求规范、功能规范、设计规范（包括程序和数据规范、开发计划、软件集成与测试计划、质量保证计划、安全和测试信息等）
2. 产品文档描述开发过程的产品。基本产品文档包括：培训手册、软件参考手册和用户指南、支持手册、产品手册和信息广告。
3、管理文档记录项目管理信息，如：开发过程各阶段的进度及进度变化记录、软件变更记录、开发团队职责定义、项目计划、项目阶段报告、配置管理计划等。
文档的质量一般可以分为四个级别：
1. 最低限度文档（一级文档）适用于开发工作量在1人月以下的自用程序，文档内容应包括程序清单、开发记录、测试数据、程序介绍等。
2. 内部文档（2 级文档）可用于不与其他用户共享资源的私有程序。除了 1 级文档提供的信息外，2 级文档还在程序列表中包含足够的注释，以帮助用户安装和使用该程序。
3、工作文档（三级文档）适用于同一单位的几个人共同开发的程序，或者可供其他单位使用的程序。
4. 正式文档（4级文档）适用于正式发布供一般使用的软件产品。关键程序或具有重复管理应用特性的程序（例如工资计算）需要4级文档。
文件的规范化管理主要体现在几个方面：文件书写标准、图表编号规则、文件目录书写标准和文件管理制度。
1.文档的编写标准。管理信息系统的文档涉及文字、图形、表格等多种类型。无论何种文档，都应遵循统一的编写标准，包括符号的使用、图标的含义、程序中注释行的使用，以及文档作者和编写日期的标明等。
2. 图表编号规则。根据生命周期方法的五个阶段，可以给出图中所示的分类编号规则
3.文件目录编写规范。管理信息系统文件目录应包括文件编号、文件名称、格式或载体、份数、每份页数或件数、存放地点、归档时间、保管人等。
4.文献管理制度。主要包括建立文献相关规范、文献借阅记录登记制度、文献使用权限控制规则等。
