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

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

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

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

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

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

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

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

接下來(lái)，我將暫時(shí)撇開主題來(lái)介紹一些將我引入本文主題的一些背景想法。

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

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

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

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

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

系統(tǒng)考慮
系統(tǒng)工程師完成功能分析、功能分解和功能分配工作（當(dāng)綜合一項(xiàng)設(shè)計(jì)時(shí)），但是功能并不是系統(tǒng)構(gòu)架的驅(qū)動(dòng)因素，一個(gè)專門的工程師團(tuán)隊(duì)能夠在評(píng)估不同的設(shè)計(jì)方面做出貢獻(xiàn)。IEEE Std 1220，系統(tǒng)工程過(guò)程的應(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é)中指出，分解是用來(lái)清晰地理解系統(tǒng)必須完成哪些功能，并且一般情況下一層分解足夠了。

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

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

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

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

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

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

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

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