需求管理

　  绝大多数RUP配置是以用例为中心的。这意味着对于功能性的需求（关于系统必须实际上做什么的需求），我们应当使用用例来描述系统的行为。什么是我们将要问的问题来确认这个团队是否真正应用了用例并从功能性的观点来描述系统。 5 出现在我头脑中的其中一个问题是："在代码中实现的所有特性 6 都在这些用例中描述到了吗？"这似乎是非常的直截了当。如果我们能够识别出实现的这些特性，我们可以将它们与用例中描述的特征进行比较。最大的困难是确定事实上被实现的这些特性。如果我们可以这样做，我们就可以计算下面用例的度量效果：

　  假定 F i 是所有被实现特性的数量， F s 是既被实现并且又被特定指定的特性的数量。如果您用100乘以U ，您将得到一个在您的用例中被实现了并实际上也被特定的特性的百分数

　  具有代表性的是，在您的用例中您所特定的特性将会比您实际上实现的要多。为了及时交付一个可使用的产品，您在管理这个项目范围时将会删除一些特性。因此 F s必须仅仅包含那些在您特定的并实际实现的特性。现在度量数据U的值在0和1之间。如果您完全使用用例作为说明功能性需求的方法，您得到的值将会是1。当您实现了您的用例中没有特定的一些特性，这个 U值将会减小。

　  度量数据的唯一问题是，我们如何才能获得 F s 和 F i? 7 首先，将用例分散到离散的特性中去， F s，并不是很难得到的。 我们能够检查用例，并且通常我们同意他们特定的特性。我们可以用场景作为我们度量的一个单元，或者将描述系统行为的每一个步骤作为一个特性。但是更困难的部分是计算 F i。 如果您仅仅测试特定的特性，您可以确定他们是否全部都被实现了，但是您不能确定您的开发人员是否实现了那些并没特定指明的特性。

　  让我们提出一些估计 F i值的方法。一个极好但耗时的确定实现的编码是否就这个用例中特定指明的方法是，对检入到项目中的所有编码实行检查。这个检查与您寻找特别的东西有点不同。在这个情况下，您应该尽力的识别已经被代码实现的特定特性，然后将这些特性映射到用例图。

　  第二个确定没有被特定指明但是已经被实现了的特性的方法是，让您的测试人员在软件上执行探测测试。 探测测试是 Cem Kaner和James 发明的技术。 8 。使用这个技术，测试人员不必以一系列测试用例开始，也不用其它预定义的测试脚本。测试人员仅仅需要启动探测软件，看它能做什么。测试人员试着确定产品允许他做什么。您可以向测试人员提供用例，让他们以用例为向导来探测这个产品。当测试人员探测到用例中所没有的情况，他就把它记录下来作为实现了但是没有被特定指明的特性。

　  我首选的找出 F i值的方法是一个混和方法：

　  首先，在严格基于用例的基础上运行您的验收试验。这些在下一步前必须都通过。
　  其次，使用代码覆盖工具运行您的验收试验。被执行的代码表示了这是实现所有F s所需要的代码。
　  最后，检查您测试中的那些没有实现的代码。这些代码要么是实现了例外条件，要么是实现了但没特性指明的特性。理想的情况是，这的代码数量很少，所以也很容易识别出那些未特定指明的特性。

　  以上的度量数据，U，告诉我们开发人员实现的是否就是特定指明的。但是一个值（特定的）小于1，就意味着这个开发人员没有很好地完成采取用例驱动开发的工作吗？也许是在项目执行时用例发生的变化，但是团队成员没有尽力去更新这个用例。也许他们依靠一种更加不正式的方法来表达一个新的场景和用例。这将表明实际的过程使用了已经编写好的、受控的用例来作为一个起始点——这并不一定是一种坏的情形，但是与计划好的过程有所不同。

　  当您在您的测试中检查到并没执行的代码时，如果需求发生了变化，但没有正式地被更新，那么最好的办法是让一个人来负责确确认需求。事实上，一个快速检察它是否是一个问题的方法是，查看您的用例工件的版本控制日志。如果他们在最初的版本之后没有任何变化，您可以清楚地确定这个团队没有保持需求更新，至少在用例中以一种持久的形式使他们保持更新。

　  迭代开发

　  任何基于RUP的裁剪的过程，除了大多数小的项目之外，都包含了迭代开发的向导，在迭代过程中软件是按照迭代的增量式地构建的。通常，最开始的两次迭代都关注于精化关键需求和开发一个可执行的架构。 9 在这些迭代之后，如果还没有最终完成项目，每个迭代都应当产生一个可运行的系统。

　  要看我们的团队实际上是否执行了迭代开发，我们应该问什么问题呢？

　  迭代的特征之一是严格控制时间。 那就是在迭代的开始您可以决定它的终止日期。当这个日期到达时，迭代就结束了。您考虑的仅仅是全部的特性或者您使用什么作为迭代的可交付工件来度量过程。如果一种特性差不多已经完成，但是正好还需要更多一点的工作，但它并不是迭代可交付工件的一部分——也就是说，您不用决定延长迭代的终止日期来适应这个特性。因此您可以这样问一个问题： "迭代都是有严格时间控制的吗？" 就是说，在迭代的开始它的终止日期就已经确定好了吗？这是迭代的实际的终止日期吗？

　  我们可以用下面的方程式为这个项目的迭代持续度定义一个度量：

　  假定I m是终止日期已经被修正了的迭代的次数（在迭代开始以后）， I t是迭代的总次数。 如果这个团队严格遵守了迭代的开发过程，我将得到的值是0。在这个可能值范围的另一个端点，这个团队在每次迭代开始后，修改了 所有迭代的终止日期。在这种情况下，我将得到的I值是1。 不考虑您是怎样维持您的项目计划的，这个度量是十分容易计算的。您所要跟踪的是您的计划中日期的变化。

　  严格时间控制的迭代是有必要的，但是要证明这个团队执行了迭代开发，理由还是不够充分。我们还需要知道什么呢？另一个我们可能要问的问题是： "在每次迭代结束的时候都会产生一个可运行的软件吗？" 您通过计算产生的可运行的软件来确定您的答案。如果您在每次迭代结束时都将软件配置存档，通常是通过在您的版本控制系统中对配置进行标记以及在必要的时候重新构建，这样您可以在很短的时间内验证这个软件的运行情况。

　  一旦您有了每次迭代的这个信息，您可以计算一个运行软件的比值，W，如下所示：

　  假定Iw 是产生可运行软件的迭代数值， I t 是总的迭代数，跟前面的一样。当可执行的构架是被第一次产生或者当第一个可执行的软件开始出现时，您可以选择调整 I t 为总的迭代数。这样可以使W的值在0和1之间变化，包括0和1。W 的值越大表明采用迭代开发的程度越高。