会员登录
会员注册
从这些考虑中可以看到，数据是否不够健康是显而易见的--例如：如果 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,其中