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

問題
直觀上看起來似乎根據(jù)用例模型的特征，可以對開發(fā)工作所需的規(guī)模和工作量進行估計。畢竟，用例模型捕獲了功能性需求，那么難道不應(yīng)該有基于等價于功能點的用例嗎？這里存在許多困難：

    有許多不同的用例規(guī)格樣式和形式，很難定義一個度量標(biāo)準(zhǔn)，例如，某人可能希望能夠度量用例的長度；
    用例應(yīng)該代表外部參與者對于系統(tǒng)的觀點，因此，500，000 sloc 系統(tǒng)的用例與 5，000 sloc 子系統(tǒng)的用例在完全不同的層次上（Cockburn 97 討論了層次和目標(biāo)的概念）；
    用例可能在復(fù)雜性方面不同，編寫時是顯式的，實現(xiàn)時又是隱式的。
    用例應(yīng)該從參與者的角度來描述行為，但是這可能相當(dāng)復(fù)雜，特別是當(dāng)系統(tǒng)具有狀態(tài)時（絕大多數(shù)情況是這樣的）。所以描述這種行為需要系統(tǒng)的模型（在實現(xiàn)它們之前）。當(dāng)試圖捕獲行為本質(zhì)時，這將導(dǎo)致過多的功能分解層次和細節(jié)。

所以，為了能夠進行評估，是否有必要實現(xiàn)一些種類的用例呢？或許是對于直接根據(jù)用例進行估計的期望過高，并且在功能點和用例點的概念之間直接劃等號對我們產(chǎn)生了誤導(dǎo)。功能點數(shù)量的計算無論如何都需要一個系統(tǒng)模型。從用例描述中派生的功能點需要達到與用例表達一致的層次，并且只有達到該層次時，我們才能夠?qū)�功能點的數(shù)量有信心。Fetcke 97 描述了一種從用例到功能點的映射，但是，用例的層次必須適當(dāng)，這樣映射才能有效。其他的方法使用基于類或基于對象的度量標(biāo)準(zhǔn)作為來源，PRICE Object Points 是一個這樣的例子(Minkiewicz 96)。

其他工作
在描述和形式化用例方面的工作相當(dāng)完備――Hurlbut 97 對此有很好的概括。而從用例中派生估計的度量標(biāo)準(zhǔn)卻寥寥無幾。Graham 95 和 Graham 98 中包含了對于用例相當(dāng)嚴格的批評（但是我并不完全理解為什么他認為他的想法和用例是大相徑庭的），并且建議將"任務(wù)場景"作為克服用例問題的方法――包括它們的變化的長度和復(fù)雜度。Graham 的"原子任務(wù)場景"是"任務(wù)點"度量收集的基礎(chǔ)。原子任務(wù)場景存在的問題是它處于低層：根據(jù) Graham的說法，它理想的情況是作為一個單一的句子，并且如果僅僅使用本領(lǐng)域的術(shù)語那么不能更進一步進行分解。Graham 的"根任務(wù)"包含一個或者更多的原子任務(wù)場景，并且每一個根任務(wù)"在初始化計劃的類中，與一個系統(tǒng)操作正好對應(yīng)" (Graham 98)。這些根任務(wù)在我看來似乎非常像低層用例，并且這些原子任務(wù)場景如同是這樣的用例中的步驟。然而，這種層次方面的問題仍然沒有解決。

Karner（Karner 93）、Major（Major 98）、Armour，以及Catherwood（Armour 96）和 Thomson（Thomson 94）完成了其他方面的工作。Karner 的論文中指出了計算用例點的一種方法，但是該方法仍然假設(shè)這些用例是以一種通過類可以實現(xiàn)的方式來表達的（例如，在一種更合適的細節(jié)層次上而不是子系統(tǒng)上）。

那么，我們應(yīng)該不使用用例來估計而依賴于所實現(xiàn)的分析和設(shè)計嗎？這個問題妨礙了做出估計的能力，并且無法滿足已經(jīng)采取該技術(shù)的項目管理者的要求――需要盡早估計并且不得不使用其他方法。對于項目管理者來說，為了做項目規(guī)劃，好能夠盡早獲得評估，然后反復(fù)對其進行精化，而不是拖延評估并且毫無頭緒地進行工作。

