本文描述了基于用例进行评估的一个框架。为了使描述更加具体，本文为框架的参数选择了一些值，尽管这些值有待于论证，但它们并不总是错误的。像往常一样，随着数据的搜集，这种估计应该根据实际情况和重新估计的参数值进行测试。这种框架对于不同种类的系统考虑了用例层次、规模和复杂度等思想，并且不再采取细粒度的功能分解。为减轻计算的负担，对于诸如 Estimate Professional 这样的工具，可以构建一个前端，从而提供一种基于用例的规模输入的不同的方法。名易软件-建筑系统

　　问题名易软件-系统文章

　　直观上看起来似乎根据用例模型的特征，可以对开发工作所需的规模和工作量进行估计。毕竟，用例模型捕获了功能性需求，那么难道不应该有基于等价于功能点的用例吗?这里存在许多困难：项目经理博客

　　有许多不同的用例规格样式和形式，很难定义一个度量标准，例如，某人可能希望能够度量用例的长度;名易软件-建筑工程

　　用例应该代表外部参与者对于系统的观点，因此，500,000 sloc 系统的用例就与 5,000 sloc 子系统的用例在完全不同的层次上(Cockburn 97 讨论了层次和目标的概念);名易软件-建筑工程项目管理系统文章

　　用例可能在复杂性方面不同，编写时是显式的，实现时又是隐式的。blog

　　用例应该从参与者的角度来描述行为，但是这可能相当复杂，特别是当系统具有状态时(绝大多数情况是这样的)。所以描述这种行为需要系统的模型(在实现它们之前)。当试图捕获行为本质时，这将导致过多的功能分解层次和细节。名易软件-建筑工程项目管理系统

　　所以，为了能够进行评估，是否有必要实现一些种类的用例呢?或许是对于直接根据用例进行估计的期望过高，并且在功能点和用例点的概念之间直接划等号对我们产生了误导。功能点数量的计算无论如何都需要一个系统模型。从用例描述中派生的功能点需要达到与用例表达一致的层次，并且只有达到该层次时，我们才能够对功能点的数量有信心。Fetcke 97 描述了一种从用例到功能点的映射，但是，用例的层次必须适当，这样映射才能有效。其他的方法使用基于类或基于对象的度量标准作为来源，PRICE Object Points 就是一个这样的例子(Minkiewicz 96)。名易软件-建筑工程项目管理系统

　　其他工作training

　　在描述和形式化用例方面的工作相当完备――Hurlbut 97 对此有很好的概括。而从用例中派生估计的度量标准却寥寥无几。Graham 95 和 Graham 98 中包含了对于用例相当严格的批评(但是我并不完全理解为什么他认为他的想法和用例是大相径庭的)，并且建议将"任务场景"作为克服用例问题的方法――包括它们的变化的长度和复杂度。Graham 的"原子任务场景"是"任务点"度量收集的基础。原子任务场景存在的问题是它处于低层：根据 Graham的说法，它最理想的情况是作为一个单一的句子，并且如果仅仅使用本领域的术语那么不能更进一步进行分解。Graham 的"根任务"包含一个或者更多的原子任务场景，并且每一个根任务"在初始化计划的类中，与一个系统操作正好对应" (Graham 98)。这些根任务在我看来似乎非常像低层用例，并且这些原子任务场景如同是这样的用例中的步骤。然而，这种层次方面的问题仍然没有解决。training

　　Karner(Karner 93)、Major(Major 98)、Armour，以及Catherwood(Armour 96)和 Thomson(Thomson 94)完成了其他方面的工作。Karner 的论文中指出了计算用例点的一种方法，但是该方法仍然假设这些用例是以一种通过类可以实现的方式来表达的(例如，在一种更合适的细节层次上而不是子系统上)。

　　那么，我们应该不使用用例来估计而依赖于所实现的分析和设计吗?这个问题妨碍了做出估计的能力，并且无法满足已经采取该技术的项目管理者的要求――需要尽早估计并且不得不使用其他方法。对于项目管理者来说，为了做项目规划，最好能够尽早获得评估，然后反复对其进行精化，而不是拖延评估并且毫无头绪地进行工作。名易软件-建筑工程项目管理系统

　　本文中描述了一个框架，在该框架中可以使用任何层次的用例来形成工作量估计。为了展示这些观点，本文描述了一些简单的规范结构，这些结构具有相关的一定实践基础上的维度和规模。本文中大多是大胆的(或者应该说缺乏根据的)推测，因为我没有其他的方法来解决这个领域中缺少的工作和数据的问题。本文引用了"互连系统构成的系统"思想。training

　　接下来，我将暂时撇开主题来介绍一些将我引入本文主题的一些背景想法。名易软件-建筑工程项目管理系统

　　避免功能分解吗?名易软件-建筑工程项目管理系统