项目配置管理为什么配置管理和项目变更控制在复杂的软件开发项目中如此难以实施

项目配置管理时间:2021-09-08 阅读:()

论述软件项目管理过程中如何开展好配置管理工作

1、配置管理员水平很重要。

2、领导要很重视（比如告诉他代码需要控制不同的权限，集中保存防止出现各种意外比如离职泄露啊，电脑坏了啊等等，与开发过程相关的就不用说了，他不关心的）。

3、项目经理要很重视，很多项目经理本身是技术出身，可能管理跟的不是那么上~.~。

4、项目成员有这样的概念。

以上是前提。

开展配置管理工作的关键是让公司内部的项目干系人的人感觉到配置管理工作在起作用。

最重要的手段：针对不同的人进行不同层次的培训。

1、对于老板/总监/技术老大/项目老大等等所有项目的统筹负责人，可以做一些月度季度年度报表PPT什么的告诉他你做了什么。

取得了什么样的效果。

2、对于项目经理们或者准项目经理们，做配置管理里关于流程方面的培训（比如配置项管理、基线管理、变更管理、构建管理、版本管理、发布管理、审计管理、外部发布管理等）、然后就是一些配合不同开发模式（比如瀑布、螺旋、敏捷等）进行配置工具培训、比如分支开发、自动构建、持续集成等 3、对于普通开发测试等项目组成员，就是培训各类工具的使用了比如svn/等，比如一些好的操作，版本对比、回退机制、代码共享、同步开发等等。

至于配置管理过程的话，网上一大堆，随便凭记忆总结下，可能不全： 1、从组织上定义标准流程规范制度等。

这个规范制度是用来指导配置管理工作的总规范。

包括具体的配置管理简介、配置管理过程中涉及到的人的权责、然后就是配置管理实施的策略（比如计划、配置项、基线、变更、发布、审计、报告、服务器管理、配置工具说明、权限管理总则、配置库结构标准、库备份啊、收尾工作比如移交转产交付取消权限刻盘保存等），可能还要定义一个内测版本、外测版本、正式版本号的附则。

制作好所有的excel/word/ppt/txt模版。

给领导审批通过就OK了。

2、项目开始就后按照组织定义的配置管理流程去做，不断裁剪修改，不同规模的配置管理工作的需求是不同的，要考虑投入产出是否合理，与项目是否适配。

------------------------------------------ 以上所有涉及到和领导相关的步奏，请考虑你在公司的实际地位和能力水平，有可能你的项目的配置管理工作没有到这个高度，还只是初级阶段，领导都不知道。

一般来说成熟的软件公司、规模比较大配置管理是单独的。

如果你只是某个项目的，没有那么高的地位那就只针对本项目的经理和普通成员来操作吧.......~.~

关于项目管理中配置管理的实现过程，配置项的知识请教以及相比版本管理的差异

你的理解更多是“产品集成”的概念，即怎么把几个产品模块或构件组合成一个产品，但这不是配置管理的概念。

配置管理：简称CM（Configuration Management的缩写），标识、控制和管理变更的一种管理活动。

它控制配置项的修改和发行；记录和报告配置项的状态和变更；保证配置项的完整性、一致性和正确性；以及控制配置项的储存、装载和交付。

根据这个定义，配置管理的主要工作包括： 1）配置库的管理活动。

配置库现在工具非常多，例如GIT、SVN、CVS、VSS等等。

通常会根据开发所处的阶段，设立开发库、受控库与产品库。

2）标识配置项，即需要定义如何去标识配置项。

配置管理中受控制的对象被称为配置项，是生命周期中创建的信息，包含程序、数据、文档，分基线配置项和非基线配置项两类。

特别是你的产品最终是如何标识的，比如怎样定义V1.0.0的规则。

3）基线的管理。

是一组经过正式审查并且达成一致的规范或工作产品，是下一阶段工作的基础。

怎样确定、发布基线，怎样管理基本的变更。

4）配置项变更管理。

可以根据不同的配置项、不同的开发周期，明确变更的管理规则。

5）配置项状态管理与配置审计。

而产品集成是如何把一个产品逐步的从一个个模块或组件，最后组合成一个产品的过程。

1）首先产品的技术结构上要能够支持，如果模块不能相互独立和拆解，谈不上灵活的组合。

2）在开发实现上，需要有一个集成的策略，哪些先实现，哪些后实现，哪些可以先进行集成 3）需要建立集成的环境，使开发好的模块可以在集成环境中进行调试 4）通常开发完成后，需要进行源代码的编译，并打包成一个测试包，然后装在集成环境中，进行调试，以确认各个模块之前是否可以兼容和运转，这时通常会进行测试工作。

5）如果你想进行ABC组合，或者AC组合，那么都需要进行相应的编译、打包（例如形成EXE）过程，然后在集成环境中进行联调和测试。