從這些考慮中可以看到，數(shù)據(jù)是否不夠健康是顯而易見的－－例如：如果 Delphi 估計是 60 萬行代碼（或者等價的功能點），并且?guī)缀鯖]有什么構(gòu)架方面的工作，那么對于系統(tǒng)結(jié)構(gòu)方面知道得并不多－－圖 3 表明用例的數(shù)量應(yīng)該在 2（所有的第四層）和 14（所有的第三層）。如果實際上用例數(shù)量是 100，那么用例可能已經(jīng)提前進行了分解，或者 Delphi 的估計嚴重出軌。

繼續(xù)分析這個例子：如果實際的用例的數(shù)量是 20，并且評估者決定它們都在 L3；更進一步講，用例的長度平均7頁，并且系統(tǒng)是一種復(fù)雜的業(yè)務(wù)系統(tǒng)，每個用例的小時數(shù)（從圖 2 中得到）是20，000。為了降低復(fù)雜度，要乘以 7/9（基于用例的長度）。所以根據(jù)這種方法計算的工作量是 20×20000×(7/9) = ~310，000 人－小時，或者 2050 人月。根據(jù) Estimate Professional，對于業(yè)務(wù)系統(tǒng)而言，60 萬行的 C++代碼需要 1928 人月。因此，在這個設(shè)計的例子中，充分體現(xiàn)了這一點。

如果實際的用例的數(shù)量是 5，并且評估者決定將 1 個用例分配到 L4，其他 4 個分配到第三層。更進一步 L4 用例是 12 頁，L3 用例平均是 10 頁，然后計算工作量將是 1×250，000×12/9+4×21000×(10/9) = ~2800 人月。這表明 Delphi 的估計需要重新進行修訂，盡管假設(shè)系統(tǒng)的主要部分看起來仍然在很高的層次上，但總之在邊界上有很大的錯誤。

如果原來的 Delphi 估計是 10 萬行 C++代碼，圖 3 表明用例應(yīng)該在 L2 并且應(yīng)該有 18 個。如果實際上有 20 個，如同前面的例子一樣，如果 Delphi 估計很糟糕的話，那么是因為不考慮實際用例層次而應(yīng)用該方法將得出一個不正確的結(jié)果。

因此，估計者必須檢查用例是否在建議的抽象的層次上（L2）并且可以通過子系統(tǒng)的協(xié)作來實現(xiàn)，以及用例并不完全在 L3 上－－盡管 Wideband Delphi 方法并不是經(jīng)常那么糟糕（例如，預(yù)計 10 萬，而實際上是接近 60 萬）。問題是這種評估方法在使用時使人缺乏自信，沒有額定的或者概念上的構(gòu)架，而這些構(gòu)架正是和用例的層次相匹配的。對于一個在該領(lǐng)域非常有經(jīng)驗的評估者來說，模型可以是一個能夠判斷形成哪一層的想象中模型，而對于一個經(jīng)驗比較少的評估者或者團隊來說，做一些構(gòu)架建模來觀察一下在一個特殊的層次上用例實現(xiàn)得如何，不失為一種明智之舉。

對于復(fù)合表達的用例（也是說，層次 N 和層次 N+1的混合）應(yīng)該計算為 n=8(l隔開兩層的部分) ，得出用例在較低一層的數(shù)量。因此，一個用例假設(shè) 50%在 L1 并且 50% 在 L2，那么應(yīng)該計算為 80.5 = 3 個 L1 用例，一個用例假設(shè)在 L2 和 L3 之間的 30%，那么應(yīng)該計算為80.3 L2 用例= 2 個 L2 用例。一個用例在 L2 和 L3 之間的 90%，那么應(yīng)該計算為 80.9 = 7 個 L2 用例。

表的規(guī)模調(diào)整
實際上考慮總的工作量規(guī)模時，需要對個別用例的小時數(shù)做進一步調(diào)整――工作量的數(shù)字只適合于在該規(guī)模系統(tǒng)的上下文中的每一個層次上。因此，在表 1 中的 L1 層，當構(gòu)建一個 7000 slocs 的系統(tǒng)時，將采用每一個用例 55 小時。實際的數(shù)字將取決于總的系統(tǒng)規(guī)模――所以如果要構(gòu)建的系統(tǒng)的規(guī)模是 40，000 slocs 并且使用 57 個 1 層的用例來描述它，那么對于一個簡單的業(yè)務(wù)系統(tǒng)來說工作量不是55×57 小時，而是(40/7)0.11 × 55 = 66 小時/用例。這是基于規(guī)模和工作量的 COCOMO 2 關(guān)系。根據(jù) COCOMO 模型，工作量＝A × (size)1.11，其中

    size 的單位為 ksloc
    A 為成本驅(qū)動因子
    項目比例因子為額定值（將 1.11 用作指數(shù)）

注意這些計算可以作為因子用到諸如 Estimate Professional這樣的工具中，從而減輕計算負擔(dān)；此處完整列出了它們。

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

對 Delphi 估計還要說明一點，系統(tǒng)的規(guī)模可以從各個層上用例的數(shù)量來粗略地計算出來：如果在第一層有 N1 個用例，在第二層有 N2 個，第三層有 N3 個，第四層上有 N4 個，那么總的規(guī)模是[(N1/10)×7 + (N2/10)×56 + (N3/10)×448 + (N4/10)×3584] ksloc。因此，我們可以計算工作量乘上表 1 中的每個用例的工作量，然后將總的規(guī)模除以表1中第一列中列出的每一層的規(guī)模（單位是 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。

顯然，以第四層為例，與第三層或第四層的用例數(shù)量相比，第一層用例的數(shù)量的影響微乎其微。

結(jié)束語
本文描述了基于用例進行評估的一個框架。為了使描述更加具體，本文為框架的參數(shù)選擇了一些值，盡管這些值有待于論證，但它們并不總是錯誤的。像往常一樣，隨著數(shù)據(jù)的搜集，這種估計應(yīng)該根據(jù)實際情況和重新估計的參數(shù)值進行測試。這種框架對于不同種類的系統(tǒng)考慮了用例層次、規(guī)模和復(fù)雜度等思想，并且不再采取細粒度的功能分解。為減輕計算的負擔(dān)，對于諸如 Estimate Professional 這樣的工具，可以構(gòu)建一個前端，從而提供一種基于用例的規(guī)模輸入的不同的方法。

對本白皮書的評論以及反饋意見，請通過電子郵件 jsmith@rational.com與 John Smith 取得聯(lián)系。

參考資料

您可以參閱本文在 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