变更(CR，Change request)管理是项目管理中的最重要过程之一。
一个项目，从开始就处于不停的变化中。用户需求变了需要调整计划或者设计；测试发现了问题需要对错误代码进行变更；甚至人员流失了，也需要项目进行一定的调整以适应这种情况。Bug管理，需求管理，风险控制等本质上都是项目变更的一种。它们都是为了保证项目在变化过程中始终处于可控状态，并随时可跟踪回溯到某个历史状态。

孤立的看单个变更（CR）的生命周期，那么它是比较简单的，大致就是提出－审核－修改这么一个过程。但变更管理并不是单纯的一个数据库记录，做个备忘而已。在这么一个简单的流程中，变更管理要能体现出它的两个重要用途，一个是控制变更，保证项目可控；一个是变更度量分析，帮助组织提供自己的开发能力。

为了保证项目可控，项目管理者要充分了解变更的信息，衡量变更实施对项目的冲击，才能决定是否要修改。比如问题是否严重必须马上得到修改，问题的修改是否很复杂，是否会牵扯到很多方面。这些信息，大致可以归为俩类，一类是变更的自身信息，比如复现步骤等；一类是关联信息，比如某个功能变更实施后，对项目其它模块的影响分析，这类信息通常不可能由变更提出人来提供，而需要变更审核者结合多方面信息进行分析。

实施变更管理的一个更重要且更有意义的作用就是对变更进行度量分析。
在项目进行过程中，对变更进行分析，可以很好的了解项目当前质量状态（如果你承认统计学有它的科学性，那么你就会承认，项目各阶段的合理变更发展情况是有确定的分布形态的）；定时进行项目复盘，分析组织中变更的产生原因和解决方法，及时了解组织中常见错误并有针对性的改正，才能促使组织的开发能力不断得到提高。在CMM五级中，缺陷预防就是一个最重要的过程域，而要进行预防缺陷，离不开对历史项目的变更分析。

DSTP变更管理的特点：
DSTP是一个集成的项目协作平台，它包含了任务计划，变更，评审等功能，且各部分功能紧密集成，过程流转完全自动化，让开发使用变得自然。
和一般的变更管理工具比起来，DSTP的变更管理有如下特色：
1． 可自定义变更属性内容，通过变更属性不同，来统一管理多种变更，如Bug管理，需求变更，风险管理等。
2． 和SVN紧密集成，用户在SVN上提交修改时，自动关联DSTP中的变更(任务)做为修改说明。查看变更时，能直接查看该变更关联修改了哪些文件，以及修改内容！当用户没关联合适的变更或者任务，系统将拒绝修改提交，有效避免的项目被随意修改。
3． 提供了完善的变更同步功能，提出了系统变更踪阶段概念，使得所有工作产品的一致性得到流程保障！所谓的系统变更跟踪是指这么一个情况：当用户提出一个需求变更后，系统工程师修改完需求文档后，该变更并没真正结束。系统自动转入到变更跟踪阶段，只有和该需求有关联的代码，用户文档等都被修改完成后，该变更才会结束跟踪阶段，走入确认关闭阶段。
4． 和DSTP的工作产品管理配合：为变更影响分析提供有力支持；变更和需求，测试计划等直接关联，方便多向跟踪追溯。
5． 和任务，邮件配合：保证变更在流程上得到及时通知和处理。
6． 强大的查询和分析功能。能自由组合任意条件进行查询；查询支持格式信息，如today+5，%提交人% = ％修改人％；可以以图形化方式为用户展示数据，趋势图，统计图，对比图，供用户从多方面进行分析研究。从而及时发现问题并采取进行项目计划调整等应对措施。

DSTP提供的变更流程如下

变更过程和相关角色说明：
记录变更：登记和提交变更请求。允许每个项目自定义变更请求模版，指导变更填写。
评审变更：变更是受控的。当提出项目变更请求后，需要由项目CCB（变更控制委员会）成员审核决定是否实施，或者是否对变更要求部分更正再实施。
    当变更提出时，CCB审核每个变更，根据相关影响决定是否接受变更，并指派合适的项目人员实施变更或者对拒绝理由做出说明。CCB一般是项目的管理人员和各方面的负责人组成。所有变更都需要通过CCB审核，有效的保证了项目有统一入口，避免项目成员任意修改项目导致无人知道项目现在实现了什么功能。
研究变更：CCB接到变更（变更请求）后，如果一下子无法清楚变更影响或者导致变更的原因（比如缺陷如何产生），可以先指派人研究下，看实施变更有什么影响或者定位出问题所在，供决策使用。
实施变更：如果CCB经过评估认为该变更应该接受，则可以指派人实施修改。
验证变更：实施人修改变更后，交由其它人进行验证评审。确认修改正确。
    验证是验证本变更相关的修改，并不需要确认变更所述内容已经得到彻底实施。比如一个需求变更，CCB审核后，可能会指派给一个系统工程师进行需求文档修改。该系统工程师只会修改需求文档，而不会修改修改代码或者测试，也不会去修改用户文档改变描述。验证变更的人，只验证系统工程师修改需求文档描述确实正确，无歧义就可。代码修改或者测试等的同步，将交由变更同步进行。
系统跟踪：变更验证通过后，如果该变更是一个项目内容变更类型的变更，那么它有可能影响到其它工作产品，系统自动检查该变更所修改的文档，并下发同步变更给下游工作产品的负责人，告诉那些负责人它们所依赖的哪些工作产品有了修改，它们的工作产品可能需要同步变更。下游工作产品变更结束后，会引起系统继续往更下游下发通知，直到所有相关工作产品都修改结束才结束， 保证变更得到彻底实现。
　如果是缺陷类的变更，因为不引起其它影响，修改完就表示变更得到了实施。所以验证过后系统直接提交给变更原始提出人进行确认。如果验证人和确认人相同，系统会跳过确认阶段直接走到关闭状态。
确认变更：变更完全得到修改或者CCB经过评审，认为不用修改或者因其它原因不适合修改，将提交给原始提交人进行确认。
    确认人如果认可变更的处理情况，可以确认通过，变更转入关闭状态；
    确认人如果认为修改不正确、不完全；或者对CCB的决策有异议，比如认为CCB拒绝或者更正变更范围的理由不充分。则可确认不通过，变更会提交到CCB处重新审议，由CCB参考确认人的意见，重新确认一个项目认可的修改标准再重走流程。
挂起变更：CCB经过评估认为变更合理，应该修改，但由于各种情况短时间内不宜修改，则可以把变更挂起，并设置一个挂起时间。以后CCB可以随时激活该激活，重新进入评审状态；或者挂起时间到了，系统会自动激活该变更进入评审状态。