Stay focused on executable software

 第三个不可缺少的RUP理论包括几个方面。首先，你应该尽最大可能的通过衡量你的可执行软件来衡量你的进展。当然一半以上的用例已经被细化是一件好事，但是这并不意味这相当程度的需求已经完成了。如果你之后发现因为你并没有恰当的了解用户需求，进而导致了大多数的主要需求需要重新实现，那么你会怎么做呢？那可能意味着你仅仅完成了实际工作总量的很少一部分。所以如果你想表明你完成了一半的用例，也就相当于你想表明你仅仅实现了一半不到的需求。
最好的衡量进展的方式就是衡量那些可以运行的软件。它允许你测试，并且基于测试和次品率，估算出真正的进展。当一个典型的开发者陈述说：“我已经完成了90%”，那么你可以问问他，“很好，请演示一下你可以运行的东西。”然后通过演示，获取一个能够说明“到底完成了多少”的客观的结果。你应该总是采用演示-->察看测试覆盖率和测试结果这样的过程来估算进展，千万不要被那些往往和现实不符的文档所蒙蔽。当然这并不是否定文档的作用，而只是说明它们对于衡量项目进展情况的时候，只能起到微乎其微的作用。
其次，明确地把精力集中于“可执行”的软件上，这一点同样提升了你的团队的一些正确意识；你不会冒着犯“过渡设计”或者“重理论，轻实践”这类错误的风险，取而代之的是，用实实在在的工作去证明方案“A”和方案“B”的优劣。强迫以可执行软件作为结束通常是最快的减少风险的途径。
再次，重视可执行的软件的第三个特点就是软件的“副产品”（计划、配置等管理手段）会去适应软件的开发，而不是让软件的开发去适应这些“副产品”。这些“副产品”是为了让你开发出更好的软件。以“可执行的软件”为出发点，你可以决定是否生产这些“副产品”。通常这些“副产品”是为了让你的软件产生更好的效果或者更加容易维护。是的，在一些情况下答案是肯定的，但是这并不是“放之四海而皆准”的。你需要衡量这些副产品所带来的优劣。通常这些副产品的优势会随着你的项目的规模，以及你的产品对于商业的重要程度而增长。在这种情况下，所有的事实都表明：应该产生出尽可能多的“副产品”。但是对于任意一个项目而言，你应该努力的减少这些副产品，进而削减费用。
一个好的方针就是：如果你对于是否生产这些副产品而犹豫不决，干脆就别生产它们。但是不要对那些重要的活动使用此方针，比如记录需求、进行设计和制定测试计划的时候就不要这样做。这些活动所产生的副产品有特定的价值。如果生产副产品的花费超出了回报，忽略它们。
RUP用户经常犯的一个错误就是仅仅因为RUP描述了如何生产那些“副产品”就去生产它们。记住RUP只是大餐前的开胃小菜。

Accommodate change early in the project.
变动是一件好事。实际上变动是一件伟大的事。为什么呢？因为当代大多数的系统正在变得太过复杂以至于你都没法获取需求并在第一时间进行设计。变动允许改善你的方案。如果没有变动，你可能会提交一个有缺陷的方案--这有可能会导致你的应用没有任何的商业价值。这就是为什么欢迎并且鼓励变动。并且迭代方法已经被进行了足够的优化，使它更加适应于变动的情况。
但是变动也有些不良的后果。持久的变动会导致你的项目无穷无止。处在项目后期的一些变动会导致一些工作成为“无用功”，会增加费用，降低质量，甚至会导致拖延--那些都是你想尽办法要避免的。为了优化你的变动管理策略，你需要了解不同类型变动的代价：
1、商业方案变动的代价。这种变动主要包含需求的重写或者要面对完全不同的用户或需求。应该在先启阶段就处理这些变动或适应这些变动，随着进入“精化”阶段，这种变动所带来的代价会越来越大。
2、框架变动的代价。遵照RUP，在价值较高的精化过程到来之前，你可以进行一些重大的框架变动。在那之后，框架变动的代价会显著增加。
3、设计和实现的变动代价。因为你的功能更加“模块化”或者“组件化”，这些变化看上去更加“本地化”一些，因此在构建阶段它们的代价相当低。但是当初在正式版本提交阶段，代价会显著增加。
4、边界变动的代价。裁减边界，把一些特性放到下一个发布版本中去，对于一个产品来说代价相对较低。项目管理者可以使用这把“利剑”来确保项目的按时提交。
上面有关代价的考虑说明你应该去管理这些变动。你需要：
1、在切当的时期决定是否引入一个变动。
2、评估变动所带来的压力。
3、尽可能缩减变动的代价。

   出自The Spirit of the RUP
RUP的那些阶段已经优化并最小化了这些变动的花费，同时增长了迎合变动的能力。这就是为什么RUP要求在先启阶段的最后，在所有的视点上达成共识；在精化阶段的最后能够有一个可以作为基线的框架结构；在beta版发布阶段不再向产品添加新的特性。使用正确的工具可以为你的变动管理带来很大的方便，并降低你的代价。