从这些考虑中可以看到，数据是否不够健康是显而易见的－－例如：如果 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。

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

结束语
本文描述了基于用例进行评估的一个框架。为了使描述更加具体，本文为框架的参数选择了一些值，尽管这些值有待于论证，但它们并不总是错误的。像往常一样，随着数据的搜集，这种估计应该根据实际情况和重新估计的参数值进行测试。这种框架对于不同种类的系统考虑了用例层次、规模和复杂度等思想，并且不再采取细粒度的功能分解。为减轻计算的负担，对于诸如 Estimate Professional 这样的工具，可以构建一个前端，从而提供一种基于用例的规模输入的不同的方法。

对本白皮书的评论以及反馈意见，请通过电子邮件 jsmith@rational.com与 John Smith 取得联系。

参考资料

您可以参阅本文在 developerWorks 全球站点上的 英文原文。

1. Armour96: Experiences Measuring Object Oriented System Size with Use Cases， F. Armour， B. Catherwood， et al.， Proc. ESCOM， Wilmslow， UK， 1996

2. Boehm81: Software Engineering Economics， Barry W. Boehm， Prentice-Hall， 1981

3. Booch98: The Unified Modeling Language User Guide， Grady Booch， James Rumbaugh， Ivar Jacobson， Addison-Wesley， 1998

4. Cockburn97: Structuring Use Cases with Goals， Alistair Cockburn， Journal of Object-Oriented Programming， Sept-Oct 1997 and Nov-Dec 1997

5. Douglass99: Doing Hard Time， Bruce Powel Douglass， Addison Wesley， 1999

6. Fetcke97: Mapping the OO-Jacobson Approach into Function Point Analysis， T. Fetcke， A. Abran， et al.， Proc. TOOLS USA 97， Santa Barbara， California， 1997.

7. Graham95: Migrating to Object Technology， Ian Graham， Addison-Wesley， 1995

8. Graham98: Requirements Engineering and Rapid Development， Ian Graham， Addison-Wesley， 1998

9. Henderson-Sellers96: Object-Oriented Metrics， Brian Henderson-Sellers， Prentice Hall， 1996

10. Hurlbut97: A Survey of Approaches For Describing and Formalizing Use Cases， Russell R. Hurlbut， Technical Report: XPT-TR-97-03， http://www.iit.edu/~rhurlbut/xpt-tr-97-03.pdf

11. Jacobson97: Software Reuse - Architecture， Process and Organization for Business Success， Ivar Jacobson， Martin Griss， Patrik Jonsson， Addison-Wesley/ACM Press， 1997

12. Jones91: Applied Software Measurement， Capers Jones， McGraw-Hill， 1991

13. Karner93: Use Case Points - Resource Estimation for Objectory Projects， Gustav Karner， Objective Systems SF AB (copyright owned by Rational Software)， 1993

14. Lorentz94: Object-Oriented Software Metrics， Mark Lorentz， Jeff Kidd， Prentice Hall， 1994

15. Major98: A Qualitative Analysis of Two Requirements Capturing Techniques for Estimating the Size of Object-Oriented Software Projects， Melissa Major and John D. McGregor， Dept. of Computer Science Technical Report 98-002， Clemson University， 1998

16. Minkiewicz96: Estimating Size for Object-Oriented Software， Arlene F. Minkiewicz， http://www.pricesystems.com/foresight/arlepops.htm， 1996

17. Pehrson96: Software Development for the Boeing 777， Ron J. Pehrson， CrossTalk， January 1996

18. Putnam92: Measures for Excellence， Lawrence H. Putnam， Ware Myers， Yourdon Press， 1992

19. Rechtin91: Systems Architecting， Creating & Building Complex Systems， E. Rechtin， Prentice-Hall， 1991

20. Royce98: Software Project Management， Walker Royce， Addison Wesley， 1998

21. RUP99: Rational Unified Process， Rational Software， 1999

22. Stevens98: Systems Engineering - Coping with Complexity， R. Stevens， P. Brook， et al.， Prentice Hall， 1998

23. Thomson94: Project Estimation Using an Adaptation of Function Points and Use Cases for OO Projects， N. Thomson， R. Johnson， et al.， Proc. Workshop on Pragmatic and Theoretical Directions in Object-Oriented Software Metrics， OOPSLA '94， 1994