從這些考慮中可以看到，數據是否不夠健康是顯而易見的－－例如：如果 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