本文中描述了一個框架，在該框架中可以使用任何層次的用例來形成工作量估計。為了展示這些觀點，本文描述了一些簡單的規(guī)范結(jié)構(gòu)，這些結(jié)構(gòu)具有相關(guān)的一定實踐基礎(chǔ)上的維度和規(guī)模。本文中大多是大膽的（或者應(yīng)該說缺乏根據(jù)的）推測，因為我沒有其他的方法來解決這個領(lǐng)域中缺少的工作和數(shù)據(jù)的問題。本文引用了"互連系統(tǒng)構(gòu)成的系統(tǒng)"思想。

接下來，我將暫時撇開主題來介紹一些將我引入本文主題的一些背景想法。

避免功能分解嗎？
功能分解的思想對于軟件開發(fā)領(lǐng)域中的許多人來說像一個"詛咒"。我對功能分解的體驗更是其中的極端（在一個很大的數(shù)據(jù)流圖中有 3000 個原始轉(zhuǎn)換，五層或者六層深，在除了基礎(chǔ)設(shè)施層外沒有使用任何構(gòu)架的思想的情況下完成），讓我感到異常悲觀。在該用例中存在的問題不僅僅與功能分解思想有關(guān)，還和下面這種想法有關(guān)，即直到分解到功能的原始層次才描述一個進程。在該層次上規(guī)格說明的長度應(yīng)該少于一頁。

所得到的結(jié)果難以理解――所需要的更高層次的行為如何從這些原始轉(zhuǎn)換中顯現(xiàn)出來，這一點很難搞清楚。另外，功能結(jié)構(gòu)如何映射到物理結(jié)構(gòu)上來滿足性能和其他質(zhì)量方面的要求并不是特別明顯。這產(chǎn)生了一種自相矛盾情況，我們一直進行分解直到達到了能夠"解決問題"（原始層次）的那一層，但是，這些原始層是否能夠?qū)嶋H上協(xié)同工作以滿足更高層的目標(biāo)卻并不清楚或者可以被證明。沒有辦法以這種方式來考慮非功能性需求。從總體上講，構(gòu)架和基礎(chǔ)設(shè)施（通訊，操作系統(tǒng)等等）都應(yīng)該隨著分解而不斷演進，并且每一次分解都應(yīng)該對其它分解產(chǎn)生影響。

那么 Bauhaus 規(guī)則"形式服從功能"又如何呢？ 有許多好的設(shè)計源自功能主義方法，但也不乏一些不良設(shè)計。例如，隨處可見的平屋頂結(jié)構(gòu)的使用。如果您只關(guān)心屋頂?shù)墓δ�，并且將其完全設(shè)計為居民所需的一個房蓋，那么至少在一些特定的領(lǐng)域中是不能夠令人滿意的 。這種屋頂很難防水，并且容易積雪。

現(xiàn)在這些問題可以解決了，但是在一個更大的范圍內(nèi)而不是在您已經(jīng)選擇的不同設(shè)計中。盡管看上去有些過時，但是形式還是應(yīng)該服從所有的功能和非功能性需求，以及后續(xù)的美學(xué)要求。架構(gòu)師面對的問題經(jīng)常是非功能性需求經(jīng)常表達模糊，并且過多的依賴于架構(gòu)師的"事情應(yīng)該是這樣"的經(jīng)驗。因此如果功能分解僅僅用來驅(qū)動構(gòu)架（即分解產(chǎn)生了幾個向下的層次并且功能的原始層次與"模塊"一一匹配）和定義其接口，那么將一無是處。

像這樣的考慮使我確信，在完成構(gòu)架工作之前，將用例向下分解到標(biāo)準(zhǔn)化的水平（這可以通過類的協(xié)作來實現(xiàn)），這沒有任何意義。對于一定規(guī)模的系統(tǒng)而言，這些分解確實必要，（參見 Jacobson 97）但是分解的標(biāo)準(zhǔn)和實施過程至關(guān)重要――特別是當(dāng)功能分解不是足夠好的時候。

