配置管理是为了系统的控制配置变更，在系统的整个生命周期中维护配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。
1.文档管理
文档类型
文档类型分为：开发文档、产品文档、管理文档。 开发文档：描述开发过程本身。包括： 可行性研究和项目任务书；需求规格说明书；功能规格说明；设计规格说明，程序和数据规格说明；开发计划；软件集成和测试计划；质量保证计划；安全和测试信息； 产品文档：描述开发过程的产物。包括： 培训手册；参考手册和用户指南；软件支持手册；产品手册和信息广告； 管理文档：记录项目管理信息。包括： 开发过程中每个阶段的进度和进度变更的记录；软件变更情况的记录；开发团队的职责定义、项目计划、项目阶段报告；配置管理计划；
规则和方法
文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写、文档管理制度等几个方面。
2.配置管理
配置管理是为了系统的控制配置变更，在系统的整个生命周期中维护配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。 配置管理主要包括六个主要活动：制定配置管理计划、配置标识、配制控制、配制状态报告、配制审计、发布管理和交付。
3.配置管理基础
3.1 配置项
为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为了一个单个实体来对待。配置项包括：项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及关键部件等，它们经评审检查通过后进入配置管理。 项目中需要加以控制的控制的配置项可以分为基线配置项和非基线配置项，基线配置项包括所有的设计文档和源程序，非基线文档包括项目的各类计划和报告等。所有配置项的操作权限应该严格管理，原则是基线配置项向开发人员开放读取权限；非基线配置项向项目经理、CCB及相关人员开放。
3.2 配置项状态
配置项的状态需要根据配置项的不同类型和管理需求进行分别定义。基于建设过程可以分为草稿、正式、修改三种状态。
3.3 配置项版本号
版本号的定义与配置项状态相关。
3.4 配置项版本管理
版本管理作用于多个配置管理活动中，如配置标识、配置控制和配置审计、发布和交付等。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到配置项的任何版本。
3.5 配置基线
配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。也是指一个产品或系统在某一特定时点的配置状况。配置基线可用于管理对象中的授权产品、标准配置项、开发和测试新配置的起点、作为提供给IT系统用户的配置标准、作为提供新软件的起点。 在信息系统项目过程中，各类配置项存在不断变化的情况，为了不阻碍合理变化的情况下来控制变化，需要使用配置基线这一概念。对基线的变更必须经过遵循正式的变更程序。 基线通常对应于项目过程中的里程碑(Milestone)，一个项目可以有多个基线，也可以只有一个基线。交付给用户使用的基线一般称为发行基线(Release)，内部使用的基线一般称为构建基线(Build)。 对于每一个基线要定义下列内容：建立基线的事项、受控的配置项、建立和变更基线的程序、批准变更基线的所需的权限。在项目实施过程中，每个基线都应纳入配置控制，对这些基线的更新只能采取正式的变更控制程序。
建立基线的价值
- 基线为项目工作提供了一个定点和快照。
- 新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目所进行的变更进行隔离。
- 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
- 可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。
3.6 配置管理数据库
使用配置管理数据库来管理数据项。配置管理数据库包括内容： 1).发布内容，包括每个配置及版本号；2）经批准的变更可能影响到的配置项；3）与某个配置项有关的所有变更请示；4）配置项变更轨迹；5）特定的设备和软件；6）计划升级、替换和弃用的配置项；7）与配置项有关的变更和问题；8）来自于特定时期特定供应商的配置项；9）受问题影响的所有配置项。
3.7 配置库
利用配置库可以回答许多配置管理相关的问题：1）哪些用户提取了某个特定的版本；2）运行一个给定的系统版本需要什么硬件和软件；3）一个系统到目前一共生成了多少个版本，何时生成的；4）如果某一特定的构件变更了，会影响到系统的哪些版本；5）一个特定的版本曾提出过哪几个变更请求；6）一个特定的版本有多少已报告的错误；
配置库可以分为开发库、受控库和产品库。 配置项的建库模式可以分为按配置项类型建库和按开发任务建库。通用软件开发的组织一般采用按配置项类型分类建库。专用软件开发的组织一般按开发任务建立相应的配置库。
4.目标与方针
主要目标是定义并控制信息系统的组件，维护准确的配置信息，包括：1）所有配置项能够被识别和记录；2）维护配置项记录的完整性；3）为其他管理过程提供有关配置项的准确信息；4）核实有关信息系统的配置记录的正确性并纠正发现的错误；5）配置项当前和历史状态得到报告；6）确保信息系统的配置项的有效控制和管理。 配置管理关键成功因素包括：1）所有的配置项应该记录；2）配置项应该分类；3）所有的配置项要编号；4）应该定期对配置库或配置管理数据库中的配置项信息进行审计；5）每个配置项在建立后，应该配置负责人负责；6）要关注配置项的变化情况；7）应该定期对配置管理进行回顾；8）能够与项目管理的其他活动进行关联；
5.管理活动
配置管理日常活动主要包括：制订配置管理计划、配置项识别、配置项控制、配置状态报告、配置审计、配置管理回顾和改进。
5.1 制订配置管理计划
是对如何进行配置管理工作的规划，是配置管理过程的基础，应该行成文件在整个项目生命周期处于受控状态。CCB负责审批该计划。
5.2 配置项识别
配置项识别是识别所有信息系统的关键配置，以及各配置间的关系和配置文档等结构识别。
5.3 配置项控制
配置项控制即对配置项和配置基线的变更控制。包括：标识和记录变更申请、分析和评价变更、批准或否决申请、实现、验证和发布已修改的配置项等任务。 变更申请，变更评估，通告评估结果，变更实施，变更验证与确认，变更的发布，基于配置库的变更控制。
5.4 配置状态报告
配置状态统计。其任务是有效的记录和报告管理配置所需的信息，目的是及时、准确的给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
5.5 配置审计
配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。
5.6 配置管理回顾与改进
定期回顾配置管理活动的实施情况，发现配置管理执行过程中有无问题，找到改进点，继而优化配管管理过程。
6.变更管理
变更产生的原因：1）产品（成果）范围定义过失或疏忽；2）项目范围（工作）定义的过失或疏忽；3）增值变更；4）应对风险的紧急计划或回避计划；5）项目执行过程与基准要求不一致带来的被动调整；6）外部事件等。
6.1 工作程序
变更申请、对变更的初审、变更方案论证、变更审查、发出通知并实施、实施监控、效果评估、变更收尾
6.2 变更申请
及时以正式的方式提出，并留下书面记录。
6.3 对变更的初审
目的：1）对变更提出方施加影响；2）格式校验，完整性校验，确保评估信息准备充分；3）在干系人间就提出评估的变更信息达成共识。
6.4 变更方案论证
变更方案的主要作用，首先对变更方案是否可实现进行论证，如查可行转化为资源需求，以供CCB决策。通常包括技术评估和经济与社会效益评估。
6.5 变更审查
审查过程是项目所有者根据变更申请及评估方案，决定是否变更项目基准。专业评审与经济评审分开。
6.6 发出通知并实施
变更评审通过意义项目基准调整，包括项目目标的确认，最终成果、工作内容和资源、进度计划的调整。如果交付期受影响，应该是变更确认是发布，而不是最终交付前发布。
6.7 实施监控
变更实施的监控，除了调整基准中涉及变更的内容外，还应当对项目的整体基准是否反映项目实施情况进行负责。
6.8 效果评估
变更评估的关注内容主要包括：1)评估依据是项目基准；2）结合变更的目标，评估变更所要达到的目的是否已达成；3）评估变更方案中的技术论证、经济论证内容与实施过程的差距、并促使解决。
6.9 变更收尾
判断发生变更后的项目是否已纳入正常轨道。配置基准调整后，需要确认资源配置是否及时到位。变更完成后，项目的整体监控应按照新的基准进行。