如何使用用例点准备报价
4.84/5 (29投票s)
2004年12月14日
30分钟阅读
183711
如何使用用例点准备报价。
目录
- 引言
- 首字母缩略词和缩写
- 假设
- 范围
- 用例点历史和定义
- UCP（用例点）估算步骤
- 示例项目范围（示例数据录入项目）
- 为示例数据录入项目编写用例
- 应用用例点
- 最终报价
- 用例结构很重要
- 使用用例点的优势
- 使用用例点的劣势
- 其他一般实用因素
- 参考文献
- 最后的话
引言
“如果你无法衡量，你就无法计划，而如果你未能计划，你就计划失败。”
报价：这是一份从供应商发送给客户的财务文件，关于将要提供的服务。它也被称为临时的财务文件，用于协商。“供应商向潜在购买者提供的商品或服务的价格、销售条款和描述的陈述，一份投标。当应询价而提供时，报价通常被视为销售要约。”
定义参考来源 此处。
报价是软件生命周期中重要的方面之一。任何过高或过低的预测都会对项目产生很大影响。让我们看看日常业务是如何处理报价的。
“哈里先生接到一份合同，负责将10吨钢材从“X”地运往“Y”地。他有2辆卡车，每辆可载5吨。X地和Y地相距1公里。”
所以，这是哈里基于经验的计算。一辆卡车运送5吨货物1公里是500美元。所以两辆卡车是1000美元。所以报价是1000美元。我想知道，我们能在软件行业做到吗？有100个模块，公司有5名程序员。每个程序员可以在3个月内完成20个模块。程序员的薪水是1000美元。所以，5 X 1000 X 3 = 15000美元。卡车报价的计算比软件报价更令人放心，为什么？
在卡车报价中，哈里遵循了以下流程
- 哈里衡量了他的工作：需要运送10吨。需要行驶1公里。
- 哈里知道所需的工作量：每卡车每公里5吨。
- 所以报价：1000美元。
基本上，哈里衡量了他的工作。他知道他要交付的体积。这是软件行业的挑战。由于软件行业的产出更多是逻辑输出，因此很难线性衡量完成项目所需的精力，从而进行报价。软件行业在过去40年里一直在努力达成一个衡量标准，而这就是所有混乱的根源。研究人员提出了许多想法和衡量方法。每种方法都有其优点和缺点。以下是一些使用的衡量方法：
- 麦凯布的复杂度测量。
- 亨利和卡弗拉的信息流。
- 哈尔斯特德复杂度测量。
- 代码行数（LOC）。
- 功能点。（我之前关于功能点的教程。）
- 用例点。
不要被上面提到的一些不熟悉的术语吓到，它们仅供知识参考。 McCabe复杂度、Henry和Kafura信息流、Halstead复杂度测量和LOC都有链接。我提到它们是因为它们是旧的测量技术。如果有人想深入研究，请参阅我的参考部分。本教程将重点介绍用例点方法论及其优缺点。因此，在本文中，我们将主要介绍用例点理论，然后通过一个实际用例示例来准备相应的报价。
首字母缩略词和缩写:
注意：请随身携带这些缩写，因为它们在整个教程中都会用到。不要被下面的缩写吓到。它们仅供参考，随着教程的深入，您将对它们的含义有更清晰的认识。
| 表1.0 | ||
| 缩写 | 全称 | 定义 |
| UCP | 用例点 | 用例点方法是一种基于用例文档的软件规模和估算方法。 |
| UAW | 未调整的参与者权重 | 在乘以系统的技术复杂性因子之前，对参与者进行分类并赋予其值后得到的数值总和。（当您学习如何计算UAW的步骤时，这一点会更清楚。） |
| UUCW | 未调整的用例权重 | 在乘以系统的技术复杂性因子之前，对用例进行分类并赋予其值后得到的数值总和。（当您学习如何计算UUCW的步骤时，这一点会更清楚。） |
| UUCP | 未调整的用例点 | UAW和UUCW的总和 |
| API | Application Programming Interface | 用于访问某些较低级别模块（如操作系统）提供的服务的应用程序。 |
| GUI | 图形用户界面 | 一种计算机终端界面，如Windows，它基于图形而不是文本。 |
| 用例事务 | 这是一组原子活动，要么全部执行，要么不执行。 | |
| Tfactor | 技术因子 | 所有技术因子的总和。有关更多详细信息，请参阅估算步骤。有关更多详细信息，请参阅表4.0。 |
| TCF | 技术复杂性因子 | 定义项目复杂性的因子。有关更多详细信息，请参阅UCP估算步骤。TCF是从Tfactor计算得出的。 |
| EF | 环境因子 | 这是一个乘数。 |
| AUCP | 已调整的用例点 | 这是乘以Efactor和Tfactor后得到的值。 |
| LOC | 代码行数 | 代码行数是一种衡量软件产品量的计数指标。 |
| OOP | 面向对象编程 | 一种编程技术，其中程序组件由称为对象的重用构建块组成。（词汇表） |
| UML | Unified Modeling Language | 代表统一建模语言。UML是一种用于分析现实世界对象、开发系统和以面向对象的方法设计软件模块的标准表示法和建模技术。UML由对象技术标准架构联盟（OMG）推动并被接受为标准。（定义来自此处） |
| UUCFP | 未调整的用例流程点 | 详细信息请参阅本文。 |
| FP | 功能点 | 一种基于软件功能的软件项目规模度量方法。 |
假设:
- 读者应具备编写用例的基本知识。本教程不涵盖用例，仅限于“用例”的估算。因此，如果您在阅读本文时对参与者、角色、场景没有清晰的概念，最好不要阅读。
- 用例结构因组织而异，这可能会严重影响估算。本教程使用了Alistair Cockburn在《有效用例编写》（**PRE-PUB. DRAFT#3**）中的模板：Alistair Cockburn 人与技术。
范围
本教程仅限于理解用例点，不深入探讨如何编写用例。本文不会集中讨论如何编写用例。互联网上有很多教程。此外，在本文的参考部分，提供了一个列表。
用例点历史和定义
1960年代后期，在爱立信工作时，Ivar Jacobson设计了用例文档。感谢Ivar Jacobson用用例文档这种出色的沟通方式。后来，用例文档成为UML的子集。1994年，Alistair Cockburn在为IBM咨询集团编写用例指南时，构建了“参与者和目标概念模型”。它为如何构建和编写用例提供了指导。这份文档不仅可以供程序员或架构师使用，也可以供利益相关者使用。它是在客户和程序员/架构师/业务分析师等之间的一份文档。当新程序员加入项目时，它也作为交接文件。用例文档也是软件设计的重要输入。简而言之，它在整个软件开发生命周期中都很有用。Karner发现这份文档还可以用于衡量和估算工作量。本教程将回顾Karner的工作，并提供一个简单的例子。那么，让我们从定义开始。
用例点是一种基于用例文档的软件规模和度量。“用例点”基于Gustav Karner在1993年的工作。这是他在林雪平大学完成的一篇毕业论文。这项工作是对Allen Albrecht的功能点工作的修改。
UCP（用例点）估算步骤
- 确定UAW（未调整的参与者权重）：第一步是将所有参与者分为以下几类。表2.0将清楚地说明如何分类参与者。第二列是判断参与者属于哪个类别的试金石。最后一列提供了复杂性因子。
表2.0
分类 用于识别分类的试金石 值/因子 简单参与者 简单参与者是通过API与系统通信的参与者。 1 平均参与者 如果平均参与者具有以下属性，则可以识别 - 通过某些协议（HTTP、FTP或可能是某些用户定义的协议）与系统交互的参与者。
- 参与者是数据存储（文件、RDBMS）。
2 复杂 复杂参与者通常通过GUI进行交互。 3 - 确定UUCW（未调整的用例权重）的数量：第二步是计算用例数，并根据场景数和事务数分配权重。
表3.0
用例类型 用于确定分类的试金石 值/因子 简单 大于或等于3个事务 5 Average 4到7个事务之间 10 复杂 大于7个事务 15 - 确定总UUCP（未调整的用例点）：总UUCP = 总UAW + 总UUCW。
- 计算技术和环境因子：最后一步是考虑技术复杂性。所有技术因子将根据复杂性从0到5进行赋值。
表4.0
技术因子 权重 描述 t1 分布式系统 2 系统是分布式架构还是集中式架构？ t2 响应时间 1 客户是否需要系统快速响应？响应时间是否是重要标准之一？ t3 终端用户效率 1 终端用户的效率如何？ t4 复杂的内部处理 1 业务流程是否非常复杂？例如复杂的账户结算、库存跟踪、高额税收计算等。 t5 可重用代码 1 我们是否打算保持高可重用性？这将增加设计复杂性。 t6 安装简易性 0.5 客户是否寻求安装简易性？默认情况下，我们有很多安装程序可以创建包。但客户可能正在寻找一些自定义安装，可能取决于模块。我们的一位客户要求，当客户想要安装时，他可以选择要安装的模块。是否需要在新版本发布时进行自动安装？这些因素在为该因子分配值时都会被考虑。 t7 易用性 0.5 用户友好性是否是首要任务？ t8 可移植 2 客户是否也在寻求跨平台实现？ t9 易于更改 1 客户是否寻求未来高度定制化？这也会增加架构设计复杂性，因此影响此因子。 t10 并发 1 客户是否需要大量用户进行锁定支持？这将增加架构复杂性，从而影响此值。 t11 安全目标 1 客户是否需要SSL等高级安全性？或者我们是否需要为加密编写自定义代码逻辑？ t12 直接访问第三方 1 项目是否依赖于使用第三方控件？理解第三方控件及其优缺点的过程中，需要花费大量精力。因此，应相应地对该因子进行评分。 t13 用户培训设施 1 从用户角度来看，软件是否过于复杂，需要提供单独的培训？因此，该因子会相应地变化。 - Tfactor的计算公式 = sum(T1....T13)
- TCF（技术复杂性因子）：TCF = 0.6 + (0.01 * Tfactor）。
- EF（环境因子）：还有其他因素，如训练有素的员工、程序员的积极性等，它们对成本估算有相当大的影响。
表5.0
环境因子 权重 描述 e1 项目熟悉度 1.5 1.5
项目中的所有人都熟悉项目的领域和技术细节吗？您可能会花很多时间向他们解释所有知识。
e2 应用程序经验 0.5 应用程序经验有多少？ e3 面向对象编程经验 1 由于用例文档是面向对象设计的输入，因此项目成员应具备OOP概念的基本知识非常重要。 e4 首席分析师能力 0.5 领导项目的分析师怎么样？他是否拥有足够的领域知识？ e5 动机 1 程序员是否对项目有积极性？项目的不稳定性总是会导致人们在中途离开他们的代码。而交接会变得非常困难。您可以根据软件行业的现状来设定此因子？例如，如果软件市场非常好，则将其设定为最大值。市场越好，工作机会越多，程序员跳槽的可能性越大。 e6 稳定的需求 2 客户是否清楚自己想要什么？我见过客户的期望是需求稳定最重要的因素。如果客户变化很大，则将此值设为最大。 e7 兼职员工 -1 项目中是否有兼职员工，如顾问等？ e8 困难的编程语言 -1 语言的复杂性如何，汇编、VB 6.0、C++、C等。 - Efactor = SUM(e1...e8)。
- 计算环境因子 = EF = 1.4 + (-0.03 * Efactor)。
- AUCP（已调整的用例点）。最后，计算已调整的用例点：AUCP = UUCP * TCF * EF
- 乘以人/小时因子：AUCP * 人/小时/AUCP。
Karner[13]建议项目估算中每个用例点需要20个工时。而Sharks则表示，现场经验表明，工作量可能在每用例点15到30小时之间。
Schneider和Winters提出，每用例点的人工时数取决于环境因素。将E1到E6中低于3的因子数量相加，再加上E7到E8中高于3的因子数量。如果总数为2或更少，则一般使用每UCP二十工时；如果总数为3或4，则使用每UCP二十八工时。如果数字超过5，通常建议对项目进行更改，以便调整数字，因为在这种情况下，风险是不可接受的高。另一种选择是将工时增加到每用例点三十六小时。
示例项目范围（示例数据录入项目）:
让我们从一个虚构的示例项目开始。这是项目的范围。TNC公司到目前为止一直使用手动方式维护其客户数据库和信用卡信息。数据录入操作员手动验证来自外部支付网关的信用卡信息。他们在客户注册表中维护客户代码、客户姓名、客户地址、客户电话以及已验证的客户信用卡信息。客户代码对客户是唯一的。因此，TNC手动检查验证并将信息录入客户注册表。TNC希望数据录入项目实现自动化。TNC正在寻求以下自动化：
- 自动检查分配的客户代码的唯一性。
- 客户代码长度不得超过8位。
- 信用卡验证对于当前系统应为自动。TNC已提供如何与第三方支付系统交互的API文档。
- 信用卡长度不得超过10位。
- 数据录入操作员应能够添加/更新/删除客户信息。
- 数据库将位于TNC总部，并且只允许数据录入操作员使用数据录入软件。
- 软件应在Windows平台上运行。目前，TNC的所有计算机都安装了Windows 2000客户端。
为示例数据录入项目编写用例
我使用了Alistair Cockburn的模板作为“用例点”的示例。用例模板因人、项目和组织而异。我发现Alistair的模板很完整，所以就用了。但是，并没有硬性规定您必须遵循此模板。重要的是您在用例中写入的步骤。
用例事务：这是一组原子活动，要么全部执行，要么不执行。什么是用例事务，什么不是：只需查看事务是否增加了业务价值，否则不要将其包含为事务。例如：用户打开计算机，用户点击添加按钮或任何GUI，都不是有效的业务事务步骤。但客户代码经过信用卡信息验证是一个有效的业务事务。用例点在很大程度上受到参与者及其事务识别方式的影响。因此，用例文档应在项目中使用预定义的指南，统一编写。在开始编写用例之前，先与整个项目团队开会。用例文档的深度将影响估算40%。
|
表6.0 | |
| 用例# | DATAENTRYPROJECTCUST-1009 |
| 用例名称 | 维护客户 |
| 描述 | 此用例描述了“数据录入”项目中的客户完整维护。 |
| 范围和级别 |
|
| 信号强度 | 用户目标级别（如果不理解此属性，请参考《有效用例编写》一书（**PRE-PUB. DRAFT#3**）：Alistair Cockburn 人与技术） |
| 主要和次要参与者 | 数据录入操作员。 |
| 利益相关者和利益 | |
| 触发器 | 数据录入操作员点击菜单：“添加新客户”。 |
| 前置条件 |
|
| 假设 | 收到的客户信息是手动输入的。范围内没有自动导入例程。 |
| 失败的结束条件 |
|
| 操作 | 添加新客户 |
| 主要成功场景（或基本流程） |
|
| 备用场景（扩展） | 更新现有客户
|
| 备用场景（扩展） | 删除现有客户
|
| 成功保证（后置条件） |
|
| 特殊要求（包括业务规则） | |
| 技术和数据变体列表 |
如果信用卡支付网关API发生变化，数据录入客户模块的交互也需要相应更改。 |
| 发生频率 | |
| 注释和未决问题 | |
应用用例点:
现在开始将用例点应用于上述文档。
- 确定未调整的用例参与者权重（UAW）：在此项目中，我们只识别了一个参与者“数据录入操作员”。上面的参与者（数据录入操作员）是复杂的，因为数据录入操作员将通过GUI进行交互。因此，根据表2.0，UAW=3。
- 确定UUCW（未调整的用例权重）的数量：表6.0用例中有12个事务[包括备用流程]。因此，根据表3.0，上述用例是复杂的。参考表3.0，UUCW=15。
- 现在计算总UUCP = 15 + 3 = 18。
- 确定技术因子
表7.0
技术因子 权重 值 加权值 解释 t1 分布式系统 2 1 2 决定采用简单的两层架构。 t2 响应时间 1 4 4 速度很重要，因为数据录入操作员需要快速输入数据。 t3 终端用户效率 1 3 3 数据录入操作员用户效率很高。 t4 复杂的内部处理 1 2 2 这是一个简单的输入屏幕，客户没有规定任何业务流程。只有信用卡检查和重复客户代码是业务检查。 t5 可重用代码 1 1 1 由于项目规模小，客户在未来两年内不打算进行任何更改，因此没有可重用性。 t6 安装简易性 0.5 0 0 TNC拥有良好的内部开发团队，安装问题将由他们处理。技术上考虑使用C#，.NET安装向导足以使安装过程变得简单。 t7 易用性 0.5 4 2 是的，数据录入操作员需要有用户友好的菜单和快捷键以快速输入数据。 t8 可移植 2 1 2 TNC拥有Windows 2000客户端，如范围文档中所述。 t9 易于更改 1 0 0 客户未指定。 t10 并发 1 0 0 客户在范围文档中没有明确说明此问题。因此，假设并发量最低。 t11 安全目标 1 0 0 客户未指定。甚至信用卡信息也会在没有加密的情况下通过。 t12 直接访问第三方 1 3 3 使用信用卡检查API。 t13 用户培训设施 1 0 0 屏幕很简单，数据录入操作员无需任何培训即可操作。 总计 19
- 根据表格，计算技术因子：TCF = 0.6 + (0.01 * Tfactor) = 0.6 + (0.01 * 19) = 0.79
- 计算环境因子
表8.0
环境因子 值 权重 加权列 对所分配值的解释 e1 项目熟悉度 5 1.5 7.5 这是一个简单的项目，因此对项目的熟悉度不是那么重要。 e2 应用程序经验 5 0.5 2.5 这是一个简单的应用程序。 e3 面向对象编程经验 5 1 5 每个人都有良好的OOP知识。 e4 首席分析师能力 5 0.5 2.5 这是一个简单的项目；到目前为止不需要首席分析师。 e5 动机 1 1 1 程序员因项目的简单性而不愿从事该项目，因此积极性略有下降。 e6 稳定的需求 4 2 8 客户对自己的需求非常清楚？ e7 兼职员工 0 -1 0 没有兼职员工。 e8 困难的编程语言。 3 -1 -3 将使用C#。大多数程序员对C#和.NET技术不熟悉。 - 根据[Kirsten Ribu硕士论文]，环境因子在估算中起着非常重要的作用。一点点变化就会导致用例点急剧增加。即使是环境因子的微小调整，例如半点，也可能对估算产生巨大影响。3到2.5的差异将估算值增加了4580小时，从10831小时增加到15411小时，即42.3％。这意味着如果环境因子的值设置不正确，可能会导致灾难性的结果——来源[Kirsten Ribu硕士论文]。请参阅下面的链接。
- 使用公式计算EF = 1.4 + (-0.03 * Efactor) = 1.4 + (-0.03 * 23.5) = 0.695。
- 计算AUCP = UUCP * TCF * EF = 18 X 0.79 X 0.695 = 9.88，约等于10个用例点。我进行了近似计算，因为它只会造成3到4小时的差异。
- 根据Karner的计算，即每用例点20个工时 = 10 X 20 = 200小时用于整个项目。
- 如果程序员每天工作8小时，则340/8 = 25天。
- 根据Schneider和Winters的计算，e1到e6中有3个属性低于3。e7到e8中没有一个值高于3。所以总数为3。我们使用28个工时。10 X 28 = 280小时。如果程序员工作8小时，则35天。如果此步骤不理解，请参阅用例点理论中定义的步骤。
如果我们运用第六感，会发现Karner的方法得出的结果比较接近。这取决于您想遵循Karner还是Schneider的方法。最好的方法是在两到三个项目之后，根据历史数据中的准确性来选择方法。最好的方法是使用Excel并正确地输入公式。
最终报价:
所以，这是针对给定范围和用例文档的最终报价。
|
表9.0 | ||||
|
XYZ软件公司 | ||||
|
改为 | ||||
| 数量 | 描述 | 折扣 | 应税 | 总计 |
| 1 | 数据录入模块 | 0% | 0% | $840 |
| 报价有效期100天 货物交付日期为付款一半后25天内 报价由：XYZ估算部门准备 批准人：XYZ SPEG部门 | ||||
在此报价中，我采用了Karner的值，即25天。一位程序员将参与该项目，薪资约为1000美元。因此，他25天的工资约为840美元。上面的报价格式是最简单的格式。每家公司都有自己的报价格式。所以报价模板没有硬性规定。但如果您仍然感兴趣，Microsoft提供了一个不错的精美模板集合。
用例结构很重要:
用例的结构很重要。根据（Bente Anda、Hege Dreiem、Dag I.K Sjoberg和Magne Jorgensen）的说法，结构的以下方面会产生影响：
- 参与者之间的泛化使用：如果两个参与者有80%的共同点，将它们置于泛化关系中，并只计算一次。这将提高估算的准确性。
- 包含和扩展用例的使用：Karner建议不计算包含和扩展用例。但Bente Anda、Hege Dreiem、Dag I.K Sjoberg和Magne Jorgensen在他们的实践经验中持不同意见。在某些用例中，他们发现包含和扩展用例是关键功能，减少它们将减少步骤，从而影响估算。
- 用例描述的详细程度（这取决于编写用例的人）：用例的详细程度和事务数量对用例估算影响很大。如果您查看上面的用例，我写了用户打开PC等步骤。事务数量会增加，从而增加估算。因此，如果该事务步骤没有增加业务价值，则不要将其作为事务步骤。这也会在很大程度上增加估算。
除了Karner和（Bente Anda、Hege Dreiem、Dag I.K Sjoberg和Magne Jorgensen）的上述建议外，我还提供了以下可用于改进估算的方法：
- 用例拆分与合并：简单的用例主数据很重要。编写用例，例如“添加国家主数据”。用户可以为添加、更新、删除编写三个不同的用例；或者可以编写一个用例，并将更新和删除放在备用场景中。如果更新和删除没有不同的业务验证，则将它们放在一个用例中。在我计数时，我发现对于简单的主数据，将它们放在一个用例中可以提高准确性。
使用用例点的优势
- 自动化：如果用例文档为公司（统一）结构化，我们可以使用自动化工具。在FP的情况下，这很难。
使用用例点的劣势
- 不能在初始阶段使用：估算通常在项目早期进行。当我说早期时，意思是与客户进行第一次和第二次会议期间。用例文档通常在项目签署完成后准备。因此，在早期阶段，如果没有获得项目，准备用例文档意味着浪费资源。对于项目初始阶段，您可以使用“功能点”。对于功能点，不需要正式文档。我之前关于功能点的教程。
- 没有标准的用例文档：用例的文档结构仍然不标准。它不仅因公司而异，也因项目而异。因此，估算会根据用例文档的结构产生显著的差异。写作本身也很重要。同样，如何识别用例及其相关事务也很重要。自由的文本描述可能导致模糊的规范[AP98]。
- 维护估算问题：功能点[文章]在维护项目上失败了。用例点很难进行维护估算。
- 参与者识别需要技术细节：为了对参与者进行分类，我们需要了解技术细节，例如参与者将使用哪个协议。因此，估算可以由技术人员进行。FP不依赖技术[文章]。
其他一般实用因素
以下几点与用例本身无关，但与一般估算相关：
- 心态改变：估算师不应有偏见。如果您是公司员工，请不要增加额外费用或减少额外费用。这些事情将在软件公司董事和客户之间的谈判桌上处理。估算师的工作是向公司展示软件的实际成本。简而言之，估算师不应关心谈判阶段以及公司是否能获得该项目？将这项工作留给公司董事。如果您是公司董事，请在估算完成后再考虑这个问题。
- 第六感方法：任何软件度量方式（用例、功能点、LOC等）都在不断发展和实践中。在看到数字后，根据您的过往经验给出第六感。有时，采用临时的估算方式也会比较公平。
- 模块化估算：在拥有数百个模块的庞大项目中，最好按模块进行估算。例如，如果客户要求一个客户模块、一个供应商模块和一个账户模块，请分别估算它们，以便在与客户谈判时，您可以向他展示完整的细分。其次，这种方法对分阶段估算非常有用。客户可以决定（由于财务原因）不选择某个模块，或者将其移至后续阶段。
- 信息蔓延和灰色地带：估算通常在项目初期进行。可能只与客户会面一两次，我们就必须给出估算。但自然，在许多领域都可能存在蔓延。处理这种情况的最佳方法是考虑最大可能性并进行估算。例如，如果客户说他需要一个聊天模块，但没有明确说明其深度，则应估算聊天应用程序可能实现的最大可能性。之后在谈判桌上，向客户展示估算基础。因此，根据客户的财务预算，将进行相应的调整。
- 其他成本：没有一种软件估算方法能够给出非软件因素的成本。
- 如果软件使用了任何第三方组件，例如Crystal Reports等，请以临时方式估算它们。
- 例如，如果项目中公司还提供网络托管、域名、硬件等，请单独列出。
- 如果涉及任何培训，请单独估算。
- 假设：由于估算是在初始阶段进行的，因此可能存在很多蔓延和灰色地带。灰色地带的估算必须有适当的假设支持。
- 第三方审查：在将成本发送给客户之前，请在内部请一位未参与项目的第三方进行审查。
- 迭代：在各个阶段尽可能多次地迭代。例如，在范围界定阶段（即初始阶段）使用功能点进行迭代，在系统需求阶段使用用例点。这可以在实施之前很好地了解成本是否合理。
- 两支团队估算：在估算过程中，让两支团队进行估算。这样就可以对估算的错误率进行交叉验证。
参考文献
如果我说整篇文章都是我自己的智慧，那将是自私的。因此，我提供了准备这篇文章所参考的所有链接。如果任何链接侵犯版权且不得转载，请发送电子邮件至shiv_koirala@yahoo.com。我将尽我最大的努力来保护版权。
- 我目前在Ag-technologies工作。感谢www.ag-technologies.com为我在估算阶段提供了职位。
- 基于行业用例经验的估算软件开发工作量（Bente Anda、Hege Dreiem、Dag I.K Sjoberg和Magne Jorgensen）
- 用例点.
- 用例点.
- 有效用例编写（**PRE-PUB. DRAFT#3**）：Alistair Cockburn 人与技术。
- 引言字典义.
- 如果您正在考虑使用用例点进行测试工作量估算，请查阅Cognizant Technology Solutions在2001年Quality Week，加利福尼亚州旧金山，2001年6月，Suresh Nageswaran撰写的论文。
- 在本文中，他们尝试使用UUCFP（未调整的用例流程点）来提高准确性。作者：Gautam Banerjee（2004年IPML年会）
- 在Microsoft上可获得出色的报价模板。
- 模板。不一定完全遵循，仅供参考。
- 使用用例点进行估算
- http://heim.ifi.uio.no/~kribu/oppgave.pdf
- UML基础.
- 我之前的功能点教程.
- 国际功能点用户组.
- 功能点分析入门.
- 一篇很好的PDF教程.
- 硕士论文，作者：Sofia Nystedt。
- 这是一篇很好的论文，其中详细介绍了McCabe复杂度、Henry和Kafura的信息流以及Halstead复杂度测量。
- UML定义.
- 面向对象编程定义.
最后的话
多年来，软件行业一直在进行最佳估算的“战争”。我在这篇文章中并不是说用例点是最佳的估算方式。因此，您会发现我介绍了优缺点部分。但毫无疑问，我们必须进行衡量。总有一天，我们必须统一一种通用的测量原则。如果我们在现实生活中可以说，城市“xyz”距离100公里，为什么我们不能说这个项目是1000复杂度，200功能点或650用例点？不同的语言、不同的编译器、公司遵循的不同流程使得达成共识和通用测量变得困难。但我们看到的最大的障碍是软件公司愿意达成关于如何衡量的共识的态度。如果软件可以自动化人类的复杂性，那么软件测量也可以自动化。
“我们不应该再问是否应该衡量，今天的问题是如何衡量？” - Dieter Rombach Eurometrics 1991
“不要报太低价，让程序员加班，你会失去项目，或者做社会服务，或者亏本。不要报太高价，你会失去项目。对自己和客户都要公平。”
Shivprasad Koirala。给我发邮件至shiv_koirala@yahoo.com。