今天在网上看到一篇文章:http://www.ibm.com/developerworks/cn/rational/edge/08/mar08/smith/。文章里面写到的一些问题，正是我所遇到的：
1.缺乏统一的、全面的、综合的变更管理处理过程。这样变更之后可能听到这样的抱怨“我真不知道您做了什么”，如果有个一统一的、全面的、通用的变更管理方案放在一个工具中执行，你们将会消除这种混乱
2.缺乏对构建顺序的理解、缺乏对代码模块的提供者和消费者之间的合同的定义和强制、以及构建所具有的完全的整体性，正是一下诸多问题发生的根源：无法重新启动构建过程、无法完成部分可靠的构建、无法进行有效地测试、无法对变更(补丁和升级)进行影响分析，等等。
3.缺乏对根本的系统对象的依赖关系的理解
4.在整个开发周期中都普遍缺乏可追溯性，没有一种方法可供用来追踪处理过程和需求覆盖。关于测试的变更管理处理过程是手工的和记录不良的。这些变更管理和组件相关的缺点，意味着没有一种方法能够进行变更级别的影响分析。
对于产品型的项目，变更是不可避免的，如果变更是失败的，那这个项目就会越做越难。微软的xp系统是有那么多人开发的，如果对xp的更新处理是失败的，那就不会有SP1、SP2和即将推出的SP3了。