会员登录
会员注册问题
直观上看起来似乎根据用例模型的特征，可以对开发工作所需的规模和工作量进行估计。毕竟，用例模型捕获了功能性需求，那么难道不应该有基于等价于功能点的用例吗?这里存在许多困难：
有许多不同的用例规格样式和形式，很难定义一个度量标准，例如，某人可能希望能够度量用例的长度;
用例应该代表外部参与者对于系统的观点，因此，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 的论文中指出了计算用例点的一种方法，但是该方法仍然假设这些用例是以一种通过类可以实现的方式来表达的(例如，在一种更合适的细节层次上而不是子系统上)。
那么，我们应该不使用用例来估计而依赖于所实现的分析和设计吗?这个问题妨碍了做出估计的能力，并且无法满足已经采取该技术的项目管理者的要求――需要尽早估计并且不得不使用其他方法。对于项目管理者来说，为了做项目规划，最好能够尽早获得评估，然后反复对其进行精化，而不是拖延评估并且毫无头绪地进行工作。