具体来说，在每一项开发任务中，都需要首先设定开发基线，确定各个配置项的开发初始版本，在开发过程中，开发人员基于开发基线的版本，开发出所需的目标版本。当发生需求变更时，通过对变更的评估，确定变更的影响范围，对被影响的配置项的版本进行修改，根据变更的性质使配置项的版本树继续延伸或产生新的分支，形成新的目标版本，而对于不受变更影响的配置项则不应发生变动。同时，应能够将变更所产生的对版本的影响进行记录和跟踪，必要时还可以回退到以前的版本，例如当开发需求或需求变更被取消时，就需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中，其实就是将部分配置项的版本回退到开发基线，将对应不同需求的不同分支重新组合归并，形成新的升级包版本。
配置审计是配置管理中的一项重要工作内容，有时被分为物理审计和功能审计，通过物理审计按照配置管理计划来验证所要求的各配置项的完整性，通过功能审计来检查各配置项的内容是否完全符合用户的要求。配置审计是配置管理工作中的重要一环，也是项目质量管理工作中的一项内容。
项目与产品的矩阵关系需要配置管理来执行
项目管理与产品管理的矩阵关系，其实是集成项目管理中必须要解决的问题。对于项目管理与产品管理之间多对多的矩阵关系，已经被普遍理解，但是在细化到操作层面时，这种矩阵式的配合关系有时还存在一定的混淆。
企业中的软件开发部门首先要关注产品，通过基于软件产品的开发工作来实现业务需求，并负责对整个软件产品生命周期的管理。许多公司目前的实际做法是，在组织层面上，项目组实际的组织方式是，在项目组中有多个产品开发小组，每个小组负责某个或某些软件产品的开发工作，项目中跨产品的整体的业务需求、技术架构、系统测试、项目管理等工作，仍由项目组统筹管理。项目组内的产品开发小组，可以与其他项目、维护任务共享资源，可以从产品角度保证软件产品的兼容性和一致性。通过这种组织方式，可以平衡项目管理与产品管理之间关系的，产品经理和项目经理是这两个管理维度的具体执行者。
对应这种组织方式，配置管理也需要支持矩阵式管理结构。对于属于项目管理的内容，可以针对项目建立配置库进行配置管理，包括项目级的业务需求、项目的整体技术方案、系统功能测试、项目管理过程等内容，而对于单个软件产品，则需要纳入产品配置管理的范畴，针对产品进行配置管理。这和产品文档与项目文档的划分思路是基本类似的。
此文章共有6页 上一页 1 2 3 4 5 6 下一页
文章来源：中国项目管理资源网
 软件开发项目管理培训课程方案
|
Leadge.com首页 > 知识库 
