基于用例的工作量估计.pdfVIP

基于用例的工作量估计 中国 [选择] 使用条款 首页 产品 服务与解决方案 支持与下载 个性化服务 developerWorks 中国 Rational developerWorks 基于用例的工作量估计 中国 本文内容包括: 问题 级别: 初级 文档选项 其他工作 将此页作为电子邮件发 避免功能分解吗？ John Smith, 技术工程师 送 系统考虑 对结构和规模的假定 2005 年 1 月 01 日 拓展 Tomcat 应用 分层结构中组件的大 下载 IBM 开源 J2EE 小 本文描述了基于用例进行评估的一个框架。为了使描述更加具体，本文为框架的参数选择了一些值， 应用服务器 WAS CE 工作量估计 尽管这些值有待于论证，但它们并不总是错误的。像往常一样，随着数据的搜集，这种估计应该根据 新版本 V1.1 结束语 实际情况和重新估计的参数值进行测试。这种框架对于不同种类的系统考虑了用例层次、规模和复杂 参考资料 度等思想，并且不再采取细粒度的功能分解。为减轻计算的负担，对于诸如 Estimate Professional 关于作者 这样的工具，可以构建一个前端，从而提供一种基于用例的规模输入的不同的方法。 对本文的评价 问题 相关链接: Rational 技术文档库 直观上看起来似乎根据用例模型的特征，可以对开发工作所需的规模和工作量进行估计。毕竟，用例模型捕获了功能性需求，那么难道 Rational Edge 电子 不应该有基于等价于功能点的用例吗？这里存在许多困难： 月刊中文版 ● 有许多不同的用例规格样式和形式，很难定义一个度量标准，例如，某人可能希望能够度量用例的长度； ● 用例应该代表外部参与者对于系统的观点，因此，500,000 sloc 系统的用例就与 5,000 sloc 子系统的用例在完全不同的层次 上（Cockburn 97 讨论了层次和目标的概念）； ● 用例可能在复杂性方面不同，编写时是显式的，实现时又是隐式的。 ● 用例应该从参与者的角度来描述行为，但是这可能相当复杂，特别是当系统具有状态时（绝大多数情况是这样的）。所以描述这 种行为需要系统的模型（在实现它们之前）。当试图捕获行为本质时，这将导致过多的功能分解层次和细节。 所以，为了能够进行评估，是否有必要实现一些种类的用例呢？或许是对于直接根据用例进行估计的期望过高，并且在功能点和用例点 的概念之间直接划等号对我们产生了误导。功能点数量的计算无论如何都需要一个系统模型。从用例描述中派生的功能点需要达到与用 例表达一致的层次，并且只有达到该层次时，我们才能够对功能点的数量有信心。Fetcke 97 描述了一种从用例到功能点的映射，但 是，用例的层次必须适当，这样映射才能有效。其他的方法使用基于类或基于对象的度量标准作为来源，PRICE Object Point