工作量估计的过程

    如何进行估计呢?这里有许多先决条件：如果不能理解问题的领域、不了解系统的规模和系统构架，以及在哪一阶段进行估计，那么就不能够进行基于用例的估计。

    第一次粗略的估计可以根据专家的观点或者更正式的采用 Wideband Delphi 技术(该技术是Rand 组织在 1948 年发明的，请参考Boehm 81 的描述)。这将使得评估者可以将系统在图 3 所示的规模范围中对号入卒。这种部署将提供用例数量的范围，并且表明表达式的层次(L1, L1/L2 等等)。然后评估者必须基于对现有构架知识和领域中的理解来决定这些用例是否适合某一层(是否毫不相关)，或者是不同层次的混合(以事件流的方式来表达)。

    从这些考虑中可以看到，数据是否不够健康是显而易见的--例如：如果 Delphi 估计是 60 万行代码(或者等价的功能点)，并且几乎没有什么构架方面的工作，那么对于系统结构方面知道得并不多--图 3 表明用例的数量应该在 2(所有的第四层)和 14(所有的第三层)。如果实际上用例数量是 100，那么用例可能已经提前进行了分解，或者 Delphi 的估计严重出轨。

    继续分析这个例子：如果实际的用例的数量是 20，并且评估者决定它们都在 L3;更进一步讲，用例的长度平均7页，并且系统是一种复杂的业务系统，每个用例的小时数(从图 2 中得到)是20，000。为了降低复杂度，要乘以 7/9(基于用例的长度)。所以根据这种方法计算的工作量是 20×20000×(7/9) = ~310,000 人-小时，或者 2050 人月。根据 Estimate Professional，对于业务系统而言，60 万行的 C++代码需要 1928 人月。因此，在这个设计的例子中，充分体现了这一点。

    如果实际的用例的数量是 5，并且评估者决定将 1 个用例分配到 L4，其他 4 个分配到第三层。更进一步 L4 用例是 12 页，L3 用例平均是 10 页，然后计算工作量将是 1×250,000×12/9+4×21000×(10/9) = ~2800 人月。这就表明 Delphi 的估计需要重新进行修订，尽管假设系统的主要部分看起来仍然在很高的层次上，但总之在边界上有很大的错误。

    如果原来的 Delphi 估计是 10 万行 C++代码，图 3 表明用例应该在 L2 并且应该有 18 个。如果实际上有 20 个，如同前面的例子一样，如果 Delphi 估计很糟糕的话，那么是因为不考虑实际用例层次而应用该方法将得出一个不正确的结果。

    因此，估计者必须检查用例是否在建议的抽象的层次上(L2)并且可以通过子系统的协作来实现，以及用例并不完全在 L3 上--尽管 Wideband Delphi 方法并不是经常那么糟糕(例如，预计 10 万，而实际上是接近 60 万)。问题是这种评估方法在使用时使人缺乏自信，没有额定的或者概念上的构架，而这些构架正是和用例的层次相匹配的。对于一个在该领域非常有经验的评估者来说，模型可以是一个能够判断形成哪一层的想象中模型，而对于一个经验比较少的评估者或者团队来说，做一些构架建模来观察一下在一个特殊的层次上用例实现得如何，不失为一种明智之举。

    对于复合表达的用例(也就是说，层次 N 和层次 N+1的混合)应该计算为 n=8(l隔开两层的部分) ，得出用例在较低一层的数量。因此，一个用例假设 50%在 L1 并且 50% 在 L2，那么应该计算为 80.5 = 3 个 L1 用例，一个用例假设在 L2 和 L3 之间的 30%，那么应该计算为80.3 L2 用例= 2 个 L2 用例。一个用例在 L2 和 L3 之间的 90%，那么应该计算为 80.9 = 7 个 L2 用例。

    表的规模调整

    实际上考虑总的工作量规模时，需要对个别用例的小时数做进一步调整――工作量的数字只适合于在该规模系统的上下文中的每一个层次上。因此，在表 1 中的 L1 层，当构建一个 7000 slocs 的系统时，将采用每一个用例 55 小时。实际的数字将取决于总的系统规模――所以如果要构建的系统的规模是 40,000 slocs 并且使用 57 个 1 层的用例来描述它，那么对于一个简单的业务系统来说工作量就不是55×57 小时，而是(40/7)0.11 × 55 = 66 小时/用例。这是基于规模和工作量的 COCOMO 2 关系。根据 COCOMO 模型，工作量=A × (size)1.11,其中

    size 的单位为 ksloc

    A 为成本驱动因子

    项目比例因子为额定值(将 1.11 用作指数)

    注意这些计算可以作为因子用到诸如 Estimate Professional这样的工具中，从而减轻计算负担;此处完整列出了它们。

    因此每 ksloc 的工作量或者每单元工作量等于 A× (Size)1.11/Size，从中推出 A× (Size)0.11，因此，每单元的工作量在 size 为 S1 到 S2 的比率为(S1/S2)0.11。

    对 Delphi 估计还要说明一点，系统的规模可以从各个层上用例的数量来粗略地计算出来：如果在第一层有 N1 个用例，在第二层有 N2 个，第三层有 N3 个，第四层上有 N4 个，那么总的规模就是[(N1/10)×7 + (N2/10)×56 + (N3/10)×448 + (N4/10)×3584] ksloc。因此，我们可以计算工作量乘上表 1 中的每个用例的工作量，然后将总的规模除以表1中第一列中列出的每一层的规模(单位是 ksloc)。

    因此, 在第一层, (0.1×N1 + 0.8×N2 + 6.4×N3 + 51.2×N4)0.11。

    第二层 (0.0125×N1 + 0.1×N2 + 0.8×N3 + 6.4×N4)0.11。

    第三层, (0.00156×N1 + 0.0125×N2 + 0.1×N3 + 0.8×N4)0.11。

    第四层, (0.00002×N1 + 0.00156×N2 + 0.0125× N3 + 0.1×N4)0.11。

    显然，以第四层为例，与第三层或第四层的用例数量相比，第一层用例的数量的影响微乎其微。