构建（Construction）阶段：管理进度风险

　　RUP 的构建阶段瞄准进度风险的管理。如果应用了 RUP 首选的基于用例的方法，就可以比利用传统的（瀑布）方法更快地集中于可用的（尽管不完全）系统。当达到这一可用地不完全层次，剩下的路也就不远了。

　　该方法生成了一系列客观的改进的可执行系统，并且拥有重要的优势：

　　在尽可能最早的时候给客户展示系统的功能。 
　　团队可以及早地获得部署经验。生成的可执行系统可以转化为产品化阶段的子集（部分部署）。这使我们获得产品化阶段问题的经验 —— 例如，验收测试所需要的是什么，如何为部署而打包，以及一百个其他的问题（参见下面的产品化阶段）。 
我们收集量度，这使得在迭代开发中可以立即看到项目进展。在瀑布过程中，不太可能直接比较分析活动量度和设计活动量度或编码活动量度，因为它们是完全不同的活动。但在迭代过程中，比较迭代 1 的量度与迭代 2 的量度更加容易，因为我们在重复同一组活动。
 
　　在几个星期内，我们就会完成一个分析——设计——编码——测试的周期，这个给我们一种明显进展的感觉。这就是构建阶段的迭代的独特之处。测试活动评估进展并验证确实有了进展。

　　评估进展

　　RUP 提到的迭代节奏到构建阶段还是活跃着的，并且该频率与测试人员有特别的关系。测试人员的主要目标是能够客观地描述系统的当前状态，并且能够将该状态与以前的状态进行比较。这两个状态之间的区别，简单地说，就是进展。

　　测试人员的“节奏”源于以下活动。