【公众号@ “项目管理研究所” 将会第一时间更新文章并分享《项目管理模板》】
归档于软件项目管理初级学习路线
第九章 软件项目配置管理计划
我们一直都希望！！！–>《初级学习路线合集 》
前言
大家好，这节我们学习软件项目管理----软件项目配置管理计划–软件项目配置管理过程。
主要学习：
前五个过程描述的是配置管理的主要活动，最后一个配置管理计划过程是来规划解决活动的。
配置项标识与跟踪
配置项标识
将软件项目中需要进行控制的部分拆分成SCI。例如需求可能有5个文件，那么5个配置项，代码就多了，有很多文件，那么就对应着很多配置项。
那么这个配置项定义过程可能是一个拆分的过程，例如项目需求规格可以拆成多个文件。其实这个拆分成多个配置项，对项目管理是有好处的，在项目执行过程中，需求的不同部分，修改的频率是不同的，因此需求的不同配置项变更的频率也是不同的。
如果某需求变更只是其中的一个配置项有关，那么其他需求配置项就不需要变更了。
那么这个项目确定下来之后，需要对每个配置项进行标识，即给出文件的命名规格。
这是某项目的命名规格，包括了5个部分，第一个部分代表企业，第二个部分代表项目的标识码，第三个部分代表项目的组号，第四个部分是文档类型，最后就是一个版本号。
配置项跟踪
为了实现配置管理，需要建立配置项的关联关系，便于跟踪和版本控制。比如需求规格有很多配置项，每个配置项有对应的设计版本、代码版本、测试用例，那么要建立这些对应关系，一但需求发生变更，就很容易把这些关联的配置项确定下来。
配置管理环境建立
配置管理库
配置管理环境的建立是将配置管理库建立起来的过程，即建立配置管理仓库。
软件配置管理库是用来存储所有基线配置项及相关文件的等内容的系统，是在软件产品的整个生存期中建立和维护软件产品完整性的主要手段。
受控操作
配置库环境是一个受控的，不可以随意对他进行操作，那么基线、配置项审核通过之后，可以添加至配置库，添加配置库之后就不可以随意来修改，一但提出变更，需要走变更流程。
这个配置管理库一般是通过安装配置管理工具来实现的。
例如这是rational管理工具界面：
SVN版本管理工具操作界面：
基线变更管理过程
基本概念
基线修改应该受到控制，这种变化要经SCCB授权，按程序进行控制并记录基线修改过程。
基线变更系统
基线变更的流程最主要的部分是变更控制系统，如下图就是一个基线变更系统：首先提出变更申请，然后进行评估，跟着进行决策，如果批准了这个变更则实现这个变更。
变更请求
这是一个变更申请：
变更评估
接下来要评估这个申请，这是一个评估流程：首先变更分类，看这个变更属于什么类型的，需求的？设计的？还是代码的变更，然后看看技术的影响如何，还要分析接口的影响，因此还要确定对进度的影响，成本的影响。
举例：一个需求的变更可能导致设计的大量变更，以及大量的代码变更，如果影响特别大，可能拒绝这个变更，因此评估的结果是决策的基础。
变更批准/拒绝
当然决策有两个，即同意和拒绝，如果同意变更了，还要实施这个变更，最后实现版本的升级。
变更实现
变更实现也需要按照流程来实现。例如将变更控制项从配置库取出来，实现这个变更，让验证确认没有问题了再提交到这个库里面去。
变更控制系统-举例
这是某项目的配置变更控制系统，项目人员来参照这个流程来实施变更的。
配置管理审计
审计大家是否遵守了这个配置管理过程，还需要审计基线产品，基线入库前一定要进行审计的。
配置状态统计
我们知道仓库管理员要定期向项目人员发布仓库里面有哪些产品，每个产品是怎么样的型号、版本、有无作废的等等等。
同理呢，软件配置管理负责人也要定期发布配置库的状态报告。例如：
配置管理计划大纲—举例
上面介绍配置管理的主要过程，他们描述了配置管理的活动，那么这些活动在配置管理计划中要体现出来。
配置管理计划具体包括哪些内容，没有一个统一的公认标准，主要看项目的具体情况，下面我们给一个大纲：
总结
总之 配置管理计划需要规划配置项，配置管理环境，基线变更管理，配置管理审计，配置状态统计等活动，作为将来项目配置管理的一个指导。
到这里，第九章 第二节 软件项目配置管理过程就讲解完毕了！下一节介绍敏捷配置管理计划~
如果您觉得这篇文章有帮助到您的的话不妨点赞支持一下哟~~😉
后续将持续更新【软件项目管理初级学习路线】的全知识点，大家感兴趣的多多关注博主哟~————————————————
