基於用例的工作量估計
本文描述了基於用例進行評估的乙個框架。為了使描述更加具體，本文為框架的引數選擇了一些值，儘管這些值有待於論證，但它們並不總是錯誤的。像往常一樣，隨著資料的蒐集，這種估計應該根據實際情況和重新估計的引數值進行測試。
這種框架對於不同種類的系統考慮了用例層次、規模和複雜度等思想，並且不再採取細粒度的功能分解。為減輕計算的負擔，對於諸如 estimate professional 這樣的工具，可以構建乙個前端，從而提供一種基於用例的規模輸入的不同的方法。
問題直觀上看起來似乎根據用例模型的特徵，可以對開發工作所需的規模和工作量進行估計。畢竟，用例模型捕獲了功能性需求，那麼難道不應該有基於等價於功能點的用例嗎？這裡存在許多困難：
● 有許多不同的用例規格樣式和形式，很難定義乙個度量標準，例如，某人可能希望能夠度量用例的長度；
● 用例應該代表外部參與者對於系統的觀點，因此，500,000 sloc 系統的用例就與 5,000 sloc 子系統的用例在完全不同的層次上（cockburn 97 討論了層次和目標的概念）；
● 用例可能在複雜性方面不同，編寫時是顯式的，實現時又是隱式的。
● 用例應該從參與者的角度來描述行為，但是這可能相當複雜，特別是當系統具有狀態時（絕大多數情況是這樣的）。所以描述這種行為需要系統的模型（在實現它們之前）。當試圖捕獲行為本質時，這將導致過多的功能分解層次和細節。
所以，為了能夠進行評估，是否有必要實現一些種類的用例呢？或許是對於直接根據用例進行估計的期望過高，並且在功能點和用例點的概念之間直接劃等號對我們產生了誤導。功能點數量的計算無論如何都需要乙個系統模型。
從用例描述中派生的功能點需要達到與用例表達一致的層次，並且只有達到該層次時，我們才能夠對功能點的數量有信心。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 de***position），和系統產品解決方案等綜合在 6.5 節中。
6.5.1 節包含了一些特別有趣的內容，分組（group）功能和分配（allocate）功能，6.
5.2 節是物理解決方案的選擇（physical solution alternatives）。在 6.
3.1 節中指出，分解是用來清晰地理解系統必須完成哪些功能，並且一般情況下一層分解就足夠了。
注意，功能分解的目的並不是為系統定型（由綜合工作來來完成定型），而是理解和溝通系統必須完成什麼――功能模型是能夠完成這些的好的方式。在綜合中，子功能首先被分配給解決方案的結構，然後評估這個解決方案――必須考慮所有的需求。這種方法和多層功能分解之間的不同之處在於：
在每一層都試圖描繪所要求的行為，並且在決定是否該行為在下一層需要被精化，以及分配到更低層的元件中之前，找到一種解決方案來實現它 。
從中可以得出乙個結論就是，在任何層次上使用數百個用例來描述行為是沒有必要的。可能很少量的外部用例（和相關場景）就能夠恰當地覆蓋所要描述的物件（系統、子系統、類）的行為。我應該講一下我所說的外部用例是指什麼。
舉乙個由子系統組成的系統例子，這些子系統又由類組成。描述系統及其參與者的用例，我稱之為外部用例。子系統或許有它們自己的用例――它們對於系統來說是內部用例，但是對於子系統來說是外部用例。
最終用來構建乙個龐大系統（大於 100 萬行**）的外部用例和內部用例的總數，可能數以百計，因為這樣規模的系統將包含其它系統，或者至少包含子系統。
對結構和規模的假定
用例的數量
在 ibm rational 中，我們認為用例的數量應該很小（10－50 個），並且認識到大量（超過100 個）的用例表明可能需要進行功能分解，在功能分解中用例對於參與者毫無價值。然而，在實際專案中我們仍然能夠發現大量的用例，並不總是"糟糕的"，至少在層次上是全面的。例如，在 rational 內部的電子郵件中，作者引用了乙個 ericsson 例子：
● ericsson，對大部分的新一代**交換機的建模，估計要多於 600 個人年（最多，3 到400 個開發人員），200 個用例（使用不止一層用例，請參考"互連系統構成的系統"）對於乙個超過 600 人年（這有多大呢？150萬行 c++ **嗎？）的系統，恐怕用例分析會限於子系統上面的某一層上（也就是說，如果乙個人定義了乙個 7000 到 10000 行**的子系統），否則用例的數量還會增加。
因此，我仍然強調這種觀點即少量的外部用例是適合的。為了匹配我曾經建議的結構和規格，我斷言 10 個外部用例，每個用例帶有 30 個相關場景 ，這對於描述行為是合適的 。如果實際中用例的數量超過了 10 個，並且確實是外部用例，那麼它們所描述的系統要比相應的規範系統具有更大規模。
在下文中我將提供一些支援理由來說明這些數字是合理的。
結構分層
建議的結構分層如下：
● 4 - 多個系統組成的系統
● 3 - 系統
● 2 - 子系統組
● 1 - 子系統
● 0 - 類
類和子系統在 uml 中定義為；在 uml 中更大的聚合是子系統（包含子系統），為了更簡單的進行描述，我進行了不同的命名。對於那些知道 2167 和 498 軍方標準（稱子系統為 csc，稱類為 csu）中的術語的人來說，子系統組（subsystemgroup）的規模用 csci -來表示。我記得，經過 2167 天的關於 ada 的結構應該對映到哪一層次的爭論後，塵埃落定，ada 包通常對映為 csu。
我並不建議系統必須嚴格的遵循這種層次結構，還將存在層次之間的混合，這種層次結構使我能夠更好地了解規模對於每個用例工作量的影響。
工作量說明
一.商品部經理 1名 工作內容 1 在服務區主任的領導下，根據上級下達的年度經營指標，制定本部門的年度經營工作計畫，每半月的對前期的經營情況及商品品種銷售趨勢做統計，採取有效的銷售措施，不斷擴大業務範圍，努力提高經濟效益。2 根據行業規則和服務區實際情況，建立本部門管理辦法，實施細則，操作流程和各崗...
工作量問題
一元一次方程應用題專題 工作量問題 一 常用公式 一般情況下把工作總量看成單位1 工作量 工作效率 工作時間工作效率 工作量 工作時間 工作時間 工作量 工作效率完成某項任務的各工作量的和 總工作量 1 如 一項工程甲隊需30天完成任務，則甲每天完成工作量的，則工作效率為 如果乙隊需要20天完成任務...
教師工作量證明
茲證明我校陸秀紅老師，在2010 2011學年度第一學期中，擔任五音 六音 六英 六語 六品 六體 六健等課程教學任務，周課時20節。同時兼任學校教導主任 資料員 農遠工程管理員 六年級班主任等職能工作負責人職務。經調查確定，該教師本學期工作量飽滿，工作認真負責，教學與管理業務熟練，成效良好。六安市...