系統(tǒng)考慮
系統(tǒng)工程師完成功能分析、功能分解和功能分配工作（當(dāng)綜合一項設(shè)計時），但是功能并不是系統(tǒng)構(gòu)架的驅(qū)動因素，一個專門的工程師團隊能夠在評估不同的設(shè)計方面做出貢獻。IEEE Std 1220，系統(tǒng)工程過程的應(yīng)用和管理標(biāo)準(zhǔn)（Standard for Application and Management of the Systems Engineering Process）在 6.3 節(jié)中描述了功能分解的使用，功能分析（Functional Analysis）在 6.3.1 節(jié)，功能分解（Functional Decomposition），和系統(tǒng)產(chǎn)品解決方案等綜合在 6.5 節(jié)中。6.5.1 節(jié)包含了一些特別有趣的內(nèi)容，分組（Group）功能和分配（Allocate）功能，6.5.2 節(jié)是物理解決方案的選擇（Physical Solution Alternatives）。在 6.3.1 節(jié)中指出，分解是用來清晰地理解系統(tǒng)必須完成哪些功能，并且一般情況下一層分解足夠了。

注意，功能分解的目的并不是為系統(tǒng)定型（由綜合工作來來完成定型），而是理解和溝通系統(tǒng)必須完成什么――功能模型是能夠完成這些的好的方式。在綜合中，子功能首先被分配給解決方案的結(jié)構(gòu)，然后評估這個解決方案――必須考慮所有的需求。這種方法和多層功能分解之間的不同之處在于：在每一層都試圖描繪所要求的行為，并且在決定是否該行為在下一層需要被精化，以及分配到更低層的組件中之前，找到一種解決方案來實現(xiàn)它 。

從中可以得出一個結(jié)論是，在任何層次上使用數(shù)百個用例來描述行為是沒有必要的�？赡芎苌倭康耐獠坑美�（和相關(guān)場景）能夠恰當(dāng)?shù)馗采w所要描述的對象（系統(tǒng)、子系統(tǒng)、類）的行為。我應(yīng)該講一下我所說的外部用例是指什么。舉一個由子系統(tǒng)組成的系統(tǒng)例子，這些子系統(tǒng)又由類組成。描述系統(tǒng)及其參與者的用例，我稱之為外部用例。子系統(tǒng)或許有它們自己的用例――它們對于系統(tǒng)來說是內(nèi)部用例，但是對于子系統(tǒng)來說是外部用例。終用來構(gòu)建一個龐大系統(tǒng)（大于 100 萬行代碼）的外部用例和內(nèi)部用例的總數(shù)，可能數(shù)以百計，因為這樣規(guī)模的系統(tǒng)將包含其它系統(tǒng)，或者至少包含子系統(tǒng)。

對結(jié)構(gòu)和規(guī)模的假定

用例的數(shù)量
在 IBM Rational 中，我們認為用例的數(shù)量應(yīng)該很�。�10－50 個），并且認識到大量（超過100 個）的用例表明可能需要進行功能分解，在功能分解中用例對于參與者毫無價值。然而，在實際項目中我們?nèi)匀荒軌虬l(fā)現(xiàn)大量的用例，并不總是"糟糕的"，至少在層次上是全面的。例如，在 Rational 內(nèi)部的電子郵件中，作者引用了一個 Ericsson 例子：

    Ericsson，對大部分的新一代電話交換機的建模，估計要多于 600 個人年（多，3 到400 個開發(fā)人員），200 個用例（使用不止一層用例，請參考"互連系統(tǒng)構(gòu)成的系統(tǒng)"）對于一個超過 600 人年（這有多大呢？150萬行 C++ 代碼嗎？）的系統(tǒng)，恐怕用例分析會限于子系統(tǒng)上面的某一層上（也是說，如果一個人定義了一個 7000 到 10000 行代碼的子系統(tǒng)），否則用例的數(shù)量還會增加。

因此，我仍然強調(diào)這種觀點即少量的外部用例是適合的。為了匹配我曾經(jīng)建議的結(jié)構(gòu)和規(guī)格，我斷言 10 個外部用例，每個用例帶有 30 個相關(guān)場景 ，這對于描述行為是合適的 。如果實際中用例的數(shù)量超過了 10 個，并且確實是外部用例，那么它們所描述的系統(tǒng)要比相應(yīng)的規(guī)范系統(tǒng)具有更大規(guī)模。在下文中我將提供一些支持理由來說明這些數(shù)字是合理的。

結(jié)構(gòu)分層
建議的結(jié)構(gòu)分層如下：

4 - 多個系統(tǒng)組成的系統(tǒng)
3 - 系統(tǒng)
2 - 子系統(tǒng)組
1 - 子系統(tǒng)
0 - 類