在这个项目的非常早期的阶段，我们能设计一个阶段计划， 作为在我们的软件开发计划里的一个部分，该计划概括了每阶段的长度和及其迭代，并且为每一个迭代阶段制定了严格的时间计划，包括应用软件的发布。 （在一项RUP项目里的每个阶段可以包含多次迭代。) 我们所不知道的是，什么功能将准确地在每一个迭代过程中被交付。

在下一个阶段——精化阶段，我们将关注在详细描述需求上，根据这些需求来开发软件，降低由技术、计划和资源带来的不确定性。随着我们的精化过程进行，我们可以在阶段计划中补充一些细节的东西。基于在先前一个迭代阶段中学到的东西，我们能将需要实现的软件的功能安排到项目的一个个迭代阶段。在精化阶段的后，项目中的大多数不确定（危险）会得到减轻，我们能谈判做出确定的关于软件功能范围的承诺。 如果我们已经采取有规律的版本式方法来开发我们的应用程序，功能范围的协商会容易得多，因为我们总能在未来某一个版本中完成所要求的功能。

根据精化阶段制定的详细的程序功能范围，我们可以进入开发阶段。此时，我们的重点转移到根据经过校订的关于功能范围的合约，开发剩下的功能。现在我们该对我们的能力感到满意，因为我们能做到根据在项目先启阶段制定的时间表来完成所需要功能的开发。
通过协作改进需求

要成功地使用RUP需要在项目研究团队和相关利益方之间形成一种新的合作关系。过去，IT界已经提出了，向商业相关利益方正确定义需求存在一定风险，但是还是假设交付软件的风险取决于这些需求。 IT界会让用户签订一份文档，然后来控制这些需求的变化，从而达到管理这些风险的目的。 IT界会由于这些变化向用户收费，然后根据这些变化相应增加事先的估计，从而得以修改时间计划和 超额的支出，从而声称项目依然准时而且不超支。这种行为会在相关利益方和IT界之间引发猜疑，导致彼此感觉不舒服。

另外一种合作的方法会大大优于上述的方法。相关利益方和项目研究团队在事先都清楚认识到，在项目一开始完全正确地定义需求事实上是不可能的。因此让项目研究团队按照预算和时间计划下执行任务也是不可能的，因为这个预算和时间计划本基于不确定的需求、资源和技术。

采用了“RUP精神”的项目中，相关利益方和项目研究团队成员清楚，随着他们了解更多，需求可以而且应当变化和改进。在项目研究团队排除项目中大多数不确定因素之前做精确的计划是不明智的。项目管理者必须尽快地说明那些不确定因素，这样负责实现的团队能够根据需要实现的功能的范围来确定软件功能。

团队经常会问：“精化阶段应该持续多久？”答案是，让这段时间足够长，从而项目研究组能降低已知的风险，项目管理者可以根据这个项目的时间安排、支出和功能范围来做出明确的说明。在一个典型的项目中，这个阶段意味着开发百分之二十的功能，或者足以证明整个框架能够支持所有的需求。

在精化阶段的后，当研究团队已经将和进度、功能、技术和资源相关的大部分不确定性消除之后，他们可以列出需求，同时把将来需求的变化纳入正常的变更控制过程中。
将维护人员调入开发团队

很多组织将新程序开发和现有程序维护区别对待。通常来说，他们会外请顾问来根据新的技术建立新的程序，但是一旦这项程序开发部署完毕，他们会将该程序应用交付给内部维护人员支持。这会让工作人员失去动力。来维护一个别人建立的应用程序，对工作人员来说不会太满意，尤其是当这些维护人员还很少和新技术接触的情况下。同样，在不知道先前的开发基于何种决策的情况下，要有效地维持一个应用程序也非常困难。如果你应用了这种方法，你必须给维护人员提供足够的材料，这将会增加系统的开销。

在迭代化开发环境中，将维护人员调到开发队伍中，让他们同时负责维护现有版本以及为未来的新版本开发新功能，更有意义了。这促使团队始终关注系统的商业目标和特色，使得团队成员能够帮助完善这个商业目标和特色。终，这种方法将带来一个更高效更愉快的开发队伍，同时也会减少文档负担。
问合适的问题，并要求增加的功能演示

迭代化开发方法会如何影响指导委员会管理与项目管理者会晤的方法呢？首先，管理者必须确认委员会了解在整个RUP各个阶段中项目会如何变化。只有这样委员会才能够问出有意义的问题，在不同阶段中调整提供的资金水平。比如，在精化过程中，他们应该问项目管理者索取定时更新的风险列表，从而能确认这些风险是否在该阶段后过程被消除。

在一个项目先启阶段中，应集中关注于降低风险和不确定因素，这是使用RUP优于使用其他迭代化方法的重要优势。在开发软件的精化阶段中，如果使用降低风险的方法，发现大的不确定性是十分必要的。很多风险与构架关系有关。尽管客户相关利益方可能会给开发团队施加压力，要求先建立他们所认为的重要的功能，在精化阶段还是要根据结构而不是客户来设置优先级。指导委员会必须知道这些。在精化过程的后，当大的不确定性已经被解决，项目也将进入开发建设阶段，这时候优先级设置可以多考虑以用户需求为驱动。

在有些情况下，先完成主要功能的构建，来降低和需求相关的风险以及工作流中的不确定性，可能是有意义的。然而，如果这种功能是很直接的而且并不和一些很明显的不确定性相关，开发团队可以将该功能的开发推迟到构建阶段进行。记住：我们的目标是尽快完成精化阶段，这样我们能给相关利益方确切的承诺，转入开发构建阶段。

指导委员会应当也需要基于一个已基线化的架构，验证关键用例场景（使用真的可以运行的软件而不是模型！）。 事实上，他们可能会考虑在他们的会议间放上投影机来使得软件演示更顺畅。这和传统的瀑布式方法有着根本的不同。指导委员会通常只有在整个应用程序即将投入使用的时候，看到demo版本而不是看到一个功能型的演示版本。另外，他们通常用甘特图来衡量整个项目的进程，在甘特图上会显示已经完成了33％尚未完成66％，诸如此类。或者，他们会问管理者是否已经签订了需求和设计文档。首先，而且也是重要的是，项目管理者需要教育指导委员会成员，如何来衡量进度：的有效方法是看能够工作的软件而不是签订的文档。