基于用例的工作量估计
| 級別: 初級 John Smith, 技術工程師 2005 年 1 月 01 日 本文描述了基于用例進行評估的一個框架。為了使描述更加具體，本文為框架的參數選擇了一些值，盡管這些值有待于論證，但它們并不總是錯誤的。像往常一樣，隨著數據的搜集，這種估計應該根據實際情況和重新估計的參數值進行測試。這種框架對于不同種類的系統考慮了用例層次、規模和復雜度等思想，并且不再采取細粒度的功能分解。為減輕計算的負擔，對于諸如 Estimate Professional 這樣的工具，可以構建一個前端，從而提供一種基于用例的規模輸入的不同的方法。問題 直觀上看起來似乎根據用例模型的特征，可以對開發工作所需的規模和工作量進行估計。畢竟，用例模型捕獲了功能性需求，那么難道不應該有基于等價于功能點的用例嗎？這里存在許多困難：
所以，為了能夠進行評估，是否有必要實現一些種類的用例呢？或許是對于直接根據用例進行估計的期望過高，并且在功能點和用例點的概念之間直接劃等號對我們產生了誤導。功能點數量的計算無論如何都需要一個系統模型。從用例描述中派生的功能點需要達到與用例表達一致的層次，并且只有達到該層次時，我們才能夠對功能點的數量有信心。Fetcke 97 描述了一種從用例到功能點的映射，但是，用例的層次必須適當，這樣映射才能有效。其他的方法使用基于類或基于對象的度量標準作為來源，PRICE Object Points 就是一個這樣的例子(Minkiewicz 96)。
其他工作 在描述和形式化用例方面的工作相當完備――Hurlbut 97 對此有很好的概括。而從用例中派生估計的度量標準卻寥寥無幾。Graham 95 和 Graham 98 中包含了對于用例相當嚴格的批評（但是我并不完全理解為什么他認為他的想法和用例是大相徑庭的），并且建議將"任務場景"作為克服用例問題的方法――包括它們的變化的長度和復雜度。Graham 的"原子任務場景"是"任務點"度量收集的基礎。原子任務場景存在的問題是它處于低層：根據 Graham的說法，它最理想的情況是作為一個單一的句子，并且如果僅僅使用本領域的術語那么不能更進一步進行分解。Graham 的"根任務"包含一個或者更多的原子任務場景，并且每一個根任務"在初始化計劃的類中，與一個系統操作正好對應" (Graham 98)。這些根任務在我看來似乎非常像低層用例，并且這些原子任務場景如同是這樣的用例中的步驟。然而，這種層次方面的問題仍然沒有解決。 Karner（Karner 93）、Major（Major 98）、Armour，以及Catherwood（Armour 96）和 Thomson（Thomson 94）完成了其他方面的工作。Karner 的論文中指出了計算用例點的一種方法，但是該方法仍然假設這些用例是以一種通過類可以實現的方式來表達的（例如，在一種更合適的細節層次上而不是子系統上）。 那么，我們應該不使用用例來估計而依賴于所實現的分析和設計嗎？這個問題妨礙了做出估計的能力，并且無法滿足已經采取該技術的項目管理者的要求――需要盡早估計并且不得不使用其他方法。對于項目管理者來說，為了做項目規劃，最好能夠盡早獲得評估，然后反復對其進行精化，而不是拖延評估并且毫無頭緒地進行工作。 本文中描述了一個框架，在該框架中可以使用任何層次的用例來形成工作量估計。為了展示這些觀點，本文描述了一些簡單的規范結構，這些結構具有相關的一定實踐基礎上的維度和規模。本文中大多是大膽的（或者應該說缺乏根據的）推測，因為我沒有其他的方法來解決這個領域中缺少的工作和數據的問題。本文引用了"互連系統構成的系統"思想。 接下來，我將暫時撇開主題來介紹一些將我引入本文主題的一些背景想法。
避免功能分解嗎？ 功能分解的思想對于軟件開發領域中的許多人來說像一個"詛咒"。我對功能分解的體驗更是其中的極端（在一個很大的數據流圖中有 3000 個原始轉換，五層或者六層深，在除了基礎設施層外沒有使用任何構架的思想的情況下完成），讓我感到異常悲觀。在該用例中存在的問題不僅僅與功能分解思想有關，還和下面這種想法有關，即直到分解到功能的原始層次才描述一個進程。在該層次上規格說明的長度應該少于一頁。 所得到的結果難以理解――所需要的更高層次的行為如何從這些原始轉換中顯現出來，這一點很難搞清楚。另外，功能結構如何映射到物理結構上來滿足性能和其他質量方面的要求并不是特別明顯。這就產生了一種自相矛盾情況，我們一直進行分解直到達到了能夠"解決問題"（原始層次）的那一層，但是，這些原始層是否能夠實際上協同工作以滿足更高層的目標卻并不清楚或者可以被證明。沒有辦法以這種方式來考慮非功能性需求。從總體上講，構架和基礎設施（通訊，操作系統等等）都應該隨著分解而不斷演進，并且每一次分解都應該對其它分解產生影響。 那么 Bauhaus 規則"形式服從功能"又如何呢？ 有許多好的設計源自功能主義方法，但也不乏一些不良設計。例如，隨處可見的平屋頂結構的使用。如果您只關心屋頂的功能，并且將其完全設計為居民所需的一個房蓋，那么至少在一些特定的領域中是不能夠令人滿意的 。這種屋頂很難防水，并且容易積雪。 現在這些問題可以解決了，但是在一個更大的范圍內而不是在您已經選擇的不同設計中。盡管看上去有些過時，但是形式還是應該服從所有的功能和非功能性需求，以及后續的美學要求。架構師面對的問題經常是非功能性需求經常表達模糊，并且過多的依賴于架構師的"事情就應該是這樣"的經驗。因此如果功能分解僅僅用來驅動構架（即分解產生了幾個向下的層次并且功能的原始層次與"模塊"一一匹配）和定義其接口，那么將一無是處。 像這樣的考慮使我確信，在完成構架工作之前，將用例向下分解到標準化的水平（這可以通過類的協作來實現），這沒有任何意義。對于一定規模的系統而言，這些分解確實必要，（參見 Jacobson 97）但是分解的標準和實施過程至關重要――特別是當功能分解不是足夠好的時候。
系統考慮 系統工程師完成功能分析、功能分解和功能分配工作（當綜合一項設計時），但是功能并不是系統構架的唯一驅動因素，一個專門的工程師團隊就能夠在評估不同的設計方面做出貢獻。IEEE Std 1220，系統工程過程的應用和管理標準（Standard for Application and Management of the Systems Engineering Process）在 6.3 節中描述了功能分解的使用，功能分析（Functional Analysis）在 6.3.1 節，功能分解（Functional Decomposition），和系統產品解決方案等綜合在 6.5 節中。6.5.1 節包含了一些特別有趣的內容，分組（Group）功能和分配（Allocate）功能，6.5.2 節是物理解決方案的選擇（Physical Solution Alternatives）。在 6.3.1 節中指出，分解是用來清晰地理解系統必須完成哪些功能，并且一般情況下一層分解就足夠了。 注意，功能分解的目的并不是為系統定型（由綜合工作來來完成定型），而是理解和溝通系統必須完成什么――功能模型是能夠完成這些的好的方式。在綜合中，子功能首先被分配給解決方案的結構，然后評估這個解決方案――必須考慮所有的需求。這種方法和多層功能分解之間的不同之處在于：在每一層都試圖描繪所要求的行為，并且在決定是否該行為在下一層需要被精化，以及分配到更低層的組件中之前，找到一種解決方案來實現它 。 從中可以得出一個結論就是，在任何層次上使用數百個用例來描述行為是沒有必要的。可能很少量的外部用例（和相關場景）就能夠恰當地覆蓋所要描述的對象（系統、子系統、類）的行為。我應該講一下我所說的外部用例是指什么。舉一個由子系統組成的系統例子，這些子系統又由類組成。描述系統及其參與者的用例，我稱之為外部用例。子系統或許有它們自己的用例――它們對于系統來說是內部用例，但是對于子系統來說是外部用例。最終用來構建一個龐大系統（大于 100 萬行代碼）的外部用例和內部用例的總數，可能數以百計，因為這樣規模的系統將包含其它系統，或者至少包含子系統。
對結構和規模的假定 用例的數量 在 IBM Rational 中，我們認為用例的數量應該很小（10－50 個），并且認識到大量（超過100 個）的用例表明可能需要進行功能分解，在功能分解中用例對于參與者毫無價值。然而，在實際項目中我們仍然能夠發現大量的用例，并不總是"糟糕的"，至少在層次上是全面的。例如，在 Rational 內部的電子郵件中，作者引用了一個 Ericsson 例子：
因此，我仍然強調這種觀點即少量的外部用例是適合的。為了匹配我曾經建議的結構和規格，我斷言 10 個外部用例，每個用例帶有 30 個相關場景 ，這對于描述行為是合適的 。如果實際中用例的數量超過了 10 個，并且確實是外部用例，那么它們所描述的系統要比相應的規范系統具有更大規模。在下文中我將提供一些支持理由來說明這些數字是合理的。 結構分層 建議的結構分層如下： 4 - 多個系統組成的系統 類和子系統在 UML 中定義為；在 UML 中更大的聚合是子系統（包含子系統），為了更簡單的進行描述，我進行了不同的命名。對于那些知道 2167 和 498 軍方標準（稱子系統為 CSC，稱類為 CSU）中的術語的人來說，子系統組（subsystemGroup）的規模用 CSCI -來表示。我記得，經過 2167 天的關于 Ada 的結構應該映射到哪一層次的爭論后，塵埃落定，Ada 包通常映射為 CSU。我并不建議系統必須嚴格的遵循這種層次結構，還將存在層次之間的混合，這種層次結構使我能夠更好地了解規模對于每個用例工作量的影響。 在每一層上都會有用例（盡管對于單個的類可能不是這樣），但并不是單純的大量細節堆砌 ，而是用例針對那個層上的每個組件（例如子系統、子系統組，等等）。在上文中我曾斷言對于每一層的每一個組件都有 10 個用例――如果用例的描述平均是 10 頁，那么將會給出一個潛在的、大約 100 頁長度的說明文檔（還要加上類似的或者少一些的關于非系統性需求的相應說明），這是 Stevens 98 提倡的數字，并且和Royce98推薦的數字很接近。但是為什么是 10 個用例呢？為了得出這個數字，基于對每一個子系統的類的數量、類的規模、操作規模等等我認為的合理的規模，我進行了自下向上的推理。這些和其他假設共同搜集在下表中供大家引用。 我沒有大量的經驗數據－貫穿文中的是瑣碎的、分散的數據，Lorentz 94 和 Henderson-Sellers 96 有一些數據，我也有一些在澳大利亞的項目中得出的數據，主要是在軍用航空航空領域。任何情況下，在這個階段，將框架或多或少的定位到合適的位置是非常重要的。 分層結構中組件的大小 這里我應該指出的是，我曾經使用代碼行來度量組件的大小，但許多人不喜歡這種度量。這些是 C++（或者相同層次的語言）代碼行，所以，要回到功能點非常容易。 在容器中的類的數目和能表達的行為的豐富性之間肯定有許多關系。我選擇了 8 個類/子系統 ，8 個子系統/子系統組，8 個子系統組/子系統，等等。那么為什么是 8 個呢？ 1. 它在 7 或－2 之間； 2. 由于每個類有 850 slocs（每 70 slocs 有 12 個操作）的 C++代碼，它得出了一個子系統的規模是 7000 slocs－一個可以由小的團隊（3－7人）在 4－9 個月就能夠交付的功能/代碼的程序塊，其中系統的迭代長度就該調整到 30 萬－100 萬slocs (RUP 99) 的范圍內 。 那么，多少用例能夠表達八個類的行為（外部的）？，哪些是屬于子系統的并且已經被定位在子系統中了？決定豐富性的原因不僅僅是用例的數量，還有每個用例的場景數量。現在，并沒有多少方法來指導場景/用例擴展――在Booch 98中，Grady Booch 指出"存在一個從用例到場景的"膨脹系統"，一個復雜度適當的系統中可能有幾十個用于捕獲系統行為的用例，每個用例可能具有幾十個場景…."，Bruce Powel Douglass 在 Douglass 99 中指出，"….為了詳細描述用例需要很多場景，通常需要1打到幾打"。我選擇了 30 個場景/用例――這處于"幾打"的較低的一邊，但是 Rechtin（在 Rechtin 91中）指出，工程師能夠處理 5 到 10 個互相作用的變量（對于這個變量，我解釋為互相協作的 5 到 10 個類）并且 10 到 50 種交互（我解釋為場景）。以這種方式解釋，多個用例即為該變量空間的多個實例。 因此，10 個用例，每個用例 30 個場景，也就是說一共 300 個場景（后面將導致大約 300 個測試用例）對于覆蓋 8 個類的有意義的行為來說已經足夠了。是否有其他的跡象表明這是個合理的數字呢？如果應用 Pareto 的 80-20 規則，那么20%的類將表達80%的功能，同樣，80% 的功能將被每個類中20%的操作來表達。讓我們保守的說，我們需要20%的類（等）來達到75%的功能并且通過這點來構建一個 Pareto 分布圖。（圖 1） 圖 1: 一個 Pareto 式樣的分布圖 如果我們想要描述 80% 的系統行為，并且將 Pareto 規則應用到類、操作和場景數量方面，那么對于每一者都需要描述其行為的 93%(0.933＝ 0.8)－－也就是對于每一個都需要 50%，例如，4 個類和 5 個操作(= (12 － 2 構建器/析構器)/2)。節點樹的不同分叉的數量可能達到數千個（其中節點樹用來代表4個類及每個類5個操作的執行模式）。我為每個節點創建了 1 到 3 個鏈接，假設在頂層有 10 個操作（接口操作）的層次結構，并且形成了一個三層的樹。這將會有 1000 條路徑或者場景。所以，500 個場景將會得到 93% 的覆蓋。使用 300 個場景（用相同的假定）我們可以得到 73% 的覆蓋。根據一個選定的算法，可以對這個樹進行修剪，從而刪除冗余的行為說明，甚至更少的數量就完全可以符合要求。 達到該目的的另一個方法就是研究一下對于 7000 slocs 的 C++代碼需要多少測試用例（從場景派生而來）。這些測試用例不受單元測試層次的制約，并且在 Jones 91 和 Boeing 777 項目中有許多證據表明這個數字是安全的，至少它符合實踐。這些來源表明在 250 到 280 之間是合適的。在一個完全不同的層次上，加拿大自動空中交通系統（Canadian Automated Air Traffic System ，CAATS)項目使用了 200 項系統測試（我私下里獲悉的）。 用例的規模 用例應該具有多大規模呢？是否應該足夠大以及表達足夠的細節才能表達所需要的行為－－這取決于與系統有關的用例復雜性、內部用例和外部用例。－－這里我們就應該描述多少系統的內部動作來深入探討一下這個問題。很明顯，從外部行為描述來構建系統，要求將輸出與輸入關聯起來。例如，如果行為對歷史記錄敏感并且很復雜，那么在沒有系統內部的一些概念模型及行為的動作時，就很難描述它。注意，沒有必要描述一個系統是如何從內部構建的－－任何滿足非功能性需求和匹配模型行為的設計就能夠滿足要求。 UML 1.3 中提供的定義是："用例【類】：一個系統可以執行的動作（包括變體）序列的說明，其中這些動作與系統參與者進行交互"。對復雜的行為的內部動作，可能合理的采用這個定義也可以在實現階段再進行定義――這對于最終用戶來說是個更遠的步驟。業務規則也應該納入到用例中以便約束參與者的行為（例如，在一個ATM系統中，銀行需要有一條規則：在一次交易中，提取的金額不能超過 500 美元，無論賬號中的余額為多少）。 根據這種解釋，事件的用例流描述的頁數可以為 2－20 。從計算的角度上看，具有簡單行為的系統顯然不需要冗長的描述。或許我們可以認為簡單的商務系統通常用 2 到 10 頁來描述，平均為 5 頁。對于更復雜的系統來說，業務系統和科學系統在 6 到 15 頁之間，平均為 9 頁。復雜的命令和控制系統在 8 到 20 頁之間，平均為 12 頁（這些比率反映了相同規模系統的工作量與類型之間的非線性關系），盡管我沒有數據來支持這種觀點。更富有表達力和描述性的形式（例如狀態機或者活動圖）可能需要更少的篇幅－－我們仍舊傾向于加強文本，所以此處不討論其他形式，畢竟相關資料很少或者根本沒有。 與上述規模有系統差異的開發應該運用乘法規則來計算在這些假設基礎上得出的每個用例的小時數（我建議增加一個 COCOMO -樣式的成本驅動，該驅動是系統類型的（簡單的業務類型、更復雜的類型、命令及控制類型等等）的觀察到的平均規模或建議的平均規模。 用例規模的另一個方面是場景的數量。例如，一個 5 頁長的用例可能是一個具有很多路徑的復雜結構。再一次重申，需要將場景的數量以及這個比例估計為 30（這是我對于每個用例的場景數的初步估計），將其作為成本的驅動因素。 得到的結果是，我們假設基于大約長度為 100 頁說明的用例，對于任何給定層次的外部說明及補充說明來說，都是足夠的。范圍是 20 到 200 頁之間（這些界限是模糊的）。注意，一個系統（子系統組）在最低的層次上的總數是 3－15 頁/ ksloc（簡單的業務系統）到 12－30 頁/ ksloc（復雜的命令和控制系統）。這或許能夠解釋 Royce 98 表中的 14－9 和實際項目之間明顯的矛盾之處，前者的工件所占用的篇幅非常少，而實際項目卻占用了大量的頁。本文的觀點認為規格說明的層次不應受頁數的限制。－－Royce 是正確的，對于大型的、復雜的系統而言，重要內容的說明（如版本聲明）可以達到范圍的上限――200 頁 子系統層次 一個子系統層次看上去像什么呢？這里有一些我用過的簡單的"標準"形式。注意，這些只是用來實現一個系統的概念形式。實際系統的范圍超出了這些形式的集合，并且每個子系統外部用例的總和就是系統全部的外部用例；因此，一個實際的系統可能有超過 10 個外部用例，但是正如我們后面將要看到的那樣，上限并不是無限的。注意，這里并不是建議所有的開發都在它們的描述中使用 4 層用例。小的系統（<5 萬 slocs）可能只用 1 層或者 2 層。 第一層 在第一層，具有通過零個或以上的子系統中的類實現的用例 圖 1: 一個 Pareto 式樣的分布圖 在這一層估計系統（系統具有可通過類來實現的用例）規模的范圍（使用7＋或者－2的概念）：
范圍為 2 到 76 個用例。這是個模糊的界限，至少對于上限來說是這樣的――在該限定下，以這種方式構建一個系統（在這個規模上），永遠也不使用更高層的形式來表達所要求的行為，那么用例的數量應該降到零。如果用例的數字大于零，那么就是畫蛇添足。 第二層 在第二個層次上，我們有一個由 8 個子系統組成的子系統組。我認為這等同于防御性術語中的計算機系統配置項（computer system configuration item ，CSC I)。在這一層，用例是通過子系統的協作來實現的： 在這一層估計系統規模的范圍（使用 7＋或者－2 的概念）：
這就是說，外部用例的范圍是 4 到 66。再次重申，這些只是模糊的界限。 第三層 在第三層，我們具有一個系統（由子系統組構成）。在這一層，用例是通過子系統組的協作來實現的： 在這一層估計系統規模的范圍（使用 7＋或者－2 的概念）：
第四層 在第四層中，我們有一個由系統組成的系統。在這一層，用例是通過系統的協作來實現的： 在這一層估計系統規模的范圍（使用 7＋或者－2 的概念）：
假設更大的聚合也是可能的，但是我實在不想再考慮了！ 每個用例的工作量 通過對每一層的額定的規模的工作量估計，我們可以對每個用例的工作量有一些深入了解。使用 Estimate Professional? 工具 （基于 COCOMO 2 和 Putnam's SLIM 模型），將語言設置為 C++（其他成本驅動因素設置為額定值），然后計算每一個示例系統類型在每個額定規模點的工作量（假設 10 個外部用例），得到表 1。表中描述的 L1 和 L2 范圍考慮到了單個用例的復雜度――使用 COCOMO 的代碼復雜性矩陣通過類比進行估計。在 L2 層，我相信復雜性在被納入系統類型的特征時復雜程度發生變化，因此一個更高層次的復雜命令和控制系統用例，將包含在一個較低的層次上復雜性的混合。在一個按照 log-log 比例的圖上繪制這些數據，得到圖 2。 圖 2: 用例工作量規模圖 從中我們可以看到，150-350 小時/用例（10 2.17-10 2.54）這個原來的 Objectory 數字在 L1 層上很適合，例如，這些用例可以通過類的協作來實現――因此存在一些理由來支持這個數字。然而，它不足以在分析中用來描述所有項目－－我的一位同事曾在電子郵件與我交流時說：它太"片面" 了。
工作量估計 當前的實際系統不能與這些槽（slot）一一匹配。所以，為了幫助了解應該如何描述一個系統，我們將使用從該方法種得出的模糊的界限并將它們繪制出來： Figure 3: 每個層次的規模范圍 從圖 3 中，我們可以看到一個超過 2.2 萬 slocs 的系統最可能是在第一層描述，用例的數量在 2 到 30 之間。在這個規模上，更高的用例數量表明用例的粒度太細了。 規模在 2.2 萬 和 5.4 萬 slocs 之間的系統，應該使用一層用例和兩層用例的混合，用例的數量在 4（都在第二層）和 76 都在第一層）之間，正如上圖所表明的那樣，一般不會出現極限值。 規模在 5.4 萬和 11 萬 slocs 之間的系統，一個結構好的系統完全在第二層進行描述是可能的，用例的數量在 10 到 20 之間；混合起來可能是 L1/L2/L3（1 到 160 個用例，一般不會出現極限值）。 規模在 11 萬 和 37 萬 slocs 之間的系統，可能在第二層和第三層之間，用例的數量在 3（全部在第三層）到 66（全在部第二層）之間。 規模在 37 萬 和 54 萬 slocs之間的系統，如果完全在第三層進行描述，那么用例的數量在 9 到 12之間；混合情況可能是 L2/L3/L4（1 到 100 個用例，一般不會出現極限值）。 規模在 54 萬 和 260 萬 slocs 之間的系統，可能在第三層和第四層之間，用例的數量在 2（全部在第四層）到 60（全部在第三層）之間。 規模超過 260 萬 slocs 的系統，在第四層的用例數量應該在 8 左右。 多少用例才是足夠的? 從一些經驗法則中可以得到一些有趣的觀察結果。有一個問題經常被問及－－多少用例是過量的呢？這個問題實際上意味著在捕獲需求的過程中多少是過量。答案似乎是多于 70 個，甚至對于最大的系統來說，70 這個數字也表明對于設計來說粒度太細了。在 5 到 40 之間是非常合適的，但是這只是數量，而并沒有考慮到層次，不能用來估計規模和工作量。這是初始的數量，對于特殊的層次是合適的。如果一個大型超級系統被分解為系統，系統又被分解為子系統，以此類推，那么需要數以百計的用例。如果直到類的層次達到后才開發用例，那么最終的數量可能是上百個甚至是上千個（對于一個 140 人－年的項目，或者對于每個用例有15個功能點這樣的項目來說是 600 個用例）。然而，作為一個純粹的獨立于設計的用例分解來說，這并不會發生。這些用例起源于 Jacobson 97 中描述的過程，Jacobson 97 中系統層次上的用例被劃分為分配給子系統的行為，其中可以為子系統編寫更低層次的用例（將其他子系統作為參與者）。 工作量估計的過程 如何進行估計呢？這里有許多先決條件：如果不能理解問題的領域、不了解系統的規模和系統構架，以及在哪一階段進行估計，那么就不能夠進行基于用例的估計。 第一次粗略的估計可以根據專家的觀點或者更正式的采用 Wideband Delphi 技術（該技術是Rand 組織在 1948 年發明的，請參考Boehm 81 的描述）。這將使得評估者可以將系統在圖 3 所示的規模范圍中對號入卒。這種部署將提供用例數量的范圍，并且表明表達式的層次（L1, L1/L2 等等）。然后評估者必須基于對現有構架知識和領域中的理解來決定這些用例是否適合某一層（是否毫不相關），或者是不同層次的混合（以事件流的方式來表達）。從這些考慮中可以看到，數據是否不夠健康是顯而易見的－－例如：如果 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,其中
注意這些計算可以作為因子用到諸如 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。 顯然，以第四層為例，與第三層或第四層的用例數量相比，第一層用例的數量的影響微乎其微。
結束語 本文描述了基于用例進行評估的一個框架。為了使描述更加具體，本文為框架的參數選擇了一些值，盡管這些值有待于論證，但它們并不總是錯誤的。像往常一樣，隨著數據的搜集，這種估計應該根據實際情況和重新估計的參數值進行測試。這種框架對于不同種類的系統考慮了用例層次、規模和復雜度等思想，并且不再采取細粒度的功能分解。為減輕計算的負擔，對于諸如 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 |
總結
以上是生活随笔為你收集整理的基于用例的工作量估计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： vs.net2003在代理下的一个奇怪小
- 下一篇： so lovely