见。造成这样的结果就是由于没有控制和管理好项目的范围。可见项目的三约束中范围的影响起到关键作用。
一般来说，在启动软件项目初期，客户就应该提出一个相对确定的项目范围，为项目的实施提供一个牢固的前提和框架，同时也是为后期的项目管理划出一个明晰的“圈”，所有项目活动的开展，包括项目成本、质量和时间的控制也应该在此范围内进行。但是，在实际的操作过程中，这个“圈”的边界有可能会出现模糊、扩大的现象，甚至这些扩大和模糊的部分会给项目带来风险。项目范围（Scope）、时间（Time）、成本（Cost）、质量（Quality）之间的关系模型如下图所示。
如果项目范围即既定的面积S不变，成本C、质量Q、时间T就可以在一个固定的S的边界限制下给出一个约束的关系模型Cost=f(Quality,Time,Scope)。但是，如果S的值并不固定，就如上图所示出现边界模糊或者向外扩展时， C、Q、T就失去可依赖的边界限制，其之间的约束关系就会变得复杂。因此，我们在对项目范围进行控制时，一是要保证项目初期的S是准确可靠的，尽量减少边界的模糊性；二是要保证项目实施过程中S的稳定，尽量避免扩大化，或是说让扩大化受到合理的控制。
范围变更控制流程分析
范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行动与教训总结。
一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的，因此变更是不可避免的，关键问题是如何对变更进行有效的控制。项目经理和项目小组必须意识到范围变更本身并没有什么不对，事实上很多时候这会使系统更健壮、更实用。客户通常不能一开始就确定所有需求，而且情况会随时间而变化，如果不能包容变更，那么最终的软件系统可能就达不到应有的价值。但是如果变更失控，后果也非常严重，甚至于导致整个项目的失败。
变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。为执行变更控制，必须建立有效的范围变更流程，它对管好项目至关重要。变更控制流程主要包括四个关键控制点：授权、审核、评估、确认。在变更过程中要跟踪和验证，确保变更被正确执行。范围变更控制流程下图所示。
提交变更请求：项目的任何涉众均可提交变更请求。通过将变更请求状态设置为已提交，变更请求被记录到变更请求追踪系统中并放置到变更控制委员会（CCB）复审队列中。
复审变更请求：此活动的作用是复审已提交的变更请求。在 CCB 复审会议中对变更请求的内容进行初始复审，以确定它是否为有效请求。如果是，则基于小组所确定的优先级、时间表、资源、努力程度、风险、严重性以及其他任何相关的标准，判定该变更是在当前发布版的范围之内还是范围之外。
确认重复或拒绝：如果怀疑某个变更请求为重复的请求或已拒绝的无效请求（例如，由于操作符错误、无法重现、工作方式等），将指定一个 CCB 代表来确认重复或已拒绝的变更请求。如果需要的话，该代表还从提交者处收集更多信息。
更新变更请求：如果评估变更请求时需要更多的信息，或者如果变更请求在流程中的某个时刻遭到拒绝，那么将通知提交者，并用新信息更新变更请求。然后将已更新的变更请求重新提交给 CCB 复审队列，以考虑新的数据。
安排和分配工作：一旦变更请求被置为已打开，项目经理就将根据请求的类型把工作分配给合适的角色，并对项目时间表做必要的更新。
进行变