2.3 产品结构混乱不清

　　规模较大、历史较长的产品结构可能存在产品结构差的问题，甚至由于文档缺失、人员更替而连产品的历史状态也不清楚。这会直接加大变更分析及确定变更后回归测试范围的难度。从根本上解决结构混乱问题可能需整理产品结构，自动化测试技术对控制回归测试工作量有所帮助。配置管理的直接贡献包括支持了解、管理配置项本身的特征、相互之间的联系，以及对回归测试用例、脚本等配置项的管理等。

　　2.4 异地、并行开发

　　由于信息安全、系统环境约束等原因，在软件公司内部可能无法得到用户的真实数据和软、硬件运行环境。为了提高效率，可能会有多名程序员对同一配置项并行开发或并行维护。配置管理对并行开发的贡献包括完整地标识、记录配置项的状态和分支版本，以及对版本变更、通知、审计、报告的控制；使用配置管理工具有助于支持并行开发管理。对配置项可以采取主负责人机制，其它程序员的修订需要得到主负责人批准或确认。在异地开发环境下还要求人员有更高的资质和素质。特别是在短期、小团队的用户现场工作时，在配置项的版本、权限等方面可能需要在严格控制与工作效率之间寻求平衡。

　　2.5 涉众不清、策略不当

　　非技术的管理性问题同样可能给配置管理造成重大混乱。不同的软件工作产品有不同的涉众（Stakeholder） ，如果涉众不清楚，容易出现让非涉众的人来控制配置项或配置项没有受到其涉众控制等问题。配置管理需要支持项目经理等人员识别并管理配置项的涉众属性。项目配置管理的具体策略需要结合项目、组织的特点而定，脱离具体条件要求配置管理单独实现高层次的目标难免会事倍功半。

　　3、配置管理的层次

　　配置管理的根本业务目的是促进组织、部门、项目团队的业绩，其具体业务目标和管理力度可以是分级的。对具体工作产品（Work Product ，简称工件） 的“完整性”可以在空间上从高层产品深入到底层工件、从单项目到多项目，时间上由静态到动态、从输入输出控制到加上过程控制来分层考虑，并根据特定的业务要求、能力、资源等约束条件来确定具体目的和相应力度的配置管理活动。如果不消除混乱源，想要达到高层次目标难免会劳而无功。

　　3.1 了解、把握产品的组成

　　完整地将该交付产品的所有相关工件（即配置项） 及其版本信息一起打包，再加上一个工件清单，可以作为基本的配置管理，可实现高层、静态配置管理目标。静态配置管理暂不关注产品配置项的历史演变、变更控制。过程能力不成熟的组织可以从静态配置管理做起。

　　3.2 支持产品的物理完整性和一致性

　　为了防止产品各阶段工件之间不一致以及需求遗漏或需求冗余等问题，可以在高层、静态配置管理的基础上加上一个需求跟踪矩阵，以证实软件产品对需求的完整覆盖，并保持各阶段工件之间的双向可追溯关系。

　　3.3 支持使用正确的配置项

　　配置项可能有多个版本。支持物理上使用正确配置项的基本要求一是使用经过审批的有效版本，二是在若干个有效版本中使用针对特定用户的版本。为了支持使用正确的配置项，配置管理需要做到前述的各类基本活动。严格地讲，在功能上使用正确配置项是评审、验证、确认等质量控制活动而不是配置管理的直接任务，在本文中不展开说明。

　　3.4 支持高效使用配置项

　　为了高效查找到针对特定用户的配置项和产品配置，除了引入配置管理工具以外，提高配置项检索效率的有效手段还包括：良好设计的、与产品结构一致的配置项结构关系，、清晰、便于检索的配置项标识规范，多样化的配置项检索途径（如按软件产品结构、生命周期模型或配置项演变历史等逻辑关系） 等。高效使用配置项的更高境界是控制配置项的有效版本数，要求良好的版本策划、向下兼容及合并分支版本的技术能力和整体管理能力。

　　3.5 支持提高变更效率和控制变更数

　　变更控制的基本活动包括变更分析、变更状态管理、变更通知等，其中变更分析直接影响变更效率。在配置管理层面主要分析变更会影响到哪些涉众、哪些工件和哪些项目。为此，在配置管理系统中需要保持配置项与其涉众、产品和项目的关联信息。技术、整体管理层面的变更分析包括变更对产品结构的影响、技术难度、所需要的工作量和成本等；涉及具体用户的变更还需要分析对用户实现使用价值、组织实现顾客满意的影响。控制变更的更高境界则是通过有效的需求开发、顾客沟通、项目策划及管理等方式减少变更数。这些都不是配置管理系统能单独实现的任务。